Twelve outputs, a PII complaint, and an EU data boundary at Verde Home
Verde Home is a DTC brand sending 380M events per month into mParticle from web, iOS, Android, and a server feed. Twelve outputs are connected. A new per-event-priced CDP bills on ingested events, and the data team sees a 2.4% count discrepancy between mParticle and that partner. A regulator-driven policy now forbids EU user data from leaving the EU-region workspace. An affiliate partner reported receiving raw email addresses inside event attributes. Meanwhile, marketing ops says a transformation added last month 'seems to be dropping checkout events' for one app version, but cannot say which version it targets. There is no data plan, and there are 140 custom event names, 22 of which any destination actually uses.
1. Design the control set that stops raw email reaching partners. Which layer does the real work, and what are the failure modes of each?
Read the worked answer
Three layers, and the order matters:
- Data plan as the contract. Define event and user-attribute schemas and move to enforcement so unexpected attributes are rejected at ingest. This is the only layer that catches a new attribute added by an app release before it reaches twelve outputs - filtering per connection does not scale to twelve partners.
- Data filtering at the connection. Remove email, phone and address-like attributes from the specific output that leaked. Filtering is per connection, so cleaning one partner leaves the others working; the failure mode is the reverse - you unblock later during a troubleshooting session and the leak returns.
- Transformation for shape, not policy. Use transformations to rename and reshape payloads. Do not rely on them as the only PII control: a transformation that throws on an unexpected shape can pass the original event through, which is a plausible contributor to the discrepancy you are already chasing.
Root-cause question to answer first: was the raw email in the event payload or in a user attribute? An attribute leaks on every event to that connection once it is on the profile, so scope the filter to attributes, not just the one event the partner complained about. Also check the affiliate's own on-page tag - the leak may not traverse mParticle at all. Then handle notification and retention exposure with legal.
2. The per-event-priced CDP both overcharges and disagrees on count. How do you attack cost and the 2.4% discrepancy separately?
Read the worked answer
Separate the two problems; they have different fixes.
Cost. Filter that connection down to the event types the partner actually uses, and drop debug and noise events. If the partner's job is audience activation, forward audience membership instead of raw event streams - on a per-ingested-event model, an audience connection can be orders of magnitude cheaper than 380M events. Quantify before and after: total events × the share represented by the 22 used names.
The 2.4% discrepancy almost always comes from one of:
- Events blocked by data filtering or rejected by the data plan, which mParticle counts at a different stage than delivered events.
- Profile and attribute updates plus audience membership syncs, which some partners count as records while mParticle reports them as separate activity.
- Partner-side dedupe on its own key, for example collapsing to user-per-day.
- Retries: a 5xx retry delivered twice inflates the partner's count on one side only.
Method: pick one day and one event type, and reconcile at event-ID level against the partner's raw logs. Do not chase a percentage without a shared definition of 'event' - the argument will never converge.
3. How do you enforce the EU boundary, and which of the twelve connections are actually at risk?
Read the worked answer
The constraint is about where data is stored and processed, so it has to be solved at the workspace level, not with attribute filters.
- Keep EU inputs and EU-bound outputs inside the EU-hosted workspace. Do not forward EU events to the US workspace 'and filter later' - the transfer has already occurred at that point.
- Decide per input. If a single app serves both regions, the SDK must initialise with region-appropriate configuration, or the inputs must be split so each workspace receives only its region. Verify with a test device in each region rather than trusting the config.
- Identify at-risk connections by asking two questions for each: does it receive EU user data, and where does it process it? Event streams to US-hosted partners and email-keyed audience syncs are the usual offenders; audience syncs are easy to miss because no event stream is visible on the connection.
- Rebuild EU-relevant audiences and calculated attributes in the EU workspace. They are not automatically portable, and a shared destination key must be region-scoped or the sync will cross regions silently.
- Keep data plan definitions in sync across workspaces so a schema change cannot pass in one region only.
- Document residual flows: hashed identifiers sent to a US ad platform may still be a transfer under your DPA. Hashing reduces exposure; it does not by itself satisfy residency. Get that reviewed rather than assumed.