· 12 min read · Samet Durgun · Platform facts checked

Can SKAN measure a subscription payment after the free trial ends?

I am Samet Durgun, a fractional Head of UA. I run paid UA for subscription apps and mobile games and write up what I find in the accounts I manage. This piece sits under what signal engineering fixes; more about me.

Sometimes, and only as a coarse value (low, medium or high), never as a fine one. The charge after a free trial happens on Apple’s side and reaches RevenueCat server to server, while SKAN only records what the app writes on the device. So the payment counts only if your one conversion value writer runs in the app before the window it falls in closes. Trial length changes the answer. With no trial, the first payment can land in the first window as a fine value. The shortest free trial Apple offers (3 days) already pushes it into the second window, and a 1 week trial usually into the third, both coarse only. A trial that ends after day 35 misses every window.

Scope: iOS subscription apps with RevenueCat, an MMP (AppsFlyer and Singular are the two whose relay rules I checked) or Firebase, on SKAdNetwork 4 and AdAttributionKit, buying on Meta and Google, all regions. Every platform fact was checked against the vendor’s own page on 1 October 2026.

What happens between “RevenueCat recorded the payment” and “the device updated the value”?

Six steps, and the gap sits between the third and the fifth.

  1. First launch. Apple’s clock starts here. The SKAdNetwork page Receiving postbacks in multiple conversion windows sets three windows from the first launch: days 0 to 2, 3 to 7 and 8 to 35. Only the first postback can carry a fine value, which Apple’s update method defines as a number from 0 to 63.
  2. Trial start. Usually on the paywall in the first session, inside window 1, where the SDK on the device sees it.
  3. Confirmed payment. When the trial ends, the App Store charges. RevenueCat’s Event Types and Fields reports a successful first charge as a RENEWAL with is_trial_conversion set to true. A trial nobody cancelled is not a payment, and neither is an active entitlement. Apple’s Reducing involuntary subscriber churn says a failed renewal enters billing retry for up to 60 days, and with Billing Grace Period on, the user keeps full access while Apple tries to collect.
  4. Server relay. RevenueCat sends the event to the MMP server to server. AppsFlyer’s SKAN Conversion Studio says AppsFlyer recalculates the value, the SDK updates the device if the app is open, and otherwise the server waits for the next app open, which must happen before the window expires or the event is disregarded. Singular’s S2S Support for Conversion Models FAQ describes the same wait for a feature you ask Singular to switch on. It works in managed SKAN mode only, and if the window closes or the user never reopens the app, Singular cannot update the value.
  5. Device execution. The SDK calls Apple’s update method. The value lands in whichever window is open at that moment, not the window the charge happened in. Apple’s updatePostbackConversionValue page says the fine value is ignored after the first window.
  6. Postback. After the window closes, Apple sends the postback after a random delay: 24 to 48 hours for the first, 24 to 144 hours for the second and third. Apple also says the app has to update the value during each window to be eligible for more than one postback, so a user who never opens the app between day 3 and day 7 leaves window 2 with nothing to report. An ad in Apple’s lowest tier, Tier 0, gets no second or third postback at all.

Who writes the conversion value?

One writer, on the device. Every update method Apple documents is a call the app makes. I found no server API.

RevenueCat is not that writer. Its Meta Ads page says it “doesn’t update SKAN conversion values” and recommends one updater, whether the app, the Meta SDK or an MMP, so values do not conflict. Its Singular page says it cannot modify them from its server events. Its AppsFlyer page also tells you to remove client side revenue tracking to avoid double counting, which means that with this setup even a day 0 purchase can reach the AppsFlyer SDK only through the server relay.

A second writer is the failure the vendors warn about. Google’s Set up your SKAdNetwork conversion value schema says it is highly recommended to set up the schema in one place. The Google Analytics version of Set up your SKAdNetwork conversion value schema has an option that lets the Firebase SDK set the value for each window, and Firebase’s Get started with Google Analytics for iOS+ says the SDK registers the app with SKAdNetwork automatically unless you set GOOGLE_ANALYTICS_REGISTRATION_WITH_AD_NETWORK_ENABLED to NO. AppsFlyer’s SKAN 4.0 anomalies explained says any update overrides the preceding one, including SKAN 3 style updates and install registrations from another SDK. That post first ran in August 2023 and is a vendor’s account, not Apple’s. Apple’s method page does not say what happens when two SDKs call it.

AdAttributionKit does not add a writer. Apple’s Understanding AdAttributionKit and SKAdNetwork interoperability says SKAdNetwork conversion value calls are mirrored into AdAttributionKit and only one impression wins across both frameworks.

Which window can the first payment land in?

The table assumes the trial starts in the first session. A trial started on day 2 moves every date two days later. The trial lengths are the free trial durations Apple lists in Set up introductory offers for auto-renewable subscriptions, where the shortest is 3 days. The window 2 and window 3 cells hold only for ads in Tier 1 or above, because a Tier 0 ad gets no postback after the first.

Trial First charge, days after first launch Window and value it can carry MMP SDK on device, payment relayed from RevenueCat MMP server to server only, no MMP SDK Firebase as a second writer
None Day 0, in the session Window 1. Fine at Tier 2 or 3, coarse only at Tier 1, no value at Tier 0 Written if the relayed event reaches the SDK while the app is open, or at the next open before day 2 ends Not written. Singular says its relay needs its SDK in the app, and AppsFlyer’s relay runs through its SDK Whichever SDK writes later replaces the other’s fine value
3 day About day 3 Window 2, coarse only. Window 3 if the first open after the charge comes after day 7 Written at the first app open after the charge, if it comes before day 35 Not written A later write replaces the coarse value
1 week About day 7, when window 2 closes Window 3 in practice, coarse only Written at the first app open after the charge, if it comes before day 35 Not written A later write replaces the coarse value
2 weeks or 1 month About day 14, or day 28 to 31 Window 3, coarse only. A trial that ends after day 35 lands in no window Written only if the user opens the app between the charge and day 35 Not written A later write replaces the coarse value

Add the postback delay to read it as a calendar. A window 3 payment reaches your MMP between day 36 and day 41 after first launch, unless the window was locked early.

What does RevenueCat’s own guide cover, and what does it leave out?

RevenueCat’s How to use RevenueCat server-to-server events for SKAdNetwork attribution, published 18 February 2025, is the most detailed vendor guide on this problem that I know of. It places trials shorter than seven days in window two and seven day trials in window three, which matches the table, and it offers two fixes: checking the trial status each time the app comes to the foreground, and a silent push when the trial ends. It also says its approach does not guarantee full accuracy. What I would add:

  • Apple’s limits on silent push. Apple’s Pushing background updates to your App says background notifications are low priority, delivery is not guaranteed, the system may throttle them (Apple says not to send more than two or three per hour), and a held notification is discarded if the app is force quit. One of the guide’s takeaways, that using Apple’s server notifications through RevenueCat tracks conversions without the user opening the app, goes further than Apple’s documentation supports.
  • The writer. The guide’s code writes to SKAdNetwork from the app. If your MMP SDK also writes, you now have two writers. Route the event through your one writer instead.
  • Payment against entitlement. The guide’s check reads an active entitlement that is no longer in its trial period. Map the value to the collected charge instead, because Billing Grace Period can keep an entitlement active while Apple is still trying to collect.
  • What the platforms do with the value, in the next section.
  • Framework changes since. Apple’s AdAttributionKit Updates page lists changes in June 2024 and June 2025, and nothing in 2026 as of this check.

What do Google and Meta do with a coarse trial payment?

Google says it does not use it. The Google Ads schema page says Google’s conversion modeling uses only fine values and that “we currently do not support SKAN version 4’s coarse conversion values”. The same page asks for more than 10 conversion events a day for each event in the schema and around 50 installs a day. Those are Google’s schema guidelines, not Apple’s privacy threshold, and Apple publishes no install number for its tiers. So for iOS App campaigns, the SKAN signal Google learns from is what happens in the first two days. Google’s modeled conversions and its Integrated Conversion Measurement are separate from SKAN, and I set the three side by side in why Google Ads, the MMP and SKAN report different iOS conversions.

Meta has its own setup. Configure Apple’s SKAdNetwork in Meta Events Manager lets you configure events with fine and coarse values for SKAdNetwork 4, by Meta’s recommendations, by importing your MMP’s schema, or by hand, and it says Meta is gradually introducing SKAdNetwork 4 support that may not be available to you yet. Prepare your app integration for Apple’s SKAdNetwork asks apps that use the Facebook SDK for iOS for version 16.2.1 or later, and advises against decreasing conversion values or using lock windows. AppsFlyer offers both: a setting that lets negative revenue, such as a refund, lower the value, and a lock that sends the postback early. If Meta is where most of your iOS budget goes, decide those two settings with Meta’s advice in front of you. The configuration page says events with coarse values may help ad performance. It does not say how delivery weighs a coarse value from window 3, and I found no Meta page confirming AdAttributionKit postbacks, so I claim neither.

What does this mean for the Meta optimization event?

On SKAN, the trial payment arrives late, coarse, and only for users who open the app after paying. An event from the first session arrives in window 1 and can be fine. So the events SKAN can report to Meta quickly are early ones: a trial start, a trial start with a condition that predicts payment, or a paid plan bought on day 0. The payment can still sit in the schema for windows 2 and 3, as a coarse value. I would read it there as a late report on the cohort and not count on it to steer delivery, since Meta does not say how delivery weighs it. Meta’s Aggregated Event Measurement is a separate path with its own rules, and when Events Manager marks the trial or the purchase ineligible there, the checks are in why trial and purchase events are ineligible for Meta AEM. The choice of event itself is in which event a subscription app should optimize for.

What changes for a mobile game?

Most of the relay problem goes away, because the payment happens in the session. When the MMP SDK logs an in app purchase on the device itself, it can write the value in that session, and window 1 can carry it as a fine value. AppsFlyer’s Conversion Studio can measure overall revenue, including ad revenue, through one event, af_skad_revenue, and notes that ad revenue values never go negative. A hybrid game can split its 64 fine values in window 1 between purchases, ad revenue and progression, and use the coarse values in windows 2 and 3 for retention or a first purchase.

The harder part is volume. Apple sets the tier from crowd size, a soft launch is small by design, and a Tier 0 ad gets one postback with no value. Fewer, larger campaigns clear the tiers sooner, which I cover in fewer campaigns, more signal. What a soft launch has to prove, and the SKAN schema for it, is on mobile game user acquisition.

How do you test it before spend goes up?

I would run four checks before a trial schema carries budget.

  1. The writer. One SDK calls Apple’s update method, and Google and Meta are given the same schema it follows. Firebase’s option to set values and every other SDK’s SKAN updates are off.
  2. The event. The payment maps to the collected charge, RevenueCat’s RENEWAL with is_trial_conversion, not to trial start plus no cancellation.
  3. Both relay paths. AppsFlyer documents two paths for a server event: the SDK updates the value at once if the app is in use, or the server holds it for the next app launch. Trace one relayed trial conversion down each path on a test device and record when the update call ran.
  4. The cohort read. For a matured cohort, at least day 41 after first launch, compare the trial conversions RevenueCat records for users your MMP attributes to that network with the payment values your MMP decoded for windows 2 and 3. The gap mixes payments written too late, Tier 0 ads that get no later postback and attribution differences between the two sources, so report it as a gap. Do not scale it up to fill the difference.

Where does this sit in my work?

This is the iOS part of signal engineering: one writer, a schema built around your trial and your volume, and a written expectation of what SKAN will and will not show before anyone judges a campaign on it. If you are not sure whether measurement is the problem, the growth audit is where I check.

Sources

All checked on 1 October 2026.

Questions people ask

Can RevenueCat update SKAN conversion values?

No. RevenueCat's Meta Ads documentation says it does not configure SKAN or AEM and does not update SKAN conversion values, and its Singular page says it cannot modify them from its server events. RevenueCat sends the trial conversion to your MMP or ad platform, and the app on the device still has to write the value.

Does a silent push make sure the trial payment reaches SKAN?

No. Apple says it treats background notifications as low priority, does not guarantee their delivery, may throttle them, and discards a held notification if the app is force quit. When the system does deliver it, a silent push wakes the app in the background, which gives the app a chance to write the value. It cannot make the measurement complete.

Does Google Ads use SKAN 4 coarse conversion values?

Not according to Google Ads Help on 1 October 2026. Its schema page says Google's conversion modeling uses only fine values and that it does not support SKAN 4 coarse values. A trial payment that can only arrive in the second or third window, as a coarse value, does not feed that modeling.

Should Firebase and my MMP both set conversion values?

No. Pick one writer. Google recommends setting up the schema in one place, RevenueCat recommends one updater, and AppsFlyer says any update overrides the preceding one. If your MMP writes the value, leave the Google Analytics option that lets the Firebase SDK set values switched off.

Do I need AdAttributionKit if I already use SKAdNetwork?

They work together. Apple mirrors SKAdNetwork conversion value calls into AdAttributionKit, and only one impression wins across both frameworks. The three windows and the fine and coarse rules are the same, so the trial timing in this post applies to both. Ask your MMP which framework its SDK calls.