First-party install attribution and RevenueCat-only attribution

RevenueCat can send SpendDaddy subscription events and subscriber attributes. That is enough to report revenue and, when the attributes are present, connect a customer to an Apple Search Ads placement.

First-party install attribution records the install when it happens and asks Apple for attribution at that point. It gives SpendDaddy the install time, the Apple Search Ads result, and a stable user record before a trial or purchase occurs.

The most useful setup for an app that uses RevenueCat is usually this:

1. Send /identify once when the app first identifies a user, with installedAt and the Apple Search Ads token.
2. Keep the same appUserId in RevenueCat.
3. Let RevenueCat continue to send trial, purchase, renewal, refund, and cancellation events through its webhook.

SpendDaddy joins the RevenueCat events to the first-party install record by appUserId. The placement then exists before revenue arrives.

What each source knows

	First-party install attribution	RevenueCat-only attribution
When SpendDaddy first sees the user	At install or first identification	When RevenueCat sends an event for the customer
Install time	The installedAt value supplied by your backend	Usually inferred from the first RevenueCat event SpendDaddy receives
Apple Search Ads placement	Apple AdServices response for the submitted asaToken	RevenueCat subscriber attributes, if your app wrote them and RevenueCat includes them in the event
Trial and purchase events	Send through /event if you use the first-party API for revenue	RevenueCat webhook
Revenue details	Your event payload	RevenueCat webhook payload
Best use	Accurate acquisition cohort and placement assignment	Subscription revenue and lifecycle events

RevenueCat-only attribution has two blind spots for placement analysis. A user who never starts a trial or purchase may never produce a RevenueCat event. And when a RevenueCat event is the first record SpendDaddy receives, the event time can stand in for the install time. That shifts the user into the wrong acquisition cohort if the install happened earlier.

RevenueCat attributes can still match a placement. SpendDaddy reads Apple Search Ads fields such as searchAdsCampaignId, searchAdsAdGroupId, and searchAdsKeywordId, plus the equivalent campaign, ad group, and keyword names. The match depends on your app sending those values to RevenueCat and RevenueCat returning them with the customer event.

The install call

Send this request from your backend when it first knows the stable app user ID. The bearer key belongs in server-side storage.

{
  "appUserId": "user_123",
  "installedAt": "2026-09-11T08:42:17Z",
  "asaToken": "apple_ads_attribution_token"
}

appUserId

appUserId is required. It creates or finds the SpendDaddy user record and is the join key for every later event.

Use the exact same stable ID in the RevenueCat SDK and in the /identify request. If /identify uses user_123 and RevenueCat reports a purchase for anonymous_456, SpendDaddy stores two users. The first record has an install and placement. The second has revenue. Neither can be used to calculate placement ROAS.

Do not use an ID that changes after login unless you also preserve the original RevenueCat identity. Anonymous users need a stable ID for their full acquisition and purchase path.

installedAt

installedAt is optional in the API but should be sent whenever your backend has the install time. It sets the user’s acquisition date and the date used to place their trial and revenue in an install cohort.

Without it, SpendDaddy uses the time it first sees the user. That may be the first request to your backend, the first first-party event, or a later RevenueCat event. Delayed registration, an offline first launch, and a trial that starts days after installation can all move the user into a later cohort.

Accurate install times make these measurements meaningful:

• install-to-trial rate
• install-to-paid rate
• revenue by D7, D30, D60, and D90 from acquisition
• cost per trial, payer, and expected payer
• comparisons between placements acquired on the same dates

asaToken

asaToken is optional in the API, but it is required to ask Apple AdServices for this install’s Apple Search Ads attribution. Your app obtains the token and forwards it to your backend. Your backend sends it to SpendDaddy in /identify.

When Apple returns a paid attribution, SpendDaddy records the campaign, ad group, keyword, country, and creative-set information in the install record. RevenueCat purchases for the same appUserId can then be assigned to that placement.

The response reports one of three states:

attribution value	Meaning
fetched	SpendDaddy submitted the token and received an Apple attribution response.
failed	SpendDaddy could not resolve the token. The install remains recorded without a resolved Apple Ads placement.
not_requested	No token was supplied. The install is recorded, but SpendDaddy did not ask Apple for paid attribution.

not_requested does not mean that the user was organic. It means SpendDaddy has no Apple response with which to classify the install. An organic user and a paid user with no submitted token are indistinguishable at the placement level.

How the hybrid setup improves analysis

First-party identification fixes the cohort before RevenueCat reports monetization. RevenueCat then adds the subscription lifecycle to that cohort.

For example, a user installs from keyword A on September 1, starts a trial on September 3, and converts on September 10. With installedAt and asaToken, SpendDaddy records the September 1 install and assigns all three events to keyword A. The September 1 cohort has one install, one trial, and one paid conversion.

With RevenueCat-only attribution, SpendDaddy may first see the user on September 3. If the needed subscriber attributes are absent, keyword A is unknown. If the attributes arrive, the keyword can be resolved, but the acquisition date may still be September 3 rather than September 1. D7 and D30 revenue are then measured from the wrong start date.

This matters most for early placement decisions. An install is available immediately, a trial often arrives later, and payment may arrive after a trial period. First-party attribution lets a dashboard count the full denominator for a placement from day one. RevenueCat supplies the later numerator. The result is a cleaner early conversion rate and a more credible estimate of future revenue.

What first-party attribution does not solve

First-party attribution does not make every install a paid Apple Search Ads install. Apple decides whether an attribution response identifies an Apple Search Ads placement. Organic and other non-Apple sources should remain unassigned to a paid placement.

It also does not replace RevenueCat’s subscription lifecycle unless you send every corresponding first-party event yourself. If RevenueCat remains your source of truth for billing, keep its webhook connected and send the same user ID through both systems.

Read Send first-party events for request and event details, and Connect RevenueCat for webhook setup.