Pixel & event pipeline

Audience: Merchant·Plan: starter·Read: 7 min·Updated: 2026-08-03

In 30 seconds

• The Web Pixel captures storefront behaviour — views, add-to-carts, checkouts, purchases — which feeds funnels, attribution, cart recovery and journey triggers.
• The ops console separates two questions that used to have the same symptom: is it installed? and is it delivering?
• Back-pressure is priority-aware. Under load, low-value events are shed first; money events are never shed.
• Failed events are retained with their payload and can be replayed through the live ingest path once the cause is fixed.
• Pixel data is treated as untrusted input — anomaly detection flags forged or implausible traffic, and pixel data alone never moves money.

What the pipeline feeds

If the pixel is not delivering, all four downstream surfaces are quietly empty or wrong. That is why it has an ops console of its own.

Installed is not the same as delivering

This is the distinction the console exists for.

Question	Answered by
Is the pixel installed?	Shopify, authoritatively
Is it delivering?	Rows landing, and failures not accumulating

A dead pixel, a rejected relay key, a stale endpoint, a schema mismatch and a genuinely quiet Tuesday all produce the identical observable: an empty table. Separating the two questions is what turns "the analytics look low" into a specific, actionable answer.

The health view shows:

Signal	What it tells you
Installed	Whether the pixel is on your storefront, from Shopify
Last event	When data last arrived
Failure ratio	The share of events that failed to ingest in the window
Event mix	Which event types are arriving, and which are not

Back-pressure that knows what matters

Admission control is per store and priority-aware.

Why a flat rate limit was actively harmful here

The pixel uses sendBeacon, which is fire-and-forget: the browser never retries. A rejected event is gone permanently.

A flat limit of 100 events per minute meant a store running a flash sale — 500 concurrent shoppers, the single most valuable hour of its year — exhausted the budget in seconds and silently lost checkout data. The analytics under-reported precisely when accuracy mattered most, and nothing surfaced that it had happened.

Under load, events are shed by priority. Critical money events — checkout and purchase — are never shed. The console states plainly what is being shed at the current load, rather than leaving you to infer it from a gap in the funnel.

The failure queue and replay

Every failed or rejected event is stored with its full payload.

When the cause is fixed — a rotated key, a corrected endpoint, a schema change — the failed events can be replayed back through the same ingest path live traffic uses. Replaying through the real path rather than a bespoke re-writer is deliberate: a separate path drifts from production semantics and silently produces differently shaped rows.

The console groups failures by reason, so you fix a cause rather than replaying blindly.

Anomaly detection

The relay authenticates with a key embedded in the Web Pixel's settings, and those settings are delivered to the browser. The key is therefore readable by anyone who inspects your storefront.

This is not a fixable implementation flaw. sendBeacon cannot set headers, so request signing is impossible from the pixel sandbox, and any secret shipped to a browser is public.

The correct posture is not "make the pixel trustworthy" but "never let pixel data alone move money". Two rules follow:

1. Money is confirmed server-side. Orders and revenue come from Shopify's own order data, not from a browser event.
2. Implausible traffic is flagged. The anomaly detector surfaces forged or improbable event patterns rather than folding them into your funnel.

Consent

Events carry the visitor's consent state where the storefront provides one. Consent handling is configured alongside your wider privacy settings — see GDPR & consent for how consent flows through the platform.

Who can see the console

The pixel ops console is gated on settings permissions — read to view, update to replay or change configuration. It is an operations surface rather than a daily analytics view.

Plan tiers

Capability	Free	Starter	Pro	Agency	Enterprise
Web Pixel event capture	✓	✓	✓	✓	✓
Funnel and attribution from events	—	✓	✓	✓	✓
Ingest health console	—	✓	✓	✓	✓
Priority back-pressure	✓	✓	✓	✓	✓
Failure queue and replay	—	—	✓	✓	✓
Anomaly detection	—	—	✓	✓	✓

Best practices

• Check the console after any theme change. A theme update is the most common way a pixel stops delivering.
• Investigate a rising failure ratio immediately. Events are not retried by the browser; every minute of a broken pipeline is data you will not get back unless it reached the failure queue.
• Replay after fixing, not before. Replaying into a still-broken pipeline just moves the rows from one failure batch to another.
• Do not reconcile revenue against pixel events. Use order data. The pixel tells you about behaviour; Shopify tells you about money.
• Expect a gap at high traffic. Shedding is a designed behaviour, and the console tells you what was shed.

See also

• Attribution & revenue — what the events feed
• Command centre & dashboards — where funnel data surfaces
• GDPR & consent — consent handling
• Pixel integration (developer docs) — the developer reference for custom events