Monitoring et performance de votre tracking Server-Side
Votre migration Server-Side est terminée, mais vous ne savez pas quels indicateurs suivre pour vous assurer que votre tracking reste 100 % optimal une fois en production ?
Aucun setup n’est à l’épreuve du temps, car des modifications sur votre site ou sur votre tracking peuvent avoir des conséquences négatives comme par exemple :
- Une chute du volume de données (arrêt involontaire du bypass des adblockers).
- Un envoi de données partielles à vos plateformes analytiques ou médias (requêtes avec un taux de succès < 100 %).
- Des performances médias non optimisées (algorithmes mal alimentés en données utilisateurs).
Il est donc essentiel de continuer à surveiller certains indicateurs clés afin d’identifier rapidement d’éventuels problèmes et de les corriger.
Bonne nouvelle, votre conteneur Addingwell contient de précieuses informations qui vous permettront de vérifier facilement que :
- Le volume de vos requêtes de tracking est aligné avec votre activité (et donc cohérent avec le trafic de votre site).
- Le bypass des adblockers est bien en place, et que vous êtes donc en mesure de récupérer ce volume de données incrémentales.
- Vos prestataires médias reçoivent bien tous les événements que vous avez configurés sur vos tags server-side (avec un taux de succès de 100 % pour chacun de vos prestataires).
- Vous contribuez à alimenter vos prestataires médias avec de la donnée qualitative pour leurs algorithmes. Vérifier notamment si des user data sont correctement transmises de votre GTM Web vers votre GTM Server.
Dans cet article, découvrez les écrans clés de votre conteneur Addingwell ainsi que les indicateurs essentiels à suivre une fois votre migration Server-Side finalisée.
Volume de requêtes cohérent avec votre activité, bypass des Adblockers effectif
Via votre Dashboard, obtenez une vue d’ensemble rapide et efficace sur :

- Le volume de requêtes reçues par votre serveur au cours des 28 derniers jours. C’est un premier niveau d’informations, mais vous avez plus de détails sur les courbes visibles juste en dessous.
- Vous trouverez sur ces courbes le détail des requêtes entrantes sur votre serveur sur les 28 derniers jours. Vous avez la possibilité de filtrer sur une période plus longue (90j, 365j, ou depuis la mise en place de votre server-side).
- En bleu, les tagging server requests correspondent aux événements envoyés depuis votre GTM WEB vers votre GTM SERVEUR. Cette courbe doit donc refléter votre activité, et vous pouvez vérifier si les éventuels pics/hausses dans les requêtes correspondent bien à votre trafic.
- En rouge, des requêtes CDN additionnelles apparaissent si votre bypass d’adblockers a été paramétré et qu’il est effectif. Si vous ne voyez pas de requêtes CDN, votre bypass d’adblockers ne fonctionne pas (ou a été desactivé suite à une modification sur votre site), et il faut tout simplement mettre en place le snippet alternatif Addingwell.
- En vert, des requêtes Database additionnelles sont présentes si vous utilisez la fonctionnalité Cookie Restore pour maintenir les cookies au-delà de 7 jours sur Safari.
- Le(s) sous-domaine(s) de tracking configuré(s) sur votre conteneur. (Cliquez sur la carte “Domains” pour voir la liste complète ou pour pouvoir ajouter un nouveau sous-domaine). Si votre sous-domaine est inactif, un message d’erreur apparaît. Vérifiez dans ce cas avec votre hébergeur l’enregistrement DNS de votre sous-domaine.
- Le nombre et la localisation des serveurs de tracking déployés.
Pour maintenir des performances optimales, il est crucial que vos serveurs de tracking soient au plus près de vos internautes, afin de limiter les allers-retours lointains et garantir une meilleure réactivité.
En scrollant vers le bas de l’écran Dashboard, vous pouvez vérifier via une carte d’où provient votre trafic sur les 28 derniers jours, et décider en conséquence s’il est pertinent d’ajouter un serveur dans une région additionnelle (tarif additionnel pour une zone supplémentaire).
- Le taux de disponibilité de vos serveurs Addingwell, sur les derniers mois. Notre promesse est simple : vous garantir une infrastructure ultra-performante pour vos serveurs. Cela signifie que nous garantissons que dans 99,95 % du temps, vos serveurs sont disponibles pour recevoir des requêtes.
Events Monitoring : monitorer les événements envoyés par votre serveur à vos prestataires
Events Monitoring est votre outil de monitoring en temps réel. Il vous permet de suivre la bonne distribution de vos événements vers vos différents partenaires média et analytics.
Fini l’effet “boîte noire” : vous savez en temps réel ce qui se passe pour chaque tag et chaque événement mis en place côté serveur. En cas de dysfonctionnement, vous pouvez identifier le problème et le corriger immédiatement.
Vérifiez facilement via Events Monitoring que vos événements sont bien envoyés, avec un score de succès de 100 % pour chacun des tags que vous avez paramétrés sur votre GTM Server. Cliquez, depuis l’onglet Events Monitoring, sur un tag en particulier pour accéder au détail de chaque événement envoyé, à son taux de succès ou d’erreur, ainsi qu’à sa volumétrie.
Prenons un exemple : vous souhaitez vérifier le bon envoi de vos événements à Meta.

- Sélectionnez une période spécifique via le filtre de temps en haut à droite.
- Cliquez sur la carte du tag Meta pour filtrer la liste des événements envoyés à ce prestataire.
- Contrôlez que vos événements ont bien été envoyés à Meta via le taux de succès de chaque événement. Ici, nous sommes à 100 % de succès pour tous, sauf pour
purchase, qui n’est qu’à 93,3 %.
Lorsque vous détectez un tag ou un événement particulier nécessitant une correction, vous pouvez aller plus loin en consultant les logs associés pour comprendre ce qu’il faut corriger de votre côté.
Bon à savoir : un système d’alerte automatique est intégré. Si un tag n’atteint pas 100 % de succès, tous les emails associés au conteneur Addingwell recevront une alerte. Afin d’éviter les spams, une seule alerte est envoyée pour une même erreur sur une période de 7 jours.
Logs : comprendre les erreurs sur les requêtes Server
Les logs sont consultables à tout moment pour chacun de vos tags serveur, sur la période de temps de votre choix. Ces logs peuvent vous aiguiller sur ce qu’il faut corriger dans votre setup pour que vos requêtes ne partent plus en erreur.
Continuons avec l’exemple précédent du tag Meta, pour lequel nous n’étions pas à 100 % de succès. Depuis l’onglet Logs, à gauche de votre conteneur Addingwell, vous pouvez consulter les messages d’erreur disponibles pour votre tag Meta, en cliquant sur Logs.

Un deuxième écran, plus détaillé, apparaît. Vous pouvez :

- Filtrer sur la période de temps qui vous intéresse (celle où vos tags n’atteignent pas 100 % de succès).
- Vérifier le nombre de requêtes en erreur (dans l’exemple : 55 erreurs avec un statut 400).
- Consulter le ou les messages d’erreur les plus fréquemment retournés pour vos requêtes en échec. Dans notre exemple, la valeur associée à des produits sur le site n’est pas valide, car elle n’est pas au bon format (le paramètre
valuedoit être un nombre, et non une chaîne de texte).
Si ces logs d’erreur ne vous suffisent pas ou ne sont pas assez clairs, vous pouvez toujours contacter l’équipe support Addingwell, pour que nous puissions ouvrir des logs avancés dans des tables BigQuery, auxquelles vous aurez accès pour des investigations plus poussées.
Vérifier les paramètres associés à vos événements de tracking, dont les user data
Pour des performances de campagnes média optimales, il est essentiel de nourrir les algorithmes de vos partenaires avec des données de qualité. Vous devez donc vous assurer d’attacher des données utilisateurs aux événements que vous leur envoyez (par exemple pour le suivi avancé des conversions Google, ou pour l’optimisation du Quality Match de Meta).
Avec Events Monitoring, vérifiez facilement la liste des paramètres associés aux événements reçus par votre GTM Server. Vous pouvez ainsi vous assurer qu’un événement purchase contient bien une value, une currency, votre liste d’items… mais également toutes les user data attachées à cet événement, comme par exemple l’email utilisateur, son téléphone, son nom, son prénom…
Pour cela, cliquez sur l’onglet Events Monitoring, puis sur un événement particulier afin de vérifier s’il contient bien les paramètres user-data attendus. Dans notre exemple ci-dessous, nous avons sélectionné l’événement purchase, et nous constatons que l’adresse email n’est présente que dans 2 % des cas.

Si vos événements ne contiennent pas de user data ou si les pourcentages ne sont pas cohérents, revoyez votre setup côté GTM Web. Pour savoir comment envoyer des user data à votre conteneur Server, consultez notre documentation sur le sujet.
Il est normal que certains événements, comme un page_view, ne contiennent pas de données utilisateur (l’internaute n’est en général pas loggé à cette étape). En revanche, un événement login ou purchase devrait logiquement contenir le paramètre email utilisateur dans 100% des cas.
Cookie Monitoring : maintien des cookies +7j sur Safari
Les restrictions sur les cookies étant plus strictes sur Safari, vous pouvez vérifier en un coup d’œil si votre setup actuel contourne efficacement les limitations ITP de Safari.
Notre outil Cookie Monitoring vous permet de vérifier que vous pouvez traquer les utilisateurs de Safari lorsqu’ils reviennent sur votre site, et que vous êtes donc en capacité de maintenir les cookies sur les navigateurs d’Apple au-delà de 7 jours.
Depuis l’onglet Cookie Monitoring, trois cartes vous permettent de comparer le trafic en provenance des 3 environnements : Apple, Chrome, et “autres navigateurs” sur les 28 derniers jours.

Vous pouvez ainsi vérifier:
- le nombre de visiteurs pour chaque type de navigateur sur les 28 derniers jours. Dans notre exemple, il y a eu 459K visiteurs en provenance de Safari, dont 211K visiteurs revenant sur le site.
- la répartition des visiteurs revenant sur le site (211K dans notre exemple)
- 1 jour après leur dernière visite
- entre 2 et 7 jours après leur dernière visite
- au-dela de 7 jours après leur dernière visite. C’est ce denier pourcentage que vous devez monitorer pour Safari, en le comparant aux autres environnements (Chrome et autres navigateurs). Si ce taux de returning users au-delà de 7 jours est à peu près équivalent pour Safari que sur les autres environnements, votre setup fonctionne correctement, et vos cookies sont bien persistants sur Safari.
- que votre configuration est bien résiliente sur Safari (avec le symbole vert) si vous avez mis en place la solution Cookie Restore.
Attention, si vous utilisez la solution Reverse Proxy, l’indicateur ne sera pas au vert ici. Dans ce cas, vérifiez simplement que le pourcentage de vos returning users pour Safari au-delà de 7 jours est cohérente (= dans les mêmes eaux que pour les autres types de navigateurs). Si c’est bien le cas, votre Reverse Proxy fonctionne correctement pour le maintien des cookies sur Safari.
Félicitations ! 🎉
Bravo, vous savez dorénavant comment tirer le meilleur parti de votre conteneur Addingwell pour un monitoring server-side efficace. N’hésitez pas à explorer ces outils pour assurer la pérennité et la performance de votre setup, et si vous avez le moindre problème, contactez l’équipe support d’Addingwell