I’ve written extensively about the practice of device fingerprinting, but especially its rampant and near ubiquitous use in the aftermath of Apple’s App Tracking Transparency (ATT) privacy policy, which explicitly forbids that method of device identification.
For a primer on mobile device fingerprinting for the purposes of advertising attribution, see this piece. At a high level:
Fingerprinting is the process of aggregating hardware and network parameters from a device into a combination that is likely to be unique, or unqiue enough to provide a sense of identity, within some period of time. The more parameters that are combined, the less common the combination, but the primary components to a device fingerprint for mobile advertising: device IP address, OS version, and model code. A fingerprint is not persistent, and it can expire rapidly, so fingerprinting can really only be used for install attribution: the time between a click and an app install tends to be abbreviated such that a fingerprint match between an ad click and app install is considered reliable. So while a fingerprint can be credibly used to attribute app installs, the same is not true for in-app events that happen hours or days later.
It’s important to emphasize the fact that mobile device fingerprinting within apps is primarily, if not singularly, useful for attributing app installs to advertising campaigns: because fingerprints have short useful lifetimes, which I speak to in this piece, they can’t be relied upon to attribute down-funnel events like purchases, registrations, engagement milestones, etc. to advertising campaigns. For mobile app campaigns, fingerprinting is utilized to conduct the kind of app install accounting that previously relied upon the IDFA for device-level accuracy: determining that a campaign generated some number of installs within a specific timeline.
SKAdNetwork, Apple’s measurement framework for app advertising campaigns on iOS, allows for the precise accounting of installs at the campaign level: it produces an absolutely credible and trustworthy record of the number of installs generated by any given advertising campaign. But SKAdNetwork currently operates on a convoluted and impractical resettable postback timer system that obfuscates the date at which an install takes place. This timer system renders cohort-level reporting and analysis difficult. It is the dysfunction and inadequacy of SKAdNetwork, in its current incarnation, that grants relevance to device fingerprinting on iOS in the first place.
Two qualifiers in the previous statement are worth unpacking. First, SKAdNetwork will be upgraded from its current incarnation to version 4.0 in the very near-term future (according to Apple: this quarter). As I point out in this piece, SKAdNetwork 4.0 abandons the resettable timer system in favor of three fixed attribution windows, meaning that three separate postbacks can be transmitted for a single install, and the timeframes in which they will be transmitted are known and transparent. These fixed windows will allow installs to be cohorted, so fingerprinting won’t be necessary for that purpose.
And the second qualifier is that fingerprinting really only remains feasible on iOS. Google introduced the Privacy Sandbox for Android initiative at the beginning of this year as part of its commitment to deprecating the Android advertising identifier, the GAID. One feature of the Privacy Sandbox for Android is the SDK Runtime, which will at some point be implemented within Android 13, which is already live. The SDK Runtime will segment “advertising-related SDKs” away from the more general operating environment within Android, untethering access to the device resources granted to apps from those available to their constituent SDKs. What this ultimately means is that “advertising-related SDKs,” a designation that applies to attribution SDKs, will likely be starved of access to the device parameters needed to create commercially dependable device fingerprints. Note that this coincides roughly with the introduction to Android of a privacy feature that allows users to restrict access to the GAID at the device level, similar to Apple’s old Limit Ad Tracking setting.
The fact that Apple has done nothing to restrict the practice of fingerprinting following the rollout of ATT is inconsistent and peculiar. I hypothesized in February, following Google’s introduction of the Privacy Sandbox for Android, that Apple might follow suit with an approach similar to the SDK Runtime that restricts access to device parameters for advertising SDKs while also potentially routing all in-app traffic through its Private Relay protocol. While Apple announced no such feature at WWDC this year, it did reiterate in a developer session that “fingerprinting is never allowed.”
The existence of Private Relay, which is a two-hop traffic routing system that camouflages a user’s IP address from network operators and site owners alike, underscores Apple’s belief that the device IP address is a privacy vulnerability, especially as a component of fingerprinting. But Private Relay currently only applies to Safari and not to apps, although that may change in the future. The attribution windows being implemented to SKAdNetwork 4.0 may arrest the use of fingerprinting on their own, however: no need exists for device fingerprinting if app install cohorting is possible through fixed attribution windows.
And app advertisers should celebrate the end of the widespread use of fingerprinting: fingerprints are imprecise, unreliable, and lead to over-attribution of organic traffic, as I call out in this piece. Furthermore, the practice of fingerprinting is a disaster for consumer privacy, as no opt-out mechanic regulates device fingerprinting, consumers can’t know when it’s happening, and fingerprints are shared across contexts with total nonchalance. It seems possible that by negating the need to use it, SKAdNetwork 4.0, released more than a year after ATT’s introduction, could extinguish the practice of device fingerprinting within mobile apps.