Third-party SDKs and trackers: your app, your responsibility
A mobile app commonly ships with dozens of third-party SDKs: ad networks, attribution, analytics, crash reporting, payments. Each one runs its own code inside your app, with your permissions, towards its own servers. And everything they do there binds you.
A responsibility you cannot delegate
The CNIL’s position is consistent: the publisher bears at minimum joint controllership for trackers used by any SDK embedded in the app, and must audit whether partners honor their commitments.
A contract with the SDK provider is not enough. You need to know what the SDK actually does inside the app, not just what its documentation promises.
The Grindr precedent
The Grindr case illustrates the risk. Norway’s authority imposed a fine of 65 million kroner, around 6 million euros, for user data shared with advertising partners through the SDKs embedded in the app, without valid consent. The decision was upheld on appeal in October 2025.
The fine targets the app’s publisher. Not the ad networks that received the data.
The chain can even reach beyond your own SDKs: location data also leaves through the ad auction, towards companies you never signed a contract with.
Inventory first
The starting point is an honest inventory: which third parties the app actually contacts at runtime, beyond what teams believe they integrated. Transitive dependencies and inherited versions hold surprises.
Public databases list several hundred known trackers, identifiable through the domains they contact. That is the baseline an app should be screened against, on every release.
Then the evidence
The inventory says what is embedded, not what happens. What remains is observing actual behavior: which data leaves before consent, what happens after a refusal, towards which domains, in which countries. It is also what lets you check what the store listing declares about all of it.
That dated, reproducible evidence is what makes the difference during an inspection. A publisher who can answer these questions before the regulator stays in control of the timeline.
It also feeds a very different file: knowing which countries the data actually reaches is the precondition for any transfer impact assessment.
Common questions
- How do you find out which SDKs a mobile app uses?
- The list the team keeps says what was integrated, not what fires. Watching the app at runtime shows which kits actually open connections, to which domains, and when. An SDK that ships but stays dormant does not carry the same weight as one that transmits before the banner appears.
- Is the publisher responsible for data collected by a third-party SDK?
- The publisher picks the SDKs it embeds and triggers the collection: the CNIL holds that it bears at least joint responsibility, and that auditing its partners falls to it. It is not responsible for the processing the provider carries out for its own purposes, but that line moves as soon as the provider reuses the data for its own ends.