There is no native Shopify-to-Mixpanel integration, so the reliable architecture is server-side: use a Shopify Admin API webhook on orders/paid to push order data to a small endpoint that calls Mixpanel's ingestion API with a stable distinct_id and an idempotency key set to the Shopify order id. Pair it with a lighter client-side Mixpanel pixel for pre-purchase funnel events, and merge the two identities once you have an email.
Why this happens
Mixpanel is built around a distinct_id-keyed event stream, the way a logged-in SaaS product naturally has one - but most Shopify shoppers check out as guests, so there's no pre-authenticated user id to key events on. A purely client-side integration (loading the Mixpanel JS SDK inside a custom pixel) can capture events fine, but struggles to consistently link a pre-purchase anonymous session to the resulting order, and inherits the same sandbox restrictions and browser-side signal loss - ad blockers, ITP, consent declines - that every client-side pixel on this site's other QA pages runs into.
Fix it
- Client-side, for funnel shape: load the Mixpanel JS SDK inside a custom pixel (Settings > Customer events > Add custom pixel) and call
mixpanel.identify()/mixpanel.track()onpage_viewed,product_viewed,product_added_to_cart, andcheckout_started. Use Mixpanel's anonymous distinct id here - exact identity match matters less than funnel shape at this stage. - Server-side, for order truth: register an Admin API webhook subscription for
orders/paid(fires once payment is actually captured, avoiding abandoned or unpaid checkouts) pointing at an endpoint you control. - In the webhook handler, extract the customer's email (or a hashed customer id) and the order data, then call Mixpanel's ingestion API server-side with
$insert_idset to the Shopify order id - this makes the call idempotent. Shopify retries webhooks on any non-2xx response, so without an idempotency key a retried webhook will double-count the order. - Merge identities using Mixpanel's identity-merge functionality to connect the anonymous pre-purchase distinct id (captured client-side) to the authenticated, email-based id used server-side - trigger this the moment you have an email, typically at
checkout_startedor in the webhook handler itself. Without this step, Mixpanel sees a disconnected anonymous browsing funnel and a separate "purchase" event rather than one continuous journey. - Validate webhook signatures: Shopify signs every webhook with an HMAC header - verify it before processing, and return a 2xx response quickly (queue any heavier work asynchronously) so Shopify doesn't retry-storm the endpoint, which combined with a missing idempotency key is the most common cause of Mixpanel showing more orders than Shopify actually has.
Branch: if you only care about post-purchase reporting (not a full pre-purchase funnel in Mixpanel), you can skip the client-side pixel entirely and run the server-side webhook alone - simpler, and it sidesteps every browser-side loss issue, at the cost of not seeing browse/cart abandonment behavior in Mixpanel.
How to verify it worked
In Shopify admin, go to Settings > Notifications > Webhooks and confirm the orders/paid subscription is active, then check its recent delivery log for 2xx responses. In Mixpanel, open Live View (or the Events explorer filtered to the last few minutes) after placing one real or test-mode order, and confirm exactly one order-completed event appears with the correct order id and value - and that it's merged onto the same profile as the pre-purchase checkout_started event rather than showing up as a second, disconnected user.