Google Analytics 4 Pro module pour PrestaShop

La version 1.4.2 nécessite au minimum PHP 7.2.5 en raison des bibliothèques HTTP fournies ; la version de PHP doit aussi respecter les exigences de votre version de PrestaShop. Les achats et remboursements côté serveur nécessitent en plus PD Cookie Pro actif en mode live avec Consent Mode v2, une révision de consentement correspondante, le consentement analytique et les données d'attribution client/session enregistrées. Un API Secret seul ne suffit pas.

Les purchase côté serveur ne sont pas envoyés pour les commandes avec emballage cadeau payant, plus de 200 lignes de produits ou une référence/EAN manquante lorsque ce format item_id est choisi. Les avoirs doivent présenter des montants et des lignes cohérents ; les enregistrements avec partial != 0 et les types de bons sont rejetés. Le type 2 n'est pris en charge que pour un remboursement sans ambiguïté des seuls frais de livraison. Le remboursement partiel de quantités de produits n'est pas la même chose que l'indicateur technique partial.

Principales caractéristiques et fonctionnalités

• 15 événements e-commerce et compte nommés : view_item, view_item_list, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, search, view_search_results, sign_up et login.
• page_view optionnel : l’administrateur peut conserver la mesure automatique des pages vues dans le module ou la désactiver si la gestion des pages vues est assurée par Google Tag Manager ou une autre solution.
• Achat après un statut configuré : la version 1.4.2 envoie purchase depuis le serveur après l'enregistrement, dans l'historique de commande, du statut choisi par l'administrateur comme confirmation du paiement et si les autres conditions sont remplies. Le module ne vérifie pas lui-même le règlement auprès du prestataire de paiement.
• Measurement Protocol pour les opérations financières : pour envoyer purchase et refund, il faut : l’ID de mesure principal, l’API Secret, les données d’attribution/session enregistrées ainsi que le consentement analytique actuel.
• Remboursements contrôlés : le module prend en charge le remboursement complet selon le statut sélectionné ainsi que les nouvelles corrections PrestaShop, y compris les corrections partielles, uniquement lorsqu’un achat éligible a été enregistré auparavant.
• Journal des événements financiers : un registre persistant et un verrou par commande contrôlent les achats et remboursements propres au module ; le back-office propose une vue en lecture seule avec filtres, tri et pagination. Cela ne déduplique pas les événements envoyés indépendamment par GTM ou d'autres modules.
• Deux identifiants Measurement ID : il est possible de configurer un identifiant principal ainsi qu’un second identifiant GA4 optionnel pour les événements envoyés depuis la balise dans le navigateur.
• Cinq méthodes de construction de item_id : ID produit, ID produit avec ID de combinaison séparé par un tiret, ID produit avec ID de combinaison séparé par un trait de soulignement, référence ou EAN.
• Données catalogue dans les événements : le module transmet notamment l’identifiant, le nom, la variante, la marque, les catégories, le prix, la remise, la quantité, la devise ainsi que les données de liste de produits, si elles sont disponibles dans PrestaShop.
• Codes de réduction : les événements du navigateur pris en charge peuvent contenir le nom et le code de la règle de panier appliquée. Dans la version 1.4.2, le purchase côté serveur envoyé via Measurement Protocol ne contient pas de codes de réduction.
• User ID pour le client connecté : après activation de l’option, le module transmet à GA4 l’identifiant technique du client avec le consentement analytics_storage ; cela ne remplace pas les données de contact.
• Données fournies par l’utilisateur : après activation de l’option et avec le consentement actuel ad_user_data, le module peut transmettre l’e-mail ainsi que le téléphone ou l’adresse disponibles dans le format requis par Google ; les données identifiantes sont normalisées et hachées en SHA-256.
• Remarketing dynamique Google Ads : après activation de la fonction et saisie de l’identifiant Google Ads, la balise reçoit les identifiants produits, le type de page ainsi que la valeur du panier.
• DebugView et diagnostic : le mode débogage journalise les événements du navigateur et définit leur indicateur debug_mode pour GA4 DebugView. Il ne définit pas cet indicateur pour les purchase et refund côté serveur. Le panneau affiche l'état de la configuration et le dernier achat avec une réponse HTTP 2xx ; les événements financiers doivent être vérifiés dans le journal et les rapports GA4.
• PrestaShop 1.7.x, 8.x et 9.x : il s'agit de la plage déclarée par la version 1.4.2, et non d'une garantie pour chaque version de PHP, thème ou checkout. Le code comprend des parcours pour le checkout standard et certains modules one-page checkout ; le parcours réel de commande de votre boutique doit être vérifié.

Quelles étapes de vente le module GA4 pour PrestaShop mesure-t-il ?

Mesure des achats et remboursements via Measurement Protocol

Dans le mode financier actuel, le module ne considère ni le clic sur le bouton ni la seule page de confirmation comme une preuve de paiement. L’événement purchase est créé après l’enregistrement dans l’historique de commande de l’un des statuts de paiement sélectionnés. Pour un remboursement, le module vérifie d’abord s’il existe pour cette commande un achat antérieur enregistré comme envoyé dans le journal ; ensuite, il ne comptabilise que la valeur restante non remboursée. Un remboursement complet peut être déclenché par le statut sélectionné, et les nouvelles corrections PrestaShop sont prises en charge indépendamment, y compris partiellement.

L’état sent dans le journal signifie une réponse HTTP 2xx, c’est-à-dire l’acceptation de la requête par l’endpoint Measurement Protocol. Il ne s’agit pas d’une confirmation que l’événement a déjà été traité ou affiché dans les rapports Google Analytics. Le module ne reconstitue pas les achats ou remboursements historiques après une mise à jour et ne dispose pas de file d’attente automatique, de CRON ni de bouton forçant une nouvelle tentative d’envoi incertaine.

GA4, Google Ads, consentements et données utilisateur

Le module peut initialiser la balise GA4 pour un ou deux Measurement ID. Pour le remarketing dynamique Google Ads, il nécessite en plus un identifiant au format AW-…. Dans le mode actuel d’achat après statut de paiement, les événements purchase et refund sont envoyés à GA4 via Measurement Protocol ; dans ce mode, le module n’envoie pas directement de conversion d’achat navigateur à Google Ads.

L’option des données fournies par l’utilisateur nécessite un PD Cookie Pro actif avec Consent Mode v2 et le consentement actuel ad_user_data. En outre, le propriétaire de la boutique doit activer la collecte de ces données dans la propriété GA4 ainsi que dans les paramètres de la balise Google ; la configuration des conversions améliorées dans Google Ads constitue une tâche distincte du côté du compte Google. Le retrait du consentement supprime les données identifiantes de la configuration de la balise, et l’envoi serveur des opérations financières vérifie à nouveau le consentement actuel avant l’envoi. User ID et les données fournies par l'utilisateur nécessitent aussi PD Cookie Pro actif en mode live, Consent Mode v2 et la révision actuelle du consentement. Le retrait d'analytics_storage efface User ID dans le tag ; le retrait d'ad_user_data efface user_data. Cela ne supprime pas les données déjà transmises à Google.

Configuration et vérification de l’implémentation

1. Saisissez le Measurement ID GA4 principal, et le second identifiant uniquement s’il est nécessaire.
2. Pour les achats et remboursements, indiquez l’API Secret Measurement Protocol et sélectionnez les statuts qui confirment réellement le paiement et le remboursement complet de la commande dans la boutique concernée.
3. Choisissez le format item_id en fonction de l’identifiant utilisé dans le catalogue ou le flux produit.
4. Activez uniquement les fonctions Google Ads, User ID et données fournies par l’utilisateur nécessaires, après vérification des paramètres et des consentements dans les outils Google.
5. Pour le test, utilisez le mode débogage et GA4 DebugView, et pour les opérations financières, vérifiez le journal du module. Le test doit être effectué sur un parcours d’achat réel et avec le bon statut de commande.

Périmètre du module et limitations importantes

• Le module transmet les données aux services Google configurés ; il ne crée ni n’administre de compte GA4, Google Ads, Merchant Center ou de campagnes publicitaires.
• Il ne remplace pas la configuration des consentements ni l’analyse juridique de la boutique. Le propriétaire de la boutique est responsable de la base légale du traitement des données, du contenu des consentements et des paramètres des comptes Google.
• Le blocage des scripts, l’absence de consentement, l’absence d’attribution enregistrée, des identifiants erronés ou des paramètres Google incorrects peuvent limiter la mesure. Le module ne garantit pas l’exhaustivité des données.
• L’envoi de données avec l’API Secret nécessite une configuration GA4 correcte. La réponse HTTP 2xx doit être considérée comme une confirmation de réception de la requête, et non comme une preuve de visibilité de la transaction dans les rapports.