- Data
- SEA
- SEO
Table des matières
Table des matières
Pourquoi Google Analytics m’annonce-t-il un chiffre d’affaires ridicule par rapport à mon ERP ? Pourquoi le nombre de produits commandés dans Magento/Prestashop est-il différent de celui indiqué dans Google Analytics ? Quelle différence est statistiquement significative ? Quel écart suis-je prêt à accepter ?
Vous vous tirez les cheveux et c’est bien normal. Empirik lutte contre votre calvitie précoce en répondant à vos questions et en vous fournissant les solutions !
La base
Avant toute chose, revenons aux bases techniques : par défaut, pour enregistrer une transaction dans Google Analytics, votre site e-Commerce doit envoyer les informations de transaction aux serveurs de Google depuis le navigateur de l’internaute (Chrome, Firefox, Safari…).
Cet envoi doit avoir lieu au moment même de la transaction, pendant que les diverses informations sont encore disponibles (montant total, contenu du panier, frais de port, coupons…).
Dans la plupart des cas, ceci se passe sur la page de confirmation de paiement. Ce système est appelé tracking côté client (Client-side).
Les causes
Plusieurs facteurs ou combinaisons de facteurs sont responsables lorsqu’une transaction a bien lieu sur votre site, apparaît dans votre ERP ou votre CMS, mais n’est pas enregistrée dans Google Analytics.
L’utilisation du mode « Navigation privée » ou la présence d’un bloqueur de publicité (AdBlocker) dans le navigateur du client
- Aucune transaction ne remontera dans Google Analytics depuis un tel navigateur.
- Par défaut les bloqueurs de pub sont configurés pour stopper tout envoi à Google Analytics.
- La navigation privée bloque l’usage des trackers classiques, dont Google Analytics.
- De même, la navigation privée et certains navigateurs bloquent automatiquement certains cookies, faussant potentiellement les données remontées par le tracker.
- À noter que cet état de fait est à relativiser car certains navigateurs et certains AdBlocker gardent le tracking Google Analytics actif.
- Ainsi Firefox avec uBlock Origin bloquera tout tandis que Chrome avec AdBlock Plus laissera le tracking intact.
- Gardez en tête la part de marché de chaque navigateur selon le type de plateforme (60% pour Chrome au global vs 15% pour Firefox, par exemple).
L’utilisation d’un navigateur obsolète et/ou exotique
Les commandes exécutées sur la page de confirmation pour envoyer l’information à Google Analytics peuvent être inopérantes dans ce type de navigateur.
Des robots crawlant le site et faussant les données
Un robot peut par exemple fausser vos données d’impression en visitant des pages produits en masse fréquemment.
Un problème de connexion internet interrompue et/ou une erreur/plantage serveur
Si le problème survient entre le moment du paiement et l’accès à la page de confirmation, les informations ne remonteront pas dans Google Analytics.
Un site mobile mal implémenté
Certains sites dont les versions mobiles sont de mauvaise qualité peuvent se retrouver avec des tunnels de commandes inactifs ou bugées, des trackings cassés ou incomplets…
Un tracker e-Commerce Google Analytics mal déployé !
- Version obsolète du tracker.
- Mauvaises valeurs renseignées pour la transaction.
- Tracker absent ou présent sur la mauvaise page.
- Tracking global (pages vues, etc.) mal configuré et entraînant des collisions avec le tracking e-Commerce.
- Non prise en compte du changement de domaine entre la plate-forme de paiement et votre site.
- Présence d’une iFrame ou autre solution risquée pour la stabilité de votre tracking.
Un tunnel mal implémenté / L’absence de visite de la page de confirmation
- On constate fréquemment des cas de non-passage du client par la page de confirmation.
- Ceci peut être dû à un temps trop long avant la redirection automatique depuis la plate-forme de paiement, laissant ainsi au client le temps de quitter le tunnel avant l’arrivée à la page de confirmation.
- Le même cas peut survenir si la redirection est mal configurée, ne pointe pas sur la bonne page, etc.
- Enfin ceci peut être le signe d’une erreur ou d’un plantage serveur.
L’échantillonnage Google Analytics
- À la consultation des données
- Vous enregistrez un grand nombre de commandes sur votre site.
- Vous souhaitez ensuite obtenir les valeurs pour une longue plage de dates dans Google Analytics ou vous appliquez un segment sur vos données.
- Vous vous exposez à de l’échantillonnage et donc à des données incomplètes affichées dans vos rapports.
- À la récolte des données
- Vous envoyez un très grand nombre de hits à Google Analytics depuis votre site (par exemple des impressions pour le e-Commerce avancée, des événements, un timer, etc.).
- Vous vous exposez à un dépassement de quota.
- Dans ce cas, l’échantillonnage s’appliquera à la récolte des données.
- Les transactions réalisées après l’atteinte du quota et avant sa réinitialisation seront ignorées. De même pour tous les autres types de hits (pages vues, événements…).
Les solutions
Quelles sont les solutions ?
- Effectuer des tests et recettes réguliers pour s’assurer du bon fonctionnement du site et du tunnel en particulier.
- Utiliser Google Tag Manager ou une autre solution de Tag Management System (TMS) pour mettre en place le tracking simplement (tags Google Analytics pré-paramétrés), centraliser les différents tags Google Analytics en les extrayant du code-source des pages et ainsi faciliter leur maintenance.
- Contrôler la bonne tenue du tracking par une configuration Google Analytics propre (filtres, canaux, dimensions personnalisées, multi-domaines, alertes) : un audit de la configuration de Google Analytics peut être indispensable.
- Utiliser conjointement un TMS et son data layer pour assurer la fiabilité des données remontées.
- Les équipes SI poussent dans le data layer, présent sur la page de confirmation, les valeurs obtenues directement au sein du CMS e-Commerce, lui-même peuplé par les données de l’ERP.
- Les tags envoyant les données à Google Analytics vont « piocher » dans ce data layer les informations nécessaires.
- Les données envoyées à Google Analytics sont donc identiques à celle du CMS et de l’ERP.
- Mettre en place d’un tracking côté serveur (Server-side).
- Les informations de transaction ne sont plus envoyées depuis le navigateur client.
- Le serveur hébergeant le site se charge de la communication avec les serveurs Google.
- Les développeurs du site doivent donc ajouter du code au moment de l’enregistrement de la transaction en base de données, pour communiquer les informations à Google Analytics.
- La solution peut s’avérer coûteuse à déployer.
- C’est cependant la solution ultime pour résoudre les problèmes posés par les ad-blockers, le non-accès à la page confirmation et plus généralement tous les problèmes liés au navigateur client.
- Passer à Google Analytics 360 pour résoudre l’échantillonnage.
- Google propose un plan tarifaire permettant de s’affranchir d’une grande partie des limites induites par l’échantillonnage présent dans sa version gratuite.
- Alternativement, vous pouvez vous tourner vers un outil tiers : AT Internet, Adobe…
- Utiliser un outil de monitoring de la performance serveur, des plantages et des erreurs 40X / 50X (404, 500, etc.).
- Faire appel à Empirik, on s’occupe de tout !
L’écart
Quel écart accepter ?
Classiquement, un tracking côté client peut présenter un écart de 5 à 10% de CA/commandes en moins dans Google Analytics en regard du CMS ou de l’ERP. Le passage côté serveur permet de réduire généralement ce delta à une fourchette 1-3%.
L’écart à accepter va dépendre de plusieurs facteurs : volume et montant des transactions, utilisation de Google Analytics au sein de l’entreprise, coût des modifications correctives à apporter, priorité de la fiabilité des données Google Analytics en regard de celles du CRM/de l’ERP, existence d’autres outils de mesure de la
L’écart
Les causes de perte de données e-Commerce au sein de Google Analytics sont multiples mais il est possible de tenter d’y remédier avec quelques actions simples avant d’envisager le grand saut vers le server-side.
Règle #1 : Assurez-vous de la qualité du tunnel de commande de votre site e-Commerce
Règle #2 : Assurez-vous de la qualité du tracking Google Analytics dans son ensemble et de son déport vers un TMS
Règle #3 : Assurez-vous de la qualité du serveur hébergeant de votre site web
Règle #4 : Si la conjonction des 3 règles précédentes ne corrige pas l’écart suffisamment, envisagez le passage au tracking server-side
Enfin et surtout, n’oubliez pas qu’un outil Analytics n’est pas un ERP. L’objectif n’est pas d’obtenir une fiabilité à l’euro près du chiffre d’affaires. L’important est avant tout de pouvoir suivre et analyser une évolution dans le temps de la performance et ainsi en dégager les tendances qui en émergent.
Besoin d'aide, de conseils en web analytics ?
