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

GA4 définit sept événements pour un tunnel d’achat : view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info et purchase. Les noms sont ceux de GA4, pas ceux d’une plateforme — les mêmes sept 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.

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_payment_info ou purchase.

Ces trois-là viennent d’un Custom Pixel. Le bac à sable de pixels de Shopify expose les événements de paiement (checkout_started, 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 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 les sept é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.

Dites à l’assistant que le site est une boutique et il ajoute, à votre conteneur web, un déclencheur d’événement personnalisé et une balise d’événement GA4 pour chacun des sept événements — quatorze entités, toutes préfixées 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. Choisir « pas de boutique en ligne » laisse les quatorze entités de côté et ne change rien d’autre — pages vues, scroll et le reste des événements standard passent par le conteneur dans tous les cas.

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 destinations Meta Conversions API et TikTok Events API, si vous les connectez, associent elles-mêmes ces sept noms ; un purchase devient un Purchase pour Meta et un CompletePayment pour TikTok, à partir du même push.

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. 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, 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.