Comment réduire les écarts de mesure des ventes avec Google Analytics ?
Quel éditeur de site marchand n’a pas déjà été confronté à ce problème : “Sur mon cms ecommerce ou mon erp je mesure 20% de ventes en plus que sur google analytics !” et là… c’est la panique :
Comment savoir qui a raison ? Analytics ou mon système de gestion ? Comment calculer du coup le ROI de mes campagnes d’acquisition qui sont étroitement liées au trafic et aux ventes mesurées par Analytics ?
Cet article a pour objectif d’expliquer les raisons du décalage et de lister des solutions pour limiter voire supprimer complètement ces écarts.
Pourquoi ça arrive et comment fonctionne Google Analytics ?
Lorsqu’un achat est réalisé sur un site web, l’enregistrement de la vente est réalisé dans 2 traitements indépendants :
1 – d’abord sur le site web où a eu lieu la vente (dans la base de données associées au CMS).
Si une interface de connexion existe avec l’ERP, la vente est également transmise automatiquement au système de gestion.
2 – ensuite sur le serveur distant de Google Analytics selon un protocole précis :
réception de l’appel déclenché depuis le site web (au chargement de la page de confirmation de la vente par exemple)
traitement des données réceptionnées (montant total, produits achetés,
devise…), calcul (taux de conversion..)
Génération des rapports analytics (rapports e-commerce et e-commerce avancé)
Quelles sont les sources fréquentes d’erreur de mesure ?
Plusieurs éléments peuvent être à l’origine du décalage de mesure entre les deux systèmes :
Sources techniques :
Le premier élément et peut être le plus déterminant est étroitement lié à la mise en place
du processus d’appel du serveur Google Analytics : En effet, il suffit par exemple que le déclenchement de l’appel – sur le site web – c’est-à-dire dans le code source du site ne soit pas le plus rigoureux. Ainsi parfois, un double appel d’analytics génère un double comptage des ventes côté Analytics (et moitié moins côté système de gestion).
Il est aussi fréquent de trouver un appel de la transaction Analytics (event ecommerce) doublé d’un Pageview (Page vue classique).
Un autre cas fréquent est l’absence du comptage par analytics de certaines ventes (pourtant enregistrées par le système de gestion) : Dans ce cas, il faut se souvenir que c’est le navigateur du visiteur web (“appel côté client”) qui déclenche l’appel vers Google Analytics.
Plusieurs facteurs peuvent survenir pendant l’appel du navigateur client vers Google Analytics et qui risquent d’empêcher l’appel :
coupure ou instabilité du réseau
interaction du visiteur sur la page en cours (fermeture du navigateur ou retour en arrière pendant le chargement de la page…)
erreur de redirection vers le site après le paiement sur le TPE
Sources liées à la protection des données personnelles :
La montée en puissance de l’e-privacy et l’impact sur le tracking classique
Depuis longtemps déjà les visiteurs utilisent des adblockers qui empêchent la dépose des cookies (pour limiter leur identification sur un site web) mais qui bloquent également les javascripts utilisés par les navigateurs pour réaliser les appels (analytics, tags emarketing…).
Ce phénomène s’est encore accentué avec l’arrivée du RGPD en 2018 ainsi qu’avec la politique décidée par certains éditeurs de navigateurs pour protéger leurs utilisateurs
(protocole ITP chez Apple avec le logiciel Safari par exemple)
Ces dispositifs empêchent les appels vers Google Analytics ce qui a pour effet de ne pas comptabiliser les ventes réalisées sur les appareils concernés.
Sources liées aux erreurs d’analyse :
On ne compare pas les mêmes données !
Analytics a son propre référentiel de mesure des transactions qui peut être différent de celui de votre CMS ou ERP. Non prise en compte des taxes ou des promotions dans analytics par exemple ou format des devises différents…
La plage de date analysée :
Les données des rapports e-commerce dans Analytics ne sont pas disponibles en temps réel (avec les propriétés classiques Universal Analytics). En effet il y a un décalage dans le temps (quelques heures, parfois une journée) nécessaire à Analytics pour traiter et afficher les rapports de vente. A avoir donc en tête lors de la comparaison des données avec celles de l’ERP.
Quelles solutions pour limiter ou supprimer les écarts de mesure ?
Qualité du code et respect du protocole de mesure
Utiliser les outils et la documentation fournie par Google et d’autres acteurs pour tester l’implémentation du tracking ecommerce sur le site web et s’assurer qu’elle est conforme.
Monitorer, Tester, tester et tester :
C’est indispensable pour éviter de découvrir après coup ces décalages. Une aide précieuse peut être aussi fournie en analysant les fichiers de logs du serveur web pour détecter notamment des erreurs de redirection.
Pour simplifier l’implémentation des scripts Google dans le code source du site marchand et garantir une maintenance de qualité, ne pas hésiter à utiliser des extensions. Il en existe pour les principaux cms (prestahop, magento, shopify, wordpress…).
Enfin, il est fortement conseillé d’utiliser un gestionnaire de tags (comme Google Tag Manager) pour simplifier et maintenir efficacement l’intégration du tag Google Analytics (et son paramétrage ecommerce).
Le tracking server side
Qu’est ce que c’est ?
Au lieu de déclencher l’appel du serveur de google depuis le navigateur client, on va le faire directement depuis le serveur web qui héberge le site.
Comment ça se met en place ?
A l’aide des APIs fournies par le Google Measurement Protocol, il est possible d’appeler le serveur de google analytics pour lui transmettre directement les données du site visité (pages vues, temps passé, produit acheté…) et ce directement dans le code source côté serveur (donc php, java, asp… et non plus javascript).
Remarque RGPD et e-privacy : comme pour le tracking “client-side” via javascript, il est impératif de prévenir le visiteur et d’obtenir son consentement avec d’implémenter ce traitement
Avantages :
On évite le bloquage du navigateur en appelant directement le serveur analytics et permettre ainsi le tracking même s’il bloque javscript. Au bénéficie ainsi de :
vitesse de chargement améliorée pour le visiteur
des données plus justes (moins d’écart voire plus de différence)
meilleur contrôle des données personnelles
tracking compatible RGPD (car first party cookie uniquement)
Inconvénients :
La mise en œuvre est plus complexe (appels aux APIs, peu d’extensions disponibles…)
Le coût de la mise en oeuvre (pour une implémentation à l’aide de GTM Server side, la solution est payante car nécessitant un abonnement à google cloud).
Changer d’outil de mesure des transactions
Matomo Analytics, Adobe Analytics… Il n’y a pas que Google Analytics qui peut mesurer vos ventes et les croiser avec votre trafic. Néanmoins, tant que la solution retenue exploite un appel (hit) client-serveur, les problématiques présentées demeurent.
Exploiter la base de données associée au site internet et Développer une solution 100% custom
Votre cms e-marchand (ou votre ERP ou CRM) exploite sans aucun doute une base de données type MySQL, PostgreSQL, SQL Server, Mongo DB….
Une piste c’est d’enregistrer dans le CMS ou ERP le User Agent (donc des données sur l’appareil, le navigateur) et la source de trafic et non uniquement les data du client ayant effectué la transaction :
Cela permet d’ajouter aux données déjà présentes la source de trafic ce qui peut permettre l’analyse croisée ventes, produits et trafic. Cependant la qualité des rapports sera loin d’être aussi riche que ceux de Google Analytics.
Acheter la version 360 Analytics
La version de base de Google Analytics affiche des rapports basés sur un échantillonnage des données (donc non complètes), ce qui n’est pas le cas de la version payante 360 de Google Analytics… mais elle n’est pas donnée !
Vous faire accompagner par des consultants spécialisés
Les consultants analytics et Dataviz de Conversion Boosters pourront analyser votre cas particulier et vous aider à identifier les problématiques, améliorer la qualité de vos données et de vos dashboards ecommerce !
Une question analytics, un projet de dashboard ecommerce ? Parlez-en avec un de nos experts Analytics
Comment réduire les écarts de mesure des ventes avec Google Analytics ?
Quel éditeur de site marchand n’a pas déjà été confronté à ce problème : “Sur mon cms ecommerce ou mon erp je mesure 20% de ventes en plus que sur google analytics !” et là… c’est la panique :
Comment savoir qui a raison ? Analytics ou mon système de gestion ? Comment calculer du coup le ROI de mes campagnes d’acquisition qui sont étroitement liées au trafic et aux ventes mesurées par Analytics ?
Cet article a pour objectif d’expliquer les raisons du décalage et de lister des solutions pour limiter voire supprimer complètement ces écarts.
Pourquoi ça arrive et comment fonctionne Google Analytics ?
Lorsqu’un achat est réalisé sur un site web, l’enregistrement de la vente est réalisé dans 2 traitements indépendants :
1 – d’abord sur le site web où a eu lieu la vente (dans la base de données associées au CMS).
Si une interface de connexion existe avec l’ERP, la vente est également transmise automatiquement au système de gestion.
2 – ensuite sur le serveur distant de Google Analytics selon un protocole précis :
Quelles sont les sources fréquentes d’erreur de mesure ?
Plusieurs éléments peuvent être à l’origine du décalage de mesure entre les deux systèmes :
Sources techniques :
Le premier élément et peut être le plus déterminant est étroitement lié à la mise en place
du processus d’appel du serveur Google Analytics : En effet, il suffit par exemple que le déclenchement de l’appel – sur le site web – c’est-à-dire dans le code source du site ne soit pas le plus rigoureux. Ainsi parfois, un double appel d’analytics génère un double comptage des ventes côté Analytics (et moitié moins côté système de gestion).
Il est aussi fréquent de trouver un appel de la transaction Analytics (event ecommerce) doublé d’un Pageview (Page vue classique).
Un autre cas fréquent est l’absence du comptage par analytics de certaines ventes (pourtant enregistrées par le système de gestion) : Dans ce cas, il faut se souvenir que c’est le navigateur du visiteur web (“appel côté client”) qui déclenche l’appel vers Google Analytics.
Plusieurs facteurs peuvent survenir pendant l’appel du navigateur client vers Google Analytics et qui risquent d’empêcher l’appel :
Sources liées à la protection des données personnelles :
La montée en puissance de l’e-privacy et l’impact sur le tracking classique
Depuis longtemps déjà les visiteurs utilisent des adblockers qui empêchent la dépose des cookies (pour limiter leur identification sur un site web) mais qui bloquent également les javascripts utilisés par les navigateurs pour réaliser les appels (analytics, tags emarketing…).
Ce phénomène s’est encore accentué avec l’arrivée du RGPD en 2018 ainsi qu’avec la politique décidée par certains éditeurs de navigateurs pour protéger leurs utilisateurs
(protocole ITP chez Apple avec le logiciel Safari par exemple)
Ces dispositifs empêchent les appels vers Google Analytics ce qui a pour effet de ne pas comptabiliser les ventes réalisées sur les appareils concernés.
Sources liées aux erreurs d’analyse :
On ne compare pas les mêmes données !
Analytics a son propre référentiel de mesure des transactions qui peut être différent de celui de votre CMS ou ERP. Non prise en compte des taxes ou des promotions dans analytics par exemple ou format des devises différents…
La plage de date analysée :
Les données des rapports e-commerce dans Analytics ne sont pas disponibles en temps réel (avec les propriétés classiques Universal Analytics). En effet il y a un décalage dans le temps (quelques heures, parfois une journée) nécessaire à Analytics pour traiter et afficher les rapports de vente. A avoir donc en tête lors de la comparaison des données avec celles de l’ERP.
Quelles solutions pour limiter ou supprimer les écarts de mesure ?
Qualité du code et respect du protocole de mesure
Utiliser les outils et la documentation fournie par Google et d’autres acteurs pour tester l’implémentation du tracking ecommerce sur le site web et s’assurer qu’elle est conforme.
Voir la documentation officielle du Measurement Protocol Universal Analytics et des APIs
Monitorer, Tester, tester et tester :
C’est indispensable pour éviter de découvrir après coup ces décalages. Une aide précieuse peut être aussi fournie en analysant les fichiers de logs du serveur web pour détecter notamment des erreurs de redirection.
Pour simplifier l’implémentation des scripts Google dans le code source du site marchand et garantir une maintenance de qualité, ne pas hésiter à utiliser des extensions. Il en existe pour les principaux cms (prestahop, magento, shopify, wordpress…).
Enfin, il est fortement conseillé d’utiliser un gestionnaire de tags (comme Google Tag Manager) pour simplifier et maintenir efficacement l’intégration du tag Google Analytics (et son paramétrage ecommerce).
Le tracking server side
Qu’est ce que c’est ?
Au lieu de déclencher l’appel du serveur de google depuis le navigateur client, on va le faire directement depuis le serveur web qui héberge le site.
Comment ça se met en place ?
A l’aide des APIs fournies par le Google Measurement Protocol, il est possible d’appeler le serveur de google analytics pour lui transmettre directement les données du site visité (pages vues, temps passé, produit acheté…) et ce directement dans le code source côté serveur (donc php, java, asp… et non plus javascript).
Remarque RGPD et e-privacy : comme pour le tracking “client-side” via javascript, il est impératif de prévenir le visiteur et d’obtenir son consentement avec d’implémenter ce traitement
Avantages :
On évite le bloquage du navigateur en appelant directement le serveur analytics et permettre ainsi le tracking même s’il bloque javscript. Au bénéficie ainsi de :
Inconvénients :
La mise en œuvre est plus complexe (appels aux APIs, peu d’extensions disponibles…)
Le coût de la mise en oeuvre (pour une implémentation à l’aide de GTM Server side, la solution est payante car nécessitant un abonnement à google cloud).
Changer d’outil de mesure des transactions
Matomo Analytics, Adobe Analytics… Il n’y a pas que Google Analytics qui peut mesurer vos ventes et les croiser avec votre trafic. Néanmoins, tant que la solution retenue exploite un appel (hit) client-serveur, les problématiques présentées demeurent.
Exploiter la base de données associée au site internet et Développer une solution 100% custom
Votre cms e-marchand (ou votre ERP ou CRM) exploite sans aucun doute une base de données type MySQL, PostgreSQL, SQL Server, Mongo DB….
Une piste c’est d’enregistrer dans le CMS ou ERP le User Agent (donc des données sur l’appareil, le navigateur) et la source de trafic et non uniquement les data du client ayant effectué la transaction :
Demander au développeur d’enregistrer la valeur des entêtes HTTP_REFERER et HTTP_USER_AGENT (voir par exemple sur https://www.php.net/manual/fr/reserved.variables.server.php pour PHP).
Cela permet d’ajouter aux données déjà présentes la source de trafic ce qui peut permettre l’analyse croisée ventes, produits et trafic. Cependant la qualité des rapports sera loin d’être aussi riche que ceux de Google Analytics.
Acheter la version 360 Analytics
La version de base de Google Analytics affiche des rapports basés sur un échantillonnage des données (donc non complètes), ce qui n’est pas le cas de la version payante 360 de Google Analytics… mais elle n’est pas donnée !
Vous faire accompagner par des consultants spécialisés
Les consultants analytics et Dataviz de Conversion Boosters pourront analyser votre cas particulier et vous aider à identifier les problématiques, améliorer la qualité de vos données et de vos dashboards ecommerce !
Une question analytics, un projet de dashboard ecommerce ? Parlez-en avec un de nos experts Analytics
Voir les derniers articles du blog du CRO :