Quelles plates-formes prennent en charge Google Tag Manager côté serveur ?

Google Tag Manager côté serveur (sGTM) prend en charge de nombreuses plateformes publicitaires et analytiques, comme GA4, Google Ads, Meta, TikTok, Pinterest, LinkedIn, Snapchat, Klaviyo et ActiveCampaign. Des couches de données e-commerce sont disponibles pour les CMS tels que WordPress, Shopify, Lightspeed, Magento, WooCommerce et PrestaShop. Les applications mobiles sur iOS et Android sont également prises en charge.

L'emplacement de chaque plateforme (conteneur web, conteneur serveur ou les deux) détermine si vos données de conversion sont exactes.

Cet article explique le pourquoi de chaque décision de placement, ce qui se produit lorsque vous vous trompez et ce que les fournisseurs d'hébergement sGTM comme TAGGRS gèrent au niveau de l'infrastructure que la configuration du conteneur ne peut pas résoudre à elle seule. Et si vous connaissez déjà votre (vos) plateforme(s), utilisez le vérificateur interactif ci-dessous pour passer directement aux étapes de configuration.

Qu'est-ce qu'un conteneur de serveur GTM et qu'est-ce qu'il héberge ?

Un conteneur serveur GTM fonctionne sur un serveur hébergé et exécute les balises de serveur à serveur, indépendamment du navigateur du visiteur. Il fonctionne parallèlement au conteneur web GTM standard en utilisant une architecture à deux conteneurs :

1. conteneur web, qui fonctionne dans le navigateur du visiteur et exécute les balises côté client
2. qui s'exécute sur un serveur hébergé (tel que TAGGRS) et exécute les balises de serveur à serveur.

C'est dans le conteneur du serveur que se fait le véritable travail. Lorsqu'il est configuré correctement, il définit des cookies de première partie qui durent jusqu'à plus de 365 jours. Cet aspect est plus important que jamais, car l'ITP de Safari limite à 7 jours la durée des cookies définis par le navigateur, et Safari représente environ 17 % de la part de marché mondiale des navigateurs au début de l'année 2026. (source : StatCounter, Browser Market Share Worldwide)

En d'autres termes, près d'une session sur cinq perd des données de suivi par défaut si vous ne travaillez qu'en mode client.

L'hébergement TAGGRS sGTM est un fournisseur de Server-side Tracking géré qui héberge votre conteneur de serveur GTM sur une infrastructure européenne indépendante. Il fonctionne avec Google Tag Manager en utilisant deux conteneurs :

L'hébergement TAGGRS sGTM fonctionne avec n'importe quelle pile de sites web. La règle est la suivante : s'il fonctionne avec Google Tag Manager, il fonctionne également avec TAGGRS. Ainsi, les CMS avec un support de couche de données dédié incluent WordPress, Shopify, Lightspeed, Magento, WooCommerce, et PrestaShop. Les applications mobiles sur iOS et Android sont également prises en charge.

Où placer le conteneur ?

Chaque plateforme est placée dans l'une des trois configurations suivantes. Il s'agit d'une décision architecturale qui détermine si les conversions sont comptabilisées correctement, si les cookies survivent à l'ITP et si les données quittent votre infrastructure avant ou après l'application du consentement. Voici la répartition :

Configuration	Ce que cela signifie	Quand l'utiliser ?
Conteneur web uniquement	L'étiquette s'exécute dans le navigateur. Il n'y a pas de composant serveur.	Non pertinent pour les configurations sGTM.
Conteneur de serveur uniquement	Toutes les données proviennent du serveur. Il n'y a pas de marqueur de navigateur.	Lorsque la plate-forme ne prend pas en charge la déduplication, ou lorsque la balise du navigateur n'est pas nécessaire. Remarque : en l'absence d'une configuration GTM côté client existante, une configuration uniquement sur serveur nécessite une mise en œuvre personnalisée du suivi, la collecte d'événements au niveau du front-end et la transmission d'événements au niveau du back-end devant être élaborées et maintenues à partir de zéro.
Les deux conteneurs	La balise du navigateur envoie des données au conteneur du serveur, qui les transmet à la plate-forme. Le conteneur web peut également envoyer des données au server-side sans rien envoyer directement à une plateforme. La déduplication n'est nécessaire que lorsque le navigateur et le serveur envoient simultanément des données à la même plate-forme.	Lorsque la plateforme bénéficie à la fois des signaux du navigateur et de la fiabilité du serveur.

Dans quel conteneur se trouve votre plate-forme ?

Vous ne savez pas où placer une plate-forme spécifique ? Utilisez le vérificateur ci-dessous. Sélectionnez une plateforme et obtenez l'emplacement des conteneurs, les exigences en matière de déduplication et les étapes exactes de la configuration.

Plates-formes qui vont dans le conteneur du serveur uniquement

Plates-formes publicitaires

Le suivi côté serveur des annonces Google nécessite 4 composants successifs :

1. GA4 Config tag (conteneur web)
2. Étiquette de serveur GA4 (conteneur de serveur)
3. Conversion Linker tag (conteneur de serveur)
4. Balise Google Ads Conversion Tracking (conteneur de serveur)

D'après les questions fréquemment posées à notre service d'assistance, le Conversion Linker est l'étape la plus souvent omise. Sans lui, les données relatives aux clics ne sont pas correctement rattachées aux conversions et l'attribution est rompue. Le Remarketing de Google Ads passe par la même chaîne.

Google Ads Remarketing fonctionne également côté serveur uniquement, en utilisant la même dépendance GA4.

TikTok est également un conteneur de serveur uniquement. Le pixel de TikTok ne prend pas en charge la déduplication des événements au niveau requis pour exécuter simultanément le suivi du navigateur et du serveur. La balise serveur envoie des événements à l'API d'événements de TikTok et transforme automatiquement les données utilisateur requises (courriel, téléphone) en minuscules et les hachure à l'aide de SHA256 avant de les transmettre.

Vérifiez votre configuration dans le gestionnaire d'événements de TikTok avant d'activer le suivi parallèle.

CRM et automatisation du marketing

Klaviyo ne prend pas en charge la déduplication des événements. L'exécution à la fois du navigateur et du serveur envoie des événements en double à Klaviyo. Configurez uniquement le côté serveur. La balise communique directement avec l'API de Klaviyo et prend en charge l'ajout de contacts, le suivi de l'activité sur le site et l'envoi de paramètres d'événements.

ActiveCampaign se connecte à l'API ActiveCampaign côté serveur. La balise prend en charge 3 types d'action : suivre les événements, créer ou mettre à jour un contact, et créer ou mettre à jour un contact tout en suivant un événement simultanément.

Plates-formes nécessitant à la fois le conteneur web et le conteneur serveur

Analyse

Google Analytics 4 n'est pas facultatif dans une configuration server-side. La balise GA4 Config du conteneur web envoie des données au conteneur serveur, qui alimente toutes les balises en aval, y compris Google Ads. Il n'y a pas d'installation de Google Ads côté serveur sans que GA4 côté serveur soit d'abord en place.

Déduplication pour GA4 ? Ce n'est pas nécessaire. La continuité des sessions est assurée automatiquement dans les deux conteneurs.

Plates-formes publicitaires

Plate-forme	Pourquoi les deux conteneurs ?	La déduplication est-elle nécessaire ?	Paramètre de correspondance
Meta	Meta recommande d'utiliser simultanément le pixel du navigateur et le CAPI du serveur pour maximiser les taux de correspondance et la couverture de l'événement.	Oui	L'identifiant de l'événement doit correspondre à celui de l'événement web et à celui de l'événement serveur.
Pinterest	Browser tag + Conversions API fonctionnent en parallèle, avec la même logique de double signal que Meta.	Oui	ID de l'annonceur + clé de déduplication de l'événement
LinkedIn	Insight Tag s'exécute côté client ; le tag serveur envoie les événements de conversion via LinkedIn CAPI.	Oui	conversionId
Snapchat	Snap Pixel (web) + Snap Conversions API (serveur) fonctionnent en parallèle. Le tag normalise et hachure automatiquement les paramètres de l'utilisateur.	Oui	event_id

Mais que signifie la déduplication dans la pratique ? La déduplication se produit lorsque le même événement de conversion se produit à la fois dans le navigateur et sur le serveur, de sorte que la plateforme le reçoit deux fois. Sans logique de déduplication (un identifiant d'événement partagé qui indique à la plateforme que ces deux événements sont identiques), vos comptes de conversion gonflent. Pour Meta en particulier, cela signifie que les rapports ROAS ne sont plus fiables.

Commerce électronique : Couches de données spécifiques au CMS

Le suivi côté serveur ne vaut que ce que valent les données d'événement qui atteignent le conteneur du serveur. Pour le commerce électronique, cela signifie une couche de données correctement structurée: une couche qui transmet les événements d'achat, d'ajout au panier et de visualisation des produits avec les bons paramètres.

TAGGRS dispose de configurations de couches de données dédiées pour les CMS, notamment WordPress (avec WooCommerce), Shopify, Lightspeed, Magento et PrestaShop.

Chaque CMS a une structure de couche de données différente. L'utilisation d'un format d'événement incorrect fait que les événements de conversion arrivent au conteneur du serveur avec des paramètres manquants ou mal formés : c'est la raison la plus fréquente pour laquelle le suivi des annonces Google côté serveur semble fonctionner mais ne rend pas compte des conversions.

Applications mobiles : iOS et Android

TAGGRS prend en charge le suivi côté serveur pour les applications mobiles sur iOS et Android. Les événements de l'application passent par le conteneur du serveur en utilisant la même infrastructure que le suivi Web. Ceci est pertinent pour les équipes qui mènent des campagnes Google Ads App ou des campagnes d'installation d'apps Meta où le suivi côté navigateur n'est pas disponible et où les données d'événements au niveau du SDK ont besoin d'un relais serveur avant d'atteindre les plateformes publicitaires.

Quelle configuration correspond à votre pile de suivi ?

Google Ads + GA4 uniquement

Configurez GA4 dans les deux conteneurs. Google Ads s'exécute uniquement côté serveur. Il s'agit de la configuration sGTM minimale viable pour les équipes qui débutent.

Google Ads + Meta + GA4

Ajoutez Meta CAPI avec la déduplication de l'identifiant de l'événement. Il s'agit de la configuration la plus courante pour les agences. Elle couvre les deux plates-formes les plus coûteuses et permet à la plupart des clients d'obtenir le gain le plus important en termes de récupération du signal.

Google Ads + Meta + TikTok + LinkedIn + Klaviyo

Toutes les plates-formes susmentionnées s'appliquent. À cette échelle, la gestion de l'infrastructure - temps de disponibilité des conteneurs, accès multi-clients, rotation des informations d'identification - devient la contrainte opérationnelle, et non la configuration des balises. L'hébergement géré et les contrôles d'accès basés sur les rôles de TAGGRS sont conçus pour cet environnement.

Pile de commerce électronique (Shopify / WooCommerce / Lightspeed)

Commencez par configurer la couche de données spécifique au CMS avant de définir les balises de la plateforme. Une couche de données incomplète produit des paramètres manquants au niveau du serveur, et aucune configuration de balise ne peut compenser des événements qui ne se sont jamais formés correctement en amont.

FAQ

Quelles plates-formes nécessitent une déduplication des événements dans le GTM côté serveur ?

Meta (Facebook CAPI), Pinterest, LinkedIn CAPI et Snapchat CAPI nécessitent une déduplication des événements lorsque le suivi est effectué simultanément par le navigateur et le serveur. TikTok ne prend pas en charge la déduplication et doit être configuré uniquement sur le serveur pour éviter de gonfler le nombre de conversions.