Tracking PrestaShop avec GA4 et GTM : dataLayer, modules et pièges

PrestaShop ne pousse pas nativement un dataLayer GA4 e-commerce complet : le tracking dépend donc d’un module ou d’un développement sur mesure. Trois voies existent : le module officiel ps_googleanalytics, un module tiers (gratuit ou payant), ou GTM alimenté par un dataLayer dédié. Le bon choix dépend de la finesse de mesure attendue, de la présence d’un développeur et de vos exigences de consentement. Sur les boutiques que j’audite, c’est presque toujours le dataLayer qui fait la différence, pas le module.

Si vous voulez un cadrage complet avant de choisir, voir mon offre consultant analytics e-commerce. Le détail des modules est dans le comparatif des modules GA4 PrestaShop.

Ce que PrestaShop fournit nativement

PrestaShop expose des hooks, c’est-à-dire des points d’accroche où un module insère du code. C’est le seul mécanisme natif utile pour du tracking. Le moteur de template dépend de la version :

• Smarty : dans les fichiers .tpl, un hook s’appelle avec {hook h='nomDuHook'}. C’est le moteur historique du thème front, présent en 1.7 et 8.
• Twig : dans les fichiers .html.twig, un hook s’appelle avec {{ renderHook('nomDuHook', { params }) }}. PrestaShop 9 généralise Twig, notamment pour le back-office, et la documentation officielle le décrit côté modules.

Les hooks utiles pour un dataLayer sont displayHeader (initialisation), displayOrderConfirmation (page de confirmation) et les hooks d’action liés au panier et à la commande. Vérifiez leur existence et leur signature dans la liste des hooks de votre version, car elles changent d’une version à l’autre.

Un point à garder en tête : un module doit enregistrer chaque hook dans sa méthode install() avant de l’utiliser. Un hook non enregistré ne déclenche rien, sans erreur visible.

Les 3 façons d’instrumenter

Voie	Exemples	Avantages	Limites	Pour qui
Module officiel	ps_googleanalytics (dépôt PrestaShop)	Gratuit, maintenu par PrestaShop, GA4 uniquement	Fiche indiquant PrestaShop 8.2 minimum, événements e-commerce peu détaillés dans la doc, pas de gestion Consent Mode mentionnée	Petite boutique, besoins de base
Modules tiers	MyPresta (gratuit, gtag.js), Linea Gráfica, PrestaShow GA4 Google Integrator, Cocos.codes	Installation rapide, interface dans l’admin, certains gèrent Consent Mode v2	Dépendance à l’éditeur, paramètres e-commerce variables, mises à jour à suivre	Boutique sans développeur, besoin de délai court
GTM + dataLayer sur mesure	Hooks et template dans le thème, conteneur GTM	Contrôle total, paramètres complets, pas de dépendance	Développement à prévoir, maintenance à assurer	Budget Ads significatif, développeur disponible

Quelques précisions sur les modules tiers, à vérifier sur leurs fiches avant achat :

• Linea Gráfica se présente comme « officiel vérifié par PrestaShop ». C’est une affirmation de l’éditeur : elle ne remplace pas la vérification de la compatibilité, annoncée jusqu’à la version 8.2 au moment de ma recherche.
• MyPresta annonce une compatibilité 1.6 à 9.x, la gestion de Consent Mode v2 et les remboursements. Il est gratuit, avec un support payant optionnel.
• PrestaShow GA4 Google Integrator couvre GA4, GTM, Google Ads avec conversions améliorées, Consent Mode v2 et l’export des commandes antérieures à l’installation. Payant.
• Cocos.codes propose un pack GTM/GA4/Ads, à un tarif de l’ordre de 60 $ selon la fiche consultée.

Le module officiel et les tiers font presque toujours le même travail de base. La différence se joue sur la qualité des paramètres envoyés, sur la gestion du consentement et sur la capacité à corriger un cas particulier.

Structure dataLayer e-commerce GA4 recommandée

Le modèle de référence est celui des événements e-commerce GA4 : une séquence d’événements, chacun poussé au bon moment.

1. view_item_list : affichage d’une liste de produits (catégorie, recherche).
2. select_item : clic sur un produit depuis une liste.
3. view_item : affichage de la fiche produit.
4. add_to_cart : ajout au panier.
5. begin_checkout : entrée dans le tunnel de commande.
6. add_shipping_info : choix du mode de livraison.
7. add_payment_info : choix du moyen de paiement.
8. purchase : commande confirmée.

Chaque item doit porter au minimum item_id et item_name. Ajoutez price, quantity, item_variant (taille, couleur) et index quand c’est possible. Voici un exemple de purchase pour une commande de deux exemplaires à 39,90 € TTC, avec 6,90 € de livraison :

{
  "event": "purchase",
  "ecommerce": {
    "transaction_id": "PS-2026-004812",
    "value": 79.80,
    "tax": 13.30,
    "shipping": 6.90,
    "currency": "EUR",
    "items": [
      {
        "item_id": "SKU-1042",
        "item_name": "Sac en toile",
        "item_variant": "Noir",
        "item_category": "Accessoires",
        "price": 39.90,
        "quantity": 2,
        "index": 0
      }
    ]
  }
}

Les identifiants sont fictifs. Le value suit ici la logique de la documentation GA4 (somme prix × quantité, frais de port exclus). Le point important n’est pas le choix, mais la cohérence : la même règle doit s’appliquer à GA4, à Google Ads et à Meta.

Les pièges propres à PrestaShop

• Page de confirmation rechargée. Le purchase part sur la page de confirmation. Un rafraîchissement ou un retour arrière le renvoie. Dédoublonnez sur transaction_id (déclencheur unique dans GTM, ou drapeau en sessionStorage), sinon vous comptez deux commandes.
• Paiement externe. Avec un paiement en redirection (PayPal, carte via une passerelle externe), la page de retour peut s’afficher avant que la commande soit payée. Vérifiez l’état de la commande avant d’envoyer purchase.
• Multi-boutique. Chaque boutique a son identifiant et souvent sa devise. Définissez si elles partagent une propriété GA4 avec une dimension de boutique, ou si elles en ont une chacune, et testez chaque flux séparément.
• Devise. Poussez currency à chaque événement, surtout en multi-devise. Une devise globale fausse les rapports dès qu’un second marché est ouvert.
• HT ou TTC. PrestaShop affiche les prix selon la configuration des taxes de la boutique. Choisissez une règle (HT ou TTC, frais de port inclus ou non), documentez-la, et appliquez-la partout.
• Référence ou identifiant de commande. PrestaShop dispose d’un identifiant numérique interne et d’une référence de commande alphanumérique. Choisissez-en un comme transaction_id, gardez-le stable, et vérifiez qu’il est présent dans votre CRM pour le rapprochement.

Consent Mode v2 et CMP

Le module de cookies livré avec le cœur de PrestaShop ou un bandeau simple ne gère pas les signaux de Consent Mode v2 de façon fiable. Pour une boutique qui utilise des balises Google, il faut une CMP qui pilote les quatre signaux (analytics, ad storage, ad user data, ad personalization) et les transmet à GTM avant tout chargement.

Les CMP courantes sur PrestaShop sont Axeptio, Didomi et Cookiebot ; leurs différences se comparent sur les fiches éditeurs. Le fonctionnement pratique du mode et ses pièges sont dans le guide Consent Mode v2. Testez toujours les deux cas : consentement accepté et refusé.

Server-side, Enhanced Conversions et Meta CAPI

Quand le tracking navigateur ne suffit plus, un conteneur server-side GTM (sGTM) hébergé, par exemple chez Stape ou Addingwell, reçoit les événements et les transmet aux plateformes. Les conversions améliorées demandent des données utilisateur hashées (e-mail, téléphone) fournies au bon moment. Pour Meta, la CAPI en server-side exige un identifiant d’événement partagé avec le pixel pour dédoublonner.

Les modules « CAPI » proposés sur PrestaShop sont souvent limités : pas de déduplication fine, pas de contrôle des paramètres, ou seulement l’événement d’achat. Vérifiez sur la fiche si la déduplication par event_id est documentée avant de vous y fier.

Checklist de recette

• Les 8 événements apparaissent dans le DebugView GA4, avec les paramètres attendus.
• Un parcours complet (liste, fiche, panier, commande, confirmation) avec consentement accepté, puis refusé.
• Une commande test avec code promo, une avec livraison différente, une avec paiement en redirection.
• Rechargement de la page de confirmation : aucun doublon.
• Un remboursement partiel (événement refund) : vérifiez son traitement.
• En multi-boutique et multi-devise : chaque flux testé séparément.
• La valeur purchase dans GA4 correspond à la valeur des conversions Google Ads.

FAQ

Le module officiel suffit-il ?

Pour une petite boutique qui veut voir ses ventes et ses produits vus, oui, à condition que la fiche confirme la compatibilité avec votre version et que vous activiez l’e-commerce amélioré dans GA4. Pour des conversions fiables sur Google Ads ou Meta, il manque presque toujours la gestion fine du consentement et des paramètres. Dans ce cas, un dataLayer dédié devient nécessaire.

Peut-on faire sans module, avec GTM ?

Oui, c’est la voie la plus propre si vous avez un développeur. Il faut pousser le dataLayer depuis les hooks du thème ou un module léger maison, puis configurer GTM avec les balises GA4 et les déclencheurs. Comptez plusieurs jours pour un parcours complet, recette comprise.

PrestaShop 9 change quoi ?

PrestaShop 9, sorti en 2025, migre le back-office vers Symfony et Twig et s’appuie sur une version plus récente de Symfony que la 8. Pour le tracking, cela touche surtout les modules : certains hooks ont changé ou ont été retirés, et un module écrit pour la 8 peut ne pas fonctionner sans adaptation. Vérifiez la compatibilité de chaque module avant la mise à jour, et refaites la recette après.

Sources

• Google Analytics : documentation sur la mesure e-commerce (GA4)
• PrestaShop 9 : documentation développeur des hooks
• Dépôt GitHub du module ps_googleanalytics (PrestaShop)