Commencez le choix entre le module GA4 direct et Google Tag Manager par définir qui crée les événements, à quel moment une commande est considérée comme un achat et qui maintient la configuration. L’identifiant G-… ou GTM-… à lui seul ne répond pas à ces questions.
Nous comparons des versions précises : PD Google Analytics 4 Pro 1.4.2, PD Google Tag Manager Pro 2.3.4 et l’ancien PD Google Tag Manager 1.2.4. La description découle de leur code et de leurs instructions vérifiés le 26 septembre 2026. Il s’agit du périmètre de ces versions, et non d’une déclaration d’un fonctionnement identique de tous les modules disponibles pour PrestaShop.
Deux voies pour un même événement
Schéma de démonstration de l’événement view_item. Il montre la répartition des responsabilités, et non le résultat de la mesure dans un compte GA4 en fonctionnement.
Dans la variante directe, le module collecte les données produit et prépare l’appel Google tag. Dans la variante GTM Pro, le module transmet l’objet événement à dataLayer, et le conteneur publié décide du déclenchement du tag et de son destinataire. Pour les deux variantes, il faut définir séparément les règles de consentement ainsi que la validité des paramètres.
dataLayer apparaît également lors de l’utilisation directe de gtag. La seule présence de cette variable dans le navigateur ne prouve pas que la boutique utilise un conteneur GTM. Google décrit les deux usages dans la documentation de la couche de données.
La différence la plus importante : quand le purchase est-il créé ?
Comportement des versions de modules vérifiées
Domaine
GA4 Pro 1.4.2
GTM Pro 2.3.4
Événements navigateur
Le module prépare les appels Google tag, notamment l’affichage du produit et le début du checkout.
Le module crée des événements dans dataLayer. Dans le conteneur, il faut configurer et publier les tags, règles et variables appropriés.
Achat
Le flux serveur Measurement Protocol vérifie le statut de paiement configuré et l’historique du paiement qualifiant. Le purchase navigateur est désactivé dans cette version.
Le purchase navigateur est créé lors de la confirmation de commande. Le code de ce flux n’utilise pas la même liste de statuts payés que GA4 Pro.
Flux serveur supplémentaire
Il gère les opérations financières lorsque les exigences d’identification, de configuration et de consentement sont remplies.
La file optionnelle de récupération d’achat nécessite la configuration de Measurement Protocol et d’une tâche CRON. L’enregistrement du rendu de la confirmation influence la décision de nouvelle tentative.
Remboursement
Des opérations sont prévues selon le statut configuré ou le document d’avoir, avec contrôle de l’achat antérieur et des remboursements.
Le document d’avoir peut alimenter la file refund ; l’envoi dépend du contexte, du consentement et de l’automatisation active.
Ne comparez donc pas les nombres de purchase sans avoir défini leur signification. Une commande créée, affichée sur la page de confirmation et qualifiée comme payée correspond à trois moments différents. Avec un virement en attente de paiement, la différence peut être particulièrement visible.
Matrice des événements avant le lancement de la mesure
Pour chaque événement, notez la source, le destinataire, la condition de consentement et la personne responsable. Téléchargez la matrice CSV modifiable. Elle contient des exemples de démonstration et des champs pour le résultat de votre propre vérification.
Exemple de répartition des responsabilités à compléter pour votre propre boutique
Événement
Source
Destinataire
Consentement et responsabilité
view_item
Module direct ou module dataLayer et tag GTM — choisissez un seul flux.
Flux GA4 indiqué.
La personne en charge de l’analytics vérifie les signaux CMP et les conditions du tag.
purchase
Moment métier défini et un seul propriétaire de l’émission.
Le même flux convenu.
Le responsable de l’intégration vérifie le contexte client, les consentements, l’identifiant de transaction et les nouvelles tentatives.
refund
Statut sélectionné ou document d’avoir conformément à la solution utilisée.
Flux dans lequel l’achat a été enregistré.
La personne responsable des remboursements définit le périmètre complet et partiel ainsi que la méthode de validation.
Les consentements et Measurement Protocol font partie du projet
Dans la version vérifiée de GA4 Pro, le consentement de confiance pour l’enregistrement de l’attribution et les opérations financières côté serveur est lié à PD Cookie Pro actif, à son mode live, à Consent Mode v2 et à la révision actuelle du consentement. Ne supposez pas que le remplacement de ce fournisseur par n’importe quelle autre bannière conservera l’ensemble du flux serveur sans vérification supplémentaire.
GTM Pro dispose de ses propres paramètres Consent Mode et d’intégrations concrètes avec des fournisseurs de consentement. Avec PD Cookie Pro actif, il lui laisse la gestion des consentements. Le comportement final dépend aussi du conteneur publié. La présence d’une bannière ou d’un champ de configuration n’est pas encore le résultat d’un test « refus → consentement → retrait ».
Le flux serveur ne signifie ni contournement du consentement ni récupération automatique de la source de session. L’API Secret relève de la configuration serveur. Le lien avec l’activité du navigateur exige les identifiants et le contexte appropriés ; le point de référence est la documentation d’envoi des événements Measurement Protocol.
L’ancien GTM et GTM Pro ne sont pas la même offre
L’ancien PD Google Tag Manager 1.2.4 sert à intégrer le conteneur. Le code vérifié ne contient pas le modèle ecommerce ni la file Measurement Protocol décrits plus haut pour la version Pro. Ne considérez pas le nom « GTM » comme une promesse d’événements d’achat prêts à l’emploi.
PD Google Tag Manager Pro ajoute une couche de données et des outils de configuration. L’export du conteneur constitue un point de départ pour l’import, la révision et la publication dans GTM. Il ne remplace pas la prise en charge de la configuration. Le champ d’adresse de serveur personnalisée ne crée pas non plus automatiquement une infrastructure GTM server-side.
Comment choisir la variante et éviter deux propriétaires de l’achat ?
Module direct : envisagez GA4 Pro si vous souhaitez maintenir ce flux dans les paramètres du module et si sa définition de l’achat payé ainsi que ses exigences de consentement correspondent à votre boutique.
Conteneur GTM : envisagez GTM Pro si vous disposez d’une personne responsable des tags, des règles, des environnements et de la publication des modifications. Définissez également qui gère la file serveur optionnelle.
Implémentation existante : commencez par inventorier les modules et tags actifs. N’ajoutez pas un deuxième émetteur de purchase simplement parce que le nombre d’achats dans le rapport suscite des doutes.
La réception devrait inclure un parcours contrôlé pour le produit, le panier, le bon moment d’achat et le remboursement, ainsi que le refus et le retrait du consentement. Distinguez la preuve « événement créé », « envoi effectué » et « événement visible dans GA4 ». Le simple dataLayer.push, le rendu de la page ou la réponse HTTP du transport ne confirment pas encore l’exhaustivité du rapport.
Google Analytics 4 Pro – module GA4 pour PrestaShop
Google Analytics 4 Pro est un module PrestaShop permettant d’implémenter la balise Google et de mesurer le comportement des utilisateurs dans Google Analytics 4. Il enregistre les événements liés aux produits, aux listes de produits, au panier, au checkout, à la recherche ainsi qu’au compte client. Les...
PD Google Tag Manager Pro est un module PrestaShop avancé pour l’implémentation de Google Tag Manager avec un DataLayer e-commerce complet, l’intégration avec GA4 ainsi que la prise en charge de Google Consent Mode v2. Le module intègre automatiquement le code GTM dans la section head et dans la partie noscript après l’ouverture de la balise body, peut...
Patryk Marek — propriétaire de PrestaDev.pl et développeur spécialisé dans PrestaShop. Depuis de nombreuses années, il se consacre à la création, au développement et à la maintenance de boutiques en ligne. Il associe le travail sur le code de la boutique et des modules à la configuration de l’environnement serveur dans lequel ces solutions fonctionnent.
Il conçoit et développe des modules PrestaShop, adapte les fonctionnalités existantes et prépare des intégrations avec des grossistes et des services externes. Il travaille sur l’importation et la mise à jour des données produits, l’automatisation de la gestion du catalogue, le processus de commande ainsi que les outils soutenant le travail quotidien du propriétaire de la boutique.
Son expérience comprend également les mises à jour et les migrations de boutiques, le diagnostic des erreurs, l’analyse des performances ainsi que la configuration des serveurs et des services nécessaires au fonctionnement de PrestaShop. Lors de la résolution des problèmes, il prend en compte les dépendances entre les modules, le thème, PHP, la base de données et les paramètres d’hébergement.
Sur le blog, il partage des connaissances issues de nombreuses années de pratique en programmation et de travail avec l’infrastructure technique des boutiques. Les guides se concentrent sur des problèmes concrets, les moyens de les vérifier et les limites des solutions décrites. Ils aident les propriétaires de boutiques ainsi que les profils techniques à préparer les changements, à en évaluer l’ampleur et à en vérifier le résultat.
commentaires (0)