Google Tag Manager
Un seul conteneur Web propre, avec un nommage clair, aucune balise résiduelle et un accès limité aux personnes qui en ont besoin.
GA4, GTM, côté serveur, API Conversions, Consent Mode v2
Nous rebâtissons votre mesure pour que chaque vente soit comptée une seule fois, avec la bonne valeur, et seulement avec le consentement sur lequel vous avez le droit de vous appuyer. Puis nous le prouvons avec des commandes test et nous vous remettons la documentation.
Schéma du trajet d’un achat après l’implantation. Le navigateur capte l’achat, la vérification du consentement ne le laisse passer que si le visiteur a dit oui, votre propre serveur sur un domaine de première partie retire les doublons, et GA4, Google Ads et Meta reçoivent chacun l’achat une seule fois, avec le même identifiant d’événement.
Ce que nous faisons
Un seul conteneur Web propre, avec un nommage clair, aucune balise résiduelle et un accès limité aux personnes qui en ont besoin.
De view_item jusqu’à purchase avec les bonnes valeurs, la devise, les taxes et la livraison, plus les remboursements pour que les revenus concordent avec la boutique.
Un conteneur serveur sur votre propre sous-domaine. Les événements arrivent en première partie, sont nettoyés, puis repartent vers chaque plateforme.
Une configuration où les événements du navigateur et du serveur partagent un même identifiant, pour que Meta compte chaque vente une fois et en associe davantage aux publicités.
Des données clients hachées envoyées avec chaque conversion, pour que Google Ads attribue les ventes que les témoins ratent.
Des valeurs par défaut à « refusé », des balises qui attendent le choix et une bannière qui offre un vrai oui ou non, bâtie selon la norme d’adhésion que la Loi 25 du Québec exige.
Le trajet des données
Le navigateur capte toujours l’événement. Votre serveur décide ce qui peut sortir, ajoute ce dont les plateformes ont besoin pour la correspondance, et envoie chaque événement avec le même identifiant pour que rien ne soit compté deux fois.
purchase · 148,00 $event_id: 7f3a…Balisage côté serveur
Les balises du navigateur parlent directement à Google et à Meta, et les bloqueurs de publicité comme la courte durée de vie des témoins coupent une partie de ce trafic. Un conteneur serveur sur votre propre sous-domaine reçoit un seul flux et le relaie, pour que vous contrôliez ce que chaque plateforme reçoit. C’est ce que veut dire, en pratique, le suivi côté serveur Shopify pour une boutique au Canada ou aux États-Unis, et la même configuration fonctionne pour WooCommerce.
Comparaison de deux chemins de suivi. Balises navigateur seulement : les événements vont directement du navigateur aux plateformes et certains sont perdus à cause des bloqueurs de publicité et des limites de confidentialité des navigateurs. Chemin côté serveur : le navigateur envoie les événements à votre propre serveur sur un sous-domaine de première partie, qui ajoute des données clients hachées, retire les doublons et relaie chaque événement à GA4, Google Ads et Meta avec le même identifiant d’événement.
Consent Mode v2
Avec des valeurs par défaut à « refusé », rien de ce qui dépose un témoin ne s’exécute avant la réponse du visiteur. Un consentement accordé envoie l’événement complet. Un refus n’envoie qu’un signal sans témoin, que Google utilise pour modéliser les conversions au lieu de les perdre.
Schéma : trois événements du navigateur (page vue, ajout au panier, achat) attendent à une vérification du consentement dont la valeur par défaut est « refusé ». Si le visiteur accorde son consentement, l’événement complet, avec son identifiant, part vers GA4, Google Ads et Meta. Sinon, seul un signal sans témoin est envoyé et Google modélise la conversion.
Comment ça se déroule
Nous confirmons le plan d’événements, les plateformes concernées et qui approuve quoi. Les constats de l’audit deviennent la liste de tâches.
GTM, GA4, conteneur serveur, API Conversions, conversions améliorées et consentement, bâtis d’abord dans un espace de travail de préproduction.
Achats test avec le consentement accepté et refusé. Nous vérifions que chaque plateforme a reçu ce qu’elle devait, une seule fois.
Nous publions les changements et nous remettons le journal d’assurance qualité et la documentation.
Pendant 14 jours, nous surveillons les données réelles pour repérer les trous, les doublons et les problèmes de consentement, et nous corrigeons ce qui ressort. Ça se termine par une comparaison des chiffres des plateformes avec ceux de la boutique.
Questions
Oui, le conteneur serveur doit être hébergé, en général une petite facture infonuagique mensuelle que vous payez directement. Nous vous indiquons le coût prévu pour votre trafic avant que vous vous engagiez.
Nous bâtissons le volet technique pour respecter le consentement : les balises attendent le choix et les valeurs par défaut sont à « refusé ». Le texte juridique de votre bannière et de votre politique de confidentialité doit être revu par votre conseiller juridique. Nous signalons ce qu’il faut vérifier.
Non. Nous cartographions ce que chaque application envoie avant de changer quoi que ce soit, puis nous désactivons les doublons dans un ordre contrôlé pour que les données ne s’interrompent jamais.
C’est le point de départ habituel, parce qu’il fixe une portée précise, et les frais d’audit sont déduits du prix de l’implantation si vous poursuivez. Si vous savez déjà ce qu’il vous faut, nous pouvons plutôt soumissionner après un court appel.
Décrivez-nous votre boutique et ce qui cloche dans vos chiffres. Nous vous répondons par courriel avec une première lecture et les prochaines étapes.