WooCommerce : tracking GA4 et purchase fiable avec GTM4WP

Sur WooCommerce, le tracking GA4 fonctionne dans les grandes lignes dès l’installation d’une extension, et c’est précisément ce qui le rend dangereux : les événements sont là, mais le purchase peut compter une valeur fausse, un remboursement ne remonte jamais, ou une variante de produit disparaît dans les rapports. Une mise en place fiable passe par un dataLayer Enhanced Ecommerce complet, un contrôle du montant envoyé et une recette sur une commande réelle. Le plugin officiel de Google couvre le minimum ; GTM4WP, bien configuré, couvre le reste.

Pour un cadrage de mise en place complète (plugin, dataLayer, Enhanced Conversions, Meta CAPI), la page dédiée est consultant tracking WooCommerce. Cet article se concentre sur la technique : ce que chaque brique fournit, ce qu’elle ne fait pas, et comment le vérifier. Pour le pilotage au-delà du tracking (marge, attribution, ROAS), voir mon approche d’analytics e-commerce.

Ce que fournit Google for WooCommerce

Le plugin officiel Google for WooCommerce est gratuit. Il envoie les événements e-commerce GA4 et les transactions. La configuration tient en un champ : le Measurement ID GA4 dans les réglages d’intégration WooCommerce.

Ses limites, à connaître avant de le garder seul :

• la version 2.4.1 a changé le calcul de la valeur du purchase : désormais la somme des prix des articles multipliés par leur quantité, hors taxes et frais de port, au lieu du total brut de la commande. Si vos rapports historiques utilisent l’ancienne logique, un écart apparaît à la date de mise à jour ;
• la version 2.4.4 corrige l’envoi d’un purchase pour une commande échouée ou annulée suivie d’un paiement réussi ;
• les avis publics sur le plugin sont partagés, avec des retours de collecte interrompue après installation à côté d’une CMP tierce. Ce sont des témoignages, non confirmés, mais ils justifient un test de consentement avant déploiement.

Le plugin ne couvre ni les tags personnalisés, ni les listeners de formulaires, ni les conversions Ads avancées. Pour cela, il faut GTM.

GTM4WP : le dataLayer Enhanced Ecommerce

GTM4WP (Google Tag Manager for WordPress, édité par DuracellTomi) est la brique que je recommande pour un dataLayer maîtrisé. Le plugin est gratuit, en version 2.0.6 à la date de cet article, avec plus de 700 000 installations actives selon la fiche wordpress.org. Il insère le conteneur GTM et pousse un dataLayer compatible avec les événements GA4 e-commerce.

Ce qu’il gère, selon sa fiche officielle :

• les blocs WooCommerce Cart, Checkout, Mini-Cart et Product Collection, ainsi que les pages en shortcode classique ;
• les données Enhanced Conversions sur l’événement purchase, pour Google Ads ;
• la compatibilité HPOS, le stockage haute performance des commandes ;
• le Consent Mode v2 en commande default, avec des intégrations pour Cookiebot, Axeptio et CookieYes.

Ce qu’il ne gère pas : les promotions et les remboursements. Les refund doivent donc être construits à part, par exemple via un hook PHP sur le remboursement côté WooCommerce, ou via un événement server-side. Ne comptez pas sur GTM4WP seul pour la marge réelle après remboursement.

Extrait purchase

Voici la forme attendue d’un événement purchase propre. Le champ value suit la logique du plugin officiel depuis la version 2.4.1 : hors taxes et hors frais de port. Gardez la même règle partout, sinon GA4 et Google Ads ne se réconcilient jamais.

{
  "event": "purchase",
  "ecommerce": {
    "transaction_id": "WC-10482",
    "value": 70.00,
    "tax": 14.00,
    "shipping": 6.90,
    "currency": "EUR",
    "coupon": "BIENVENUE10",
    "items": [
      {
        "item_id": "SKU-TSHIRT-M",
        "item_name": "T-shirt",
        "item_variant": "Noir / M",
        "price": 35.00,
        "quantity": 2
      }
    ]
  }
}

Trois points à contrôler sur chaque commande de test :

• transaction_id est unique et identique entre le dataLayer et le back-office WooCommerce ;
• coupon contient le code réellement appliqué, pas un libellé marketing ;
• item_variant est présent pour les produits à déclinaisons (taille, couleur). Sans lui, GA4 agrège toutes les variantes sous un seul article.

Pièges propres à WooCommerce

Les pièges rencontrés le plus souvent :

1. Checkout en blocs vs shortcode. Un événement poussé par un listener calibré sur le shortcode ne se déclenche pas sur le checkout en blocs, et inversement. Vérifiez quel type de checkout est actif avant de coder.
2. Thank-you page rechargée. Si le client recharge la page de confirmation, le purchase part une deuxième fois. Une déduplication par transaction_id côté dataLayer ou côté GTM évite le doublon.
3. Variations et devise. En multi-devise (WPML, WooCommerce Multi-Currency), la currency doit être poussée par événement, pas en configuration globale.
4. Ordre d’exécution. Un purchase poussé avant la confirmation du moyen de paiement peut compter une transaction qui échoue ensuite. Pour les paiements différés ou en 3D Secure, déclenchez sur la page de confirmation, pas sur la soumission.

Alternatives : un tableau de synthèse

Solution	Type	Forces	Limites
Google for WooCommerce	Gratuit, Google	Simple, maintenu par Google, transaction et GA4	Peu de contrôle sur le dataLayer, pas de listeners personnalisés
GTM4WP	Gratuit, open-source	dataLayer complet, Consent Mode v2, Enhanced Conversions	Demande de maîtriser GTM, remboursements à construire
PixelYourSite	Freemium	Pixels Meta, Google et autres dans une interface	Périmètre large, à auditer avant d’empiler
Plugins premium type WooCommerce GA4	Payant	Interface, support éditeur	Dépendance, personnalisation limitée

Pour un site qui a déjà GTM, je garde GTM4WP et je ne cumule pas un deuxième plugin de pixels. Deux sources de vérité pour purchase produisent des écarts impossibles à expliquer.

Enhanced Conversions et Meta CAPI

Les conversions remontées côté navigateur perdent une partie des signaux, notamment avec les bloqueurs et les restrictions de cookies. Enhanced Conversions pour Google Ads envoie des données utilisateur hashées avec la conversion, à partir du purchase. GTM4WP prépare ces données ; il reste à configurer le tag Google Ads.

Pour Meta, la réponse est le server-side : l’API de conversions envoie les événements depuis un serveur, avec déduplication par event_id. Le détail est dans le guide Meta CAPI server-side. Sur WooCommerce, je passe par un conteneur sGTM plutôt que par un plugin de pixel qui duplique la collecte.

Consent Mode v2

Le Consent Mode v2 doit être en place avant GTM4WP, et la commande default doit précéder les tags. GTM4WP l’envoie et s’intègre à Cookiebot, Axeptio et CookieYes. Pour une autre CMP, il faut vérifier l’ordre d’exécution dans le réseau.

Deux points spécifiques à WooCommerce : la page panier et la page checkout ne doivent pas être servies depuis un cache statique avec un état de consentement figé, et les extensions de paiement qui ouvrent une fenêtre externe (PayPal, 3D Secure) doivent conserver le consentement à leur retour. Le détail des bannières est dans bannière cookies centrale ou discrète et attribution.

Recette

Une recette sérieuse se fait sur une commande réelle, en test, sur le site de production avec une passerelle de test ou une commande remboursée.

1. Parcours complet : catalogue, fiche produit, ajout au panier, checkout, confirmation, avec consentement accepté puis refusé.
2. Vérification de la valeur purchase contre le total hors taxes et hors frais de port de la commande.
3. Une seule transaction dans GA4 DebugView, même après rechargement de la confirmation.
4. Comparaison GA4 et back-office WooCommerce sur une journée. Un écart de quelques pourcents, lié aux bloqueurs et au consentement, est normal. Au-delà, on cherche la cause : doublon, commande non payée, devise.
5. Un remboursement de test est remonté par le canal prévu (hook PHP ou server-side), pas laissé implicite.

Questions fréquentes

Google for WooCommerce suffit-il pour une petite boutique ?

Pour un catalogue simple sans besoin de dataLayer personnalisé, oui, à condition de vérifier la valeur du purchase et le Consent Mode. Dès que les variantes, les coupons ou les conversions Ads comptent dans la décision, il faut GTM4WP.

Peut-on tracker les remboursements sans développement ?

Pas proprement. GTM4WP ne les gère pas, et le plugin officiel non plus. Un hook PHP sur le remboursement ou un événement server-side est nécessaire, et il doit être testé sur un remboursement réel.

Faut-il un plugin en plus de GTM4WP pour les pixels Meta ?

Non. Une seule source de collecte pour purchase évite les doublons. Pour Meta, l’approche server-side est préférable à un plugin de pixel en plus.

Sources

• Google for WooCommerce, plugin officiel sur wordpress.org
• GTM4WP, plugin WordPress sur wordpress.org
• Consent Mode, documentation développeurs Google