What is fingerprint attribution?

It is a method of matching an install to a click by assembling a signature from device and network characteristics — IP address, screen dimensions, OS version, locale, and in aggressive implementations free disk space and system boot time. No single value identifies a device, but the combination is distinctive enough in a short window to act as an identifier.

Is device fingerprinting allowed on iOS?

No. App Store Review Guideline 5.1.2 states that you may not derive data from a device for the purpose of uniquely identifying it, and lists device and browser properties, location and network connection as examples. Apple's privacy guidance confirms that this applies regardless of whether the user granted App Tracking Transparency permission.

Does ATT consent make fingerprinting acceptable?

It does not. Granting the ATT prompt authorises use of the IDFA, which is an identifier Apple provides and the user can reset or revoke. It does not authorise constructing a substitute identifier from device characteristics, and Apple's guidance addresses this case explicitly because the confusion is common.

What happens if an SDK in my app fingerprints devices?

The risk lands on your app rather than on the vendor, because the SDK ships inside your binary. Consequences range from an App Store rejection citing 5.1.2 or a missing required-reason declaration, through an inaccurate privacy manifest, to removal for repeated issues. Ask vendors in writing which device APIs their SDK reads and what reason codes it declares.

What can I use instead of fingerprinting?

Maximise deterministic signals first — tagged links, correct referrer encoding, and Apple's AdServices token for Search Ads — then use SKAdNetwork or AdAttributionKit for aggregate campaign truth on iOS, and validate budget decisions with geo holdout tests. Report whatever remains as an explicit unattributed bucket rather than filling it with an inferred match.

Glossary/Attribution mechanics

Fingerprint attribution

Definition

Fingerprint attribution matches an install to a click by building a signature from device and network characteristics such as IP address, screen dimensions, OS version and locale, rather than from an identifier either party consented to share.

It is the highest-coverage attribution method available and the one we do not offer. Apple's App Store Review Guidelines prohibit deriving data from a device in order to identify it, and that prohibition applies whether or not the user granted App Tracking Transparency permission. This page sets out what fingerprinting actually reads, why it survives in the market anyway, and the honest alternatives — including admitting that some installs will stay unattributed.

What a fingerprint is made of

No single one of these values identifies anyone. The technique works because their *combination* is rare enough to be near-unique in a short time window, which is precisely the property that makes it an identifier under Apple's definition.

The signal set a matcher typically collects on both sides

{
  "ip": "203.0.113.47",
  "ip_v6_prefix": "2001:db8:85a3::/64",
  "user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X)",
  "screen": { "w": 1179, "h": 2556, "scale": 3 },
  "os_version": "18.4.1",
  "device_model": "iPhone16,1",
  "locale": "en_GB",
  "timezone": "Europe/London",
  "carrier": "EE",
  "language_list": ["en-GB", "fr-FR"],
  "font_metrics": "…",
  "battery_level_bucket": 0.7,
  "free_disk_bytes": 41203847168,
  "boot_time": 1755301200
}

Several entries in that list are not merely discouraged — they are the exact APIs Apple placed behind required reason declarations in the privacy manifest regime. Free disk space, boot time and active keyboard lists were singled out because their overwhelming use in the wild was fingerprinting. An SDK that reads them and cannot justify a permitted reason code is an App Store rejection waiting to happen.

Why each family of signals is collected, and what its declaration status is.
Signal family	Why it is useful	Status on iOS
IP address	Narrows to a network and a rough location	Permitted to observe; not permitted as an identifier
User agent / OS version	Coarse device class	Ordinary; weak on its own
Screen dimensions and scale	Distinguishes device models	Ordinary; weak on its own
Free disk space	Highly distinctive per device	Required-reason API
System boot time	Near-unique per device	Required-reason API
Active keyboard list	Distinctive and stable	Required-reason API
The combination	Near-unique in a short window	This is what 5.1.2 prohibits

Apple's position, stated plainly

This is not an inference from the spirit of ATT. It is written in the App Store Review Guidelines under 5.1.2, Data Use and Sharing: you may not derive data from a device for the purpose of uniquely identifying it, and the guideline names browser and device properties, location and network connection as examples. Apple's User Privacy and Data Use guidance states the consequence for attribution directly — fingerprinting is not allowed regardless of whether ATT permission has been granted.

ATT consent does not unlock fingerprinting

This is the most common misreading in the category. Granting ATT permits use of the IDFA; it does not permit substituting a derived device signature for it. A user who taps "Allow" has consented to an identifier Apple provides and can reset — not to one assembled behind their back from disk space and boot time.

The practical risk is not usually a fine. It is that the app carrying the SDK gets rejected, or removed, for something the marketing team bought and the engineering team never audited. Because the SDK ships inside your binary, the review outcome lands on you rather than on the vendor.

Where the responsibility actually sits when a third-party SDK fingerprints.
Party	What they did	Who bears the consequence
Attribution vendor	Shipped the matching feature	Commercial risk only
Marketing team	Enabled it for coverage	None directly
Your app	Embedded the SDK	Rejection, removal, manifest inaccuracy
Your privacy manifest	Declares what the app collects	Becomes untrue

Why it persists, and what to do instead

Fingerprinting survives because it answers the question every advertiser asks — *which click caused this install* — for the population where nothing else can. On iOS, an install from a non-Apple ad channel where the user did not use the paste button has no deterministic carrier at all. Fingerprinting fills that gap, and the alternative is an unattributed bucket that nobody enjoys presenting.

Our position is that the unattributed bucket is the honest answer, and that it is smaller than it looks once the fixable losses are fixed. The order below is roughly by return on effort.

Fix the deterministic losses first. Untagged links, stripped redirect parameters and unencoded ampersands account for more missing attribution than iOS privacy ever did.
Use the sanctioned aggregate paths. SKAdNetwork and AdAttributionKit give campaign-level truth with no device identifier involved.
Use Apple's own token for Apple Search Ads. The AdServices attribution token is deterministic, first-party and explicitly supported.
Measure the rest with holdouts. Geo splits and scheduled pauses answer the causal question better than any per-install match ever did.
Report unattributed as a real number. A bucket you can see is a bucket you can shrink; a synthetic match hides the problem and adds a policy liability.

Questions worth asking any attribution vendor

Does the SDK read free disk space, boot time or the active keyboard list? What required-reason codes does its privacy manifest declare? Is per-install probabilistic matching on by default for iOS, and can it be disabled? A vendor who cannot answer those in writing is asking you to accept their review risk on your binary.

Android is a different regime, not a free one: Play policy governs identifier use, and the App Set ID is explicitly not permitted for ads measurement. But Android also has the Play install referrer, which means the gap fingerprinting exists to fill is far narrower there to begin with.

UTM builder

The alternative to inferring an identity is carrying one you were given. This builds correctly-encoded campaign URLs whose parameters survive the redirect chain and the store, which is the deterministic base that decides how much you ever needed to infer.

Open the utm builder →

Frequently asked questions

What is fingerprint attribution?: It is a method of matching an install to a click by assembling a signature from device and network characteristics — IP address, screen dimensions, OS version, locale, and in aggressive implementations free disk space and system boot time. No single value identifies a device, but the combination is distinctive enough in a short window to act as an identifier.
Is device fingerprinting allowed on iOS?: No. App Store Review Guideline 5.1.2 states that you may not derive data from a device for the purpose of uniquely identifying it, and lists device and browser properties, location and network connection as examples. Apple's privacy guidance confirms that this applies regardless of whether the user granted App Tracking Transparency permission.
Does ATT consent make fingerprinting acceptable?: It does not. Granting the ATT prompt authorises use of the IDFA, which is an identifier Apple provides and the user can reset or revoke. It does not authorise constructing a substitute identifier from device characteristics, and Apple's guidance addresses this case explicitly because the confusion is common.
What happens if an SDK in my app fingerprints devices?: The risk lands on your app rather than on the vendor, because the SDK ships inside your binary. Consequences range from an App Store rejection citing 5.1.2 or a missing required-reason declaration, through an inaccurate privacy manifest, to removal for repeated issues. Ask vendors in writing which device APIs their SDK reads and what reason codes it declares.
What can I use instead of fingerprinting?: Maximise deterministic signals first — tagged links, correct referrer encoding, and Apple's AdServices token for Search Ads — then use SKAdNetwork or AdAttributionKit for aggregate campaign truth on iOS, and validate budget decisions with geo holdout tests. Report whatever remains as an explicit unattributed bucket rather than filling it with an inferred match.

Related terms

Probabilistic attribution — Probabilistic attribution estimates which ad interaction most likely caused an install by inferring a match from signals such as timing, network and device characteristics rather than from an identifier shared by both records.
Deterministic attribution — Deterministic attribution credits an install to a specific click by matching an identifier that is present in both records, producing a one-to-one link rather than a statistical estimate.
Required Reason API — A required reason API is an iOS API that Apple has designated as usable only if the calling bundle declares an approved reason for using it in its privacy manifest.
App Tracking Transparency (ATT) — App Tracking Transparency is the iOS framework that requires an app to obtain explicit user permission before accessing the device's advertising identifier or otherwise tracking that user across apps and websites owned by other companies.