Apple Search Ads Attribution: Tie ASA Keywords to Real Subscription Revenue

Jamal Brooks·10 min read

Key Takeaways

  • Apple Search Ads reporting stops at the install, so bidding on install cost alone can fund keywords that never turn into paying subscribers.
  • The AdServices token is Apple's one sanctioned, ATT-free way to resolve the keyword behind an install, but it expires quickly and says nothing about revenue.
  • Real ASA attribution means stamping the resolved keyword onto the actual subscription charge at settlement, so it survives token expiry, renewals, and refunds.
  • RevenueCat normalizes App Store subscription revenue but cannot tell you the keyword on its own, so you must feed the ad source in to close the loop.
  • Keyword-level ROAS and LTV on settled, refund-adjusted revenue reorder bids by profit instead of by cost per download, and cover both web and in-app sales.

You are spending real money on Apple Search Ads, and your Apple Search Ads attribution stops at the install. Apple tells you a keyword drove a tap and an install, maybe a download conversion rate, and then the trail goes cold. It never tells you whether that install turned into a paying subscriber, whether that subscriber renewed, or whether the keyword that looks cheapest per install is actually the one bleeding money once you count who pays and who churns. If you sell a subscription app, the install is not the finish line. The charge is.

This is the core problem with ASA attribution as most teams run it: you are optimizing bids against installs, but installs are not revenue. A keyword can be a install machine and a revenue graveyard at the same time. The only way to fix it is to connect the keyword that drove the tap to the actual subscription charge that settled later, and keep that link alive through renewals and refunds. This post walks through how that works, what the AdServices token gives you, where RevenueCat closes the loop, and how to set up keyword-level ROAS on real revenue without stitching three dashboards together by hand.

Why Apple Search Ads reporting stops at the install

Apple Search Ads Campaign Management gives you tap-through rate, average cost per tap, average cost per acquisition, and conversion rate down to the keyword. That is genuinely useful for the top of the funnel, and Apple deserves credit for keyword-level granularity that most privacy-first ad networks no longer offer. But every one of those metrics ends at the App Store product page or the install. Apple sees the tap and, through the App Store, the download. Apple does not see your paywall, your trial, your first charge, or the renewal fourteen months later.

That gap matters because subscription economics live entirely on the far side of the install. Consider a meditation app running two keywords. The generic term "meditation" installs cheaply at two dollars per install. The intent term "sleep anxiety help" installs at six dollars. On an install-cost basis, "meditation" wins by a mile and you shift budget to it. But if the intent keyword converts installs to paid trials at four times the rate and those subscribers renew twice as often, the expensive keyword is the profitable one and the cheap keyword is quietly torching your budget. Install-level reporting cannot see any of that. It grades keywords on the wrong exam.

The second reason reporting stops at the install is privacy. Apple built Search Ads to work without cross-app tracking and without asking for the App Tracking Transparency prompt, which is exactly why it is attractive. But that same design means the ad network and your analytics do not share a device identifier you can join on later. You need a different mechanism to carry the keyword forward, and Apple provides exactly one: the AdServices token.

What the AdServices token gives you (and what it does not)

When someone taps your Apple Search Ad and installs your app, your app can call Apple's AdServices framework and receive a short attribution token. You send that token to Apple's Apple Ads Attribution API, and Apple returns the campaign, ad group, and keyword that drove the install, along with a claim type that tells you whether it was a click-through or a broader match. This is AdServices token attribution, and it is the sanctioned, deterministic way to learn which ASA keyword produced a specific install without any tracking prompt.

Here is what the token genuinely gives you:

  • Keyword-level source for each new install, deterministically, on iOS, without the ATT prompt

  • Campaign and ad group context so you can roll keyword data up cleanly

  • A claim type so you can separate exact keyword taps from broad and search-match installs


Here is what the token does not give you, and this is the part most teams miss. The AdServices token is a one-time signal captured at install. It tells you the keyword. It says nothing about whether that install ever paid you. The token has a short validity window, so if you do not redeem it promptly you lose the keyword entirely. And the token lives on the device at install, which means you have to capture it in your app, hold onto the resolved keyword, and carry it all the way to the moment money changes hands. Apple hands you the keyword and then walks away. Connecting that keyword to revenue is your job, and that is where almost every ASA setup falls apart.

Connecting ASA keywords to the actual subscription charge

The mechanism that makes App Store install attribution useful is the same one that makes any first-party attribution useful: you stamp the source onto the transaction at the moment the transaction settles, so attribution becomes a permanent property of the order rather than a fragile browser or device signal that expires. We cover the general pattern in our guide to first-party ad attribution, and ASA is a clean example of it in action.

The flow looks like this. Your app calls AdServices at install and gets the token. Your SDK sends that token to your attribution backend, which redeems it against Apple's Attribution API within the validity window and resolves the campaign, ad group, and keyword. That resolved keyword gets attached to the visitor or user identity, not to a cookie and not to a device advertising ID. Then, when that user starts a trial and later converts to a paid subscription, the subscription charge that settles (through Stripe if you bill on the web, through the App Store and RevenueCat if you bill in-app) gets the ASA keyword stamped directly onto it at settlement time.

In Affiliateo, that stamping happens at sale time through the ad_source field. The visitor arrives with an ASA keyword resolved from the AdServices token. When the charge settles, a trigger writes the ad source, the campaign, and the keyword identifiers onto the conversion record before it is inserted. From that point on the attribution does not depend on the token still being valid, the device still being reachable, or any retention window. It rides with the charge. If Apple later refunds the subscription, the refund flows through and the keyword's revenue adjusts down to the truth. If the subscriber renews two years later, the renewal inherits the original keyword so lifetime value keeps accruing to the term that earned the customer.

Keyword-level ROAS instead of install-level guesswork

Once the keyword is stamped on the charge, Apple Search Ads ROAS stops being a guess. You divide the real, settled revenue attributed to a keyword by what you spent on that keyword, and you get true ASA keyword ROAS on money you actually kept, not on installs you hoped would convert.

The difference in decision-making is stark. Here is how the same three keywords look under install-level reporting versus revenue-attached attribution.

KeywordInstall-level viewRevenue-attached viewRight call
meditationCheap installs, best CPALow trial-to-paid, high churn, negative ROASCut or cap the bid
sleep anxiety helpExpensive installs, worst CPAHigh trial-to-paid, strong renewals, positive ROASScale the bid
calm app freeCheapest installs of allAlmost no paid conversions, brand tire-kickersPause

Under the install view you would fund exactly the wrong keywords. Under keyword-level revenue you fund the term that produces paying, renewing subscribers even though it costs the most per install. That is the entire point of measuring subscription revenue by keyword: it reorders your bids by profit instead of by cost per download.

How RevenueCat closes the loop for iOS subscriptions

If you bill subscriptions inside the app through StoreKit, your revenue truth does not live in Stripe. It lives in the App Store, and RevenueCat is the standard way teams normalize App Store and Google Play subscription events into clean, deduplicated revenue data with trial conversions, renewals, and cancellations handled correctly. RevenueCat is genuinely excellent at what it does: it turns messy StoreKit receipts and server notifications into a reliable subscription revenue stream, and it will happily tell you your total MRR and churn.

What RevenueCat does not do on its own is tell you which Apple Search Ads keyword produced that MRR. RevenueCat Apple Search Ads attribution requires you to feed the ad source in, because RevenueCat sees the subscription, not the ad tap. This is the join that closes the loop. Affiliateo redeems the AdServices token, resolves the keyword, and stamps that keyword onto the RevenueCat subscription event when the charge settles. The renewal webhook from RevenueCat carries the original keyword forward, so you measure Apple Search Ads revenue and lifetime value on the real subscription stream, whether the first dollar came through Stripe on the web or through the App Store in the app.

That web-plus-app coverage is the part that unifies everything. A user might tap your ASA keyword, install the app, poke around, then later subscribe on your website through Stripe because you offered a discount there. A cookie-based tool loses that entirely. Because the keyword is stamped on identity and then on whichever charge settles, the sale still credits the Apple Search Ads keyword even though it closed on the web. One attribution model covers both surfaces.

Setting up ASA attribution self-serve in Affiliateo

You do not need a mobile measurement partner contract or a solutions engineer to wire this up. The setup is self-serve and follows the same three-step shape as every first-party integration:

  • Connect Apple Search Ads through the App Store card, which authorizes read access so spend and keyword metadata sync automatically alongside your revenue

  • Drop in the Swift SDK (or the React Native, Flutter, Kotlin, or web SDK if your stack is cross-platform), which captures the AdServices token at install and hands it to Affiliateo to redeem within the token window

  • Point your RevenueCat or Stripe webhook at Affiliateo so settled subscription charges get the keyword stamped at sale time


Once spend is flowing in from Apple and revenue is flowing in from RevenueCat or Stripe, the dashboard joins them on the keyword and you read ROAS and LTV per keyword directly. If you are still setting up your UTM discipline on the web side of the funnel, our UTM tracking guide pairs well with this, since web-billed subscriptions should carry consistent source tags that resolve the same way the ASA keyword does.

Reading LTV by keyword, not just installs

Installs are a moment. Lifetime value is the whole story, and it is where subscription businesses are won or lost. Because the ASA keyword rides on the charge and gets inherited by every renewal, you can watch a keyword's cohort mature. A keyword might look mediocre in month one because trials have not converted yet, then reveal itself as your best performer by month four once renewals stack up. Install-level and even first-charge ROAS both miss this. LTV by keyword catches it.

Reading LTV by keyword also changes how you handle refunds and cancellations honestly. When Apple issues a refund, that revenue leaves the keyword's total, so you are never looking at inflated numbers that count money you had to give back. The keyword's ROAS is always the settled, refund-adjusted truth. That is the same discipline that makes web ad measurement trustworthy, and it is why we treat revenue-attached attribution as the baseline rather than a nice-to-have across the whole platform, from Meta ads ROAS to Apple Search Ads.

Common ASA attribution pitfalls

A few mistakes show up again and again when teams try to measure Apple Search Ads revenue:

  • Letting the AdServices token expire before redeeming it, which silently drops the keyword and leaves installs looking organic

  • Attributing on the install event instead of the charge, so you optimize toward downloads that never pay

  • Trusting Apple's reported conversions as revenue when they are download conversions, not dollars

  • Losing the keyword on renewals because the renewal event does not inherit the original source, which collapses your LTV to first-charge only

  • Running ASA data in one tool and subscription data in another and eyeballing the join, which never survives contact with real volume

  • Ignoring the web path, so a keyword-driven install that subscribes on your website files as direct


Every one of these traces back to the same root cause: attribution that lives in a fragile signal instead of on the transaction. Fix that and the pitfalls disappear.

If you are running Apple Search Ads and still guessing at which keywords actually pay, that guessing is optional. Affiliateo redeems the AdServices token, resolves the keyword, and stamps it onto the real Stripe or RevenueCat charge at sale time, so you get keyword-level ROAS and LTV on revenue you actually kept, across web and App Store, self-serve. Connect Apple Search Ads, drop in the SDK, and read your true numbers by keyword instead of by install. Try Affiliateo and see which keywords earn.

apple search adsattributionrevenuecatsubscription roas

Written by Jamal Brooks

Jamal is a product engineer at Affiliateo who writes about payments, integrations, and technical best practices.

Frequently Asked Questions

Related Articles