Every SDK you install is a data-sharing agreement

An engineer decides to add an SDK to a game; the review covers crash risk and binary size; nobody responsible for the studio's data signs it off. That is the wrong owner. A network SDK is a standing agreement about which events leave the device and who receives them, and about what the recipient may build with them; so is a mediation SDK, and so is an analytics one. Measurement should own that review, and in most studios it does not even see it.

The engineering view is defensible. Someone vetted the SDK for stability, it ships with documentation, and the vendor's terms went into the commercial contract at signing. Adding a process layer slows integration for marginal benefit. The problem with that view is that it treats the data flow as a fixed property of the contract, when in practice it is a property of the code, and the code changes with every version bump.

What actually leaves the device

Strip the marketing language and an ad network SDK does three things. It renders ads. It reports events (impressions, clicks, installs, purchases, session starts, sometimes level completions, plus any custom events you pass it) back to the network. And it collects device and context signals to help the network decide which ad to show and what to bid.

The second and third functions are where the agreement lives. Your purchase events, sent to a network so it can optimise your campaigns towards payers, also teach that network's model what a payer in your genre looks like. That model then bids on behalf of every other advertiser in your genre, including the competitor whose install you are outbidding. The network is not doing anything improper; this is what a shared optimisation model is. But the asymmetry is real. You contribute your best signal, and the network uses it to sell installs against you.

Mediation adds a layer. A mediation SDK sits above the networks and sees everything: which network filled, at what price, how the user behaved afterwards. If the mediation provider also operates a demand-side business, as most of the significant ones now do, your monetisation data informs a bidder you may also be buying from. Whether that improves or degrades your buying terms is genuinely uncertain, and the point is that nobody at the studio has usually asked.

The second-order effects nobody reviews for

Three consequences follow from SDK accumulation, and none of them show up in the integration ticket.

The first is that your attribution becomes a negotiation. Every SDK with a view of the install claims it, and your MMP arbitrates between them using rules you configured once and rarely revisit; add a network SDK and you've added a claimant. Adjust's March report on gaming app sessions and retention put ATT opt-in at 39 percent for the first quarter, barely moved from a year earlier, which means the majority of iOS attribution is probabilistic or SKAN-based, and every additional party asserting a view into that murk makes the arbitration less stable, not more.

The second is a cost UA pays without knowing it. Each SDK adds to binary size and to start-up work on first launch. The store conversion rate the UA team is buying, and the day-one retention the network is optimising towards, are both sensitive to install size and first-session latency. A studio that adds two networks to chase five percent more fill may lose part of that on the funnel it is paying for. The effect is small per SDK and cumulative across all of them.

The third is that data-sharing terms track the code version, not the contract. A network can add a new signal collection in a minor release, document it in a changelog, and be entirely within its terms. Your legal review from the original contract doesn't cover it, and the engineer who ran the update saw nothing but a routine version bump. The agreement changed, and nobody at the studio signed anything.

The SDK ledger

The fix is a document, not a tool. For every third-party SDK in the build, maintain one row with six columns.

• Sends. Which event types and device signals leave the device through this SDK, in plain language. Not "standard events" but the actual list, including any custom events you forward.
• Receives. Which companies get the data. The vendor, and any partners the vendor's terms allow it to share with.
• Restricts. What you can switch off. Most SDKs allow you to withhold custom events, limit purchase value reporting or disable certain signals. Record what you have actually configured, not what is possible.
• Returns. What you get back, concretely: reporting, optimisation, fill. This is what you are trading the data for, and it should be a large enough return to justify the row.
• Exits. What happens to the data when the relationship ends, and whether you can retrieve your history. The ironSource shutdown in April gave advertisers a five-week retrieval window; assume nothing that generous is guaranteed.
• Owner. A named person on the measurement team who reviews the row at every version update.

The decision rule for adding a new row is deliberately blunt. If you would be uncomfortable emailing the contents of the Sends column to the vendor's sales team as a spreadsheet, do not install the SDK until you have restricted it to the point where you would be.

An illustrative example. A studio reviewing a mediation SDK finds that the Sends column includes purchase values and session length, along with a custom "tutorial completed" event forwarded for optimisation. The Receives column, after reading the terms, includes the vendor's demand-side business. The Returns column shows a small fill-rate improvement on one placement. The measurement lead withholds the purchase values and the custom event, accepts the fill improvement as the trade, and records the decision. Six months later a version update adds a new signal; the Owner column means someone actually reads the changelog.

Renegotiate on data terms, not just rate

The ledger's most useful moment is contract renewal. Studios negotiate SDK and network relationships almost entirely on price and volume commitments. Everyone treats the data terms as boilerplate. They are not; they are the part of the relationship that compounds.

At renewal, bring the row. Ask the vendor which signals optimisation needs in order to function and which are merely useful to them. Ask whether the vendor excludes custom events forwarded for your campaigns from cross-advertiser model training, and get the answer in the contract rather than in an email. Ask for a retrieval window on exit. Vendors expect to concede on price. Very few have ever faced a request to concede on data, and the ones who refuse have told you something about the Returns column that the rate card never will.

Related archive reading

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

• Value optimisation selects for what you can measure
• Every platform privacy change is a pricing change