Mobile App Attribution in 2026:SKAdNetwork, AdAttributionKit, and What's Left After Privacy Sandbox

Mobile attribution used to answer one simple question with a direct lookup: which ad produced this install? For most of the last decade, both major platforms carried a stable, cross-app device identifier, Apple's IDFA and Android's GAID, that an ad network could read at click time and an app could read again at install time, and matching the two was the entire system. That system is gone, not because any single vendor decided to kill it, but because both platform owners independently concluded that a persistent, freely readable identifier was a privacy problem worth breaking a working ad-tech industry to fix.

What exists now is three separate, imperfect layers stacked on top of each other, and most of the confusion we see from operators comes from treating them as one system instead of three. The platform layer (Apple's SKAdNetwork and AdAttributionKit, Android's AD_ID-gated GAID) handles the actual privacy-preserving math of connecting a click to an install without exposing a stable identifier to anyone who shouldn't have one. The measurement layer (your mobile measurement partner, if you use one) ingests whatever the platform layer gives it, deduplicates across ad networks, and tries to make the result usable. And the compliance layer (CCPA, COPPA, GDPR and ePrivacy, enforced by regulators who have shown they will act on mobile-specific cases) sits over both and determines what any of this is even allowed to do with the data it touches.

This guide is for the operator who needs to know what to actually build, not the ad-tech trade press take on who "won" the privacy fight. If you are weighing how this fits into a broader custom mobile app build rather than a bolt-on to an existing app, the attribution layer is one of the pieces worth scoping during discovery, not bolted on after launch, because conversion-value mapping has to be designed around your actual post-install funnel from day one.

App Tracking Transparency has not changed its basic shape since it shipped in iOS 14.5 in April 2021: before any app can read the IDFA or otherwise track a user across apps and websites owned by other companies, it must show Apple's system prompt and the user must affirmatively allow it. What has changed is everything built on top of that gate.

SKAdNetwork, Apple's original privacy-preserving attribution framework, works by having the ad network, not your app, hold the attribution claim. A conversion value (a 6-bit number Apple lets you encode with post-install signal) gets set by your app, and Apple sends a delayed, randomized postback to the ad network once enough installs have accumulated to clear Apple's undisclosed crowd-anonymity threshold, so no single install can be traced back to an individual user. It works, but it has two structural limitations operators run into constantly: the postback goes only to the ad network by default, not to you, so reconciling what the network reports against your own backend has always required extra engineering, and it only ever covered App Store installs.

AdAttributionKit, which Apple introduced at WWDC 2024 and which ships starting with iOS 17.4, is built to close both gaps. Postbacks now go to the ad network and directly to the developer, which means you no longer have to trust a network's self-reported numbers without a way to check them. And because EU users can now install apps from alternative marketplaces and the web under the Digital Markets Act, AdAttributionKit was built to measure those installs too, while SKAdNetwork never covered anything outside the App Store. Apple documents full interoperability between the two frameworks: the same network identifiers work across both, and SKAdNetwork calls get mirrored into AdAttributionKit automatically.

The engineering implication is concrete: your conversion-value mapping (the logic that decides what number to encode, and when, based on what the user actually does after install) is the single highest-leverage piece of this entire system, on either framework. A conversion value scheme designed around your actual revenue or activation events, reviewed and adjusted as your funnel changes, is worth more to measurement accuracy than any vendor dashboard sitting downstream of it.

Android's version of the identifier fight played out on a different timeline, and as of 2026 it has arrived at a genuinely unsettled place that Apple's side has not.

Google's Advertising ID (GAID) is gated two ways today. First, any app targeting Android 13 (API level 33) or later must declare the com.google.android.gms.permission.AD_IDnormal permission in its manifest to read it at all; skip the declaration and the identifier silently returns as a string of zeros rather than throwing an error, which means a missed manifest line fails exactly the way a dead push token does: quietly, with nothing surfacing until someone audits the raw numbers. Second, a user with ad personalization opted out gets zeros regardless of your manifest, and Google Play policy separately requires that apps serving children or users of unknown age never transmit the advertising ID for those users, which means your ad SDK's child-directed and under-age-of-consent tags need to be correctly configured, not left on defaults.

What was supposed to be Android's long-term, privacy-preserving replacement for direct GAID matching was Google's own Privacy Sandbox on Android, centered on an Attribution Reporting API conceptually similar in spirit to SKAdNetwork: aggregate, on-device, no stable identifier exposed. On October 17, 2025, Google announced it is retiring that API, along with Topics, Protected Audience and SDK Runtime, for both Chrome and Android, citing low levels of ecosystem adoption after reviewing developer feedback. Chrome began deprecating the underlying technologies starting with Chrome 144 in January 2026, with removal targeted for Chrome 150 in July 2026.

The practical consequence for anyone building or auditing an Android measurement stack today: GAID (where the user and app configuration allow it), the Play Install Referrer API, and probabilistic or modeled attribution through an MMP remain the real toolkit, not a transitional stopgap on the way to something better that has now been cancelled. If a vendor pitched you an Android roadmap built around Privacy Sandbox adoption sometime in the last two years, that roadmap needs revisiting.

We are deliberately not ranking mobile measurement partners by accuracy, fraud detection, or any performance metric, for the same reason we refuse to print a single opt-in rate as fact later in this guide: there is no independently audited, third-party comparison of these claims, only each vendor's marketing about itself and its competitors. What we did verify is corporate status, because it is checkable and it changes real risk.

Smaller independents worth naming without the same depth of verification: Tenjin and AppsFlyer-adjacent regional players like Airbridge have real market share in specific verticals (gaming, Asia-market apps respectively) but we have not independently confirmed their current funding or ownership status to the standard above, so treat them as names to research directly rather than entries we are vouching for here.

Three real, named enforcement actions do more to explain what regulators actually care about than any summary of the statutes, because each one shows exactly what a real investigator flagged in a real mobile app.

• Sephora, August 2022, $1.2M, first-ever CCPA settlement: The California Attorney General's complaint stated that a business's use of "widely-used" advertising and analytics technologies can itself constitute a "sale" of personal information under CCPA's broad definition, because the "other valuable consideration" a business receives in exchange can be the free or discounted analytics service itself, not just cash. An attribution SDK sending a device identifier to an ad network in exchange for free measurement tooling fits this description directly.
• Tilting Point Media, June 2024, $500K, CCPA and COPPA: The California Attorney General and the Los Angeles City Attorney settled with the mobile game developer over misconfigured ad and analytics SDKs that shared children's personal information without the required consent. The settlement requires Tilting Point to maintain a written SDK governance framework, reviewed at least annually, documenting every SDK, what data category it can access, and the business purpose for using it: a concrete, reusable template for any app's own SDK audit.
• PlayOn Sports (2080 Media Inc.), February 2026, $1.1M, CCPA: The California Privacy Protection Agency's stipulated order against the high-school sports ticketing platform (GoFan, MaxPreps, NFHS Network) found its tracking-technology opt-out mechanism inadequate: phone and email opt-outs alone weren't sufficient when the app used tracking SDKs including Meta Pixel, and directing users to third-party industry opt-out tools (the NAI, the DAA) didn't satisfy the legal obligation either. On mobile specifically, the order noted the consent banner sometimes blocked the screen area needed to display a ticket, functionally forcing consent to enter a venue.

Layered over all three is the FTC's amended COPPA Rule, published in the Federal Register on April 22, 2025, effective June 23, 2025. General compliance was required by April 22, 2026, a deadline that, as of this guide's publication date, has already passed; COPPA safe harbor programs had an earlier compliance date of October 22, 2025. If your app has any plausible child-directed or mixed-audience exposure, that is a current obligation, not a future one, and it belongs in the same SDK-inventory exercise the Tilting Point settlement describes, not treated as a separate legal review disconnected from the technical implementation.

Two separate EU-adjacent developments landed on nearly the same calendar as this guide, and conflating them is an easy mistake to make.

The first is specific to Apple's tracking consent prompt. Germany's Federal Cartel Office, the Bundeskartellamt, opened an investigation into Apple's App Tracking Transparency framework in June 2022 over self-preferencing: whether Apple's own first-party consent flow was designed to encourage "allow" while third-party apps' requests were structured in a way more likely to discourage it, which the authority viewed as unequal treatment under German competition law. On August 17, 2026, the Bundeskartellamt declared Apple's remedial commitments binding and closed the case. The redesign reported across multiple outlets covering the decision: Apple removes the warning-hand icon and the word "tracking" from the prompt, simplifies the choice to a neutral "Allow" or "Reject," gives developers room (reportedly up to 4,000 characters) to explain why personalized advertising funds their app, and may ask the same user again after one year rather than only once. Apple has roughly four months from the decision to implement the change, and the commitments are reported to bind Apple for seven years once implemented.

The second, unrelated except in timing, is Apple's broader EU Digital Markets Act compliance terms, which took effect October 1, 2026: a single set of business terms for every developer distributing in the EU, the Core Technology Fee replaced by a 5% Core Technology Commission on digital transactions outside the App Store, and expanded ability to link users to alternative payment processors, third-party marketplaces, or a developer's own website rather than only Apple's own payment system.

We want to be precise about what we could and could not confirm here: the Bundeskartellamt's decision is a German antitrust matter, and while multiple news outlets covering it report that Apple's resulting prompt redesign applies EU-wide rather than only in Germany, we were not able to directly verify that scope detail against Apple's own primary documentation due to a network restriction in our research tooling. Confirm the current rollout scope directly with Apple's developer documentation before making a scope-specific decision based on it.

Every conversation about mobile attribution eventually arrives at the same question: what percentage of users actually allow tracking? We are going to answer it more carefully than most of what circulates in this market, because the honest answer is "it depends on whose panel you're reading, and none of them is everyone."

Adjust's Mobile App Trends 2026 report, built on its own install-cohort data with a disclosed methodology (aggregated and anonymized, subject to volume thresholds, averaged per app after excluding statistical outliers), reported a global average opt-in rate of 38% in Q1 2026, up from 35% in Q1 2025, with gaming apps highest at roughly 39% and publication apps showing one of the largest year-over-year gains. Separately, eMarketer's industry KPI trackeraggregates quarterly benchmark reports from AppsFlyer and Singular, each with its own disclosed but different methodology; AppsFlyer's figure, for instance, is calculated only from apps clearing a minimum 30,000-install threshold per quarter and country, which is a meaningfully different sample than Adjust's.

The deeper reason this matters operationally, not just rhetorically: your conversion-value mapping strategy (discussed earlier) and your realistic spend-attribution coverage both depend on your own opt-in rate, not an industry figure. An app in a vertical with a 20-point-lower opt-in rate than the "average" needs a measurement strategy that leans more heavily on modeled and aggregated data from day one, not a strategy copied from a benchmark report describing a different population of apps entirely.

The order matters because each layer depends on the one before it reporting correctly, the same lesson our offline-first architecture guide makes about foundational engineering generally: a sophisticated system built on top of a broken foundation just produces confident-looking garbage faster.

Two further architectural notes worth stating plainly. First, deep linking and attribution are adjacent but distinct systems that too many teams conflate: a link can route a user to the right in-app screen without ever touching attribution, and attribution can correctly credit an install without any deferred deep link involved. If you are building both, our deep linking implementation guide (linked below) covers the routing layer specifically, including why Firebase Dynamic Links' shutdown broke more attribution flows than most teams expected, since many apps had quietly used Dynamic Links as a deferred-deep-link-slash-attribution shortcut.

Second, the SDK inventory step (step 3) is not a one-time audit to close out in a sprint. Ad networks and analytics vendors update their own SDKs on their own schedule, sometimes changing what data a given SDK version collects without a corresponding version bump in your own app. A named owner reviewing the inventory on a recurring cadence, the same discipline our mobile app RFP template guide recommends specifying up front when scoping a build through a formal proposal process, is the only way this step stays true after launch instead of becoming stale documentation nobody re-checks.

We don't have a Frenchy Digital client case study that specifically documents attribution-stack metrics; rather than stretch an unrelated project's public numbers to fit this topic, here is an honest, explicitly illustrative scenario worked from figures verified earlier in this guide.

One scoping note specific to this domain: discovery should always include a specific check for two artifacts most teams have never looked at directly: whether the app still relies on Firebase Dynamic Links for any deferred-deep-link-as-attribution shortcut (a shut-down product, covered in our deep linking guide), and whether the Android manifest actually declares the AD_ID permission on every build variant, not just the one someone checked once.