June 5, 2026 · The Caliper team

Self-reported attribution is deterministic. SKAN isn’t.

There is a habit in mobile measurement of treating “deterministic” as a property that only device-level attribution gets to claim. The IDFA was deterministic. A matched click on a logged-in user is deterministic. SKAN is “privacy-preserving,” which everyone has quietly agreed to read as “less deterministic but we work with it.” And the survey — asking the user — gets filed under soft, fuzzy, directional.

That taxonomy is backwards. Post-ATT, the survey answer is one of the few inputs you have that is deterministic at the install level. SKAN is the probabilistic one. It is worth being precise about why, because the precision changes how you use each.

Most iOS installs are dark to device-level attribution

ATT opt-in rates settled somewhere in the 25-35% range depending on category and prompt. Round it however you like; the point is that the majority of your iOS installs never granted tracking permission. For those users there is no IDFA to match, so there is no deterministic device-level join between the ad they saw and the install you got. That is not a tuning problem you fix with a better SDK. It is the design of the platform.

So for most of your iOS traffic, the question “where did this specific install come from” has no device-level answer at all. Whatever fills that gap is either modeled, aggregated, or asked.

SKAN gives network truth, not install truth

SKAN — and AdAttributionKit after it — is genuinely useful, and it is also probabilistic in ways people underweight. The postback tells you a campaign drove conversions, with three constraints baked in.

Crowd-anonymity tiers decide how much detail you get back. If a campaign clears a high threshold of conversions, Apple releases fine-grained conversion values and source identifiers. If it does not clear the threshold, the conversion value gets coarsened or nulled and the source detail collapses. So your measurement resolution is a function of your volume, not your need. Small campaigns, long-tail creatives, and granular geo tests are exactly the cases where SKAN tells you the least.

Then there are the timers and the coarse conversion values. The conversion value is a handful of bits, mapped through a schema you defined in advance, fired on a delay designed to break the timing link between install and postback. You get a usable signal about campaign performance. You do not get a clean per-install record, and you cannot reconstruct one from the postback.

Net: SKAN is network-level truth. It tells you, within anonymity and timing limits, that a network and campaign produced conversions. It is the right tool for that job. It is not an install-level record, and treating its aggregates as if they were one is how teams talk themselves into precision they do not have.

Fingerprinting is the move people reach for to paper over the gap, and it is the wrong move. It is against platform policy, it is actively detected, and its accuracy decays as the signals it relies on get restricted. Building measurement on it is building on a surface that is being deliberately sanded down.

The under-used third leg: ask the user

Here is the leg most teams treat as a garnish. You ask the user how they heard about you, and for that user, the answer is deterministic at the install level. There is no probabilistic match, no anonymity threshold, no coarsening. One install, one recorded answer, attached to that install.

It is also channel-granular in a way no postback is. SKAN can tell you a campaign worked. It cannot tell you that the install came from a specific podcast, a specific creator, or a friend’s recommendation, because those channels never generated a postback in the first place. An influencer read, a podcast spot, a CTV impression, word of mouth — these produce no click for an MMP and no source ID for SKAN. The user’s answer is the only attribution signal that will ever exist for them. Self-reported attribution is not a downgrade you accept for dark channels. For dark channels it is the entire measurement.

So the deterministic/probabilistic split is not device-versus-survey. It is: SKAN is probabilistic and network-scoped; the survey is deterministic and install-scoped; they cover different channels and answer different questions.

The honest limits

A practitioner essay that skipped the limits would be useless, so here they are plainly.

Response rates are not 100%, and they are not uniform. The people who answer are not a random sample of installs; motivation to respond correlates with how memorable the touch was. That means you cannot take a raw response percentage and multiply it against installs. You model the non-responders — you build a response-rate-aware estimate that accounts for who declined, rather than assuming silence looks like the answers you collected.

Recall bias is real. People compress and rationalize their own journey. Someone who saw three ads and then got a recommendation will often credit the recommendation, because that is the touch they remember consciously. You manage this with question design, not by pretending it is absent.

And the design decisions are load-bearing. Randomizing option order per impression keeps the list from over-indexing whatever sorts first. A prominent skip matters because a skipped survey is honest missing data, while a forced guess is noise you will mistake for signal. Both are methodology choices that determine whether the deterministic-at-install property survives contact with real users.

Use each leg for the job it’s good at

The argument is not that surveys replace SKAN. It is that the two answer different questions and you stop forcing one to do the other’s job. Use SKAN for network truth — which campaigns and networks are producing conversions, within the anonymity and timing constraints. Use surveys for channel truth — especially the dark channels where no postback will ever arrive. Then triangulate, with MMM as the third reference when you need a top-down read on incrementality the bottom-up signals can’t give you on their own.

Caliper’s role here is the install-level deterministic leg: capturing the self-reported answer and attaching it to the install record so it sits alongside your SKAN and MMP data instead of in a separate report. The triangulation is yours to run. The point is to run it with each leg labeled honestly.