Control which sites can send events to your pixel, and avoid the silent event drop that comes from a too-narrow list.
If your event count looks stuck, or "last event" won't update even though the site is live, a misconfigured allowlist is one of the more common causes. This article explains what the allowlist does, how matching works, and why a bad entry fails silently instead of throwing an error.
The allowlist controls which sites are allowed to send events to your pixel. It lives on the Tracking settings page, under Allowed domains. You add domains one per line or comma-separated.
An empty list accepts events from any domain. This is the default, and it's not a "deny all" state — it's the opposite. Most workspaces never need to touch this list at all; it exists for merchants who want to lock a pixel down to their own domains.
An entry matches itself and any subdomain. Add example.com and it also covers shop.example.com, checkout.example.com, and so on. You don't need to list every subdomain separately.
A leading www. is stripped on both sides before comparing, so www.example.com and example.com behave the same way in the list.
When you save, each entry is cleaned up automatically:
https://shop.example.com/checkout still saves as shop.example.com.The list holds at most 20 entries. If you're tracking a large number of separate storefronts under one pixel, list their shared parent domains instead of every individual subdomain.
This is the part worth understanding before you touch the list. When the allowlist is non-empty, an incoming event is checked against it. If the event's origin doesn't match — or the request arrives with neither a Referer nor an Origin header at all — the request is dropped. It still returns success to the browser. No event is stored, but nothing errors either.
That means the failure mode isn't a visible one. You won't see a console error on the storefront and you won't see a failed request anywhere in your own tools. What you'll actually notice is:
If you add only www.shop.com and forget that checkout runs on checkout.shop.com, or that your storefront's real origin is slightly different from what you typed, events from the missed origin just vanish. There's no error to chase — the counter going quiet is the symptom.
The fix is to widen the list to cover every origin that legitimately loads the pixel, or clear it entirely to accept any domain.
If you serve the pixel from your own subdomain (see Serve the pixel from your own domain), saving that custom domain automatically adds its parent registrable domain to the allowlist — for example, setting up px.shop.com adds shop.com. This happens because the beacon still originates from the shop's own pages, so that domain needs to be allowed once any allowlist exists.
One thing to know: if you later remove the custom domain, that auto-added allowlist entry is left in place rather than removed automatically. Removing it silently could drop events from a domain you're still relying on, so it's left for you to prune by hand if it's no longer needed.
Editing the allowlist requires workspace admin access. Anyone else on the workspace sees the list as read-only.
If your counter has already gone stale, start with The pixel shows no events — the allowlist is one of several checks in that list.