Connecting Yotpo to Mixpanel

Architecture

How Yotpo and Mixpanel actually connect

Two systems that know nothing about each other. Everything below exists to give them one shared reference.

1. Step 1

   Yotpo holds the truth

   The flag is what matters. A redeemed order is revenue that a retention program produced, and crediting it to the paid click that acquired the customer eighteen months ago overstates that campaign badly.

2. Step 2

   Mixpanel needs a click to match

   Mixpanel needs a distinct_id, an event name and its properties. Events without a distinct_id are rejected; events with the wrong one land on a stranger's profile.

3. Step 3

   The identifier is the bridge

   The distinct_id, captured at the visit and carried into the Yotpo loyalty redemption. Without it there is nothing to join on and no tool fixes that.

4. Step 4

   The event source decides reliability

   Send purchases with a channel attribute distinguishing first orders, loyalty-driven repeats and referral-driven orders. Three different economics, three different owners.

5. Step 5

   Deduplication at the destination

   Mixpanel deduplicates on $insert_id within a time window. Without it, a retried server request creates a second event, and because Mixpanel is where product decisions get made, that inflation ends up in a roadmap rather than in an ad report.

Diagnose it honestly

Working vs. broken, side by side

Both states look identical from the Mixpanel dashboard, which is why this runs for months before anyone notices.

Diagnostic sequence

Diagnostic order

Each step rules out a class of cause. Run them in order and the last one usually has a single explanation standing.

1. 1

   Count redemptions carrying the distinct_id

   The ceiling on everything else. Do this before debugging anything downstream.

2. 2

   Follow one real conversion end to end

   From the ad click through Yotpo and into Mixpanel.

3. 3

   Count orders carrying a reward or referral code

   Then check whether any of them appear in your paid conversion figures. If they do, the acquisition numbers are inflated by exactly that amount.

4. 4

   List every event name in the project and look for near-duplicates

   Case differences, tense differences and synonyms are the usual finding, and they are cheap to fix before a year of data is built on them.

5. 5

   Read the match rate, not the success message

   Mixpanel shows events in the live view within moments. Check that the distinct_id matches the signed-in user rather than a lingering anonymous ID, because that is the failure that quietly breaks every cross-signup funnel.

Source-of-truth validation

How it gets proven

Against Yotpo's own records, not against either platform's dashboard.

• The distinct_id confirmed present on a live redemption.
• A real conversion followed from click through Yotpo to Mixpanel.
• Purchase events reconciled per transaction against your billing system, with identity aliasing verified across the signup boundary.
• First-time-buyer orders reconciled against imported conversions, with loyalty and referral orders excluded and reported separately.
• Reconciled over a fully closed window, matched per record rather than on totals.
• Re-checked 30 days later.

Straight talk

When you don't need this

Worth reading before paying anyone, including us.

• If Mixpanel already reports conversions that reconcile against Yotpo's records within a few percent, this join is working and there is nothing to buy.
• Measure identifier coverage yourself first — pull your last hundred redemptions and count how many carry the distinct_id. Ten minutes, free, and it tells you whether any of this is worth doing.
• If you run Yotpo for reviews only and have no loyalty or referral program, this reduces to the Trustpilot case: keep reviews out of your conversion list and stop there.
• If you already have the same events in a warehouse and nobody is running product analysis on them, adding Mixpanel adds a second source of truth rather than an answer.