An EFF investigation published this month found that popular Android ad and monetisation SDKs — bundled into apps with a combined 60 million-plus downloads — quietly inherit whatever location permission the host app already holds and forward precise GPS coordinates to ad-tech and data-broker backends by default. The integrating developer often has no idea it’s happening, because the data never passes through their own analytics event schema. It leaves through a network call the SDK vendor controls.
That’s the real problem for anyone running a tracking or analytics stack: location tracking has quietly stopped being a first-party consent-flow question and become a third-party-SDK auditing question. A team can build an exemplary consent flow, log every location-sharing event correctly in its own analytics pipeline, and still ship a build that leaks raw GPS data through a bundled SDK nobody re-reviewed since the last ad network integration. Your own event log looking clean tells you nothing about what the SDKs riding alongside it are doing on the wire.
The gap is visibility, not intent. Most teams instrument what their own code explicitly logs, but rarely capture outbound network traffic at the SDK layer as a first-class tracking surface. Without that, a location leak looks identical to compliant behaviour in every internal dashboard — the only place it shows up is in a security researcher’s packet capture, or in a regulator’s inquiry, months later.
Data Points to Track
- SDK-level network destination, logging which third-party host each outbound request from a bundled SDK is sent to, not just that a request occurred
- Permission-to-SDK mapping, recording which bundled SDKs have runtime access to location, contacts, or device identifiers granted to the host app
- Payload field inventory for each outbound SDK call — flagging any field that resembles latitude/longitude, GPS accuracy, or a raw device identifier
- SDK version and vendor, tracked per release, so a permission-scope change in a routine SDK update doesn’t slip through unreviewed
- First-party vs third-party event volume ratio, so a sudden spike in SDK-originated network calls relative to your own instrumented events is visible as an anomaly
Setup Steps
- Run a network-traffic audit on a build with all production SDKs enabled, using a proxy tool to capture every outbound request and its payload before shipping a location-permission-dependent feature.
- Map each bundled SDK’s manifest-declared permissions against what your app actually needs, and flag any SDK inheriting more than its stated purpose requires.
- Diff SDK payloads on every version bump — treat a monetisation or analytics SDK update the same as a dependency security review, not a routine changelog skim.
- Add outbound-request logging as its own tracked category, separate from your first-party event schema, so SDK network activity is visible in the same dashboards as your own instrumentation.
- Set an alert threshold for unexpected growth in third-party outbound call volume following an SDK update.
Actionable Insights
Once SDK-level network visibility exists, the data answers a question no first-party event log can: is a location leak happening below your own code? A payload-field audit that finds GPS coordinates leaving through an ad SDK’s endpoint — one your consent flow never mentioned — is the clearest signal that a permission-scope mismatch exists between what the SDK is contractually allowed to access and what it’s actually sending. Tracking the first-party-to-third-party call ratio over time also catches slow drift: an SDK vendor quietly expanding what it collects in a minor version bump shows up as a ratio shift long before it becomes a headline.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert