Si vous utilisez déjà server-side GTM, ne créez pas un deuxième pipeline de mesure Google concurrent uniquement pour ajouter Google Tag Gateway. Le modèle combiné recommandé par Google sépare deux chemins de même origine : un chemin de script transmet les requêtes gtm.js ou gtag.js à Google, tandis qu'un chemin de collecte transmet les événements de mesure à votre serveur de balisage. Le conteneur du serveur reste le lieu où les événements sont traités et acheminés.
L'architecture combinée
Une configuration de même origine peut utiliser des chemins tels que www.example.com/scripts pour le chargement de scripts Google propriétaires et www.example.com/metrics pour le conteneur de serveur. Le CDN ou l'équilibreur de charge achemine chaque préfixe vers une origine différente. Google prévient que les deux chemins doivent être inutilisés et ne doivent pas contenir /gtm.
Le navigateur charge le conteneur Web ou la balise Google via le chemin du script. La balise Google est ensuite configurée pour envoyer la mesure au chemin de collecte. Le client sGTM revendique cette requête, produit un événement et déclenche les balises de serveur appropriées.
Lorsque vous exécutez les deux, c'est utile
Cette combinaison est utile lorsque vous souhaitez bénéficier des avantages en matière de résilience du navigateur du chargement de scripts propriétaires et que vous avez également besoin des transformations, de la minimisation des données, des destinations non Google ou de l'observabilité de sGTM. Google recommande explicitement le chargement de scripts propriétaires parallèlement au balisage côté serveur pour une configuration durable.
Cela est moins utile lorsque GTG ne fait que dupliquer les fonctionnalités déjà fournies par un chargeur sGTM propriétaire et une route de collecte correctement configurés. Auditez les chemins actuels avant d’ajouter une autre règle. L'architecture devrait devenir plus claire après le changement et ne pas se contenter de contenir davantage de produits.
Le piège des événements en double
Le modèle dangereux consiste à envoyer la même conversion Google directement via un chemin de transfert GTG et également à l'envoyer via sGTM, où une balise de serveur la soumet à nouveau. Les deux requêtes réseau peuvent aboutir, laissant des conversions gonflées qui ressemblent à une récupération améliorée.
Définissez un propriétaire de livraison pour chaque événement et destination. Les ID de transaction ou d'événement stables sont toujours utiles, mais la déduplication doit être un mécanisme de sécurité et non l'architecture principale. Prévisualisez les conteneurs du navigateur et du serveur ensemble et comptez les demandes de destination sortantes.
La même origine est meilleure qu'un sous-domaine de suivi aléatoire
Google documente la même origine comme étant la meilleure pratique en matière de sécurité et de durabilité des cookies définis sur le serveur. Un chemin sur l'hébergeur du site Web, tel que www.example.com/metrics, a la même origine. Un sous-domaine tel que metrics.example.com est propriétaire mais n'a pas la même origine.
Le routage de même origine nécessite normalement un CDN ou un équilibreur de charge et une priorité de chemin minutieuse. Transférez tous les cookies et chaînes de requête requis par le serveur de balisage, acheminez chaque chemin client, y compris le sous-chemin /_/* documenté, et vérifiez le point de terminaison d'intégrité avant de modifier les balises de production.
Le consentement et la confidentialité contrôlent toujours le flux
La diffusion par la première partie est une décision de transport et non une autorisation. Initialisez les paramètres de consentement par défaut avant la mesure, transmettez l'état de consentement dans la demande de collecte et configurez les balises du serveur afin que les choix de stockage ou de publicité refusés soient traités comme prévu.
Réduisez les données à la limite du serveur. Vérifiez quels cookies, en-têtes, paramètres de requête et champs d'événement entrent dans le conteneur du serveur, puis autorisez uniquement les champs dont chaque destination a besoin. GTG supprime les cookies propriétaires non Google sur son propre chemin de transfert, mais votre chemin de collecte sGTM a ses propres responsabilités en matière de gestion des données.
Une règle de décision claire
Si vous n'avez pas de sGTM et que vous avez uniquement besoin de mesures Google prises en charge, le GTG seul peut suffire. Si vous disposez de sGTM, activez le script Google propriétaire faisant partie de cette architecture et conservez la collecte de mesures pointée vers le conteneur du serveur.
Si deux équipes possèdent GTG et sGTM, publiez une feuille de route et une matrice de propriété de l'événement avant le lancement. Une règle CDN, un paramètre de conteneur Web et une balise de serveur peuvent chacun modifier la destination du même événement ; le chevauchement non documenté est la source habituelle de duplication.
Utilisez deux chemins, pas deux propriétaires de mesures
Le chemin du script et le chemin de la collection sont intentionnellement différents. Le chemin du script charge le code Google en première partie ; le chemin de collecte envoie les événements dans sGTM. Ne laissez pas les deux chemins fournir indépendamment la même conversion.
Configurez GTG avec server-side GTM
Les menus exacts varient selon le CDN, mais les responsabilités et la séquence de validation restent les mêmes.
- 01
Confirmez que le conteneur de serveur est prêt pour la production
Utilisez un déploiement de balisage de production, un serveur de prévisualisation fonctionnel, des contrôles d'accès, une surveillance et un domaine personnalisé avant de modifier l'itinéraire du navigateur.
- 02
Réserver deux chemins de même origine inutilisés
Choisissez un chemin de script tel que /scripts et un chemin de collection tel que /metrics. Aucun des deux chemins ne peut entrer en conflit avec le site ou contenir /gtm.
- 03
Acheminer le chemin de collecte vers sGTM
Configurez le CDN ou l'équilibreur de charge pour transmettre le préfixe de collecte complet, les cookies et les chaînes de requête au serveur de balisage, y compris les chemins requis par les clients du serveur.
- 04
Ajouter l'URL de la collection dans les paramètres du conteneur du serveur
Définissez l'URL du conteneur du serveur sur l'URL de même origine, y compris son préfixe de chemin, puis confirmez que le client attendu revendique une demande d'aperçu.
- 05
Acheminer le chemin du script pour GTG
Transférez le préfixe de script réservé à l'origine de la passerelle Google et mettez à jour la source gtm.js ou gtag.js pour qu'elle soit chargée via ce chemin.
- 06
Pointez les événements Google sur le chemin de collecte
Définissez server_container_url ou le paramètre de balise Google équivalent sur le point de terminaison /metrics afin que la mesure entre dans sGTM au lieu d'aller directement deux fois à la même destination.
- 07
Configurer les clients, les balises et le consentement
Vérifiez la priorité du client, les transformations d'événements, les vérifications de consentement, les balises de destination et les identifiants d'événements stables à l'intérieur du conteneur de serveur.
- 08
Testez l'itinéraire complet
Confirmez que le script se charge à partir de /scripts, qu'une requête atteint /metrics, que le client du serveur la réclame et qu'exactement une requête attendue part pour chaque destination.
- 09
Surveiller après la sortie
Alertez en cas de problèmes de santé et de volumes inhabituels, examinez les diagnostics de destination et rapprochez les achats ou les prospects avec la vérité du système source.
Exécutez des couches complémentaires, pas des pipelines parallèles
GTG et sGTM fonctionnent bien ensemble lorsque la passerelle gère la livraison de scripts propriétaires et que sGTM possède le traitement des événements. Le modèle à deux chemins rend cette frontière visible et testable.
La configuration échoue lorsque la même conversion a deux propriétaires de diffusion. Documentez les chemins, préservez l'identité d'un événement, testez les états de consentement et comptez les requêtes qui quittent réellement le serveur.
GTG plus sGTM : questions courantes
Chaque configuration sGTM devrait-elle également utiliser Google Tag Gateway ?
La diffusion de scripts propriétaires est recommandée par Google, mais auditez d'abord votre chargeur et vos itinéraires existants. Certaines configurations sGTM servent déjà des dépendances propriétaires et peuvent nécessiter uniquement une mise à jour de la configuration.
GTG et sGTM peuvent-ils utiliser le même chemin ?
Le modèle CDN de Google utilise des chemins distincts : un pour les scripts et un pour la collecte d'événements. Des itinéraires séparés évitent les conflits d’origine et clarifient les responsabilités.
Comment puis-je éviter les conversions Google en double ?
Choisissez un expéditeur pour chaque conversion. Si sGTM envoie la demande de destination Google, n'envoyez pas également une demande de navigateur directe équivalente. Vérifiez le nombre de demandes sortantes dans l’aperçu et les diagnostics de destination.
Un sous-domaine est-il la même chose qu'une diffusion de même origine ?
Non. Un sous-domaine est propriétaire, mais la même origine signifie le même schéma, le même nom d'hôte et le même port que le site Web. Google répertorie les deux comme prenant en charge les cookies définis par le serveur, mais considère que la même origine est la meilleure pratique.
Quel chemin doit envoyer les événements Meta ou TikTok ?
Ces demandes de destination doivent être créées par des balises de serveur dans sGTM ou une autre intégration de serveur. Le chemin de script Google de GTG n'est pas une route générale d'API de conversion non Google.