AdAttributionKit for Advertisers: The App Sets the Rules

Almost all the published writing on AdAttributionKit was produced for engineers, and it answers one question: how to integrate the framework. These are the other questions, the ones media buyers keep asking and nobody answers: what changed about who gets credit for an install, and how much of that is now decided inside the advertised app rather than by Apple.

The short version is that an advertised app can set its own install attribution windows, tell the system to disregard an entire interaction type from a named ad network, and block new conversions for up to 30 days after a qualifying conversion. Those are settings in an information property list, not negotiations with a partner. Many apps are running the defaults, and few media teams have ever seen the values.

Everything below is drawn from Apple's own developer documentation, and the relevant page is linked at each claim.

The contest, before anything is configured

When someone installs an app after seeing ads, several ad networks may each have a qualifying impression. One wins.

Apple's interoperability documentation states the sorting rules plainly. Click-through ads always take precedence over view-through ads, and within each group impressions sort by timestamp. The system considers a maximum of six impressions for any conversion. If a person sees more than one advertisement, attribution goes to the advertisement that person tapped most recently; if that person tapped none, it goes to the one that person viewed most recently.

Two consequences follow.

A click beats a view regardless of recency. An impression that your network served and that the user clicked three weeks ago outranks a view that another network served an hour before the install. This is not a tiebreaker applied at the end. It is the first sort key.

AdAttributionKit and SKAdNetwork impressions also compete in the same contest. Apple's documentation is explicit that the system sorts both and picks one winner across the two frameworks. There is no separate race.

One more number matters for anyone buying view-through inventory. Apple's postbacks documentation states that AdAttributionKit records a maximum of 15 view-through impressions per publisher app, discarding the oldest once that cap is reached, and that each recorded impression expires after 24 hours. Those impressions "may advertise various products," so the cap is shared across every advertiser running view-through in that app. That storage cap is separate from the six impressions the interoperability page says the system weighs at attribution.

The three settings an advertised app controls

This part gets almost no attention, and it is what quietly changes the volume a channel reports.

Apple's page on configuring attribution rules describes a dictionary named AdAttributionKitConfigurations that an app adds to its information property list. Inside it are the controls below.

A dating caveat belongs up front. Apple's AdAttributionKit change log dates attribution rules and cooldown windows to June 2025, in the same group of entries that introduced multiple conversion windows and the postback country code. The change log does not name an operating system version, and it is not a complete record of what shipped when: conversion tags, which Apple gates to iOS 18.4, appear nowhere in it. So treat June 2025 as the date the capability was documented rather than as a release marker, and take from it only what it supports, which is that these controls are not present across AdAttributionKit's whole install base going back to iOS 17.4. The minimum version is a question for whoever maintains the app.

Attribution windows, for install conversions. By default, view impressions are valid for one day and click impressions are valid for 30 days. An app can set view impressions anywhere from one to seven days and click impressions from one to 30 days, using the AttributionWindows dictionary. Those windows can be set globally or per ad network, and the order of precedence is ad network, then global, then system defaults. Every documented path sits inside an install dictionary, and there is no equivalent control for reengagement windows.

Read that again as a buyer. The window your impressions are measured against is a value the advertised app's engineering team chose. That value can differ by partner, and nothing in a campaign report says which one applied.

Ignoring an interaction type. Inside the install dictionary of a per-network configuration, an app can set ignoreInteractionType to either view or click, which tells the system to ignore impressions of that type from that network during attribution. Apple notes that this works only for ad network configurations; the system does not recognize an ignored interaction type set globally.

This is the setting to ask about. When an app owner decides a particular network's view-through impressions are not worth crediting, the app can tell the system to disregard them for install attribution. The network keeps serving, the system keeps recording the impressions, and those impressions stop entering the contest. Attributed installs fall.

Cooldown. Using the AttributionCooldown dictionary, an app can specify install-cooldown-hours or re-engagement-cooldown-hours, each accepting a value from zero to 720 hours, which is 30 days. Apple describes cooldown as a duration after the last conversion in which the system will not create new conversions, and gives the motivating case directly: someone installs from an ad and taps another ad two hours later, and by default that second tap produces a reengagement conversion. An app owner who considers the install the more important signal can suppress the conversions that follow.

Apple's per-key descriptions clock each cooldown from a conversion of its own type, install-cooldown-hours after an install conversion and re-engagement-cooldown-hours after a reengagement conversion, although the same page's overview describes it more loosely as time between conversions. On the per-key reading, a 720-hour install cooldown means the system creates no new conversions on any device whose attributed install conversion landed within the preceding 30 days. That is the ad-attributed slice of a recently acquired cohort rather than everyone who installed, since a device with no attributed install conversion has no install clock running. For a reengagement campaign aimed at that cohort, the cooldown can still remove a material share of the addressable audience. The campaign is not underperforming, and the ads are still serving. The conversions are being suppressed by a key in the app build.

Reengagement is a different animal

Treating reengagements as installs with a different label is a common and expensive mistake. Apple's postbacks documentation separates them in several ways.

Reengagement comes from clicks only. The system does not create reengagement conversions from view-through impressions.

On a reengagement, there are no runner-up postbacks. On an install, up to five ad networks receive a nonwinning postback with did-win set to false. Only the ad network whose impression drove the conversion hears about it.

The first conversion value update is due far sooner. After an install, the device has 60 days to send it. After a reengagement, it has two days.

Reengagement postbacks are capped per app and per device. Apple states that the system does not always produce postbacks after a reengagement, and that reengagement limits apply monthly per app and yearly per device. Install conversions carry no equivalent cap; the postbacks documentation says they always produce winning postbacks where a qualifying impression exists, subject to the crowd anonymity tier. In iOS 18 and later, publisher apps can pass a reengagement URL, and Apple notes that the parameter the system appends to that URL is present even when no reengagement postback is created. The advertised app can therefore see the open while the ad network sees nothing.

A new reengagement conversion also disturbs the old one. When a reengagement occurs while an install or reengagement conversion is still active, the system locks the active postbacks from the prior conversion and schedules them for transmission, then removes that conversion's unregistered postbacks and replaces them with postbacks from the latest conversion. Conversion tags do not prevent that sequence. What Apple added in iOS 18.4 and later is narrower: when the system opens an app from a reengagement, it supplies a conversion tag with the reengagement URL, and passing that tag to the update method targets that specific conversion instead of the most recent one, which is the conversion the framework updates when no tag is supplied. The documentation describes tags being supplied only on reengagement opens, so there is no documented way to obtain one for an install conversion.

The practical point is that running acquisition and reengagement against the same audience at the same time means those campaigns interact inside the operating system, not only in your report.

What still limits the report, whatever the app is set to

The settings above change which impression wins. They do not change how much detail comes back. That is governed by crowd anonymity, through the postback data tiers.

Apple assigns a postback data tier to each app download, not to the app as a whole. The tier depends on crowd size for the publishing app or domain, the advertised app, and the install country, together with the source identifier the ad network provides. The conversion window documentation spells out what each tier returns in the first postback. Tier 0 returns that first postback and nothing else; it carries a two-digit source identifier and no conversion value. Tier 1 adds a coarse conversion value. Tier 2 adds the fine-grained conversion value, and a longer source identifier becomes possible: Apple computes a tier for the two-, three-, and four-digit versions of the identifier separately and sends whichever reaches the highest tier, choosing the longest on a tie, so three and four digits appear only at Tier 2 or above. Tier 3 adds the publisher item identifier, plus a country code if the install country's crowd is also Tier 3.

The three conversion windows run days 0 to 2, days 3 to 7, and days 8 to 35, counted from the user's first app launch rather than from the install or the impression. An app can update conversion values in all three windows, and Apple is specific that it must: receiving the second and third postbacks at all depends on an update inside each window. The fine-grained conversion value appears only in the first postback, and the second and third carry a coarse value and a two-digit source identifier, whatever the tier. Per the change log, multiple conversion windows arrived in the same June 2025 cycle as the configuration controls above.

Delivery delays stretch that timetable further. The first postback is sent 24 to 48 hours after its window closes. The second and third are sent 24 to 144 hours after theirs. A day-30 event sits in the third window, which closes at day 35, so it can be sent as late as day 41, long after the campaign that produced it was judged.

That arithmetic is what makes a flight look weaker on the day you review it than it will look once every postback has landed. Our post on why CTV installs arrive late and land in organic walks through the same problem on the channel where it bites hardest.

Is SKAdNetwork dead or deprecated?

No. Dead and deprecated are different claims, and neither is true today.

What Apple's SKAdNetwork class documentation actually contains is an Important callout that opens: "Use AdAttributionKit for app ad campaigns on the App Store and alternative marketplaces." That is direction, not a deprecation. The page carries no deprecation marker on the class itself and no end date, and the only symbols marked deprecated are two legacy methods: one for registering an app for attribution and one for updating a conversion value.

The documentation also says the two frameworks work together. Ad network identifiers ending in .adattributionkit and .skadnetwork are compatible across both. When an app calls the SKAdNetwork conversion update methods, SKAdNetwork mirrors the call into AdAttributionKit. An app integrated with both should call the update methods of each.

For a media plan, that means AdAttributionKit is where the new capability lands and where Apple is pointing. SKAdNetwork still functions. Neither the app owner nor the buyer has to pick a side this quarter. Ask any partner who presents a migration as urgent which Apple document sets the deadline.

Where AdAttributionKit actually runs

Availability is the other question a media plan has to settle, particularly for anyone buying connected TV against app outcomes. Apple lists AdAttributionKit as available on iOS 17.4 or later and Mac Catalyst 17.4 or later. There is no tvOS support. The framework that resolves this contest does not run on the device the ad played on, which is the structural reason CTV-to-mobile measurement stays probabilistic no matter how the campaign is set up.

What to do with this

Four items, in the order they pay off.

Ask what is in the app's property list. Not whether AdAttributionKit is integrated. Ask specifically whether AdAttributionKitConfigurations exists, what AttributionWindows is set to globally and per network, whether any network has an ignoreInteractionType, and what install-cooldown-hours and re-engagement-cooldown-hours are set to. In most cases this takes one message to whoever maintains the app build, and the answer can explain months of reporting that otherwise made no sense.

Check cooldown before blaming a reengagement campaign. No conversions at all against a freshly acquired cohort is the exact symptom an install cooldown produces.

Stop comparing view-through and click-through performance as if they competed evenly. They do not. Clicks win the sort first, which inflates click-attributed channels and understates view-attributed ones before anyone looks at the creative.

Set the read date before the flight starts, not after. Given conversion windows that run to day 35 and postback delays of up to 144 hours, a flight reviewed at day 14 is being judged on a fraction of what it will eventually report. Deciding the read date in advance costs nothing. Where a postback cannot settle a question, an incrementality test can, and the questions worth asking a DSP cover how a partner handles read dates and incrementality alike.

What matters for a media plan is that the attribution contest has an app-side configuration layer that did not exist under SKAdNetwork, and the defaults in it are doing work nobody signed off on. The question is worth 20 minutes of an engineer's time, and it should be answered before anyone takes it to a vendor.

FAQ

Is SKAdNetwork deprecated?

No, and it is not dead either; the two claims are different. Apple's SKAdNetwork documentation carries an Important callout directing developers to use AdAttributionKit for app ad campaigns on the App Store and alternative marketplaces, and two legacy methods are marked deprecated, but the class itself carries no deprecation marker and no end date. The two frameworks also interoperate: ad network identifiers work across both, impressions from both compete in a single attribution contest, and SKAdNetwork mirrors conversion value updates into AdAttributionKit.

What is the default attribution window in AdAttributionKit?

There are two. View impressions are valid for one day and click impressions for 30 days. An app can override these defaults for install conversions in its information property list, setting view impressions from one to seven days and click impressions from one to 30 days, either globally or per ad network. Ad network settings take precedence over global settings, which take precedence over the system defaults. There is no equivalent control for reengagement windows, and Apple's change log dates this capability to June 2025.

Can the advertised app stop a network's view-through impressions from being attributed?

Yes. Inside the install dictionary of a per-ad-network configuration, an app can set ignoreInteractionType to view or click, and the system then ignores impressions of that type from that network during attribution. Apple states that this works only for ad network configurations.

Why is a reengagement campaign reporting no conversions?

There are several documented causes. Reengagement conversions come only from clicks, never from view-through impressions. The app may have an install-cooldown-hours or re-engagement-cooldown-hours value set, up to 720 hours, measured from a conversion of the matching type, during which the system creates no new conversions for that device. Reengagement postbacks are also capped on a monthly per-app and yearly per-device basis, and Apple notes the system does not always produce them.

How long after an install can a postback arrive?

Counting from the user's first app launch rather than from the install itself, the three conversion windows run days 0 to 2, days 3 to 7, and days 8 to 35. The first postback is sent 24 to 48 hours after its window closes, and the second and third are sent 24 to 144 hours after theirs. An event in the third window can therefore be sent as late as day 41, counted from that first launch. Receiving the second and third postbacks at all requires the app to update the conversion value during each window.

Does AdAttributionKit work on tvOS or connected TV?

No. Apple lists availability as iOS 17.4 or later and Mac Catalyst 17.4 or later. There is no tvOS support, which is why measuring app outcomes from CTV campaigns relies on probabilistic household-level matching rather than a signed postback.

Does AdAttributionKit require App Tracking Transparency consent?

No. On the AdAttributionKit framework page, Apple states that apps do not need to use App Tracking Transparency before calling ad attribution APIs, and that they can call these APIs regardless of their tracking authorization status.

‍