Votre tracking PrestaShop fonctionne-t-il vraiment ? Un auto-contrôle en 5 minutes

La plupart des trackings cassés ne s'annoncent pas. Il n'y a aucun message d'erreur, aucune bannière rouge — juste des chiffres discrètement faux, menant à des décisions discrètement mauvaises. La seule façon de savoir si votre tracking PrestaShop est sain est de le vérifier délibérément.

La bonne nouvelle est qu'un contrôle de santé significatif prend environ cinq minutes et ne nécessite aucun outil spécial au-delà de votre tableau de bord GA4 et de votre back-office PrestaShop. Faites les cinq vérifications ci-dessous. Si vous les réussissez toutes, votre configuration est probablement en bon état. Si vous en échouez ne serait-ce qu'une, vous perdez vraisemblablement des conversions et devriez creuser davantage.

Vérification 1 : comparer les achats GA4 aux vraies commandes

C'est le test le plus révélateur. Choisissez une plage de dates propre — le mois dernier est idéal — et récupérez deux chiffres : le nombre d'événements purchase dans GA4, et le nombre de commandes valides dans votre back-office PrestaShop sur les mêmes dates.

Maintenant comparez. Une configuration saine atterrit à quelques pour cent près, avec de petites différences explicables (commandes annulées, commandes de test, fraude filtrée). Si GA4 est 20 %, 30 % ou plus en dessous de votre back-office, vous avez une sous-estimation structurelle — le symptôme classique d'un tracking uniquement côté client qui perd des événements à cause des bloqueurs de publicités, de l'ITP et des onglets fermés.

Faites de même avec le chiffre d'affaires, pas seulement le nombre de commandes. Si le chiffre d'affaires GA4 est bien en dessous de l'argent réellement encaissé, l'écart est réel et il vous coûte des enchères et un reporting précis. Nous traitons les causes en profondeur sous côté serveur vs côté client.

Vérification 2 : regardez votre part iOS et Safari

Votre exposition à la perte de tracking dépend fortement de votre audience. Dans GA4, regardez la répartition des sessions par système d'exploitation et par navigateur, en vous concentrant sur iOS et Safari.

Plus votre part iOS et Safari est grande, plus l'Intelligent Tracking Prevention et l'App Tracking Transparency d'Apple érodent vos données côté client. Une boutique où la majorité du trafic mobile est iOS est bien plus exposée qu'une dominée par Android, car l'ITP plafonne agressivement les cookies côté client sur les appareils Apple.

Cette vérification ne produit pas un succès/échec à elle seule, mais elle vous dit à quel point les autres vérifications comptent. Une part iOS élevée signifie que même un petit écart visible cache probablement un écart réel plus grand, et elle augmente l'urgence de déplacer les événements clés côté serveur.

Vérification 3 : traquez le trafic non attribué et direct

Ouvrez votre rapport d'acquisition de trafic et regardez quelle part du trafic est classée comme « non attribué », « (direct) » ou « (not set) ». Une petite quantité est normale. Une part importante ou croissante est un signal d'alerte.

Quand les cookies de tracking expirent prématurément sous l'ITP, les visiteurs récurrents arrivés à l'origine d'une publicité ou d'une campagne reviennent en ressemblant à des sessions toutes neuves et sans source. Cette attribution ne disparaît pas en silence — elle s'accumule dans les compartiments non attribué et direct, les gonflant.

Si une part suspicieusement grande de vos conversions est créditée au direct ou au non attribué, votre reporting par canal n'est pas fiable et vous sous-créditez presque certainement les campagnes payantes. Cette mauvaise attribution mène directement à couper des budgets qui fonctionnaient réellement.

Vérification 4 : testez vos événements clés en direct

Les chiffres agrégés peuvent cacher des lacunes ; un test en direct confirme la tuyauterie. Ouvrez le temps réel ou le DebugView de GA4, puis parcourez votre propre boutique comme un client : voyez un produit, ajoutez au panier, commencez le paiement et terminez un achat de test.

Guettez l'apparition de chaque événement : page_view, view_item, ajout au panier, begin_checkout, et enfin purchase. Confirmez que purchase porte la bonne valeur — le total TVA incluse que vous avez réellement payé — et un transaction_id sensé.

Maintenant répétez la vérification de l'achat avec un bloqueur de publicités activé, ou sur un iPhone dans Safari. Si l'événement disparaît dans ces conditions, vous venez de reproduire, de vos propres yeux, la perte exacte qui se produit sur une grande part de votre trafic réel. C'est la preuve la plus convaincante qui soit.

Vérification 5 : cherchez les doublons et les mauvaises valeurs

La perte est un mode de défaillance ; l'inflation en est un autre. Pendant le test, rechargez la page de confirmation ou cliquez sur retour puis avant à nouveau. Si un second purchase apparaît en temps réel, vous avez un problème de duplication — généralement un transaction_id aléatoire plutôt que déterministe.

Vérifiez aussi le bon sens des chiffres de chiffre d'affaires. Si GA4 affiche des sous-totaux hors taxes au lieu du montant payé par les clients, votre ROAS et vos enchères basées sur la valeur travaillent à partir de chiffres sous-estimés. Doublons et mauvaises valeurs corrompent tous deux les données dont le Smart Bidding apprend.

Une configuration qui compte en double peut en réalité paraître plus saine que la réalité sur le nombre de commandes tout en étant tout aussi cassée. La solution est une identité déterministe issue de la référence de commande, le même principe que nous appliquons sur tracking GA4 et Meta CAPI.

Quand faire un vrai audit

Si vous avez réussi les cinq vérifications, bravo — votre tracking est en meilleur état que la plupart. Relancez la comparaison chaque trimestre et après tout changement de thème, de paiement ou de module, car les mises à jour cassent régulièrement le tracking en silence.

Si vous en avez échoué une ou plusieurs, les vérifications vous ont dit où vit le problème mais pas toujours à quelle profondeur il va. Un écart GA4 de 30 %, une part iOS élevée, un trafic non attribué gonflé, ou des événements qui disparaissent sous un bloqueur de publicités pointent tous vers la même réponse : vos conversions les plus importantes n'atteignent pas de façon fiable les systèmes qui en dépendent.

C'est le point où un audit structuré se rentabilise. Réservez un audit et nous mesurerons votre vrai écart face à vos commandes PrestaShop, identifierons chaque fuite et montrerons ce que sa récupération vaut. Vous pouvez aussi lire à propos du module qui la comble.