Si vous êtes tombé sur le bandeau « No future enhancements are planned. Upgrade to the Data Manager API to future-proof your integration » en ouvrant la doc du Measurement Protocol, vous vous posez sûrement la mauvaise question. Le vrai sujet n’est pas « lequel est le meilleur ». C’est « est-ce que je dois réécrire mon pipeline maintenant, et à quel coût ». Cet article tranche, cas d’usage par cas d’usage. Le duel Measurement Protocol vs Data Manager API se joue sur des détails très concrets : chiffrement, multi-destinations, quotas, et surtout une contrainte que 90 % des contenus oublient de mentionner, l’accès sur allowlist. Pour le rappel de ce que fait le MP, gardez sous la main notre guide complet du Measurement Protocol.
Faut-il migrer ? La version courte. Conversions offline CRM vers Google Ads : oui, préparez la bascule. Purchase server-side multi-destinations : oui. Enrichissement analytique GA4 pur : non, le MP reste opérationnel. Nouvelle intégration : partez directement sur la Data Manager API.
Ce que Google a réellement changé (et ce qu’il n’a pas changé)
Décryptons le bandeau, parce qu’il dit exactement deux choses et rien de plus. Un, le Measurement Protocol n’évoluera plus : aucune nouvelle fonctionnalité, aucun nouveau champ. Deux, Google désigne la Data Manager API comme le chemin d’avenir. C’est tout.
Une précision avant d’aller plus loin, pour éviter la confusion la plus courante : on parle ici de l’API, pas de l’interface. Le Data Manager côté produit, celui qui gère les connexions BigQuery et le Customer Match dans l’UI Google Ads, est un autre sujet, traité dans notre guide du Data Manager Google Ads. Cet article-ci vise la Data Manager API, la brique programmatique.
Ce que le bandeau ne dit pas, et c’est capital : il n’y a aucune date de sunset. Le MP n’est pas déprécié, il est figé. Vos requêtes POST actuelles continuent de fonctionner, vos conversions offline remontent toujours dans GA4, votre attribution ne casse pas du jour au lendemain. « Maintenance mode » veut dire « on ne touche plus », pas « on éteint bientôt ». Rassurez-vous d’abord, décidez ensuite.
Cela dit, la trajectoire est sans ambiguïté. La Data Manager API avance vite : la v1.6 du 7 mai 2026 a ajouté les store sales et élargi l’ingestion d’événements Analytics web et app ; la v1.7 du 28 mai 2026 a branché Campaign Manager 360, Search Ads 360 et Display & Video 360. En face, le MP n’a strictement rien reçu. Quand un produit gagne une version majeure par mois et l’autre zéro, la question n’est plus « si » mais « quand » vous migrez.
Measurement Protocol vs Data Manager API : le comparatif technique
Voici la comparaison champ par champ, sur les critères qui comptent une fois en production, pas dans une slide marketing.
| Critère | Measurement Protocol | Data Manager API |
|---|---|---|
| Modèle de données | Propriétaire à GA4 | Unifié, partagé entre produits Google |
| Destinations | Une data stream GA4 par requête | Multi-destinations (GA4 + Google Ads) en une requête |
| Chiffrement des identifiants | Aucun (vous envoyez en clair) | XChaCha20-Poly1305, clés wrappées via KMS (GCP ou AWS) |
| Authentification | api_secret en query param | OAuth 2.0, scope datamanager |
| Transport | POST HTTP simple | REST et gRPC |
| Évolution | Figé, maintenance mode | Actif, v1.7 au 28 mai 2026 |
| Accès | Ouvert à tous | Allowlist sur certaines capacités |
Deux lignes méritent qu’on s’y arrête. Le chiffrement d’abord : le MP envoie vos identifiants utilisateur en clair, la Data Manager API impose un chiffrement côté client avant l’envoi. C’est plus de travail à l’implémentation, mais c’est aussi ce qui la rend défendable devant une équipe sécurité. Le multi-destinations ensuite : là où le MP exige une requête par flux, la Data Manager API pousse le même événement vers GA4 et Google Ads d’un coup. Sur un volume de conversions offline conséquent, ça change la donne opérationnelle.
Les quotas et limites à connaître avant de dimensionner
Avant de promettre une bascule à votre client ou à votre lead, chiffrez le dimensionnement. La Data Manager API impose des plafonds par projet Google Cloud qu’il faut connaître :
- 100 000 requêtes par jour et 300 requêtes par minute par projet Cloud.
- 10 000 membres d’audience ou 2 000 événements de conversion par requête.
- Jusqu’à 10 identifiants utilisateur par enregistrement.
Ces chiffres suffisent très largement pour la majorité des pipelines de conversions offline. Ils deviennent structurants si vous envisagez des uploads d’audiences massifs ou un backfill historique : dans ce cas, prévoyez le batching et la gestion des quotas dès la conception, pas après le premier 429.
Faut-il migrer ? La grille de décision par cas d’usage
C’est le cœur de la décision. Ne migrez pas « parce que Google le dit » : migrez si votre cas d’usage y gagne. Voici la grille que j’applique en mission.
| Votre cas d’usage | Décision | Pourquoi |
|---|---|---|
| Conversions offline CRM vers activation Google Ads | Migrer | C’est le cas que la Data Manager API sert le mieux, et les anciens chemins Ads se ferment |
| Purchase server-side ecommerce multi-destinations | Migrer | Une requête pour GA4 + Ads, chiffrement natif, dimensionnement propre |
| Enrichissement analytique GA4 pur, événements unitaires | Rester | Le MP fait le job, reste opérationnel, et migrer n’apporte rien ici |
| Kiosque, POS, device sans tagging | Rester | Tant que l’accès allowlist n’est pas accordé, vous ne pouvez pas basculer |
| Nouvelle intégration à partir de zéro | Data Manager API d’emblée | Autant partir sur le format d’avenir, pas sur un format figé |
Le cas qui doit migrer en premier, c’est le CRM vers Google Ads. La séquence de fermeture des anciens chemins l’impose : depuis le 1er avril 2026, les uploads Customer Match via les anciens services de la Google Ads API sont fermés, et depuis le 15 juin 2026 les nouveaux imports de conversions offline via la Google Ads API sont bloqués. Si votre pipeline B2B ressemble à celui décrit dans notre guide Enhanced Conversions for Leads en server-side GTM, vous êtes en première ligne.
À l’inverse, si vous poussez juste des événements unitaires pour enrichir vos rapports GA4, sans activation publicitaire derrière, ne bougez pas. Le MP fait exactement ce qu’il faut, et une migration serait du travail sans bénéfice.
Le vrai frein : l’allowlist
Voici le point que personne ne met en avant, et qui rend un « migrez maintenant » souvent inapplicable : plusieurs capacités de la Data Manager API sont réservées à des comptes sur allowlist. L’envoi d’événements avec un transaction ID comme source de données additionnelle pour GA4, ou l’upload de store sales conversions, ne sont ouverts qu’aux propriétés et comptes allowlistés. Concrètement, vous pouvez avoir tout codé et buter sur un mur d’accès.
La demande d’accès passe par un formulaire Google dédié à la propriété ou au compte concerné. Préparez en amont le projet Google Cloud avec l’API activée et les credentials OAuth 2.0 prêts, pour ne pas perdre de temps une fois l’accès accordé. Et acceptez cette idée qui dérange : en septembre 2026, « attendre » est une décision parfaitement légitime. Préparer la migration sans la lancer, c’est souvent la bonne réponse tant que l’accès n’est pas là.
Le plan de migration en 5 étapes
Quand vous décidez d’y aller, la bascule tient en cinq étapes.
- Créez un projet Google Cloud et activez la Data Manager API dessus.
- Générez les credentials OAuth 2.0 avec le scope
datamanager(attention, il est distinct du scope de la Google Ads API). - Mappez votre payload Measurement Protocol vers le schéma Data Manager : c’est le gros du chantier, les modèles ne se recopient pas champ pour champ.
- Donnez au compte opérant l’accès à la propriété GA4 ciblée.
- Vérifiez via le Realtime et le DebugView de GA4 : ces outils de diagnostic restent parfaitement valables après la bascule.
Si votre collecte s’appuie déjà sur du server-side GTM, situez bien où la Data Manager API s’insère dans l’architecture ; notre guide GTM server-side pose le décor. Et pour un exemple concret d’intégration déjà bâtie sur cette logique, regardez notre article Shopify GA4 server-side.
Les 3 pièges à éviter
Premier piège, le scope OAuth. Le scope datamanager n’est pas celui de la Google Ads API. Si vous réutilisez des credentials existants sans vérifier, vous prendrez un refus d’autorisation en pleine bascule.
Deuxième piège, croire que la Data Manager API remplace votre tagging. Elle ne le fait pas. Comme le MP, elle a besoin d’un tagging standard à côté (gtag ou GTM), sinon le contexte de session est incomplet et l’attribution en souffre. La Data Manager API active et enrichit, elle ne collecte pas le parcours web à votre place.
Troisième piège, le double comptage pendant la bascule. Si vous envoyez la même conversion via le MP et via la Data Manager API en parallèle pour tester, vous compterez deux fois. Cadrez précisément la fenêtre de transition et coupez un chemin avant d’ouvrir l’autre, ou filtrez par source pour ne pas polluer vos rapports.
Verdict au 5 septembre 2026
Ma recommandation, telle que je la donne à un client aujourd’hui, dépend d’une seule chose : ce que vous faites de vos données. Si vous alimentez Google Ads depuis un CRM ou un back-office ecommerce, planifiez la migration maintenant, demandez l’accès allowlist si votre capacité en dépend, et gardez le MP en fonctionnement tant que la bascule n’est pas validée. Si vous ne faites qu’enrichir GA4 avec des événements offline sans activation derrière, restez sur le Measurement Protocol : il est figé, pas mort, et il fait le travail. Et si vous démarrez de zéro, ne vous posez pas la question, partez sur la Data Manager API.
La bonne posture n’est pas de foncer ni d’ignorer. C’est de savoir dans quelle case vous êtes, et d’agir en conséquence.
FAQ
Le Measurement Protocol GA4 va-t-il être supprimé ?
Rien ne l’indique à ce jour. Il est en maintenance mode, sans nouvelle fonctionnalité, mais aucune date de sunset n’a été annoncée. Vos intégrations existantes continuent de fonctionner.
Comment demander l’accès à la Data Manager API ?
Certaines capacités (transaction ID comme source additionnelle, store sales) passent par un formulaire d’allowlist Google, propriété par propriété ou compte par compte. Préparez d’abord le projet Google Cloud avec l’API activée et les credentials OAuth 2.0.
Data Manager API ou Google Ads API pour les conversions offline ?
La Data Manager API est le chemin d’avenir : les anciens imports de conversions offline via la Google Ads API se ferment progressivement depuis 2026. Pour toute nouvelle intégration d’activation, partez sur la Data Manager API.
Quel scope OAuth pour la Data Manager API ?
Le scope datamanager. Il est distinct du scope de la Google Ads API : ne réutilisez pas des credentials existants sans le vérifier, sous peine de refus d’autorisation.