# What is a first-party pixel? > Why Ordinary uses a first-party pixel instead of the traditional Meta/Google pixel and what that means for the data quality you see in reports. Source: https://help.tryordinary.com/concepts/first-party-pixel --- Short version: a pixel that runs on **your Shopify domain** and reports **to us** instead of running on Meta's / Google's infrastructure and reporting to them. It's more reliable, more accurate, and not blocked by ad-blockers or iOS privacy changes. ## The problem with traditional pixels Meta's pixel, Google's tag, and most other ad-platform pixels are **third-party**: - They load from `connect.facebook.net` or `googletagmanager.com`. - The browser treats them as third-party scripts. - iOS 14.5+ blocks third-party tracking by default. - ~30% of visitors run ad-blockers that block these domains outright. - Browser cookies set by these pixels expire after 7-30 days under Safari ITP and similar Firefox/Chrome rules. Net effect: your Meta pixel sees ~60-80% of your real traffic and under-reports conversions by an equal margin. Most brands have learned to not fully trust their ad-platform numbers. ## How a first-party pixel is different Ordinary's pixel: - Runs via **Shopify's Customer Events extension** — loaded by Shopify's own infrastructure, first-party to your store domain. - Not blocked by ad-blockers (the URL is your own shop, not a known tracker). - Not subject to iOS 14.5 third-party restrictions. - Cookies are first-party, so they persist for the browser's normal retention period (not the shortened third-party window). Result: materially more session coverage than a traditional third-party pixel can capture — and a cleaner view of your data since it isn't subject to platform reporting quirks. ## What the pixel captures - Page views (generic page URL + referrer + UTM chain) - Product views (which SKU was viewed) - Collection views - Onsite search queries (the term typed into the storefront search bar) - Add-to-cart (which SKU + variant, quantity, price) - Cart views - Checkout started - Payment info submitted - Checkout completed (with order ID linking back to Shopify) - Storefront alerts (out-of-stock messages, payment-declined notices, shipping-rate errors — the kinds of messages that indicate checkout friction) - App-extension errors (when a third-party checkout extension fails; helps diagnose app reliability issues affecting your conversions) Each event is tagged so that repeat visits from the same browser are recognized as part of one journey instead of a string of disconnected sessions. ## Bot traffic filtering Not every event the pixel captures comes from a real shopper. Search engine crawlers (Googlebot, Bingbot), AI scrapers (GPTBot, ClaudeBot, PerplexityBot), SEO tools (AhrefsBot, SemrushBot), social link unfurl previews, uptime monitors, and disguised crawlers all fire pixel events as they browse your store. Ordinary classifies these as **bot traffic** and excludes them from session, visitor, and funnel reports — so your headline numbers reflect what real humans actually did. See [how bot traffic filtering works](https://help.tryordinary.com/concepts/bot-traffic-filtering) for the full picture of what we exclude and why. ## What the pixel doesn't capture - **Logged-in customer identity** unless Shopify's Customer Events API provides it. When Shopify tells us which customer just placed an order, we link their prior anonymous browsing to their profile. Before that link happens, their activity is tracked anonymously. - **Activity on other sites** — we only see what happens on your store. UTMs tell us where they came from; they don't let us follow them elsewhere. - **Offline purchases** — in-store POS, phone orders, B2B invoicing. Those hit Shopify's order webhook but have no pixel session attached. - **Pre-purchase browsing for shoppers on aggressive privacy browsers who don't end up buying.** A small slice of visitors use browsers (Brave with default shields, Safari with strict tracking protection, iOS content blockers) that block our pixel from running on their device. We pair the pixel with two recovery layers — a first-party beacon path that defeats most cross-origin tracker blocking, and a server-side reconstruction of the conversion event for shoppers who do buy — but pre-purchase browse activity (page views, product views) for blocked-browser shoppers who never complete an order is genuinely uncapturable. We don't fabricate it. ## What we still capture for blocked-browser shoppers who buy For an order from a shopper whose browser blocked our pixel entirely, we reconstruct the conversion record server-side from Shopify's order webhook (which is server-to-server and unaffected by browser blocking) and Shopify's own customer-journey data. So the merchant gets: - The order in their reports - Accurate revenue attribution - Real channel attribution (e.g. "Paid Social", not the catch-all "Direct" bucket) - Proper product / SKU / discount-code attribution What's missing for these orders: the pre-purchase funnel (which products were viewed, how long the visitor browsed, etc.) — there's no server-side equivalent for that data. ## How Ordinary compares against Meta's own numbers You'll typically see: - **Ordinary's sessions > Meta pixel's** on your store (better coverage). - **Ordinary's orders ≈ Shopify's** (we read from Shopify's webhook, which is authoritative). - **Ordinary's ROAS < Meta's reported ROAS** (Meta includes view-through + cross-device stitching that inflates their numbers). Meta's reporting is useful for relative campaign performance. Ordinary is useful for absolute revenue truth and first-party attribution. ## Checking your Meta CAPI match quality If you also have the Meta Conversions API connected, the **Meta CAPI** card on Settings shows an **Aggregated Event Measurement (AEM) priority** diagnostic. AEM is Meta's iOS-14+ mechanism that prioritises a small ranked list of conversion events per pixel — mis-prioritised events can silently degrade ad delivery. The diagnostic surfaces: - The current ranked list of events Meta is using to optimise your campaigns - Whether `Purchase` is at position 1 (it should be — that's where the revenue signal lives) - Whether the events Ordinary is sending match the ones Meta has prioritised, so you don't end up paying for impressions on events Meta isn't actually counting If anything looks off, the card links to the relevant page in your Meta Events Manager so you can rerank without leaving the context. ## What if I still want to run a Meta pixel? You can. Ordinary's pixel doesn't conflict with Meta's; they're on different infrastructures. Most brands keep their Meta pixel for the downstream benefit (Meta's ad optimization uses it) and treat Ordinary as the source of truth for reporting. ## Optional: CNAME first-party forwarding (recover the last ~3-4%) Even with our Shopify Customer Events pixel, the events your visitors fire have to POST to *somewhere*. By default that destination is `app.tryordinary.com` — which the browser treats as a third-party domain relative to your storefront. Safari ITP, Brave Shields, uBlock Origin, and aggressive content-blockers strip or drop those POSTs. You can close that gap by configuring CNAME forwarding in Settings → First-Party Pixel. We give you a hostname like `i..com` that points at Ordinary. Once you add the CNAME record at your DNS provider and we verify the record is live, your storefront pixel POSTs events to *your own subdomain*. The browser sees same-site requests and stops blocking them. Setup is a single CNAME record at your DNS host: ``` Type: CNAME Name: i Value: TTL: 3600 ``` (Use whatever subdomain you prefer — `i` is the convention; `track` or `pixel` also work as long as you control that subdomain.) We auto-provision a TLS certificate within ~30 seconds of DNS propagating. Status updates live in the Settings card. You can revoke at any time and the pixel falls back to the standard `app.tryordinary.com` route — no broken state in between. What's identical with vs without forwarding: the data we collect, how long we keep it, who processes it, our role as your data processor. Only the network route changes — events flow `your-storefront → your-cname-subdomain → Ordinary` instead of `your-storefront → Ordinary` directly. From your end-customers' perspective there's nothing visibly different. What you get with it: closer to ~99% session capture in environments where ad-blockers / Safari ITP / Brave Shields would otherwise drop the third-party POST. Most useful for brands with high iOS / Brave / privacy-focused-browser traffic shares. What if your storefront is `*.myshopify.com` only (no custom domain)? You can't add a CNAME under `myshopify.com` (Shopify owns that zone). Skip CNAME forwarding for now — it's only useful once you bring your own domain. ## Related articles - [Customer Events pixel extension](https://help.tryordinary.com/integrations/customer-events-pixel) — how the pixel gets installed. - [Pixel says "Disconnected"](https://help.tryordinary.com/troubleshooting/pixel-disconnected) - [Attribution numbers don't match Shopify](https://help.tryordinary.com/troubleshooting/attribution-mismatch) - [How bot traffic filtering works](https://help.tryordinary.com/concepts/bot-traffic-filtering)