Trekkie is Shopify's own internal analytics loader. When a Facebook Pixel ID is entered in Shopify's native Facebook & Instagram sales channel or the legacy Online Store preferences field, Trekkie fires that pixel ID itself, entirely separately from any pixel added manually via a custom pixel, theme code, or GTM. The result is the same pixel ID - or two different ones - firing twice for the same visitor and order, because Shopify does not de-duplicate across its own integration points.
Why this happens
Shopify integrates Facebook Pixel in more than one place at once: the Online Store > Preferences legacy pixel field, the Facebook & Instagram sales channel app, and whatever a merchant or developer has hand-added via a custom pixel or (pre-migration) theme code and Additional Scripts. Each of these is a completely independent integration point - none of them checks whether another one is already sending the same event.
Trekkie itself is not a rogue script; it's simply Shopify's own event bus, and it happens to also carry the pixel ID a merchant configured through the admin UI. So what looks like "Shopify is injecting a mystery pixel" is almost always "Shopify is correctly firing the pixel you told it about in the admin, in addition to the one you also hand-coded and forgot was still there."
Fix it
- Audit every integration point: Settings > Customer events (custom pixels), the Facebook & Instagram sales channel app, Online Store > Preferences legacy pixel field, and theme code or Additional Scripts if the store predates Checkout Extensibility.
- Pick exactly one source of truth for the pixel. The Facebook & Instagram sales channel app is the recommended default - it's Meta-maintained and ships with Conversions API (CAPI) support and event_id deduplication built in.
- Remove the pixel ID or manual pixel code from every other location you found in step 1.
- If you deliberately need a second, distinct pixel (for example an agency's own ad account) running alongside Shopify's native one, set the same event_id value on both the browser pixel event and the matching CAPI event for that specific pixel ID - Meta's own deduplication collapses same-source duplicates when the event_id matches.
- Understand what event_id dedup cannot do: it only collapses duplicates within one pixel ID. Two genuinely different pixel IDs both receiving a Purchase event for the same order is not a bug to de-dupe - it's two ad accounts each getting the same signal, which needs a business decision about which pixel belongs to which relationship, not a technical dedup.
Branch: if the duplicate is between two different pixel IDs rather than one ID firing twice, the fix in step 4 doesn't apply - go back to step 2 and remove one of the two pixel relationships entirely, since both are legitimately configured and Meta has no way to know they should be treated as the same event.
How to verify it worked
Install the Meta Pixel Helper browser extension and open it on your storefront and at checkout completion - it lists every pixel ID firing on the page and flags duplicate PageView/Purchase events per ID. Separately, open Meta Events Manager > Test Events for each pixel ID individually, place one test order, and confirm exactly one Purchase event appears per pixel ID with the correct value. If the same pixel ID still shows two Purchase rows for a single order, the event_id dedup from step 4 isn't wired correctly yet and needs rechecking before you call this fixed.