Connecting Smile.io to Mixpanel

Architecture

How Smile.io and Mixpanel actually connect

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

1. Step 1

   Smile.io holds the truth

   A redeemed order is retention revenue at a reduced margin. Crediting it to the paid click that acquired the customer originally counts one acquisition twice and at the wrong value.

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 Smile.io points redemption. Without it there is nothing to join on and no tool fixes that.

4. Step 4

   The event source decides reliability

   Send orders net of the discount points redeemed, with first orders and reward-driven repeats marked.

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 Smile.io and into Mixpanel.

3. 3

   Compare gross order value against value net of points issued and redeemed

   The gap is the programme's real cost, and it is rarely in any marketing report.

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 Smile.io'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 Smile.io to Mixpanel.
• Purchase events reconciled per transaction against your billing system, with identity aliasing verified across the signup boundary.
• First orders reconciled against imported conversions, with redemption-driven orders 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 Smile.io'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 no loyalty programme, this reduces to an ordinary store integration.
• 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.