ECAPI : le standard universel des Conversions API à l'épreuve

Le 10 septembre 2026, Google a qualifié sa Data Manager API d’« universelle ». Le mot a fait tiquer tous ceux qui gèrent un conteneur server-side avec trois, cinq, parfois huit Conversions API empilées : universelle, vraiment ? Derrière l’annonce, il y a ECAPI, le standard de l’IAB Tech Lab censé remplacer votre pile de Conversions API propriétaires par un seul schéma d’événement. La promesse tient en trois mots : écrire une fois, envoyer partout. La réalité, quand on ouvre la doc de mapping de Google, tient en un constat : trois écarts qui cassent le copier-coller. Cet article vous dit ce qu’ECAPI change pour vous aujourd’hui, ce qu’il ne change pas, et comment préparer votre couche d’événements sans tout refaire.

La version courte. ECAPI donne enfin un vocabulaire commun aux Conversions API. Mais « vocabulaire commun » n’est pas « plomberie commune ». Aucune plateforme n’accepte aujourd’hui un payload ECAPI brut sans adaptation. Ne refondez pas vos intégrations qui marchent. Alignez plutôt votre couche d’événements interne sur la taxonomie ECAPI : c’est ça qui vous fera gagner du temps quand l’adoption arrivera, plutôt en 2027.

ECAPI en 150 mots : ce que dit vraiment la spec

ECAPI, c’est l’Event Conversion API standard publié par l’IAB Tech Lab, version 1.0 finalisée le 3 mai 2026. Il a été co-écrit par les gens qui reçoivent vos conversions : Meta, Google, TikTok, Walmart et Roku. L’idée est simple. Au lieu que chaque plateforme impose son propre format d’événement serveur, tout le monde s’accorde sur un seul schéma. Un événement ECAPI porte quelques champs obligatoires, dont data_set_id, timestamp et event_type, et s’appuie sur une taxonomie full-funnel qui couvre l’entonnoir en entier, du haut de funnel jusqu’au cycle de lead complet, de generate_lead à close_convert_lead.

C’est là que le standard devient intéressant pour un praticien : il ne se limite pas au purchase e-commerce. Il modélise le lead B2B, le retail media, la CTV. Reste à savoir qui l’accepte vraiment. Réponse : personne, pas encore tel quel.

Ce que Google a annoncé le 10 septembre, et ce que dit sa doc

L’annonce du 10 septembre présente la Data Manager API comme « universelle » parce que construite sur ECAPI. C’est la première adoption officielle du standard par un gros receveur, et ça compte : la Data Manager API est le chemin d’avenir que Google pousse depuis qu’il a gelé le Measurement Protocol. Si le sujet vous a échappé, notre comparatif Measurement Protocol ou Data Manager API fait le point, et le guide du Data Manager Google Ads traite l’interface produit à ne pas confondre avec l’API. Cette même annonce du 10 septembre portait aussi la métrique Data Strength Uplift.

« Universelle » sonne bien. Sauf que la doc de mapping publiée par Google montre, noir sur blanc, que le payload ECAPI ne part pas tel quel dans la Data Manager API. Il faut le transformer. Et les transformations ne sont pas cosmétiques.

Les 3 écarts entre ECAPI et la Data Manager API

Voici les trois points où le « write once, send everywhere » se casse dès qu’on passe de la théorie à la doc Google.

1. La déduplication ne se fait pas sur le même champ. ECAPI identifie un événement par sa clé id. La Data Manager API, elle, déduplique sur transaction_id. Ce n’est pas un détail : si vous mappez naïvement id vers id, Google ne dédupliquera rien, et vos conversions server-side risquent de doubler celles du navigateur. Il faut router votre identifiant unique vers transaction_id.

2. Le routage n’utilise pas le même champ. Dans ECAPI, la destination d’un événement se lit dans data_set_id. Dans la Data Manager API, elle passe par un objet destinations. Le champ que le standard rend obligatoire n’est donc pas celui qui pilote réellement l’envoi côté Google. Encore une transformation à écrire.

3. Le consentement GPP n’est pas lu. C’est l’écart le plus lourd, et j’y reviens en détail plus bas. ECAPI transporte le consentement via la chaîne GPP. La Data Manager API ne la lit pas et exige son propre objet Consent. En Europe, se fier au seul mécanisme prévu par le standard, c’est envoyer des données sans le signal de consentement que Google attend.

Bonus, parce qu’il piège tout le monde au premier test : le format d’horodatage. ECAPI et beaucoup de CAPI historiques raisonnent en timestamp Unix. La Data Manager API attend du RFC 3339. Un 1757462400 qui part au lieu d’un 2026-09-10T00:00:00Z, et l’événement est rejeté.

Trois écarts plus un piège de format. Chacun est surmontable, aucun n’est « universel ». Le standard vous donne un vocabulaire ; la plomberie, vous continuez de la câbler à la main.

La table des clés de déduplication, plateforme par plateforme

C’est le vrai point de friction quand on veut « standardiser ». Chaque plateforme dédup sur son propre champ, et ECAPI en propose encore un autre. Tant que vous générez un identifiant unique par événement et que vous savez vers quel champ le router pour chaque destination, vous êtes bon. Voici la correspondance à garder sous les yeux.

La leçon opérationnelle : générez un seul identifiant d’événement, une fois, le plus tôt possible dans votre couche serveur, puis propagez-le vers le bon champ de chaque destination. C’est exactement ce qu’ECAPI encourage, même si les noms de champs, eux, ne convergent toujours pas. La multiplication des receveurs accélère : Microsoft Ads a lancé sa CAPI en pilote, et ChatGPT Ads arrive avec la sienne. Plus il y a de destinations, plus un identifiant unique et centralisé devient vital.

Consentement : le point aveugle en Europe

C’est le sujet que personne ne traite, et c’est le plus dangereux. ECAPI a un modèle de consentement intégré. Il transporte la chaîne GPP via gpp_string et gpp_sid, et il prévoit un flag mmt_only : mesure seule, pas d’optimisation ni de ciblage. Sur le papier, c’est propre, et c’est même le seul mécanisme de consentement que le standard définit.

Le problème, je l’ai signalé plus haut : Google ne lit pas cette chaîne GPP. La Data Manager API exige son propre objet Consent. Autrement dit, si vous suivez le standard à la lettre en Europe et que vous vous reposez sur gpp_string, votre consentement n’arrive jamais côté Google. Et un point que le standard rappelle sans ambiguïté : ECAPI ne génère pas le consentement, il ne fait que le transporter. La collecte reste votre responsabilité, en amont.

Concrètement, en UE, vous devez continuer de brancher votre signal de consentement au format attendu par chaque plateforme, sans supposer que le champ ECAPI suffira. Pour le cadre côté Google, Consent Mode v2 reste la référence, l’évolution réglementaire est suivie dans notre article Digital Omnibus, et la question du champ event_ip_address d’ECAPI rejoint directement celle de l’adresse IP dans Google Ads.

Faut-il refondre vos Conversions API dans votre sGTM ?

Réponse honnête : la plupart du temps, non. Voici la grille que j’applique.

Ne touchez à rien si vos intégrations CAPI actuelles fonctionnent, remontent, dédupliquent correctement. ECAPI n’apporte aucun endpoint universel qui remplacerait votre câblage. Casser une intégration qui marche pour « passer au standard » est une mauvaise idée en 2026.

Alignez votre couche interne, en revanche, et faites-le maintenant. C’est là qu’ECAPI est utile sans rien casser : nommez vos événements selon la taxonomie ECAPI, générez un event_id unique une seule fois et propagez-le partout, et centralisez la normalisation et le hachage SHA-256 de vos identifiants clients. Ce travail est réutilisable quelle que soit la destination. Sur le hachage server-side, notre guide Enhanced Conversions server-side détaille la méthode.

Priorisez dans trois cas. D’abord le lead funnel B2B, parce que la taxonomie ECAPI modélise tout le cycle, de generate_lead à close_convert_lead : voir Enhanced Conversions for Leads en sGTM. Ensuite la CTV et le retail media, que le standard couvre nativement. Enfin toute nouvelle plateforme que vous branchez : autant partir directement sur un nommage aligné.

Checklist ECAPI-ready en 6 points pour votre conteneur sGTM

Si vous voulez préparer votre server-side sans vous précipiter, voici les six points à cocher. Ils s’appuient sur les bonnes pratiques de notre guide GTM server-side.

1. Un identifiant d’événement unique, généré une seule fois côté serveur, propagé vers chaque destination.
2. Un nommage d’événements calqué sur la taxonomie ECAPI, y compris le cycle de lead complet.
3. Une normalisation et un hachage SHA-256 centralisés des données clients, pas répétés tag par tag.
4. Un horodatage stocké dans un format pivot, converti en RFC 3339 ou Unix selon la destination.
5. Un signal de consentement câblé au format attendu par chaque plateforme, jamais supposé porté par le seul champ GPP.
6. Une table de mapping documentée, clé de dédup et champ de routage pour chaque receveur.

Ce qui reste flou, et il faut le dire

Soyons clairs sur les limites, parce que beaucoup de contenus survendent le sujet. Aujourd’hui, aucun endpoint universel n’existe. Chaque plateforme garde son endpoint, ses champs minimaux, ses règles. Google est le premier gros receveur à revendiquer ECAPI, et même lui exige des transformations. À ce jour, rien n’indique que Meta ou TikTok exposent un endpoint qui avale un payload ECAPI brut : tant qu’ils ne l’ont pas publié, ne le supposez pas.

L’adoption sérieuse est attendue plutôt en 2027. Le mouvement est réel, poussé par un contexte qui rend le sujet concret : Safari 27 qui bloque des endpoints pixels par IP, la multiplication des CAPI, les guidelines ECAPI pour les data clean rooms dont la consultation IAB s’est close le 4 septembre 2026. Mais entre « le standard existe » et « je copie-colle mon payload partout », il y a encore un an de plomberie.

Le bon réflexe, donc : traitez ECAPI comme une cible d’architecture, pas comme un bouton à presser. Alignez votre couche d’événements dès maintenant, gardez vos intégrations qui marchent, et vous serez prêt le jour où les receveurs, eux, le seront vraiment.