Attribution cross-device sans cookies (mobile ↔ web)

Le parcours utilisateur n’a jamais été aussi fragmenté.
Un utilisateur découvre ton site sur mobile, lit une page produit sur desktop, ouvre ton app le soir, puis finalise son achat dans l’app quelques jours plus tard. Voir notre guide sur Impact d’iOS 17 l’attribution mobile.

1. Introduction : Pourquoi le cross-device devient indispensable sans cookies

Le problème :
👉 avec la fin des cookies tiers et la purge automatique des cookies sur Safari, Firefox, iOS et bientôt Chrome, la continuité entre ces appareils disparaît.
Les plateformes d’attribution (GA4, Google Ads, Meta, TikTok…) perdent la capacité d’associer les événements entre mobile et desktop. Voir notre guide sur attribution marketing.

Résultat :

• ROAS faussé

• entonnoirs brisés

• LTV sous-estimée

• conversions non attribuées

• funnel incomplet

• reporting incohérent

Cet article te donne un tutoriel complet, étape par étape, pour construire une attribution cross-device fiable sans cookies, en combinant : Voir notre guide sur Enrichir GA4 avec données CRM.

• User_ID,

• email hashé,

• deep links,

• server-side tracking,

• CRM,

• BigQuery,

• et GA4.

Objectif : retrouver une vision claire, unifiée et exploitable du parcours utilisateur.

2. Comprendre le cross-device tracking (bases indispensables)

2.1. Définition simple

Le cross-device tracking consiste à identifier le même utilisateur sur plusieurs appareils, même s’il change de :

• navigateur,

• device,

• session,

• app → web ou web → app.

Sans cookies, on doit créer un identifiant commun.

2.2. Pourquoi les cookies ne fonctionnent plus

• Cookies tiers : bloqués (Safari/Firefox) + supprimés en 2025 (Chrome).

• Cookies first-party : durées réduites à 1–7 jours sur Safari.

• Cookies effacés lors du remplacement d’IP / changement d’appareil.

• Cookies inaccessibles en mode privé.

Bref :
Les cookies ne sont plus un support viable pour l’attribution.

2.3. Les 4 sources possibles d’identifiants cross-device

1. User_ID (recommandé)

ID interne stable, envoyé côté web + app.

2. Email hashé (SHA256)

Conforme RGPD, compatible GA4, CRM, BigQuery, Ads.

3. Identifiants device mobile

• IDFV (iOS)

• Firebase App Instance ID

• GA4 App Instance ID

4. Identifiant serveur (external_id)

Utilisé par Meta, TikTok, Snap.

2.4. Comment GA4 fait du cross-device

GA4 combine trois niveaux :

1. User-ID si l’utilisateur est connecté

2. Device ID si pas loggé

3. Modelling pour relier les sessions “probables”

Mais GA4 seul n’est jamais suffisant.
Pour un vrai cross-device, tu dois créer ton propre système.

3. Étape 1 — Cartographier les parcours multi-device

3.1. Les scénarios les plus courants

• Un utilisateur clique une pub mobile → achète sur desktop.

• Un utilisateur lit un article sur mobile → installe l’app → finalise l’achat dans l’app.

• Web → app → web pour un processus de paiement.

• Mobile → desktop pour un formulaire complexe.

3.2. Identifier les “zones d’ombre”

Sans cross-device, tu perds :

• conversions web attribuées au trafic direct

• conversions app impossibles à relier à une source web

• abonnements mobiles non attribués

• retargeting impossible faute d’identifiant stable

3.3. Prioriser les parcours critiques

Priorise les parcours où la perte de continuité coûte le plus cher :

• acquisition paid → conversion

• signup web → conversion app

• ajout au panier web → achat app

• free trial app → upgrade desktop

4. Étape 2 — Construire un identifiant cross-device fiable

4.1. Le User_ID : la base de tout

C’est le seul identifiant réellement stable.
Il appartient à ton CRM.

Il doit être :

• généré par ton backend

• envoyé côté web (via GTM / gtag)

• envoyé dans l’app (Firebase / SDK)

• identique dans tous les environnements

Piliers d’une bonne implémentation User_ID :

• user_id = identifiant interne unique

• jamais d’email brut

• user_id envoyé sur chaque event GA4

4.2. Email hashé : indispensable pour le cross-device marketing

L’email est le seul identifiant commun web ↔ app ↔ CRM.

Tu dois :

1. nettoyer l’email (lowercase/trim)

2. appliquer un hash SHA-256

3. stocker dans ton CRM

4. utiliser dans BigQuery

5. l’envoyer vers Ads (Customer Match)

GA4 interdit l’email brut mais accepte l’email hashé via server-side.

4.3. Identifiants natifs côté app

• IDFV : stable par app publisher

• Firebase Instance ID

• GA4 App Instance ID

Ces identifiants permettent de relier des actions app à un user_id (via CRM).

4.4. Identifiant externe serveur (Meta/TikTok)

Tu peux envoyer un identifiant commun via CAPI :

• external_id

• event_id

Ces IDs permettent la déduplication navigateur ↔ serveur.

5. Étape 3 — Implémenter le cross-device dans GA4

5.1. Activer User-ID dans GA4

GA4 → Admin → Data Streams → Web → Config → User-ID

Cela dit à GA4 de fusionner les sessions web + app en un seul profil utilisateur.

5.2. Ajouter User_ID côté web

Via GTM :

gtag('set', {
  'user_id': userId
});

Via dataLayer :

dataLayer.push({
  user_id: userId
});

5.3. Ajouter User_ID dans l’app

Firebase :

await analytics().setUserId(userId);

5.4. Fusion automatique des sessions GA4

Avec User-ID :

• GA4 fusionne les sessions web + app

• les funnels deviennent multi-device

• les rapports cross-platform sont activés

Attention :
→ GA4 ne fusionne pas rétroactivement
→ GA4 ne fusionne pas sans login réel

6. Étape 4 — Créer un pont mobile → web / web → mobile

6.1. Mobile → web : deep links enrichis

Lors d’un deep-link :

• inclure un JWT contenant :

  • user_id

  • email hash

• décoder côté web pour recharger le user_id

Déjà utilisé par : Deliveroo, Uber, Spotify.

6.2. Web → mobile : deferred deep links

Technos :

• Branch

• Adjust

• AppsFlyer

On encode dans le lien :

• user_id

• email hash
  → puis l’app récupère ces données lors du premier launch.

6.3. Web → desktop : synchronisation via CRM

Un utilisateur se connecte :
→ tu synchronises le user_id dans GA4, back + front.
→ GA4 fusionne automatiquement.

7. Étape 5 — L’avenir du tracking : server-side (indispensable)

7.1. Pourquoi server-side = essentiel

Parce que :

• les navigateurs bloquent le tracking → pas les serveurs

• le backend connaît la vérité (user_id + email hash)

• S2S = attribution stable, cross-device et cookieless

7.2. Architecture recommandée

Web/App → Backend → BigQuery → GA4 server-side
                        ↓
                 Google Ads / Meta

7.3. Outils possibles

• Google Tag Manager Server-Side (le plus populaire)

• Segment Connections

• mParticle

• Plateforme custom server-side

8. Étape 6 — Reconstruire l’attribution cross-device dans BigQuery

8.1. Export native GA4 → BigQuery

Activer l’export → les tables GA4 arrivent :

• events

• app_events

• device_id

• user_id (si login)

8.2. Import CRM → BigQuery

Colonnes clés :

• customer_id

• email

• email_hash

• LTV

• subscription_status

• cohort

• segments marketing

8.3. Construire la Customer 360 Table

SELECT
  bq_ga4.user_id,
  crm.customer_id,
  crm.email_hash,
  crm.ltv,
  crm.segment,
  crm.subscription_status,
  COUNT(*) AS sessions
FROM ga4.events AS bq_ga4
LEFT JOIN crm.customers AS crm
ON bq_ga4.email_hash = crm.email_hash
GROUP BY 1,2,3,4,5,6

La Customer 360 permet d’identifier les conversions cross-device :

• mobile click → desktop conversion

• web signup → app purchase

• web cart → app checkout

9. Étape 7 — Réinjecter les données enrichies dans GA4 & Ads

9.1. Réinjecter dans GA4 (sans PII)

Via GA4 Measurement Protocol :

• user_property: segment

• user_property: ltv_bucket

• user_property: device_bridge

9.2. Réinjecter dans Google Ads (Customer Match)

Avec email hash →

• audience VIP,

• anti-churn,

• high-value,

• multi-device purchasers.

9.3. Réinjecter dans Meta / TikTok via CAPI

Avec external_id stable :

• meilleure attribution iOS

• fusion navigateur/app

• ROAS plus proche de la réalité

10. Étape 8 — Monitoring : vérifier que le cross-device fonctionne

10.1. Les dashboards à créer

• % sessions fusionnées

• % users multi-device

• ROAS cross-device

• app-to-web conversions

• web-to-app conversions

• matching rate user_id

• taux d’anomalies (session cassée)

10.2. Anomalies fréquentes

• user_id envoyé avant connexion

• différence user_id web/app

• email hash mal normalisé

• perte sur Safari/iOS

• APIs server-side non dédupliquées

10.3. QA à exécuter systématiquement

1. web → login → app → checkout

2. app → deep link → web

3. web → mobile (deferred deep link)

4. multi-device signup

5. suppression cookie + relogin

11. Cas d’usage concrets

E-commerce

• panier web → achat app

• audiences cross-device basées sur le login

SaaS

• signup mobile → upgrade desktop

• abonnement multi-device

Apps mobile

• attribution web → install app

• multi-device retargeting optimisé CAPI

12. Erreurs courantes à éviter

• Espérer que GA4 suffise seul

• Confondre Client_ID ↔ User_ID

• Utiliser des cookies tiers (obsolète)

• Stocker des PII dans GA4

• Ne pas normaliser email hash

• Ne pas utiliser de deferred deep links

• Ne pas envoyer user_id dans l’app

• Oublier server-side (indispensable)

Conclusion : le futur du tracking est cross-device, login-first et server-side

Le cross-device sans cookies n’est plus un challenge technique, mais un avantage stratégique.
En combinant :

• login (User-ID)

• email hashé

• deep links

• server-side events

• BigQuery

• GA4 identity modelling

… tu reconstruis une vision utilisateur complète, cohérente, et durable.

C’est la seule architecture encore viable pour :

• analyser correctement,

• attribuer précisément,

• optimiser ton ROAS,

• et maintenir un tracking robuste dans un monde cookieless.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.