Comprendre le défi : pourquoi un plan de tagging multi-appareils ?
Je le vois souvent avec mes clients : un achat commence sur mobile, passe par le desktop pour la comparaison, puis se finalise via une app ou même un appel téléphonique. Sans un plan de tagging adapté, vous perdez la vue d'ensemble des parcours et vous risquez d'attribuer mal vos conversions, d'optimiser des leviers inefficaces ou de sur-investir dans des canaux peu performants.
Un « plan de tagging » pour parcours multi-appareils vise à standardiser la collecte des événements et des identifiants afin de relier les sessions et les actions d'un même utilisateur quel que soit l'appareil. Cela implique des choix techniques (User-ID, first-party data, suivi côté serveur), des règles de nommage, et une gouvernance claire autour des données et du consentement.
Les principes que j'applique systématiquement
Avant d'entrer dans la technique, j'applique toujours ces principes simples mais essentiels :
penser identifiant stable : privilégier un User-ID (ID utilisateur connecté) quand c'est possible ; standardiser les noms d'événements et des propriétés (naming convention) ; collecter le minimum utile pour respecter la vie privée et faciliter l'analyse ; prévoir une architecture hybride : client-side + server-side pour fiabilité et contrôle ; documenter chaque événement dans un measurement plan partagé. Les briques techniques à considérer
Voici les éléments que j'intègre systématiquement dans mes plans :
Google Analytics 4 (GA4) : orientation événementielle, support natif pour apps et web.Google Tag Manager (GTM) et GTM Server-Side : centraliser les tags et réduire la perte due aux bloqueurs.User-ID : lier les sessions lorsque l'utilisateur est authentifié.Firebase pour les apps : collecte d'événements mobile, export vers BigQuery.BigQuery : source centralisée pour l'analyse cross-device et l'attribution avancée.Consent Mode / CMP : respecter les préférences des utilisateurs et contrôler la disponibilité des données.Comment je structure un measurement plan
Je crée toujours un document clair et partagé (Google Sheets ou Notion) qui contient :
liste des événements clés (view_item, add_to_cart, begin_checkout, purchase, lead_submitted, etc.) ; propriétés standardisées pour chaque événement (value, currency, content_id, content_type, method, etc.) ; contexte d'envoi : web (GTM), mobile (Firebase) ou server-side ; fréquence et conditions d'envoi ; mapping vers des objectifs / conversions dans GA4 et les outils d'attribution. Voici un exemple simplifié de mapping que j'utilise comme base :
| Événement | Propriétés minimales | Origine | But |
| view_item | content_id, content_type, item_name, value | Web / App | Suivre intérêt produit |
| add_to_cart | content_id, quantity, value, currency | Web / App | Funnel e‑commerce |
| begin_checkout | cart_id, value, currency, items | Web / App | Mesurer intent d'achat |
| purchase | transaction_id, value, currency, method, items | Server-side preferred | Converions fiabilisées |
Comment relier les appareils : User-ID, first-party data et stitching
La meilleure méthode reste le User-ID : un identifiant interne quand l'utilisateur est connecté. Mais ça ne couvre pas les visiteurs non authentifiés. Voici les approches complémentaires que j'utilise :
First-party identifiers : email hashé (si le consentement le permet), customer_id stocké en cookie first-party et synchronisé avec le serveur.Device stitching côté serveur : via un backend qui reçoit les événements (web + app) et tente d'agréger par email hashé, login, ou même token de paiement.Session stitching probabiliste : à éviter si possible (empreintes), à considérer uniquement en dernier recours et en transparence.Je recommande de prioriser la déduplication par transaction_id et l'utilisation du server-side pour envoyer les conversions finales (purchase) afin de garantir l'intégrité des données.
Consentement et confidentialité
Le tagging multi-appareils doit être pensé avec le respect du RGPD et autres régulations. J'exige toujours :
un flux clair de consentement via CMP ; des événements « non-identifiants » pour les utilisateurs non-consentants ; le chiffrement/ hashing des identifiants sensibles (email) côté serveur ; une durée de rétention adaptée et documentée. Google Consent Mode et les solutions CMP comme Didomi ou OneTrust facilitent l'adaptation dynamique des tags selon le statut de consentement.
Mise en place pratique : étapes que je suis
Voici le process que j'applique généralement pour déployer un plan de tagging multi-appareils :
Audit des tags existants (GTM, SDK Firebase, pixels) ;Rédaction du measurement plan avec stakeholders (marketing, produit, devs) ;Implémentation des events standardisés dans GTM (web) et Firebase (app) ;Déploiement d'une couche server-side pour les conversions critiques ;Activation du User-ID et tests d'assemblage cross-device ;Monitoring via BigQuery, dashboards Data Studio / Looker ;Itération : corriger les incohérences et ajouter des événements business-critical. Tests et validation : ce que je contrôle
Rien ne vaut des tests rigoureux. Je vérifie :
que l'ordre et la fréquence d'événements correspondent au parcours réel ; l'unicité des transaction_id pour éviter les doublons ; le bon enrichissement des events (ex : présence de content_id) ; la cohérence entre la source client et la source server (valeur et currency identiques) ; la capacité à reconstituer un parcours complet dans BigQuery. Exemples concrets d'outils et d'architectures
Selon le contexte, voici des architectures que j'ai déployées :
Start-up e‑commerce : GTM web + Firebase SDK + GTM server-side + GA4 + BigQuery. User-ID connecté, server-side pour les purchases, export vers BigQuery pour attribution multi-touch.Site média avec app : Standardisation des events view_article et share depuis web et app, envoi des identifiants anonymisés vers un service d'analytics, puis liaison via login si l'utilisateur se connecte.Retail omnicanal : Synchronisation POS → backend → envoi server-side d'events purchase avec customer_id, liaison avec web/app via email hashé. Indicateurs à suivre pour valider le plan
Pour savoir si votre plan fonctionne, regardez :
taux d'attribution cross-device (augmentation attendue) ; réduction des doublons de conversions ; cohérence des valeurs transactionnelles entre sources ; part des events reçus via server-side (fiabilité) ; couverture User-ID pour les utilisateurs récurrents. Si vous voulez, je peux vous aider à construire un measurement plan adapté à votre produit : inventory des événements, naming convention et un modèle d'implémentation (GTM / Firebase / server-side). Dites-moi quel environnement vous utilisez et je ferai une proposition concrète et directement exploitable.
