La confidentialité des navigateurs change, les cookies tiers sont bloqués par certains navigateurs, Chrome prévoit de supprimer progressivement les cookies tiers d'ici jusqu’à 2022 et Apple a mis en place ses restrictions de suivi pour les utilisateurs iOS. Tous ces changements ont affecté le suivi Web.
Nous avons eu l'habitude de considérer le suivi Web comme une chose frontale, mais avec toutes les nouvelles restrictions de suivi, le suivi Web devient plus difficile. Certains disent que le suivi côté serveur deviendra une nouvelle norme.
L'un des moyens les plus simples et les moins chers pour implémenter le balisage ss consiste à utiliser le serveur Google Tag Manager. Après avoir configuré l'hébergement sGTM, la question suivante serait de savoir comment fournir des données au GTM côté serveur. Avez-vous besoin de créer une couche de données similaire au conteneur Web, ou existe-t-il un autre moyen?
Dans cet article de blog, je voudrais de plonger dans plus de détails sur la création d'une couche de données pour Google Tag Manager côté serveur.
Dans Google Tag Manager Web, les données sont collectées côté client. Vous utilisez les éléments DOM ou extrayez des données du site à l'aide de sélecteurs CSS. Mais dans certains cas, ces méthodes peuvent être instables.
La règle d'or du suivi Web GTM consiste à créer une couche de données fiable. La création d'une structure de couche de données appropriée et sa mise en œuvre sur le site Web prennent un certain temps, non seulement pour les spécialistes du marketing, mais également pour les développeurs. Mais ça vaut le temps. Avec la couche de données, vous obtenez plus de données, et ces données sont fiables.
Un nouvel objet a été ajouté au GTM côté serveur - il s'appelle Client. L'objectif principal du client est de transformer les données de la demande en données d'événement à l'intérieur du serveur GTM.
Comment le Client comprend-il quelle demande traiter et réclamer ? Il vérifie le chemin de la demande. Par exemple, Universal Analytics envoie des demandes contenant /collect. Le client examine le chemin des demandes HTTP entrantes, et si le chemin de la demande a sa « clé », le client transforme les données de la demande en données d'événement dans le sGTM.
Un autre objectif essentiel des clients sGTM est de gérer les demandes HTTP sortantes. Une fois la balise déclenchée dans le sGTM, le Client envoie une demande HTTP sortante pour résumer toutes les demandes envoyées par chaque événement. S'il y avait une erreur avec la balise, vous verriez la raison de l'erreur si vous cliquez sur la requête HTTP sortante et faites défiler jusqu'au l’essentiel de la réponse.
Permettez-moi de vous montrer un exemple. Je vais utiliser Data Tag/Data Client pour cela. Dans le conteneur Web GTM, j'ai configuré une balise de données qui envoie des demandes au conteneur du serveur.
Le chemin des demandes de balise de données contient /data.
Dans le sGTM, j'ai Data Client qui écoute toutes les requêtes contenant /data dans la demande HTTP entrante.
Il y a deux balises (GA4 et Klaviyo actives sur le site) dans le serveur GTM qui se déclenche chaque fois que Data Client est revendiqué, et le nom de l'événement est page_vew. Voyons ce qui se passe dans le serveur GTM lorsqu'il reçoit une requête entrante avec /data et le nom d'événement page_view. Les deux balises sont déclenchées et le client de données envoie une demande HTTP sortante.
Si vous cliquez sur les demandes HTTP entrantes, vous verrez quelles données ont été envoyées au conteneur du serveur. Si vous cliquez sur la demande HTTP sortante, vous verrez quelles informations Data Client a envoyées sur l'exécution des balises déclenchées.
Lorsque vous cliquez sur les données d'événement, vous verrez quelles informations des demandes HTTP entrantes Data Client sont mappées aux données d'événement.
La couche de données n'existe pas dans le serveur Google Tag Manager d'une manière que nous avons eu dans le Web Google Tag Manager. Vous allez créer généralement des balises dans le sGTM en fonction des données d'événement et des données demandées.
Il est très probable que nous ne pourrons pas passer au suivi côté serveur seulement pendant les deux prochaines années. Nous utiliserons une approche hybride - combinant le suivi du Web et du serveur. Cela signifie que certaines balises fonctionneront toujours côté client (soit parce que les plates-formes ne prennent pas encore en charge le suivi ss, soit simplement parce qu'elles ne peuvent pas être déplacées vers ss, cela concerne des outils comme HotJar), et d'autres balises seront mis en place côté serveur. Il y aura un Tag/Client responsable de l'envoi de données spécifiques ou de l'ensemble de la couche de données du Web au conteneur GTM du serveur.
Le schéma ci-dessous montre comment fonctionne le processus de livraison des données au sGTM. Web GTM a une couche de données, UA et pixel FB utilise le suivi Web. Ensuite, nous avons une balise côté serveur GA4 qui est responsable de la transmission des données du Web au serveur GTM. Sur la base de la balise de données GA4 fournie à sGTM, nous pouvons configurer des balises ss Adwords et FB CAPI dans le serveur GTM.
Pour moi, les deux méthodes les plus fréquemment utilisées pour envoyer des données du Web au serveur GTM sont :
- Utiliser Google Analytics 4
- Utiliser la balise de données/client de données (Data Tag/Data Client)
1. Envoyez la couche de données au serveur GTM à l'aide de Google Analytics 4.
Vous pouvez envoyer des données sur les propriétés utilisateur et les paramètres d'événement depuis le Web vers le serveur GTM à l'aide de GA4. Dans la balise GA4 du Web GTM, vous verrez des champs prédéfinis pour ces données et vous pourrez ajouter des variables de couche de données à chaque paramètre individuellement.
Google Analytics 4 et UA ont des normes de couche de données de commerce électronique différentes (couche de données UA, couche de données GA4). Donc, si vous avez une couche de données ee sur le site conçue pour UA, assurez-vous de la modifier pour GA4. La bonne chose est que vous pouvez utiliser des variables dans la galerie de modèles GTM qui convertissent les événements et les variables UA aux normes GA4.
Cette option fonctionne mieux si vous envisagez de configurer le suivi côté serveur pour Google Ads ou Floodlight, car ces deux fonctionnent uniquement sur la base des balises GA4.
2. Utilisez Data Tag/Data Client pour envoyer la couche de données du Web au serveur GTM.
L'avantage le plus important de l'utilisation de Data Tag/Data Client est que DT envoie automatiquement la couche de données et d'autres données communes du Web au serveur GTM. Si vous activez deux cases à cocher, Envoyer les données communes et Tout envoyer depuis DataLayer, il analysera les données dans le Web GTM et enverra toutes les informations qu'il pourrait trouver au serveur GTM. Pas besoin de configurer chaque paramètre à la main.
C'est ainsi que vous verrez les données de commerce électronique dans le sGTM. Vous pouvez utiliser la variable de données d'événement pour l'extraire et l'utiliser pour les balises de serveur, et j'ai fait un article plus détaillé qui décrit Data Tag/Data Client.
Le conteneur Server GTM n'a pas quelque chose de similaire à la couche de données que nous avons utilisée dans le conteneur Web. Mais vous pouvez utiliser la couche de données Web GTM à l'intérieur du sGTM. Cet article de blog a décrit deux méthodes de transformation ultérieure des données Web en données d'événements de serveur - GA4 ou Data Tag/Client.
Il suffit de répondre à quelques questions simples. Cliquez sur Obtenir un devis, remplissez le formulaire, et nous vous enverrons un devis.
