Trial Abandoners counts 41,000 where analytics says 120,000
Pulse Streaming sells monthly and annual plans. Its lifecycle team built three audiences in mParticle: 'Trial Abandoners' (fired trial_start, no subscription_started within 7 days), 'High-Value Subscribers' (3+ months active and lifetime_value above 120), and 'Recent Purchasers' (subscription_started in the last 30 days), which is forwarded to two ad platforms as a suppression list. Analytics says 120,000 users started a trial in the last quarter without converting; the Trial Abandoners audience shows 41,000. The ad platform reports that 22% of users in the prospecting audience also appear in the suppression audience. trial_start is sent from the web app only; subscription_started is server-side. About 30% of trial users convert and pay on a different device from the one they started on, and identify() only fires at checkout.
1. Diagnose the 41,000 versus 120,000 gap. List the candidate causes in the order you would check them and say what fix follows from each.
Read the worked answer
Check in this order, cheapest first:
- Source coverage.
trial_startis web-only, so app-initiated trials never enter the audience at all. Compare the audience size against distinct MPIDs that fired the event in the window - not against the analytics headcount, which counts users on a different definition. - Window semantics. 'No subscription within 7 days' is usually misconfigured as a 7-day lookback from evaluation time. The inflating version of this error is easy to spot; the deflating version - a 7-day condition window applied to
trial_startitself - is not. If the trial-start condition is scoped to the last 7 days, the audience caps out at roughly one week of trial volume. 41k against a quarter of 120k is exactly that shape. - Recompute cadence and snapshotting. Standard audiences recompute on a schedule and members who convert drop out. A number pulled at 09:00 and a number pulled at 14:00 of the same day will not reconcile; pin a snapshot timestamp for reconciliation.
- Identity on the exclusion side. Conversions on a different device may never carry the trial device's identity, so those users are never excluded - that inflates membership, so it does not explain the gap but it means your final number will still be wrong after the fix.
Fix: anchor the window to the event (trial start), express the exclusion as 'has not performed subscription_started since trial_start', and add trial_start to the app inputs.
2. The prospecting and suppression audiences overlap by 22%. How would you redesign this so the overlap is structurally impossible rather than periodically corrected?
Read the worked answer
Two audiences with opposing intent is a design smell. Platforms apply inclusion and exclusion inconsistently, and the ordering of add and remove membership updates is not guaranteed.
Better: build one audience, Prospect_Net_Recent_Purchasers, defined as all eligible users AND NOT (purchased in the last 30 days), and send that to the ad platforms. Keep Recent Purchasers as a reporting audience only, or send it exclusively to destinations that natively support a suppression list with a defined precedence rule.
Then check the three things that keep overlap above zero even with a clean design:
- Match basis. If prospecting matches on device ID and suppression on hashed email, a desktop purchaser is never matched on mobile. A 22% overlap is roughly what a split match basis produces.
- Forwarding lag. Standard audiences update on the connection's schedule and the ad platform takes further hours to ingest; a purchase at 09:00 can still serve an impression at noon. That is unavoidable and should be measured, not eliminated.
- Paused outputs. A paused or disconnected suppression connection stops delivering remove events, so former buyers persist in the platform's list indefinitely. Alert on connection health.
Target: overlap equal to ingestion lag, not zero.