SKAdNetwork ROAS audit for iOS app campaigns
Before cutting an iOS campaign because SKAdNetwork ROAS looks low, check what the report has actually measured. A revenue bucket, a trial-start milestone and a missing conversion value can appear in the same dataset. They need different treatment.
SKAdNetwork provides privacy-preserving attribution signals. Its conversion values are codes defined by your app’s schema, rather than a ready-made revenue ledger. A defensible ROAS calculation needs that schema, a stated revenue horizon and matching campaign spend. Apple documents the conversion-value fields and the conditions under which they appear in its postback parameter reference.
This audit is for teams already running iOS acquisition through an ad platform and a mobile measurement partner, or MMP, or Google Analytics for Firebase. It produces a measurement decision: use the number, wait for it to mature, or repair the implementation before using it to change budgets.
Start by naming the ROAS you mean
Write the calculation in one sentence. For example: “Estimated first-window revenue represented by winning SKAN postbacks for this campaign cohort, divided by its associated media spend.”
That is different from day-30 subscription revenue divided by spend. It is also different from a network’s modeled conversion value divided by spend. Keep those views separately named:
- Bucket-derived SKAN ROAS: revenue estimated from the conversion values actually available, using a documented decoding rule.
- Platform or MMP modeled ROAS: the vendor’s estimate, using its declared inputs and methodology.
- Business revenue view: revenue recorded in your own subscription, purchase or finance systems, with its own cohort and attribution limits.
This separation is our recommended reporting convention. It helps stop a change in measurement method from being mistaken for a change in campaign economics. Google also explains that SKAN reporting and Google’s modeled App campaign reporting can disagree because their underlying logic differs. Google’s iOS reporting guidance
For each view, record the currency, date basis, revenue window, refund treatment and whether revenue is gross customer payments or net proceeds. A report labeled simply “ROAS” leaves too many ways for two teams to reach different answers.
1 Check the framework and postback maturity
Record the iOS versions, attribution framework, SDK version and ad-network integration in use. Apple now documents AdAttributionKit alongside SKAdNetwork and describes how they work together. Do not relabel an implementation as “SKAN 5” without an actual supporting specification. For an app using both frameworks, follow the current integration instructions for the participating networks and SDKs. Apple’s interoperability guide
For eligible SKAN 4 attribution, Apple defines three conversion windows measured from first launch:
- Days 0–2: first window; fine or coarse information can be available, subject to the postback data tier.
- Days 3–7: second window; coarse information can be available.
- Days 8–35: third window; coarse information can be available.
Without an early lock, the first postback has a further random 24–48-hour delay; later postbacks have a 24–144-hour delay. Locking finalizes that window’s value earlier and prevents further updates within the same window. Eligibility and privacy conditions still apply. Apple’s conversion-window reference
Operationally, mark recent cohorts as incomplete. Compare cohorts at the same age and with the same lock policy. A report generated immediately after a spend increase cannot yet answer a 35-day revenue question.
2 Find the schema that was active for the cohort
Ask for the actual mapping used by the installed app, not a slide describing the intended funnel. Keep a small schema register:
| Field | What to record |
|---|---|
| Version | Schema name, release date and effective cohort |
| Owner | Team and system responsible for conversion-value updates |
| Mapping | Fine values, coarse values and their exact event or revenue conditions |
| Revenue basis | Currency, boundaries and whether a value represents incremental or cumulative revenue |
| Timing | Window-specific logic and any early locks |
| Distribution | Which networks receive the schema and how receipt was checked |
Use this register as an operating control, not as a platform requirement. If a schema changes, retain the old decoding rules for earlier cohorts. Otherwise the same code can silently acquire a different financial meaning.
For Google App campaigns, there is an important current distinction. Google Analytics allows configuration of fine and coarse SKAN values. Google’s separate Ads integration guide, reviewed on 3 October 2026, states that its conversion modeling uses fine values and does not currently support SKAN 4 coarse values. Configuring a coarse schema in GA4 therefore does not establish that Google Ads uses those values for optimization. Google also recommends choosing one place to set up the schema. GA4 schema configuration, Google Ads schema integration
Check the event selected for bidding, its conversion settings and the documented integration for your account. Save the answer with the date; product support can change.
3 Keep missing values separate from zero revenue
Apple’s postbacks can contain a fine value or a coarse value, rather than both. Availability depends partly on privacy conditions. A missing value does not identify a non-paying customer. A code your schema explicitly maps to no observed purchase has a different meaning. Apple’s postback parameter reference
In your audit, separate:
- Postbacks with a decoded revenue bucket.
- Postbacks with a non-revenue milestone, such as trial started.
- Postbacks without a usable conversion value.
- Records that cannot be decoded because the schema version is unknown.
Report the size of each group. Investigate changes against the previous comparable cohort, SDK release and schema release. A higher missing-value share is a reason to diagnose the measurement; it is not evidence on its own that customer value fell.
Avoid universal spending thresholds advertised as a way to unlock fine values. Apple describes privacy tiers, not a dollar-per-day guarantee. Treat campaign consolidation as a testable operating choice and inspect the resulting data rather than promising that a particular budget will remove suppression.
4 Translate revenue buckets without disguising assumptions
For a revenue-based schema, the basic calculation is:
Estimated represented revenue = sum of each available bucket’s postback count multiplied by the revenue assigned to that bucket.
Divide that estimate by the spend associated with the same reporting cohort. Document how your reporting system associates delayed postbacks with campaign spend; received-date totals alone are not a complete cohort definition.
Here is an arithmetic example, not a recommended schema or a customer result. Assume three first-window buckets are cumulative revenue bands, with no overlapping counts:
| Decoded bucket | Available postbacks | Assumed representative revenue | Estimated represented revenue |
|---|---|---|---|
| $0.01 to $9.99 | 100 | $5.00 | $500.00 |
| $10.00 to $24.99 | 40 | $17.50 | $700.00 |
| $25.00 to $49.99 | 10 | $37.50 | $375.00 |
| Total | 150 | Not applicable | $1,575.00 |
With $3,000 of associated media spend, the result is 52.5%. The representative values are rounded midpoint assumptions. The result estimates revenue represented by those 150 records; it does not prove that the acquired cohort earned exactly $1,575.
If another 30 records lack a usable value, show them separately. Setting them to zero would turn missing information into a revenue claim. Increasing all bucket counts to compensate would introduce a different assumption. Either choice needs a documented model and validation, not a hidden spreadsheet adjustment.
If a coarse value means “trial started,” it has no direct dollar amount. Estimating future revenue requires a separate model of trial conversion, timing and customer value. Label the output as modeled revenue and validate it against mature business cohorts. A milestone count alone is not observed ROAS.
5 Check for duplicate and incompatible records
Confirm which source supplies each report: the ad network, the MMP, your own endpoint or a combination. Apple can send the app developer a copy of a winning postback, so two delivery routes can carry the same underlying record. Apple provides a transaction identifier for deduplicating install-validation postbacks. Developer postback copies, postback identifiers
As an audit rule, keep winning attribution separate from nonwinning records, keep sequence windows separate and do not count every later postback as another install. Also check whether later-window revenue buckets are incremental or cumulative before adding them together. Adding cumulative estimates across windows can count the same revenue repeatedly.
Do not assume that an MMP webhook, a raw SKAN postback and an ad-platform conversion API accept interchangeable payloads. A backup delivery design needs its own supported destination, consent treatment, duplicate handling and end-to-end test. Documenting a backup endpoint does not demonstrate that it preserves attribution or bidding behavior.
6 Produce a decision the media team can use
Close the audit with one of three outcomes:
Usable for the stated purpose. The cohort is mature enough, schema versions are known, records are decoded consistently and estimates are clearly labeled. This supports using the report within its stated limits; it does not prove the campaign will remain profitable.
Wait for maturity. The configuration is understood, but the required window has not finished or postbacks are still arriving. Put a review date against the cohort rather than treating the current total as final.
Repair before interpreting. The schema is missing, events are duplicated, currency is inconsistent, an integration is unsupported or the app release differs from the documented setup. Name the owner, corrective action and evidence needed to close the issue.
Keep account funding and permissions in the same launch review, but assign them separately. A measurement defect needs a measurement owner. A billing interruption needs the account or finance owner. Changing the ad-account arrangement does not by itself repair conversion-value logic.
Questions to settle before the next budget change
- Which cohort and revenue horizon does the decision use?
- Which schema version applies, and who can verify the live implementation?
- How much of the report is decoded, modeled, missing or immature?
- Are currency, spend dates and revenue definitions aligned?
- Are repeated deliveries and postback windows handled correctly?
- Does each platform support the signals the team expects it to use?
- Who approves the measurement, account-access and funding parts of the plan?
Frequently asked questions
Can I calculate ROAS from coarse conversion values
You can derive an estimate if the values map to revenue, or apply an explicitly validated revenue model to milestones. Explain the mapping and uncertainty. “High” has no universal monetary value.
Should every report agree with my MMP
Start by comparing scope, attribution logic, cohort age and revenue definitions. A mismatch is a diagnostic clue. It is not enough on its own to identify which implementation is wrong.
Does an agency ad account improve SKAN data quality
An account arrangement may change access, funding and operational responsibility. Evaluate those terms separately from the attribution implementation. Ask for evidence of the actual schema and supported data flow before accepting any measurement claim.
Discuss your setup
If your team is reviewing managed app-ad infrastructure, bring the measurement and account dependencies into the same conversation. Share your App Store URL, platforms, approximate monthly UA spend, MMP or Firebase setup, and the specific issue you need to resolve. Keep credentials and user-level event exports out of the first message.
Discuss your app setup on WhatsApp
Confirm the proposed work and responsibilities in writing before making changes.
Policy and documentation sources checked 3 October 2026. Recheck relevant platform guidance before implementation.