Shared family tablets and line-level identity at Metro Mobile
Metro Mobile is a telecom with 6.2M lines on family plans. The app runs on shared family tablets, and the account holder's CRM ID stays stored on the device after sign-in, sometimes for weeks. Line-level CRM IDs are the canonical customer ID in mParticle; the household account ID is sent as a user attribute. Symptoms since a server-side migration: (a) 7% of profiles carry two different line-level CRM IDs, (b) an email-keyed destination sometimes receives line-2 events under line-1's email, (c) line-level audience membership flips within minutes, and (d) server purchase events occasionally land on an anonymous profile even though the app called identify() a second earlier. The team wants real-time offers keyed on the line, never the household.
1. Explain the mechanism behind symptoms (a) and (c), and state what must change in the app and the data model.
Read the worked answer
Both are the same root cause: a shared device reusing an identity context.
(a) The app never resets identity on sign-out. When line 2 signs in with identify(customer_id=B) on a device whose profile already holds customer_id=A, mParticle receives a new identity for an existing profile and merges. The profile now carries A and B and its history belongs to two people. There is no unmerge operation - the profile can only be prevented, not repaired.
(c) Once two lines share a profile, every audience keyed on line-level attributes evaluates both. A purchase by line 2 adds membership, a dormancy signal from line 1 removes it, and the profile oscillates. The symptom looks like a scheduling problem; it is a data-model problem.
Changes:
- On sign-out, call the SDK's logout/reset so the next session begins on a fresh anonymous MPID. Never reuse the prior MPID for a different person.
- On shared devices, stop persisting the CRM ID between sessions and identify on every session.
- Keep
account_idstrictly as a user attribute. As an identity it would merge every line in the household into one profile, which is the opposite of the requirement. - Audit existing profiles for 2+ line IDs and quarantine them from line-level campaigns rather than attempting cleanup; those profiles are permanently ambiguous.
2. Diagnose symptom (d). Why can a server event land anonymously when the client identified a second earlier, and what is the robust fix?
Read the worked answer
Cross-input ordering is not guaranteed. A client identify() and a server Events API call are independent HTTP requests over different networks; the server request can arrive first even when the user tapped a second earlier. mParticle merges when the identity arrives, but the event has already been attributed to the anonymous MPID it was attached to.
Fixes, in order of robustness:
- Send identity with the event. The Events API payload should include the identities block (
customer_id, email) alongside the event. Then the event cannot land anonymously - this is the real fix. - Pass the MPID from client to server when it is available, so the server event targets a known profile explicitly.
- Fail loudly. A server call whose identity block is missing should error and retry rather than succeed into an anonymous profile.
- Reconcile. Anonymous profiles that later identify are merged, so analytics heals over time - but any destination that already received the anonymous event never gets corrected. That asymmetry is why the destination team noticed first.
Separately, check the connection's identity priority. If email outranks customer_id and the event carries only a CRM ID, the mapping to the destination can resolve to the wrong record or drop silently.