Blog
Tagging côté serveur pour une boutique Shopify ou WooCommerce : ce qui se déclenche, ce qui ne se déclenche pas, et quoi installer
Publié · Mis à jour · 5 min de lecture
Un conteneur serveur ne fait pas rapporter des achats à une boutique. Il transmet ce que le navigateur envoie, depuis votre propre nom d’hôte au lieu de celui de Google, et cela vaut la peine : les bloqueurs de publicité et Safari suppriment ensemble une part significative des conversions d’une boutique. Mais l’achat doit d’abord être envoyé, et sur les deux plateformes qui font tourner la plupart des boutiques, rien ne l’envoie d’origine. C’est l’article que nous aurions aimé pouvoir remettre à chaque client le premier jour.
Les neuf événements, et la seule chose qu’ils ont en commun
GA4 définit neuf événements pour un tunnel d’achat : view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info et purchase. Les noms sont ceux de GA4, pas ceux d’une plateforme — les mêmes neuf fonctionnent pour Shopify, WooCommerce et une boutique que vous auriez construite vous-même.
Ce qu’ils partagent, c’est un mécanisme. Chacun est un push dans le dataLayer de la page, exactement sous ce nom, portant un objet ecommerce à la forme GA4. Un déclencheur Tag Manager écoute le nom ; une balise d’événement GA4 lit l’objet ecommerce et l’envoie. Écrivez mal le nom, imbriquez l’objet un niveau trop bas, ou poussez-le sur la mauvaise page, et la balise reste là pour toujours sans erreur. Voici à quoi ressemble un push d’achat :
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'ORD-10442',
value: 89.90,
currency: 'EUR',
items: [
{ item_id: 'SKU-118', item_name: 'Trail jacket', price: 89.90, quantity: 1 }
]
}
});Le push préalable de ecommerce: null n’est pas décoratif. Sans lui, les articles de l’événement précédent peuvent se glisser dans le suivant, et un view_item d’il y a trois pages apparaît dans un purchase.
Shopify : le thème ne voit pas le paiement
Un conteneur installé dans un thème Shopify se charge sur la vitrine — pages produit, collections, panier. Il ne se charge ni sur le paiement ni sur la page de remerciement, que Shopify sert depuis son propre domaine et ses propres modèles. Un conteneur installé dans le thème peut donc envoyer view_item et add_to_cart et n’enverra jamais, quelle que soit la configuration, begin_checkout, add_shipping_info, add_payment_info ou purchase.
Ces quatre-là viennent d’un Custom Pixel. Le bac à sable de pixels de Shopify expose les événements de paiement (checkout_started, checkout_shipping_info_submitted, payment_info_submitted, checkout_completed) et permet à un pixel de pousser dans un dataLayer à lui — un petit script associe chacun au nom et à la forme de l’événement GA4 ci-dessus. Les événements de la vitrine viennent toujours du thème, donc une installation complète a les deux : une application dataLayer ou un extrait dans le thème pour la moitié navigation, un Custom Pixel pour la moitié paiement.
Une décision de plus. Le canal Google et YouTube de Shopify peut envoyer des événements GA4 directement, hors de tout conteneur. Si vous y connectez une propriété GA4 ET que vous faites passer la même propriété par votre conteneur, chaque achat est compté deux fois. Choisissez une voie. Si l’objectif est la collecte first-party, le conteneur est la voie, et la connexion Analytics du canal reste désactivée.
WooCommerce : le cœur ne pousse rien
WooCommerce lui-même n’écrit aucun dataLayer. Un plugin le fait — GTM4WP est celui vers lequel la plupart se tournent — et son option e-commerce GA4 produit ces événements dans la bonne forme sur les bonnes pages : view_item sur un produit, add_to_cart sur le bouton, begin_checkout sur la page de paiement, purchase sur la page de commande reçue.
Le défaut classique de WooCommerce est un achat en double, et il a une cause précise : la page de commande reçue se recharge. Un visiteur l’actualise, y revient depuis un prestataire de paiement, ou le thème la traverse deux fois par redirection, et purchase est poussé de nouveau avec le même transaction_id. GA4 dédoublonne les achats par transaction_id au sein d’une session, ce qui en rattrape la plupart, mais pas un rechargement le lendemain. Le réglage « ne déclencher qu’une fois par commande » du plugin vaut d’être activé ; il garde le marqueur côté serveur, où un rechargement ne peut pas le réinitialiser.
Ce que SignalHost construit pour vous
Chaque conteneur SignalHost a, dans son conteneur web, un déclencheur d’événement personnalisé et une balise d’événement GA4 pour chacun des neuf — et aussi pour les sept dont un site sans boutique a besoin : inscriptions, essais et prospects. Tous sont préfixés SH pour ne jamais entrer en collision avec ce que vous avez déjà. Chaque balise envoie l’objet ecommerce directement depuis le dataLayer, si bien que items, value, currency et transaction_id passent sans une variable par champ, et chacune nomme votre ID de mesure explicitement au lieu de l’hériter.
Rien n’est installé sur votre boutique. Les déclencheurs écoutent ; les pushes sont ceux du plugin ou du pixel. Si votre conteneur envoie déjà l’un de ces événements à GA4 avec une balise à vous — un plugin qui a apporté sa propre balise d’achat, par exemple —, SignalHost lui laisse cet événement et ne construit pas de seconde balise, si bien qu’aucune commande n’est comptée deux fois. Chaque balise transmet aussi un event_id que vous poussez avec l’événement, de sorte qu’une plateforme publicitaire qui reçoit aussi le même événement de son propre pixel ne le compte qu’une fois.
Côté serveur, il n’y a rien par événement. La balise GA4 du conteneur serveur transmet chaque événement reçu, quel que soit son nom, de sorte qu’un nouvel événement sur votre site n’exige aucun changement chez nous. Les plateformes publicitaires que vous connectez — Google Ads, Meta, TikTok, Reddit, Pinterest, Snapchat, LinkedIn — reçoivent les mêmes événements : un purchase devient un Purchase pour Meta et TikTok, avec ses produits et sa valeur, et chaque plateforme obtient ceux dont elle a l’usage, à partir du même push.
Vérifier avec une commande test
Passez une vraie commande en mode test, ou une commande peu chère que vous rembourserez, et observez la liste d’événements de la page du conteneur. Dans l’ordre, vous devriez voir view_item, add_to_cart, begin_checkout, add_payment_info et purchase — chacun une fois, avec view_cart et add_shipping_info entre eux si votre installation les pousse. Un purchase absent sur Shopify signifie que le Custom Pixel n’est pas installé ou ne pousse pas ; un begin_checkout absent sur WooCommerce signifie généralement que l’événement de paiement du plugin est désactivé.
Si vous faites passer les conversions Google Ads par le conteneur, purchase est l’événement de conversion, sauf si vous en choisissez un autre, et sa valeur, sa devise et son identifiant de transaction sont lus dans ce même objet ecommerce. Un push d’achat sans value enregistre une conversion qui ne vaut rien — ce qui est un vrai chiffre dans un rapport, et le mauvais.
Si GA4 compte encore moins de commandes que votre boutique après cela, voici pourquoi GA4 compte trop peu, et ce qui peut être récupéré.

