For subscription apps: see when each campaign pays back

How RevenueCat revenue reaches the right campaign

The join is one user id. The app gives the same id to the Traqio SDK (userId) and to RevenueCat (app_user_id); RevenueCat's webhook then sends each purchase to Traqio server to server, and Traqio attaches it to the install it attributed for that user.

• Initial purchases, renewals and non-renewing purchases are ingested, with RevenueCat's event id as the deduplication key.
• The webhook is authenticated with a secret shown on the app's RevenueCat card — not the public SDK key that ships in the app.
• No revenue is sent from the device for these purchases, so no client secret lives in the app.

A worked example

ROAS is attributed revenue divided by spend, computed per campaign. In an illustrative month, an app spends $500 on a Meta campaign and $300 on a TikTok campaign; the installs attributed to the Meta campaign generate $1,200 of revenue and those attributed to the TikTok campaign generate $480.

The figures are arithmetic chosen for readability, not a typical or target result; this page publishes no ROAS benchmark. What the example shows is the shape of the calculation Traqio runs for every campaign, ad set and ad, every day.

• Meta campaign: $1,200 ÷ $500 = ROAS 2.4
• TikTok campaign: $480 ÷ $300 = ROAS 1.6
• Both campaigns together: $1,680 ÷ $800 = ROAS 2.1

Why the networks' own numbers don't add up

A self-reporting network is an ad platform — such as Meta, Google or TikTok — that measures and reports its own campaign results, so its numbers cannot be independently verified from the platform itself. When Meta and TikTok both credit themselves with the same install, the revenue of that user is counted twice and both networks' ROAS looks better than the business result.

A typical question from a team running both networks: Meta reports 300 installs, TikTok reports 260, and the app sold 410 subscriptions — what did the $800 actually return? Answering it requires assigning each install to one network before dividing, which is the job of a third party rather than of either network.

Traqio assigns each install once, attaches the revenue of that user to the same campaign, and divides by that campaign's spend. The revenue credited to Meta and to TikTok then adds up to the account's real attributed revenue instead of exceeding it, so the account's ROAS is not inflated.

Where the two halves of ROAS come from

Attributed revenue is in-app revenue — subscriptions and in-app purchases — matched back to the campaign that drove the install of the paying user. Traqio reads that revenue from three sources and reads the spend from the Meta and TikTok ad accounts directly.

Traqio reports attributed revenue gross: the purchase price reported by the SDK or by RevenueCat, before the app store's commission. Traqio's ROAS is therefore a gross-revenue ratio, and a team reasoning in net revenue should apply its own store commission on top.

The RevenueCat join is a single rule: the app user id set in RevenueCat must equal the user id passed to the Traqio SDK. When the two ids match, every renewal attaches to the install that acquired the subscriber, months after the install.

• Revenue events sent by the Traqio SDK, with the value and currency the app provides.
• Subscription and in-app purchase events from RevenueCat webhooks, matched to the install through a shared user id.
• Impression-level ad revenue from AdMob.
• Daily spend from the Meta Marketing API and the TikTok Reporting API, at campaign, ad set and ad level.

D0 cohorts: install day counts

D7 ROAS is the revenue attributed to a campaign within seven days of install, divided by that campaign's spend; D0 counts install day itself. Traqio counts D0, so revenue earned in the first hours after install is part of every cohort instead of being dropped.

An install cohort is the set of users who installed the app on the same day; ARPU for a cohort is its revenue divided by its number of users at a given day since install. Cohort days in Traqio are measured from install, not from the calendar date. Vendors differ on whether day 0 is counted; Traqio states its convention because a stated convention can be compared and a hidden one cannot.

Lifetime value (LTV) is the total revenue a user is expected to generate over their lifetime in the app. Traqio shows realised LTV — revenue observed to date for the cohort — and does not show a predicted LTV.

When the numbers arrive, and why a closed day can still change

Traqio pulls Meta and TikTok spend once a day, at 04:30 UTC, for the previous three days, and never writes the current day. Spend therefore appears in Traqio the day after it is incurred; attributed revenue appears as soon as the revenue event arrives.

The three-day lookback exists because ad networks restate spend after the fact — late-billed impressions and invalid-traffic credits change totals for a few days. Traqio re-pulls those days, so a day that already looked closed can move slightly, in either direction. This is Traqio's own operational observation, not a figure published by Meta or TikTok.

Today's spend is never stored as final. A partial day written as final reads as a sudden spend drop and an inflated ROAS the next morning — a bug many advertisers have seen in some dashboard.

A failure on one connector never stops the other: a revoked TikTok token does not interrupt the Meta spend sync, and the Meta ROAS keeps updating while the TikTok connection is repaired.

How an Apple Ads install is attributed

The Traqio SDK reads the AdServices attribution token on iOS 14.3 and later, and Traqio resolves it with Apple, retrying while Apple has not registered the install yet. No advertising id is read and no tracking prompt is shown.

Apple decides how detailed its answer is from the choice the user already made for the app. With tracking allowed, the answer carries the campaign, ad group, keyword and ad. Without it, the answer only says the install came from Apple Ads — Traqio records exactly that and never guesses a campaign.

Where the spend and the names come from

The customer creates an Apple Ads API user, uploads the public key Traqio generates, and pastes back its ids. Through it Traqio reads campaign and ad group names and daily spend for the campaigns that promote the app, and writes nothing.

How to read campaign ROAS honestly

Campaign ROAS divides the revenue of installs Apple attributed to that campaign by the campaign's spend. Installs Apple did not detail have their own row: their revenue counts in the Apple Ads total and is never spread across campaigns, so the total is complete and each campaign figure is a floor.

How are app installs attributed on iOS after ATT?

SKAdNetwork (SKAN) is Apple's attribution framework: instead of user-level data, Apple sends the ad network a signed, delayed and aggregated postback stating that a campaign produced an install, plus a small conversion value describing early in-app behaviour. Traqio attributes iOS installs from those postbacks.

Traqio verifies Apple's signature on every SKAN postback, decodes the conversion value against a versioned mapping defined per app, and stores the raw postback untouched. Postbacks from SKAdNetwork 2.1 and later are accepted; unsigned or invalid postbacks are rejected.

SKAN attribution is campaign-level, not user-level. Apple's documentation states that the first postback arrives after a random 24–48 hour delay once its conversion window closes, and that Apple limits the detail in each postback according to a crowd-size tier. As a result, per-user iOS ROAS does not exist in Traqio, and Traqio does not model one into existence.

App Tracking Transparency (ATT) is the iOS framework, mandatory since iOS 14.5, that requires an app to ask the user's permission before accessing the IDFA or tracking them across other companies' apps and websites. Traqio does not need that permission, because SKAN attribution does not depend on it.

What the report does not do yet

Revenue is reported gross, before app-store commission and taxes: the commission is stored but not applied. iOS installs attributed through SKAN are campaign-level, so user-level renewal curves exist for deterministic installs only.

One workspace per client, one login

Each client app is a product with its own keys and its own free allowance. Each client can have its own workspace, with its own ad accounts and members; the agency switches between them from one login, and a client invited to their workspace sees their apps only.

Reports that send themselves

Any saved view can be mailed daily, weekly or monthly at a chosen hour, in English, French or Spanish, with the CSV attached — up to twenty recipients per report.