Privacy by design in UA data flows

Every UA stack moves personal data through a chain: device, SDK, MMP, ad network, reporting dashboard. Privacy by design means treating that chain as something to minimise and map in advance, not something to defend after a regulator or a platform security review asks a question about it.

Data minimisation is the first and cheapest step. It's also the one most teams skip, because the default SDK configuration collects more than any single use case needs. A value-based bidding signal doesn't need a raw revenue string tied to an individual user; an aggregated bucket, or a SKAN-style discretised conversion value, does the same optimisation job with less exposure. The exercise is worth running SDK by SDK: what does this integration collect by default, and does any active use case actually require that field.

Retention windows are a setting, not a given

GDPR says a controller may keep personal data no longer than the purpose it collected the data for requires. Most MMPs offer configurable retention windows, commonly a choice between thirty and ninety and three hundred and sixty five days of raw event retention, and studios routinely leave that at whatever the vendor set as default. Define the window deliberately. Tie it to how long raw event-level data actually stays useful for cohort analysis before aggregation or deletion, and you get a straightforward compliance improvement that also shrinks the amount of raw data a breach could expose.

What an MMP actually shares downstream

Understanding what a mobile measurement partner passes on to ad networks matters more than most vendor contracts make explicit. Historically this meant device-level postbacks carrying identifiers; under SKAdNetwork and AdAttributionKit, most of that traffic now arrives aggregated by design, but Android flows built around a device identifier still carry more granular data where consent allows it. For each integrated network, a UA team should be able to state what data the MMP forwards and in what form, and whether that network can retain and reuse it across its own advertiser base beyond the single campaign that produced it. That last point belongs in the data processing agreement explicitly, not assumed from a general privacy policy link.

Consent is not the only lawful basis, but it needs to be documented

GDPR gives several lawful bases for processing, and consent is only one of them. Legitimate interest can cover some first-party analytics. It doesn't extend to third-party ad targeting without consent, and the distinction matters because regulators have shown they will ask for the documented basis behind a specific data flow rather than accept a blanket reference to a privacy policy. Each flow, first-party analytics, MMP attribution, ad network optimisation, should have a stated lawful basis on file, reviewed when the flow changes rather than written once at launch and forgotten.

Consent management platforms need to actually gate the SDK

A consent management platform, whether an IAB TCF string on a web-to-app flow or a mobile-native consent gate, only does its job if a rejected consent choice actually suppresses the SDK calls it governs, rather than hiding a banner while the SDK initialises regardless. Test this directly instead of trusting the CMP vendor's documentation: reject consent in a test build, then check the network traffic to confirm nothing fires that shouldn't.

Cross-border transfer belongs on the same map

Cross-border transfer adds another layer worth mapping alongside retention and lawful basis. Where a network or MMP processes data outside the EU, standard contractual clauses or an equivalent transfer mechanism need to sit behind that flow, and the data map should note which vendors process data in which region, not just what each one collects. A vendor list built purely around functionality (this SDK handles attribution, this one handles creative testing) misses the transfer question entirely unless the map explicitly tracks where processing happens geographically. That gap is exactly the kind of detail an enterprise partner's due diligence or a regulator's request surfaces first.

The data map is the actual deliverable

The most useful artefact a UA or measurement lead can produce is a data map: every SDK in the build, what it collects, where that data goes, whether a data processing agreement exists for that vendor, and who inside the studio owns the relationship. It needs updating whenever the team adds a new network or creative-testing tool, not a once-a-year revisit at audit time. Most studios have a folder of vendor contracts and no map of the flows those contracts actually govern. The map, not the contracts folder, is what a regulator or an enterprise partner's security review or a platform's own compliance team will ask to see first.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• From ad promise to first session: the funnel is collapsing
• Web shop attribution: measuring D2C without breaking your MMP setup