How SKAdNetwork web attribution preserved payments for iOS installs

New payment terms put iOS install revenue at risk

A key partner of a large international advertising agency changed its terms. The partner, an advertiser with a mobile app, would pay only for installs confirmed by postbacks through AppsFlyer. A postback is an automated install notification. AppsFlyer handles attribution: linking an install to its advertising source so the advertiser can measure results.

Users arriving from websites posed a particular challenge. A substantial share used iOS, and confirming installs after website ads required SKAdNetwork, Apple's install-attribution mechanism. It reports installs to the ad network without revealing the user's identity.

Colleagues working with advertisers brought me the problem. Without these confirmations, the agency would lose payment for iOS installs from one of its main partners. It could still attract users through websites, but the commercial viability of that work was at risk.

Available integrations covered in-app ads, not websites

Before building a custom solution, I investigated existing options. At the time, the major ad networks I checked had integrated SKAdNetwork only for ads inside mobile apps. Our scenario was different: a user saw an ad on a website and then installed an app on an iOS device. No ready-made solution existed for this use case then.

The agency needed its own ad network, registered with Apple and supporting SKAdNetwork. I could not find a useful practical implementation guide online. On Stack Overflow, I found a discussion of a similar problem: a developer at a major ad network could not get the integration working and reported waiting months for an answer from Apple.

That experience showed why relying solely on vendor support was not enough. Apple did not provide help in time for our project either, so I had to investigate the failures independently.

Reconciling documentation across Apple and AppsFlyer

Apple's documentation was the starting point, but it lacked implementation details. AppsFlyer's documentation filled some gaps. However, the two platforms' materials described different integration versions and could not simply be combined into a working guide.

I compared the requirements and reconstructed the full data flow. The documents explained individual mechanisms but did not explain why a particular test produced no result. Each support team addressed only its own part of the integration. I remained responsible for making the entire chain work.

Testing in parallel despite delayed feedback

I built the ad network's backend and a test environment. I used it to test hypotheses by changing integration conditions and checking whether an install postback arrived.

Tests did not produce immediate answers. SKAdNetwork delays postbacks to protect privacy by making notifications harder to associate with individual users. An accelerated debugging mode was available, but it still involved waiting. Testing every option sequentially would have prolonged the work considerably.

Instead, I ran several experiments in parallel, testing different ways of interacting with the ad network. Each waiting period then produced results for multiple hypotheses, helping me identify the necessary changes sooner.

Completing the chain from Apple to the advertiser

I registered the agency's ad network with Apple and connected it to AppsFlyer. Advertisers also needed to configure their side of the integration, and I helped them complete that setup.

The full confirmation flow then worked: an iOS user installed the app after seeing a website ad; Apple sent a SKAdNetwork postback to the agency's ad network; the data then reached AppsFlyer and appeared in the advertiser's dashboard.

The partner received confirmations in the required form. The agency retained the partnership and continued receiving payment for iOS installs under the new terms, preserving a part of its business that had been at risk of losing revenue.

I completed all the technical work myself, from researching the documentation to developing and launching the integration.

A separate AppsFlyer integration to recover missing data

An earlier project involved a different problem. A mobile app development team approached me because its standard tracking tools were losing a substantial amount of data. No suitable ready-made solution was available. Before building a custom AppsFlyer integration, I needed to understand the incoming data and how it was processed.

I wrote a backend using Python and FastAPI. It received data from the mobile apps, parsed and structured it, then sent server-side postbacks to AppsFlyer. After launch, tracking worked correctly, and the team was pleased with the result.

Both projects required checking the entire data path to AppsFlyer, not just connecting a service. For the agency, install confirmations determined payment. For the mobile development team, the priority was complete tracking data. I discuss why metrics differ between systems and how to investigate them in my article on analytics discrepancies.