Cross-device attribution

Definition

Cross-device attribution is the practice of crediting a conversion that happens on one device to an advertising touch that happened on a different device belonging to the same person, which requires an identity that both devices share.

Every identifier the platforms give you is scoped to one device, so cross-device attribution is not a harder version of ordinary attribution — it is a different problem with one reliable solution. That solution is a logged-in identity you observe on both devices. Everything else on offer is either a walled garden reporting an aggregate back to you, or probabilistic matching whose accuracy nobody can verify. This is distinct from cross-platform attribution, which is about reconciling iOS, Android and web measurement regimes for one campaign.

Why no device identifier can do this

The last row is the entire answer, and it explains why the vendor conversation about cross-device so often ends in vagueness. A measurement partner has access to the same device-scoped identifiers you do. If they claim cross-device without asking you to send them a user identity, they are either reporting a platform's aggregate back to you or inferring the link from signals like IP address and user agent — which is fingerprinting under a friendlier name.

The stitch: anonymous identity to known identity

The implementation is the same on every surface. Assign an anonymous identifier on first touch, record every event against it, and when the user authenticates, emit an alias that binds that anonymous identifier to the durable user ID. The alias is what lets you re-attribute a history recorded before you knew who someone was.

// First touch. No identity yet, so record the campaign against an
// anonymous id that persists in first-party storage.
const anonymousId = getOrCreateAnonymousId();

track({
  anonymousId,
  event: "campaign_click",
  campaignId: new URLSearchParams(location.search).get("cid"),
  clickId: new URLSearchParams(location.search).get("click_id"),
});

// Later, possibly days later, on the same browser.
async function onLogin(userId) {
  // The alias is the whole mechanism. Without it the campaign_click
  // above stays orphaned and the conversion looks organic.
  await identify({ anonymousId, userId });
}

// The app has its own anonymous id — a different device, so a
// different value. It must send the identical userId string.
func onAuthenticated(userId: String) {
    // Normalise before hashing or sending: trim, lowercase.
    // "User@Example.com " and "user@example.com" must not become
    // two identities, which is the most common stitch failure.
    Deeplinkly.identify(userId: userId)
}

func onPurchase(amount: Decimal, currency: String) {
    // Attributed by identity, not by this device's click history —
    // there was no click on this device.
    Deeplinkly.track(event: "purchase", value: amount, currency: currency)
}

-- Resolve every anonymous id to a person, then credit the
-- conversion to the campaign touched on ANY of their devices.
WITH identity AS (
  SELECT anonymous_id, user_id
  FROM identity_alias
  QUALIFY ROW_NUMBER() OVER (
    PARTITION BY anonymous_id ORDER BY aliased_at DESC
  ) = 1
),
touches AS (
  SELECT
    COALESCE(i.user_id, t.anonymous_id) AS person,
    t.campaign_id,
    t.device_id,
    t.occurred_at
  FROM campaign_touch t
  LEFT JOIN identity i USING (anonymous_id)
),
conversions AS (
  SELECT
    COALESCE(i.user_id, c.anonymous_id) AS person,
    c.device_id AS converting_device,
    c.revenue,
    c.occurred_at
  FROM conversion c
  LEFT JOIN identity i USING (anonymous_id)
)
SELECT
  t.campaign_id,
  COUNT(*)                                          AS conversions,
  SUM(c.revenue)                                    AS revenue,
  -- The share of credit that only a cross-device join can see.
  AVG(CASE WHEN t.device_id <> c.converting_device
           THEN 1 ELSE 0 END)                       AS cross_device_rate
FROM conversions c
JOIN touches t
  ON  t.person = c.person
  AND t.occurred_at <= c.occurred_at
  AND t.occurred_at >= c.occurred_at - INTERVAL '7' DAY
GROUP BY t.campaign_id;

The cross_device_rate column is the one worth reporting to whoever asked for this. It states, as a measured fraction rather than a vendor claim, how much credit the join actually moved — and it is usually far smaller than expected, which is a useful correction before anyone builds a strategy on it.

Double counting, and the windows that cause it

A single person with three devices generates three touch histories, and a naive join credits the conversion once per matching touch. The query above already guards against the worst of it with an attribution window and a single conversion row, but the design decision cannot be avoided: when touches on two devices both precede one conversion, which gets the credit?

The privacy position is worth stating plainly, because it is the part that gets teams into trouble. Stitching identities you were given — a user logging into your own product on two devices — is first-party data handling, and the consent you need is the ordinary consent for processing account data. Inferring that two devices belong to one person from IP address and user-agent similarity is a different act, it is what ATT exists to govern, and it is not made acceptable by a vendor performing it on your behalf.