Connect AppsFlyer to SiteOps

On the web, a click carries its own story — UTM tags land on your site and your analytics sees where the visit came from. On mobile the story breaks: the click happens in one app, the install in a store, the first open in your app. Attribution tools exist to stitch those three back together, and AppsFlyer is the one most mobile teams run.

Connecting it to SiteOps brings the stitched truth in: installs per network, what each install cost, and the revenue those installs produced. Your TikTok and Meta campaigns stop being judged by clicks and start being judged by what actually happened — people installing and using the app.

On mobile projects the connection also improves attribution order: conversions attribute through the SiteOps SDK first (first-party events), then through AppsFlyer — real installs — before any payment provider or analytics goal. Read-only throughout: SiteOps never touches campaigns, postbacks or app settings.

Attribution flowing one way — which network drove the install

Set it up, step by step

0 of 4 done

1. Account menu
2. Security center
3. API tokens
The V2 token's journey — from the security center to one SiteOps field
1. Settings
2. Connections
3. AppsFlyer

If something does not work

The token saves but no numbers arrive: Check the app actually has installs in the AppsFlyer dashboard for the same date range, and that you picked the right app id. A brand-new integration honestly shows zero until real installs report.
I can't find the API tokens screen: Token creation lives in the Security center and is admin-gated on most plans. Ask your AppsFlyer admin to mint a V2 token for SiteOps — it takes them under a minute.
iOS numbers look lower than Android: That is Apple's App Tracking Transparency at work: users who decline tracking attribute through aggregated SKAdNetwork data instead, which is slower and coarser. AppsFlyer shows what can honestly be measured; SiteOps repeats it without inflating.
Why does the ad cabinet still say 'SiteOps SDK' attributes conversions?: By design: first-party events from your own product are the strongest attribution there is, so the SDK outranks everything when connected. AppsFlyer takes over exactly when the SDK is absent on a mobile project.
I want to disconnect — what happens?: Remove the token in SiteOps settings, or revoke it in the Security center. Access stops immediately; the install metrics freeze at their last read and nothing in AppsFlyer changes.

What it unlocks

Installs and cost-per-install in the ads surfaces, per network — the mobile numbers next to the web ones.
Attributed ROAS from AppsFlyer's revenue data, so 'which network pays for itself' has an answer.
On mobile projects, campaign conversions attribute through AppsFlyer right after the SiteOps SDK — installs, not clicks.
Budget auto-rules can watch the install metrics like any other number.

Before you start

An AppsFlyer account with the SDK integrated in your app — attribution data only exists once installs report in.
Access to the Security center in the AppsFlyer dashboard (admin users see it; token creation may be admin-only on your plan).
Know your app id(s) — you pick the app during connect if the account tracks several.

Quick links

What SiteOps reads

Installs — per network and per day, the attribution truth AppsFlyer measured.
Cost and CPI — what each network's installs cost, where cost data is available.
Attributed revenue and ROAS — what those installs went on to spend, as AppsFlyer measured it.
SiteOps never writes to AppsFlyer: campaigns, postbacks, app settings and raw device data stay untouched. Attribution follows your app's consent setup (ATT on iOS) — SiteOps shows what AppsFlyer measured, nothing more.

Connect AppsFlyer to SiteOps

Set it up, step by step

If something does not work

Set up once, see everything every morning