Cross-platform attribution

Definition

Cross-platform attribution is the practice of measuring one advertising campaign across iOS, Android and the web, where each platform supplies a different attribution signal at a different level of granularity and the results cannot be directly summed.

The instinct is to treat platform as a dimension you can group by, the way you group by country. It is not, because the number in each row was produced by a different measurement system: iOS reports installs in aggregate through SKAdNetwork with a delay and a privacy threshold, Android reports them deterministically and immediately through the Play install referrer, and the web reports them from your own server. Averaging those is arithmetic without meaning. This is a separate problem from cross-device attribution, which is about one person using two devices.

Three regimes, one campaign

Two rows make blending indefensible. Aggregate granularity means an iOS row is a count with no rows behind it, so it cannot be filtered, joined or deduplicated after the fact. Suppression means an iOS row can be *absent* rather than zero when volume is below the privacy threshold — so a naive platform comparison reports Android outperforming iOS partly because Android tells you about small campaigns and iOS declines to.

The one thing that must be identical everywhere

You cannot normalise granularity, latency or identity — those are properties of the platforms. You can normalise the campaign key, and it is the only thing standing between you and a report where the same campaign appears as four rows. Decide the taxonomy once, encode it in every link regardless of platform, and mirror it into the constrained iOS campaign ID space with an explicit mapping table rather than an ad-hoc convention.

# The campaign key is generated once and reused verbatim. Same
# cid on every platform is what makes a single GROUP BY possible.
CID="spring_launch_2026"
CREATIVE="hero_v3"

# Android and web: the key travels in the link as-is.
echo "https://example.com/product/42?cid=${CID}&creative=${CREATIVE}&utm_source=meta"

# iOS: SKAdNetwork campaign IDs are a small integer space, so the
# mapping has to be stored, not encoded. Keep it in version control
# next to the taxonomy — an undocumented mapping is unrecoverable
# once the person who chose it leaves.
echo "skan_campaign_id=37  ->  ${CID}"

# Verify the key survives to the landing page on every platform.
for ua in "iPhone; CPU iPhone OS 18_0" "Linux; Android 15"; do
  curl -s -o /dev/null -w "%{url_effective}\n" -L -A "Mozilla/5.0 ($ua)"     "https://links.example.com/l/abc?cid=${CID}&creative=${CREATIVE}"
done

-- The grain column is not decoration. It is what stops someone
-- averaging an aggregate row with a per-install row six months
-- from now, and it travels with the data into every downstream view.
WITH unified AS (
  SELECT campaign_id, 'ios'     AS platform, 'aggregate'   AS grain,
         installs, NULL::NUMERIC AS revenue, TRUE AS may_be_suppressed
  FROM skan_postback_rollup

  UNION ALL
  SELECT campaign_id, 'android' AS platform, 'per_install' AS grain,
         COUNT(*) AS installs, SUM(first_day_revenue), FALSE
  FROM android_attributed_install
  GROUP BY campaign_id

  UNION ALL
  SELECT campaign_id, 'web'     AS platform, 'per_session' AS grain,
         COUNT(*) AS installs, SUM(first_day_revenue), FALSE
  FROM web_attributed_conversion
  GROUP BY campaign_id
)
SELECT
  campaign_id,
  platform,
  grain,
  installs,
  revenue,
  -- Report per platform. Deliberately no SUM() across platforms:
  -- a total here would be three incompatible measurements added up.
  revenue / NULLIF(installs, 0) AS revenue_per_install
FROM unified
ORDER BY campaign_id, platform;

The absence of a grand total in that query is the design, not an omission. A cross-platform report answers "how did this campaign do on each platform", and the honest answer is three numbers with three provenances. If a stakeholder needs one number, the defensible construction is spend against revenue per platform, compared to each platform's own eCPI — never a blended install count.

What you can and cannot compare

The qualified row is worth expanding. Cohort analysis on iOS can only use cohorts SKAdNetwork is able to describe, which is a coarser grouping than the install-level cohorts Android gives you. Comparing a coarse iOS cohort's retention to a precise Android one is a comparison of measurement precision as much as of user behaviour, so state the grain alongside the figure whenever both appear in the same chart.

Where a genuine unified view is required — a board slide, a channel budget decision — the practical approach is to hold the taxonomy identical, report per platform, and reconcile at the spend level rather than the install level. Spend is the one quantity measured the same way everywhere, because you paid it. Everything downstream of it is platform-specific, and pretending otherwise is how a campaign gets cut on iOS for underperforming when it was only being measured more conservatively.