Audit du suivi des achats WooCommerce dans GA4, Google Ads et GTM

Vérifie si [WordPress site] remonte correctement les achats vers GA4 et vers [Google Ads account]. 1. Comparaison quotidienne, sur les 14 derniers jours complets : - WooCommerce : parcours wordpress_woo_orders page par page jusqu'à dépasser les commandes datant de plus de 14 jours. Ne compte que les commandes terminées (completed) et en cours de traitement (processing), jour par jour. Dis-moi si les commandes s'arrêtent avant le 14e jour, et traite à part toute commande qui ressemble à un test (mon propre nom, total à 0). - GA4 : lance ga4_report avec la dimension "date" et dimension2 "event", et ne retiens que le nombre d'événements purchase. N'utilise pas le chiffre total des conversions, qui additionne tous les événements clés. - Google Ads : lance google_ads_query sur l'action de conversion d'achat, segmentée par segments.date et segments.conversion_action_name, afin que les autres actions ne gonflent pas le chiffre. Note que Google Ads rapporte les conversions à la date du clic : les jours récents peuvent donc encore se compléter. - Note les fuseaux horaires de la boutique, de la propriété GA4 et du compte Ads s'ils diffèrent, car cela déplace des commandes d'un jour à l'autre. 2. Paramètres : - Confirme que purchase est un événement clé avec ga4_list_conversions. - Avec list_conversion_actions et get_conversion_settings, confirme que l'action d'achat Ads est activée, incluse dans les conversions (principale), qu'elle a enregistré des données, et vérifie son type de comptage. MANY_PER_CLICK sur une action d'achat est une source fréquente de surcomptage. 3. Inventaire des balises : - wordpress_tracking pour chaque endroit où se déclenche une balise GA4 ou GTM (extensions, snippets WPCode, code d'en-tête/pied de page, options du thème). Lis tout snippet suspect avec wordpress_snippet et toute option de thème vers laquelle il pointe avec wordpress_option. - wordpress_list_plugins pour repérer les extensions qui envoient elles-mêmes des données d'achat (par exemple GTM4WP, WooCommerce Google Analytics, Site Kit, PixelYourSite). - Dans GTM, liste les balises et les déclencheurs de l'espace de travail du conteneur en ligne et signale chaque balise qui envoie purchase à GA4 ou une conversion Google Ads, avec son ID/libellé de conversion et ses conditions de déclenchement. Utilise gtm_workspace_status pour voir si une modification liée aux achats attend d'être publiée. - Le mode de consentement ne se lit pas comme un paramètre unique. Rapporte ce que montre l'inventaire des balises (une extension de consentement, des paramètres de consentement dans les balises GTM, un snippet de consentement) et dis clairement si tu ne peux pas trancher. Livrable : - Un tableau quotidien avec ces colonnes : date, commandes, achats GA4, conversions Google Ads, écart GA4 en % vs commandes, écart Ads en % vs commandes. - Une liste numérotée de constats, chacun relié aux éléments qui l'étayent. Utilise ces seuils uniquement comme indices, puis confirme la cause à partir de l'inventaire : - Plus de 10 % au-dessus des commandes : cherche deux sources qui envoient le même achat (une extension plus une balise GTM, deux conteneurs), un transaction_id manquant, un comptage MANY_PER_CLICK, ou un déclencheur de page de remerciement qui se déclenche au rechargement. - Plus de 25 % en dessous des commandes : cherche une balise manquante ou non publiée, une condition de déclencheur qui ne couvre pas l'URL de la page de remerciement, un blocage par le consentement, ou une passerelle de paiement qui ne revient pas à la page de remerciement. Si les données de commande n'indiquent pas le mode de paiement, demande-moi quelles passerelles nous utilisons. Propose des correctifs en nommant précisément la balise, le déclencheur, le snippet ou l'extension à modifier. N'effectue aucune modification avant que j'aie approuvé un aperçu de chacune.