SKAN Evolution: Future Enhancements to Optimize iOS Attribution for Advertisers

A few weeks ago, I wrote a short LinkedIn post on SKAN-enabled fraud. When I posted it, I had no idea it would capture so much attention. Since it did, it pushed me to complete a more extended form feedback doc on SKAN, which outlines some of the current challenges with SKAN and proposes potential solutions.

The Origin Story

When SKAdNetwork (SKAN) was introduced, the goal was to become an essential tool for iOS app attribution, especially following Apple’s privacy-centric changes. It’s already been 3 years since then, and it’s still questionable what percentage of advertisers leverage SKAN as the single source of truth for iOS attribution. This stems from the gap between the advertisers’ need (to measure their performance) and the design (to prevent any possibility of privacy breach). We expected the gap to close with SKAN 4.0, which indeed offered some creative solutions for the problem — but they ended up being too much for the “common” advertisers, who ended up entirely deferring to alternative measurement solutions.

The ultimate challenge — Low Signal Quality

So far, our challenges with SKAN can be summarized in one sentence: low signal quality. The goal of an attribution solution is to help us understand how efficient our campaigns are. To do so, we need to understand the quality of users (retention, revenue) coming from these campaigns at a relatively granular level (campaign/creative) and on time (1–7 days).

Unfortunately, this hasn’t been the case due to the following reasons:

• Poor understanding of what conversion value schema generates the highest output. Up until iOS 15, we had a hard time understanding what conversion values were being received by networks. Fortunately, this is no longer the case, as we can get postbacks directly from Apple.
• We still need to rely on MMPs for enriched postbacks that include campaign metadata. The formatting of SKAN postbacks shared with MMPs is not standardized, and what we get back differs from partner to partner (fidelity type, did-win, campaign name, etc.).
• Poor or no understanding of privacy thresholds led to High Null Value Rates. This led to advertisers and networks spending time reverse engineering thresholds so we don’t waste our UA dollars. The problem could’ve been solved much better if there had been an active conversation between the three parties.
• Poor understanding of the ad network side of business and how to get the most out of them. A one-size-fits-all solution for the Conversion Value Schema could’ve been easier to set up and optimize against. Think about Facebook AEO and their predefined events, which made things more universal for them. It would’ve been easier if we had a similar approach vs. a bespoke one for each advertiser, which makes it easier for ad algorithms to learn and optimize.

SKAN 4.0 was supposed to solve some of these issues, but it felt over-engineered and hard to understand. This led to poor initial adoption across the board (networks, publishers), longer delays, and, ultimately, the industry doubling down on fingerprinting.

Let’s explore features that would help us get more out of SKAN and turn it into the single source of truth of iOS Attribution.

1. Start from the top — Organic and ASA Attribution

To use it across the board, we must ensure that all installs are measured in the apples-to-apples way (pun intended). Organic and Apple Search Ads installs are not being reported, so we have to build complex extrapolation logic for SKAN campaigns. If we at least had a total number of installs, we could compare that number with the internal install numbers (using a first-party ID), which would make it easier to understand a few things:

• Is SKAN overattributing due to using a different attribution logic (iTunes account-based attribution vs 1st party ID)
• Is our extrapolation logic sound, or are we giving more credit to specific channels?
• Are we being victims of ad fraud as a result of the above?

In the example below, you’ll see that SKAN usually overreport numbers (compared to MMP, which reports ASA and Organics). Since we don’t have the total number of SKAN installs, we must assume that the delta in installs comes from Organics and adjust the number of organic installs to fit the total install count. This is suboptimal. With Meta, Google, SNAP, and Tiktok being (or trying to be) SKAN only, the rest of the industry moved away from it and went down the MMP-only route.

2. iTunes account-based attribution and no configurable attribution windows

The next question to answer is why these discrepancies occur and why SKAN overreports install numbers for some partners and not others.

The answer to this question is twofold:

a) SKAN is leveraging the iTunes Account as a persistent ID to report the number of new installations. I like the idea of using an iTunes account as the source of truth, mainly because it’s the most permanent ID and addresses some edge cases (like secondary installs—new device, same user).

Still, there are a few caveats that are worth outlining:

• MMPs are using an advertising ID or a fingerprint. These two IDs are radically different.
• Advertising ID is not always available.
• Fingerprinting is not always accurate.
• Developers have no access to iTunes accounts to be able to dedupe on their own

So it’s not apples-to-apples, and we don’t have a way to reconcile these two. However, even if we assume that they are not that different and that the discrepancy between the two attribution approaches isn’t as high, we have a second and a more impactful change:

b) Lack of configurable attribution windows

On the MMP side, the attribution windows are configurable and somewhat standardized. It’s worth mentioning that they are pretty reasonable. I have had quite a few chances to analyze MTTI (Mean Time to Install, sometimes referred to as Click Time to Install or View Time to Install) over the years, and there is a reason why we mostly stick with 7-day click—1-day view attribution.

Let’s do a quick refresh on Appsflyer’s attribution windows:

The 7-day click, 1-day view has been the industry standard for quite some time (this is the time between the click/impression and app opening). This is because 95–98% of installs generally happen in those 7 days. Since most networks don’t work off CPI billing anymore, but oCPM or dCPM, it only made sense to limit it to 7 days and standardize it across the board.

On the SKAN side, things are slightly harder to pull apart, but the attribution window can be extended to 90 days for a fidelity type 1 impression. This difference between 90 days and 7 days is likely causing the majority of discrepancies here.

Lastly, there is no predefined reattribution window, which makes it hard for us to dedupe new from old installs if the user experience has significantly changed over the last few years. This should be defined at the account level, allowing us to align it with the internal attribution window (using a first-party ID) and leading to lower discrepancies between SKAN, MMP, and, ultimately, our internal reports.

3. No ways to do retargeting

This will likely be addressed in SKAN 5.0, as they teased it in the previous WWDC, but it’s still worth mentioning that not having a non-targetable ID that we could use to target our existing players will lead to the end of retargeting. This is again a result of moving away from IDFA to iTunes account-based attribution, and we need a solution. I look forward to learning more about SKAN 5.0 once it comes out.

Essentially, what we need is a way to:

• Tell whether it’s a new install or a reengaged user (we can use the redownload flag for this, but need to be able to configure reattribution windows)
• Measure retargeting efforts using not necessarily the same conversion value schema, as their behavior is different. This is particularly hard due to privacy thresholds because these campaigns are on a lower scale, and user-level data is super important (we’re targeting specific opted-in users who accepted our Terms of Service).
• Build audiences and share them with 3rd party partners in a privacy-safe way (and Audience Management tool similar to Protected Audience API)

4. Fidelity types and their limitations

What’s interesting is that SKAN does not always overreport. In the case of Meta, I’d say it’s underreporting in more cases, even when compared with Apple’s own Custom Product Pages install numbers. This is why it’s crucial to analyze further Fidelity Types and how they impact our attribution.

In SKAdNetwork, Fidelity Type 1 refers to StoreKit-rendered ads, which provide more granular and accurate postbacks, whereas Fidelity Type 0 pertains to view-through ads, offering less detailed attribution data (Apple Developer) (Apple Developer) (Unity Documentation).

Fidelity Type 1 ad leveraging SKOverlay has a 30-day window. They don’t distinguish high CPM, highly intrusive placements like a non-skippable 30s (rewarded) video or a skippable 15s video. If an ad is SKOverlay rendered, it defaults to a 30-day window. On the other hand, Fidelity Type 0 (or VTA) is 1 day, which is not too different from what we’re seeing with MMPs. Still, we live in an era where any video ad is firing a click on each impression or SKOverlay in 100% of cases, meaning that the actual % of installs coming from Fidelity Type 0 is not high.

If you add the 60-day window to open the app that extends the attribution window to 90 days. This is causing lots of issues when pausing campaigns as installs continue tricking in for months after being paused.

Why is 30 days too long?

As mentioned, 95–98% of installs happen in the first 7 days due to non-preload traffic. After 14 or 30 days, it is questionable whether the download happened due to an earlier ad exposure or something else (seeing a TV ad, for example). We would value having this information in an ideal world where we could build our own Multi-Touch Attribution model. Unfortunately, that’s not possible with the aggregated-only signal and did-win information not being shared with us. MMPs could use the did-win signal to build similar assist rate reports that we use to understand the incremental contribution of each channel.

Instead, shortening the window to 7 days would lower the amount of latent installs being reported and make it easier for us to move the budget around. It would also make it easier for algorithms to learn and make decisions as a result of shorter and more efficient feedback loops.

What about the 60-day open window

Some app preloading channels, like Digital Turbine, use a 90-day window with the same idea in mind — once the app is on the device, we should give users more time to engage. However, this is not the case with other types of networks where there is a clear install intent. Apps are downloaded on purpose, not preloaded as an ad. If someone downloads the app by clicking the install button, we should expect that user to open the app in the next 24 hours. This doesn’t always happen, but the real question is — do we need to wait for 60 more days to see it? And what are we getting from these edge cases?

We need more options

Fidelity Type 1 and 0 are not sufficient. We need a more complex attribution waterfall to distinguish different advertising approaches like preloads or static banners. As well as shorter and longer videos. MMPs do this using different tracking links. They are also trying to add a few more options like engaged click (intentional, not forced) and engaged view (3s view) which rank higher in the attribution waterfall.

Another solution is to have partner-specific configurable windows. This would likely require Apple to build an MMP-like dashboard with some simple partner-level settings, but it would help tremendously if we want to give every network the credit it deserves.

5. Creative data — no install, retention or revenue data

I think this is self-explanatory to an extent. Creatives are our number one way to control the cost per install. In most cases, we don’t have any other levers left. Most industry peers currently use Android data to understand what works better, but it’s not always 100% applicable. To my previous point, having some level of data, at least for the top-spending creatives, would be of great help.

Here is an example I used in my previous article on how creative data is used to control the cost per install payer

Creatives also stop performing (start fatiguing) after some time, and since we have a 3-day turnaround, it’s really hard to know when to replace a creative with a new one. We must rely either on Android or an early signal such as Click Through Rate to understand this. Both of these are suboptimal.

In my opinion, creative information should be included in the SKAN postback. Even if it’s not always reported, it would help us at least understand the top-spending/most successful creatives.

6. The promise and (s)low adoption of SKAN 4.0

A year later, publishers have not fully moved to SKAN 4.0. This multi-step process requires publishers to update their SDKs, MMPs to update their own SDKs, and advertisers to implement the updated SDKs and conversion schemas and start running campaigns. This takes time, and some networks are quicker to adapt than others.

I think this is where Apple failed to work closely with advertising partners to bring this solution to the market sooner. The SKAN 4.0 Meta fiasco is probably the best example of that. Please remember that Meta used to be everyone’s number-one iOS partner. It is a massive channel with sophisticated buying tools that we can’t leverage at scale on iOS anymore. Instead, we had to move the money to other channels, which is not particularly problematic, but I think this is a missed opportunity for the SKAN team to build a better solution.

To speed up adoption, it’s essential to work closely with ad networks to release the SDKs at the same time as the new version of SKAN so developers can start moving quickly. This will still take 3–6 months to implement, but it would help tremendously.

It would be great to see if it’s possible to build an SDK-less solution down the road, which would be significantly quicker to adopt.

7. The biggest promise of SKAN 4.0 was a less sparse signal

Regarding SKAN 4.0, we welcomed a higher quality signal output with arms wide open, and I think the ideas were the right ones; it’s just that the implementation is a bit too complex and not necessarily accretive to our day-to-day operations.

For example, the industry was quite vocal about the inability to spot high LTV customers in the first 24–48 hours, and Postback 2 and Postback 3 are supposed to address that. Still, the main dilemma we now have is: How useful are Postback 2 and 3?

Source: Branch

It’s hard to make optimization decisions 8–35 days after an install happened. It’s always good to err on the side of more data, and we could use this to further polish our predictive LTV models. However, ad networks likely couldn’t leverage this due to a high learning period (40 days). This would lead to a cold start problem, where we would need to run “warm up” campaigns first, focusing on CPI and then adding more complexity later. This is hard and inefficient from a ROAS standpoint.

Postback 2 is slightly better; it is coming in 7–14 days later. We’re using similar conversion windows with Google, and Apple should consider existing conversion optimization windows when building a similar solution. More about conversion windows here.

A scalable privacy-first attribution solution can exist

As I mentioned, it’s always better to err on the side of more data. We would love more signal or frequent postbacks, but that doesn’t mean we’re against Privacy-First Attribution. One of the most common misconceptions about UA teams is that we are obsessed with user-level data, but that’s not entirely true. Ad networks do care about user-level data as that helps them target more efficiently. On the other hand, UA teams optimize campaigns using aggregated data, and all we need is an accurate read on the channel/campaign/creative performance so we can make the right decisions and invest the UA budget adequately. Investing our UA budget more efficiently means our games and businesses are growing.

So what we need from future versions of SKAN is a way to figure out things like:

• Can we get low-granularity retention postbacks? Campaign level? D1 and D7
• Can we get a low granularity of creative postbacks? Installs at a creative level that meet a certain privacy threshold?
• Can we get more information on when the install happened? Even at the app level, just so we can split the organics from the rest more easily? Right now, we’re stuck using a 3-day average of installs to address the 24–48 delay.

So, it’s not all about user-level data. It’s really about understanding how to deploy more money more efficiently and grow our businesses that way.

The ultimate enhancement: Can SKAN become a queryable API?

The more I think about this, the more I am leaning towards the idea of SKAN being a queryable API solution where you can only access data at a certain level of granularity (2 dimensions — Partner and Campaign or Partner and Geo, etc). This is something FB Marketing API does as well. They give you a way to get the marketing data, but only at a limited level of granularity. You could pull ad and placement level data, but not necessarily at a geo level. Or ad and geo but without the placement information. This is quite flexible and could lead to us being able to triangulate the user-level data, but SKAN API doesn’t have to be that flexible. Again, our goal is not to breach privacy limitations — but to make better investment decisions.

So instead of getting one, two, or three postbacks, we don’t get postbacks at all. We just get a way to pull the campaign attribution data data respecting the same Crowd Anonymity/Privacy Threshold limitations. But using different dimensions. Here are a few examples:

• Get partner/creative level data with just install numbers and 2 digit source ID
  This allows us to compare creatives and accurately understand which creatives drive more engaging users. This would enable us to build better creative reporting or any creative reporting for iOS that doesn’t leverage fingerprinting. The granular data is less relevant as we only care about install numbers (to get the IPM) and whether Creative A drives more engaging players than Creative B.
• Get partner/campaign level data for the last 30 days (no daily granularity), with the full source id and fine CV. Since we’re looking at 30 days worth of data, it’s harder to understand the users who performed a specific action, but this helps us better understand the overall campaign performance.
• Get partner/campaign data at a daily level (to get install numbers) with a coarse CV and 2-digit source ID.
  Since we’re asking for daily install numbers, we can’t get access to more granular revenue/retention data. But this helps us make better estimates of where the installations come from.

These examples are just scratching the surface of what could be done if Apple decided to pursue this route. It’s also not surprising that Google uses a similar solution as part of Privacy Sandbox. As an advertising network, they understand these use cases better and the limitations of postback-based reporting solutions.

In any case, the only thing we can do at this point is wait for SKAN 5.0 and upcoming releases, which should address some of these issues. I think it’s helpful to think about potential enhancements and share your ideas with the industry, as that will help us get SKAN to a more desired state sooner. All to grow our businesses further while fully preserving users' privacy.