Pinterest Conversions API server-side GTM : déduplication et EMQ

Installer le Pinterest Conversions API en server-side GTM n’est pas le vrai défi : le template officiel dans la GTM Template Gallery et les tags Stape ou TAGGRS enchaînent le setup en quelques minutes. Le problème, c’est que la plupart des annonceurs restent sur le seul Pinterest Tag client-side et perdent une part importante de leur signal de conversion, à cause des bloqueurs, du consentement et de l’ITP de Safari. Cet article ignore le tuto générique pour se concentrer sur les deux réglages qui décident vraiment de la qualité de votre signal Pinterest : la déduplication via event_id entre le Pinterest Tag et le serveur, et l’Event Match Quality (EMQ) visible dans Pinterest Ads Manager. Objectif : repartir avec un CAPI propre, sans doublons, et un matching solide pour l’algorithme d’enchères.

Pourquoi le Pinterest Tag seul ne suffit plus en 2026

Le tracking navigateur s’érode sur les mêmes fronts que pour Meta ou TikTok. Les adblockers et l’ITP de Safari empêchent les tags GTM client-side de se déclencher sur 30 à 50 % des sessions selon les audiences, et les taux de refus du consentement oscillent souvent entre 50 et 60 %. Sur Pinterest, l’enjeu est particulier : l’audience est en phase de découverte et d’inspiration, avec un cycle d’achat parfois long entre le premier pin vu et la commande. Si une part structurelle de vos conversions ne remonte jamais au Pinterest Tag, l’algorithme d’enchères optimise sur un signal amputé et vous payez plus cher chaque conversion attribuée.

Le Pinterest Conversions API en server-side GTM répond à ce problème en envoyant les événements directement depuis votre conteneur serveur vers Pinterest, sans dépendre du navigateur. Le gain est double : un volume d’événements plus complet et des données utilisateur plus riches, deux leviers directs sur la performance des campagnes. C’est exactement la même logique que celle décrite dans le guide Meta CAPI server-side GTM, appliquée à l’écosystème Pinterest.

Architecture duale Tag + CAPI : comment Pinterest gère la déduplication

Pinterest recommande de garder les deux canaux en parallèle : le Pinterest Tag côté navigateur pour la réactivité, et la Conversions API côté serveur pour la fiabilité. Mais faire tourner les deux sans câblage entraîne un comptage double. C’est là qu’intervient la déduplication.

Contrairement à Snapchat qui propose deux clés distinctes, Pinterest fonctionne sur une logique simple et unique : une seule clé, l’event_id. Quand le même événement arrive à la fois via le Pinterest Tag et via la CAPI avec un event_id identique, Pinterest reconnaît qu’il s’agit de la même action et ne la compte qu’une fois. La condition est stricte : la déduplication ne fonctionne que si l’event_id est rigoureusement le même dans les deux sources. La moindre différence, et vous vous retrouvez avec des conversions comptées en double, un ROAS gonflé et un algorithme qui apprend sur des données faussées.

Prérequis avant de configurer le Pinterest CAPI

Trois éléments doivent être en place avant de commencer :

• Un conteneur server-side GTM actif, sur Google Cloud ou via un hébergeur comme Stape ou Addingwell. Si vous n’y êtes pas encore, commencez par le guide GTM server-side : pourquoi et comment migrer, et gardez en tête le coût réel du server-side.
• Le Pinterest Tag côté client déjà en place, car la déduplication repose sur l’envoi du même événement par deux canaux (le Tag et le serveur).
• Un accès à Pinterest Business et un compte Pinterest Ads, avec les droits pour générer un token.

Récupérez ensuite deux identifiants dans Pinterest Ads Manager : votre Pinterest Advertiser ID et un Access Token. Le parcours : Ads Manager, puis Settings, puis la section Conversions, puis la page Set Up API. Dans le bloc de génération de token de conversion, vous trouverez l’Advertiser ID et le bouton pour générer un nouveau token. Ce token authentifie les appels serveur, ne le partagez jamais côté client.

Setup server-side GTM pas à pas

Le workflow suit la logique de tout tag CAPI en server-side :

1. Importez le template Pinterest Conversions API dans votre conteneur serveur, depuis la GTM Template Gallery (template Stape) ou le dépôt correspondant de TAGGRS.
2. Créez un flux de données du web vers le serveur, via un client GA4 server-side ou un Data Tag / Data Client, pour que les événements du navigateur atteignent le conteneur serveur.
3. Configurez le tag Pinterest : renseignez le Pinterest Advertiser ID et l’Access Token, choisissez l’Action Source (web dans la plupart des cas), puis la méthode de nommage des événements. L’option standard mappe vers les événements Pinterest (page_visit, add_to_cart, checkout, signup, lead, etc.), l’option héritée du client tente un mapping automatique.
4. Passez les données utilisateur pour l’EMQ (voir plus bas) et l’event_id de déduplication.
5. Ajoutez un déclencheur correspondant aux événements que vous voulez remonter.

L’erreur classique consiste à mapper les événements sans jamais transmettre ni les données utilisateur ni l’event_id. Le tag se déclenche, Pinterest reçoit bien un événement, mais le matching plafonne et les conversions se comptent en double.

Câblage de l’event_id : générer, pousser, relayer

Le principe tient en trois étapes, et la cohérence de la valeur entre les deux canaux est la seule chose qui compte.

D’abord, générez un event_id unique au moment exact de l’action utilisateur. Un UUID, ou une combinaison d’horodatage et d’identifiant de transaction, fait l’affaire. L’important est l’unicité par événement : deux actions distinctes ne doivent jamais partager le même identifiant, sous peine de déduplication accidentelle.

Ensuite, poussez cette valeur dans le dataLayer avec l’événement, par exemple :

window.dataLayer.push({
  event: 'purchase',
  event_id: 'pin_1721456789123_45678',
  // autres paramètres de l'événement
});

Enfin, référencez le même event_id des deux côtés : dans le Pinterest Tag du conteneur web, et dans le payload de la CAPI côté serveur. Le template Pinterest récupère en général l’event_id automatiquement depuis les données d’événement, mais vérifiez toujours qu’il part bien avec la même valeur qu’en client. Cette exigence de cohérence entre client et serveur est identique à celle décrite pour TikTok Events API et LinkedIn CAPI.

Améliorer l’Event Match Quality (EMQ) Pinterest

L’Event Match Quality mesure la capacité de Pinterest à rattacher vos événements à de vrais comptes utilisateurs. Plus le score est élevé, mieux l’algorithme optimise. Le levier, c’est la quantité et la qualité des données utilisateur transmises, hachées en SHA-256 côté serveur avant l’envoi pour toutes les données personnelles.

Le server-side GTM a un avantage décisif ici : l’IP et le user agent sont captés nativement par le conteneur serveur, sans manipulation. Pour l’email, le téléphone et le nom, récupérez-les au moment de la conversion (formulaire, checkout), hachez-les côté serveur, puis passez-les au tag Pinterest. Le click_id se capture via le paramètre d’URL _epik à l’atterrissage et se stocke en cookie first-party pour être renvoyé avec chaque événement. Priorisez l’email, le téléphone et l’external_id : ce sont les identifiants qui font le plus bouger le score. C’est le même principe que les Enhanced Conversions en server-side pour Google Ads.

Vérification et checklist finale

Une fois le tag en place, validez avant de vous fier aux chiffres :

• L’aperçu du server-side GTM (mode Preview) confirme que le tag se déclenche, que l’Advertiser ID et l’Access Token sont corrects, et que l’event_id part bien avec la même valeur que côté client. Le mode Test du template envoie des requêtes sans les enregistrer, pratique pour valider la structure.
• Pinterest Ads Manager affiche l’état de vos événements et la qualité du matching. Vérifiez que vos conversions apparaissent une seule fois, sans doublon.
• Le score EMQ met quelques jours à se stabiliser. Visez le vert et itérez en ajoutant des données utilisateur si le score reste bas.

Avant de considérer votre Pinterest Conversions API comme opérationnel, vérifiez que :

• le conteneur server-side GTM est actif et le Pinterest Tag client-side toujours en place ;
• le Pinterest Advertiser ID et l’Access Token sont correctement renseignés dans le tag serveur ;
• un event_id unique part avec la même valeur des deux côtés, généré au moment de l’action ;
• l’email, le téléphone et le nom sont hachés en SHA-256, l’IP, le user agent et le click_id transmis ;
• Pinterest Ads Manager montre des événements dédupliqués, sans doublon ;
• le consentement conditionne bien l’envoi des données, car passer côté serveur ne dispense pas du RGPD. Pour brancher le consentement dans cette architecture, voyez le guide Consent Mode v2 avec GA4.

Le Pinterest CAPI en server-side GTM complète une stack déjà couverte pour Meta, TikTok, LinkedIn et Snapchat. En traitant sérieusement la déduplication et l’EMQ, vous donnez à l’algorithme Pinterest un signal propre et complet, la vraie condition d’une optimisation efficace en 2026.