Quand on parle de suivi des conversions multi-appareils en restant compatible avec le RGPD, on se heurte vite à deux réalités : d'un côté, l'attente légitime des équipes marketing pour des données précises et actionnables ; de l'autre, le cadre légal et éthique qui limite la collecte et le traitement des données personnelles. Ici je vous partage la méthode que j'applique pour concevoir un plan de taggage analytics fiable, respectueux du RGPD et utilisable pour attributer des conversions sur plusieurs appareils.

Poser le cadre : objectifs, données indispensables et contraintes

Avant toute balise, je commence par une réunion avec les parties prenantes (marketing, produit, juridique). L'objectif : définir les conversions clés, le niveau d'attribution souhaité (session, utilisateur, cross-device) et les usages (rapports, activation pub, rétention). Ça permet de trancher sur la nécessité de chaque donnée recueillie.

Ensuite, je liste les contraintes RGPD qui s'imposent :

  • Principe de minimisation : ne collecter que ce qui est strictement nécessaire.
  • Consentement préalable pour les traceurs non essentiels (cookies publicitaires, identifiants persistants).
  • Droit à l'effacement et portabilité — prévoir des mécanismes pour répondre aux demandes.
  • Si on utilise des identifiants personnels (email, tel), ils doivent être pseudonymisés/haschés et traités sur la base d'une finalité licite et documentée.

Architecture recommandée : combiner client + serveur + consentement

Je préconise une architecture hybride :

  • Tagging côté client via Google Tag Manager (GTM) ou équivalent pour la capture d'événements UX.
  • Une couche serveur (GTM Server-Side, Segment Functions, ou un endpoint propriétaire) qui reçoit, nettoie et enrichit les événements avant de les envoyer aux outils analytics et CDP.
  • Un CMP (Consent Management Platform) pour gérer les choix utilisateurs (ex. : Didomi, OneTrust, Cookiebot) et propager l'état de consentement partout.

Pourquoi le server-side ? Parce qu'il facilite :

  • La suppression ou l'anonymisation en flux selon le consentement.
  • La limitation des tiers côté client (réduction des cookies tiers).
  • Le contrôle sur les données envoyées aux partenaires (mapping, filtrage).

Stratégie d'identification multi-appareils compatible RGPD

Le cœur du problème est d'identifier qu'un même utilisateur a converti depuis plusieurs appareils. Voici l'approche que je mets en place :

  • User-ID serveur : utiliser un identifiant interne (ID utilisateur) lorsque l'utilisateur s'authentifie. Cet ID n'est pas un PII exposé — il est généré côté back-end et stocké en première partie.
  • Hashed identifiers (si consentement explicite) : email ou tel peuvent être haschés (SHA-256) pour faire du matching entre devices — seulement si la base légale et le consentement sont clairs.
  • Device linking via login : encourager le login cross-device (offrir valeur) pour lier sessions sans recourir à des techniques invasives.
  • Fallback probabiliste / agrégé : utiliser des modèles probabilistes d'attribution anonymisés côté serveur pour estimer les parcours multi-appareils sans stocker de PII.

Important : j'évite absolument toute forme de fingerprinting sans consentement clair — c'est risqué juridiquement et souvent inefficace face aux protections modernes des navigateurs.

Plan de taggage : événements, paramètres et user properties

Je définis un plan de mesure simple et réutilisable. Voici un exemple d'éléments que je capture :

ÉvénementQuandParamètres clés
page_viewChargement de pagepage_path, page_title, referrer
product_viewVisite fiche produitproduct_id, category, price
add_to_cartAjout au panierproduct_id, quantity, cart_value
purchaseConversion (commande)order_id, revenue, currency, items[], user_id (si dispo)

Pour chaque événement, j'indique :

  • Si le paramètre est nécessaire sans consentement (p.ex. event d'usage anonyme) ou conditionné au consentement.
  • Comment stocker (chiffrement/hasher) et la durée de conservation.
  • Le mapping vers les outils (GA4, Matomo, Data Warehouse).

Gestion du consentement et commandes aux tags

Le CMP doit contrôler l'activation des tags. Dans GTM, j'utilise un trigger "consent" qui s'active seulement si l'utilisateur accepte les catégories pertinentes (analytics, marketing). En server-side, je filtre également les événements selon l'état du consentement transmis.

Je mets en place des règles claires :

  • Sans consentement analytics : collecte minimale, events anonymes (p.ex. counts), pas d'identifiants persistants.
  • Avec consentement analytics : envoi d'événements détaillés et, si consentement marketing, possibilité de forwarding vers ad-networks de façon contrôlée.
  • Opt-out effectif : respect immédiat et suppression rétroactive si le CMP le demande.

Envoi vers les destinataires : segmentation et contrôle

Avant d'envoyer les données à des tiers (Google Analytics 4, Facebook Conversions API, CDP comme Segment ou RudderStack), j'applique en server-side :

  • Filtrage selon consentement.
  • Pseudonymisation (hash email) si nécessaire.
  • Minimisation des champs transmis (pas d'IP, ou IP truncation).
  • Batching et agrégation pour réduire l'exposition de données individuelles.

Mesures supplémentaires pour la conformité et la robustesse

Voici quelques pratiques auxquelles je tiens systématiquement :

  • Documenter le plan de taggage et les finalités — utile en cas d'audit CNIL/autorité locale.
  • Mettre en place des politiques de rétention et automatiser la suppression des données au bout du délai autorisé.
  • Faire des tests de bout en bout : vérifier que le CMP empêche bien les envois quand l'utilisateur refuse.
  • Utiliser des outils qui respectent la vie privée : Matomo (hébergé en propre) ou un GA4 configuré avec server-side tagging et Consent Mode.
  • Prévoir un mécanisme pour répondre aux demandes RGPD (portabilité, effacement) lié à l'ID utilisateur.

Exemples d'implémentation pratique

Dans un projet récent j'ai mis en place :

  • GTM en front, GTM server-side sur Google Cloud Run.
  • Didomi pour le CMP, avec propagation de l'état de consentement dans dataLayer et headers vers le serveur GTM.
  • User-ID interne généré au login, stocké côté server, utilisé pour lier événements web et app mobile. Les email hashés n'étaient envoyés qu'aux partenaires publicitaires après consentement explicite.
  • Attribution multi-appareils réalisée via User-ID pour 60% des conversions (login) et estimation probabiliste pour le reste, présentée dans un tableau de bord BI agrégé.

Indicateurs à surveiller après déploiement

Pour valider que le plan fonctionne et reste conforme, je suis ces métriques :

  • Taux de consentement (par catégorie).
  • Pourcentage de conversions liées à un User-ID (indique l'efficacité du login cross-device).
  • Écarts entre donnees client-side et server-side (garantie d'intégrité).
  • Requêtes de droits RGPD et temps de réponse.

Si vous voulez, je peux vous fournir un template de plan de taggage (CSV / table) ou un exemple de mapping GTM -> server-side -> GA4 adapté à votre site. Dites-moi simplement quel outil vous utilisez (GA4, Matomo, Segment, autre) et si vous avez déjà un CMP en place — je vous aiderai à en faire un plan pratique et conforme.