Data Manager API ou Measurement Protocol : lequel pour vos conversions serveur GA4 ?

Les deux fonctionnent aujourd’hui, et c’est ce qui rend le choix délicat.

Côté Google, la note GA4 du 7 mai 2026 présente Data Manager comme une alternative au Measurement Protocol pour envoyer des événements recommandés et personnalisés. Elle couvre les flux web et app, hors événements réservés. La page de référence du Measurement Protocol, mise à jour le 26 octobre 2026, dit autre chose que ce qu’on lit partout. Le protocole est présenté comme mature, sans projet de dépréciation, avec une recommandation d’utiliser Data Manager pour les nouvelles intégrations.

Le mot « successeur » vient donc des tiers, comme Addingwell. Dans les pages Google que j’ai lues, je trouve « upgrade » et « recommandé », pas « successeur ». PPC Land a aussi relayé un bandeau « maintenance mode ». Le libellé actuel est différent, donc revérifiez avant de citer l’un ou l’autre à votre client.

Les fenêtres de 72 h et 48 h changent-elles avec la migration ?

Non. Le Measurement Protocol accepte un antidatage de 72 heures. Les événements à joindre à ceux de gtag.js ou du SDK Firebase doivent arriver dans les 48 heures. Data Manager pose les mêmes bornes sur eventTimestamp. Au-delà, le traitement peut s’écarter de l’attendu, surtout pour l’attribution.

Si votre CRM valide les commandes à J+4, changer d’API ne vous sauvera pas.

La déduplication par transaction_id est-elle équivalente ?

C’est là que ça se complique. Côté GA4, la déduplication joue sur les achats portant le même transaction ID, pour un même utilisateur. Dans Data Manager, le mécanisme « source de données additionnelle » rattache vos événements serveur à ceux de votre balise. La version 1.6 du 7 mai 2026 l’étend à tout événement avec transaction ID, en web comme en app. Cette fonction reste réservée aux propriétés sur liste d’autorisation. Pour les flux web, ces événements n’alimentent pas les enchères Google Ads pendant une période d’essai de 14 jours.

La liste d’autorisation est un déploiement restreint. Le comportement décrit peut donc évoluer. Je n’ai vu aucune restriction annoncée pour l’envoi d’événements recommandés ou personnalisés seuls, mais ce n’est pas la même chose que de l’avoir vu écrit noir sur blanc.

Autre point à confirmer. Une version de l’aide GA4 précise que la déduplication ne fonctionne que sur les flux web. La note de version parle de flux web et app. Je n’ai pas trouvé de source qui réconcilie les deux.

Enfin, la documentation Google indique que l’API sert surtout à enrichir des événements déjà collectés par gtag, GTM ou Firebase, et que des rapports partiels sont possibles sans cela.

Consentement et authentification : ce qui change vraiment

L’objet consent de Data Manager est décrit comme des réglages DMA, avec adUserData et adPersonalization. Il s’applique à la requête, et le consentement au niveau de l’événement le remplace. Je n’y vois aucun champ pour le stockage analytics. C’est ma lecture, pas une position de Google. Je n’ai pas non plus consulté de position CNIL ou EDPB sur ce point. Filtrez donc en amont : un utilisateur qui a refusé ne doit pas partir.

Côté accès, l’API secret n’est plus requis. En échange, il faut le scope OAuth datamanager. L’account_id correspond à l’identifiant de votre propriété GA4. Dernier piège : le modèle est « fast-fail », donc tous les enregistrements d’une requête échouent si un seul est en erreur. Gardez des lots petits.

À quoi ressemble le flux cible ?

Commande validée (back-end, transaction_id = numéro de commande)
  -> filtre consentement (état stocké lors de l'achat)
  -> file d'attente (horodatage = date de la commande, pas du job)
  -> contrôle d'âge : moins de 48 h ? sinon marqué "hors attribution"
  -> events:ingest en validateOnly, puis en réel
  -> diagnostics, Realtime et DebugView

Google conseille de vérifier avec les diagnostics, le rapport Realtime et DebugView.

Grille de décision et plan de migration

Gardez le Measurement Protocol si votre pipeline est stable, que vous n’avez pas d’allowlist et que vous ne visez que GA4. Passez à Data Manager pour un nouveau projet, ou si vous alimentez aussi Google Ads. Une seule requête peut viser plusieurs destinations, et le chiffrement est supporté.

Pour migrer, procédez dans cet ordre :

1. Inventoriez vos payloads et créez les identifiants.
2. Convertissez avec la table de correspondance de Google. Il n’existe plus d’horodatage au niveau de la requête, donc renseignez-le sur chaque événement.
3. Testez sur une propriété de recette.
4. Basculez type d’événement par type d’événement.

Ne laissez jamais les deux chemins actifs sur un même événement non-achat en production. Aucun transaction_id ne protégera alors vos comptages.

Je n’ai trouvé chez Simo Ahava aucun test indépendant de Data Manager pour GA4. Tout ce qui précède est de la documentation, pas de l’observation terrain.

Prenez le log d’envoi de la semaine et calculez l’âge de chaque événement à son arrivée. Si une part notable dépasse 48 heures, votre vrai chantier est la file d’attente, pas l’API.