Mixpanel

info

This is a pro feature. Get the pro version here

Mixpanel is a product analytics platform. It is built around events and the people who trigger them, which makes it strong at funnels, retention and cohort analysis. Once a project token is configured, the Pixel Manager loads the Mixpanel JavaScript SDK and sends the whole shopping funnel to Mixpanel automatically.

Mixpanel does not prescribe an e-commerce schema, so the Pixel Manager follows Mixpanel's own naming convention: Title Case event names in the past tense, such as Product Viewed and Order Completed, and snake_case property names.

Setup

1. Open Mixpanel: https://mixpanel.com/

2. Browse to Settings > Project Settings

3. Copy the Project Token. It is a 32 character hexadecimal string that looks similar to this: a1b2c3d4e5f60718293a4b5c6d7e8f90

4. In the Pixel Manager, open Tracking Pixels → Mixpanel, paste the token into the Project Token field, and save.

That's it. There is no need to add the Mixpanel snippet or any event code to your site. The Pixel Manager loads the SDK and sends the events automatically.

Data residency

Mixpanel hosts projects in three regions: the United States (the default), the European Union and India. Each region has its own API host, and Mixpanel does not ingest events that are sent to the wrong region. It does not report an error either, so a mismatch looks exactly like a shop with no traffic.

Check which region your project lives in by looking at the Mixpanel URL:

Mixpanel URL starts with	Region
mixpanel.com	United States
eu.mixpanel.com	European Union
in.mixpanel.com	India

Select the matching region in the Data Residency setting in the Mixpanel advanced settings section of the Pixel Manager. It routes both the browser SDK and the server-side events to the right host.

Ingestion API

The Ingestion API is an optional addition that reports purchases to Mixpanel server-side, through Mixpanel's /track endpoint. It has two advantages over browser-side reporting:

• Purchases that ad blockers or browser restrictions keep from the browser still reach Mixpanel. Purchases are triggered directly by WooCommerce order events, so they are also tracked when the customer never returns to the order confirmation page.
• Refunds are reported as well. A refund happens in the WooCommerce backend, long after the customer has left, so the browser never sees it. Without the Ingestion API, Mixpanel keeps counting revenue that was given back.

No additional credential is needed: Mixpanel authenticates /track with the project token, which the Pixel Manager already has.

You can enable the Ingestion API in the Mixpanel advanced settings section of the Pixel Manager.

Purchases are reported once, not twice

With the Ingestion API enabled, the purchase is reported server-side only and the browser stops sending it. This is deliberate. Mixpanel treats two events as duplicates only when the event name, the distinct_id, the timestamp and the $insert_id all match, and the server cannot guarantee the same timestamp as the browser, so reporting from both sides would count every order twice.

The server-side event is the better of the two anyway: it carries the final order totals, and it is the only one that can report refunds.

One customer, not two

Mixpanel identity lives in the browser: the SDK assigns a distinct_id and stores it in a first-party cookie. A server-side purchase that does not know that ID would land on a separate anonymous Mixpanel user, and every funnel that ends in a purchase would break.

The Pixel Manager therefore reads the distinct_id out of Mixpanel's own cookie while the customer is checking out and stamps it onto the order, so the server-side purchase joins the same Mixpanel user as the visitor's funnel events. When no browser identity was captured, it falls back to the WordPress user ID (if user identification is enabled) and finally to a per-order ID, so the revenue reaches Mixpanel either way.

Testing

Mixpanel has no test mode, so server-side events go into your project as real events.

1. Place a test order in your shop
2. Open Events in Mixpanel and look for the Order Completed event
3. Check the order_id property against the WooCommerce order

Server-Side Proxy

You can offload the Mixpanel Ingestion API calls from your WooCommerce server to the edge using the Server-Side Proxy. This reduces server load and improves tracking accuracy by routing events through a first-party subdomain.

Session replay and heatmaps

Mixpanel can record browsing sessions and collect heatmap data through the same SDK. With the setting enabled, the Pixel Manager initializes the SDK with session recording and heatmap collection turned on.

Session replay also has to be enabled in the Mixpanel project itself, under Settings > Project Settings > Session Replay. Mind that session replay records what your customers do on your shop, so check it against your privacy policy before enabling it.

You can enable session replay and heatmaps in the Mixpanel advanced settings section of the Pixel Manager.

Autocapture

Mixpanel's autocapture records clicks, form submissions and input changes on its own, on top of the e-commerce events the Pixel Manager sends. It is useful for interactions that have no dedicated e-commerce event, and it needs no tracking code.

It is off by default, for two reasons: it produces a lot of events, and it captures interaction context from pages that may hold personal data, such as the checkout. Enable it deliberately.

You can enable autocapture in the Mixpanel advanced settings section of the Pixel Manager.

User identification

With user identification enabled, the Pixel Manager identifies logged-in customers in Mixpanel by their WordPress user ID and writes these properties to their Mixpanel user profile:

• $email
• $first_name and $last_name
• $phone
• $city, $region and $country_code

This stitches a customer's sessions across devices and browsers into one Mixpanel user, which is what makes retention and cohort reports accurate.

Unlike the advanced matching of the ad platforms, these values are not hashed. Mixpanel is a first-party analytics tool that shows you your own customer records, and a hash would make the profile useless to you. That also means real personal data is sent to Mixpanel, so check it against your privacy policy and your Mixpanel data processing agreement before enabling it.

The profile is written once per browser session, not on every page view.

You can enable user identification in the Mixpanel advanced settings section of the Pixel Manager.

Supported Events

The Pixel Manager sends these Mixpanel events:

• Page Viewed: sent on every page. The SDK's own page view tracking is disabled, so pages are never counted twice.
• Product List Viewed: sent on product listings, with all products of the listing in one event.
• Product Clicked: sent when a product in a listing is clicked.
• Product Viewed: sent on product detail pages, with the product details.
• Product Added to Cart: sent when a product is added to the cart, with the product details, price and quantity.
• Cart Viewed: sent on the cart page, with the cart value and items.
• Checkout Started: sent when the checkout is started, with the cart value and items.
• Shipping Info Added and Payment Info Added: sent when the customer completes those checkout steps.
• Products Searched: sent on search result pages, with the search term.
• Order Completed: sent when an order is placed, with the order ID, the revenue, the currency and all purchased items.
• Order Refunded: sent when an order is refunded. Requires the Ingestion API, because a refund never reaches the browser.

Here's a list of supported events.

The event names can be changed with the event filters, if your Mixpanel project already uses a different taxonomy.