The Attribution SDK and the Nine-Day Launch
You are the mobile platform lead at a subscription fitness app with 900,000 monthly active users. Nine days before a paid acquisition campaign, marketing asks you to add a third-party attribution SDK. Reading the vendor's integration guide, you find the SDK transmits at first launch: advertising ID, IP address, device model, OS version, install timestamp, and a SHA-256 hash of the user's email - which the app has never used for this purpose. The vendor's click-through contract contains no data processing terms and lets it retain data for 36 months to improve its products. Your published privacy notice says the company does not share data with advertisers. The product manager says legal "already looked at it" and asks you to merge the dependency.
1. Triage before touching the build. Which claims in the request are unsupported or wrong, and how do you verify each?
Read the worked answer
Treat every claim as a hypothesis to test, and test with artifacts rather than assurances.
- "Legal already looked at it." Ask for the artifact: a review, a memo, an email with a date and a named reviewer. If none exists, the claim is a rumor with a deadline attached. This is the first thing you check, because everything else assumes it.
- "The email hash is anonymous." It is not. A hash of an email address is drawn from a low-entropy space; anyone holding a candidate list can hash it and match in seconds. It is pseudonymous personal data, and it functions as a join key between your users and a vendor's graph - arguably the most valuable field in the payload.
- "We can quietly enable it." The advertising ID is not silent. On iOS it requires an explicit tracking prompt; if the SDK initializes it before authorization, the app is non-compliant and may be rejected.
- "Standard terms are fine." A click-through with no processing terms and 36-month retention means a third party sets the purpose and the clock. You cannot satisfy minimization or storage limitation through a contract you did not negotiate.
- Notice contradiction is a fact you can verify in ten seconds and must fix before launch either way.
Verification step: build with the SDK in a test target, capture traffic through a proxy, and write down the actual fields, endpoints, and timing. Vendor documentation is marketing; the packet capture is evidence.
2. Marketing will not move the date. Design the lowest-risk way to measure install attribution by launch.
Read the worked answer
Start from the decision the data must support. The campaign decision is "which channel to scale" - that rarely requires a per-user join on device.
Option A (preferred): server-side attribution. The app sends an install event with a first-party identifier to your own backend; your backend performs matching with the ad network's server API. No third-party SDK in the binary, no advertising ID on device, no email hash leaving your boundary. This is achievable in nine days if the network supports server-side conversion APIs, and it keeps you as the controller.
Option B: aggregate measurement. Install counts per campaign pulled from network dashboards, no user-level linkage. You lose cross-channel de-duplication and incrementality estimates, which is a real analytical cost - say so explicitly rather than pretending it is equivalent.
Option C: constrained SDK. Only viable if the vendor supports field configuration: disable email hash and IP collection, cap retention at 30 days contractually, sign processing terms, add a kill switch, update the notice and in-app disclosure before launch.
Do regardless of option: update the privacy notice so it stops being false, inventory the new data flow, and get written sign-off from a named accountable owner. Nine days is enough to do A or B; it is not enough to negotiate a DPA, so don't plan on one.
3. Suppose you are overruled and told to ship as specified. What do you do, and what do you write down?
Read the worked answer
Make the risk legible in writing, then comply as far as you legitimately can - while refusing the part that is deceptive.
Write down: the specific data fields, where they go, how long they are kept, the exact sentence in the notice they contradict, the mitigations you proposed and what each would have cost, and the date. Put it in the ticket and in an email to the product manager and the privacy officer. A decision record that exists only in your head protects no one - including you.
Request written risk acceptance from a named owner, not from "product." The point is not bureaucracy; it is that accountability should sit where the decision is made.
Fix what you can within the instruction. If the payload is fixed but the notice is not, update the notice and the in-app disclosure. If a kill switch or a retention setting exists, use it. If a data-flow inventory exists, add this flow. These are not trivial: many real incidents are made worse by the gap between what a company said and what it did, not by the collection itself.
Escalate past the PM to the privacy officer or DPO. Escalation is not disloyalty; it is the control that a privacy-by-design role exists to operate.
Do not ship a flow that misrepresents collection to users while staying silent, and do not treat "I was told to" as a complete defense. The professional obligation is to make the trade-off explicit to the person empowered to accept it.