Les transactions dans Google Analytics : comment faire remonter 100 % de vos commandes ?

Toujours dans le cadre du mois du webanalytics nous allons aujourd’hui aborder le thème du suivi des transactions e-commerce dans Google Analytics. Un sujet sensible et délicat qui est malheureusement assez mal géré par défaut par les nombreuses solutions e-commerce.

De nombreux e-commerçants utilisent Google Analytics pour surveiller le trafic de leur site e-commerce, la gratuité de l’outil étant un de ses gros point fort. Les données

de trafic et de consultation des pages sont indispensables pour analyser les parcours des internautes et étudier les endroits à optimiser dans le site.

La partie e-commerce, qui s’active assez simplement dans Google Analytics, permet de suivre le chiffre d’affaires de votre site et de mesurer la conversion et la rentabilité des différents canaux acquisition, étape essentielle pour piloter ses investissements en webmarketing avec un minimum de visibilité.

La configuration classique du e-commerce sur Google Analytics nécessite un code de tracking appelé « _addTrans » qui s’active sur la page de confirmation de commande, avec Magento « /checkout/onepage/success/ » et avec Prestashop « /order-confirmation.php?XXXX » .

commandes-google-analytics

Avec cette configuration, vous obtiendrez le nombre de commandes réalisées dans l’interface « Conversions > commerce électronique », et vous activerez l’affichage du taux de conversion et la performance des produits. Par contre, il est nécessaire que tous vos clients reviennent sur cette page après avoir payé ! Ce n’est malheureusement pas toujours possible …

Certains modes de paiement empêchent un retour immédiat et automatique à la boutique, d’autres imposent un délai minimum de 10 secondes, certains affichent leur propre page de confirmation de commande etc..

Une partie des commandes peut donc vous échapper et ne pas s’afficher dans Google Analytics. C’est pour cela que l’on observe souvent une différence assez prononcée entre les statistiques de ventes Google Analytics et les données de ventes en back office. Il est donc dommage de perdre des informations de commandes car cela joue sur la rentabilité de vos campagnes et donc sur vos choix d’investissement !

Quelle solution pour suivre 100% de ses commandes ?

Pour suivre 100 % des commandes dans Google Analytics il est nécessaire d’inverser la conception du suivi en enregistrant toutes les commandes AVANT le paiement et en supprimant les commandes non payées. C’est faisable avec un petit travail de configuration.

Le tag de la transaction (_addTrans) doit être envoyé à Google Analytics au moment ou l’internaute est renvoyé vers la page de paiement, on enregistre ainsi toutes les commandes du site.

commande-analytics-annulation

Par contre, certaines commandes peuvent ne pas être finalisées : paiement non reçu, commande frauduleuse, annulation du client etc.. il est donc nécessaire d’annuler une partie des commandes plus ou moins longtemps après l’enregistrement dans Google Analytics. Ça tombe bien c’est prévu par l’outil.

La fonction de Google Analytics _addTrans est en effet « reversible » , en temps normal vous pouvez envoyer des données classiques : 3 produits à prix X,Y et Z mais vous pouvez également annuler la commande, ou une partie en envoyant le code de tracking avec les informations « négatives » .

Exemple tiré de l’aide Google Analytics, le code est divisé en trois parties : _addTrans, _addItem et _trackTrans (en gras dans l’exemple ci dessous).

 

Vos concurrents convertissent plus que vous ! Contactez nous pour booster votre conversion

Transaction de départ

<script type= »text/javascript »>
var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘UA-XXXXX-X’]);
_gaq.push([‘_trackPageview’]);

_gaq.push([‘_addTrans’,
‘1234’, // order ID – required
‘Womens Clothing’, // affiliation or store name
‘28.28’, // total – required
‘1.29’,

// VAT
‘15.00’, // shipping
‘Carlisle’, // city
‘Cumbria’, // county
‘UK’ // country
]);
_gaq.push([‘_addItem’,
‘1234’, // order ID – necessary to associate item with transaction
‘DD44’, // SKU/code – required
‘T-Shirt’, // product name
‘Olive Medium’, // category or variation
‘11.99’, // unit price – required
‘1’ // item quantity – required
]);
_gaq.push([‘_trackTrans’]);

(function() { var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true; ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’; var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s); })();

 

Et pour supprimer la transaction dans Google Analytics :

Note : j’ai indiqué en gras les changements avec le code de création de commande ci dessus.

<script type= »text/javascript »>

var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘UA-XXXXX-X’]);
_gaq.push([‘_trackPageview’]);

_gaq.push([‘_addTrans’,
‘1234’, // order ID – required
‘Womens Clothing’, // affiliation or store name
‘-28.28’, // total – required
‘-1.29’, // VAT
‘-15.00’, // shipping
‘Carlisle’, // city
‘Cumbria’, // county
‘UK’ // country
]);
_gaq.push([‘_addItem’,
‘1234’, // order ID – necessary to associate item with transaction
‘DD44’, // SKU/code – required
‘T-Shirt’, // product name
‘Olive Medium’, // category or variation
‘11.99’, // unit price – required
‘-1’ // item quantity – required
]);
_gaq.push([‘_trackTrans’]);

(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);
})();

Ce script doit être déclenché à chaque annulation de commande, vous pouvez donc l’insérer dans un popup qui se déclenchera à chaque fois que vous annulerez une commande en back office. Pour les annulations automatiques (un script qui annule toutes les 30 min toutes les commandes non payées par exemple) il est nécessaire de faire exécuter ce javascript par votre serveur, c’est faisable mais demande un peu de configuration. Toute la documentation sur l’annulation des commandes est ici

Attention: Google Analytics accepte un nombre illimité d’annulations pour une même commande, il est donc facile de faire remonter de fausses informations dans vos statistiques si le script annule plusieurs fois la même commande.

Pour savoir une transaction est annulée correctement, il faut consulter Google Analytics. Si tout s’est bien passé la commande devient introuvable dans les données de chiffre d’affaires :

Transactions   Google Analytics

 

Si vous annulez la commande plusieurs fois, ou avec les mauvaises données, le montant va s’inscrire en négatif, entre parenthèse, dans l’onglet transactions de Google Analytics, et apparaître aussi en négatif dans la courbe de CA.

Transactions  negative Google Analytics

 

J’espère que cet article vous permettra d’avoir des données de conversion fiable dans le suivi des transactions Google Analytics et d’améliorer l’analyse de la rentabilité de vos campagnes.

Like it ? Share it !
Benoit Gaillat - Directeur Associé
Author

Diplômé de l’HETIC et spécialisé dans l’e-commerce depuis 2004. Après avoir été Responsable VAD pour le Palais des Thés, Benoit à co-fondé Skeelbox. Il est spécialisé sur le développement du chiffre d’affaires des sites e-commerce, la conversion, et dans l’étude des webanalytics. Il est certifié Google Analytics. Il rédige depuis 2009 le blog info-ecommerce.fr, primé en 2011 par la FEVAD comme le meilleur blog e-commerce, et intervient régulièrement comme conférencier/formateur sur l’acquisition de trafic et la conversion.

Plus d'articles de cet auteur
Stay in touch :
  1. romainboyer dit :

    Salut Benoît, peux-tu partager ton expérience en racontant dans quels cas tu n’as pas 100% des transactions dans Google Analytics ?

    Je n’ai pas 100% mais un pourcentage très proche simplement parce que la page de paiement redirige immédiatement vers la page de confirmation de paiement (page traquée on-site) lorsque le client clique sur « payer » (du moins c’est ce que j’avais avec Prestashop avant de passer à DemandWare ou l’interface de paiement est maintenant directement on-site).

    Merci

  2. jb gabellieri dit :

    Un exemple tout bête pour sortir un peu du ecommerce : une appli mobile avec achat inapp mal sécurisée ou avec des annulations de paiements par la plateforme (courant sur FB par exemple). Avec Universal Analytics c’est d’ailleurs d’autant plus simple d’envoyer ces annulations en php, par exemple à la réception des callback d’annulation.

  3. Celine Montheard dit :

    Très bon à savoir ! Cette astuce nous aurait bien aidés l’an passé, nous avions des différences substantielles de tracking des commandes sur notre implémentation Magento -> Ogone -> Magento.

  4. romainboyer dit :

    +1 🙂

  5. romainboyer dit :

    Bonjour Céline, aviez-vous une redirection automatique après paiement ou passiez-vous par une page de confirmation Ogone avant de retourner au site ?

  6. Benoit Gaillat dit :

    Typiquement un prestataire de paiement un peu « oldschool » (certaines banques par exemple) ou la redirection est impossible en automatique. Sur la majorité des clients de l’agence les transactions sont ok entre 90 et 99% mais pour certains on approche (avant correction) les 70 %, même 50% parfois, là c’est assez grave.

  7. Celine Montheard dit :

    J’ai envie de dire « les 2 mon capitaine » !
    Ogone commençait par afficher sa page de confirmation « succès paiement » puis redirigeait automatiquement vers notre page de confirmation commande sur le site. Cela donnait un process assez long au final.
    Cela dit cela fonctionnait pas trop mal pendant un certain temps (<1% de commandes manquantes dans GA), mais du jour au lendemain les écarts ont augmenté de façon substantielle et nous avons passé beaucoup de temps à chercher comment limiter la perte d'info.

  8. romainboyer dit :

    wow.. merci

  9. garifuna13 dit :

    Pratique pour les commandes par chèque non honorées également ! Je pense que cet article va en aider quelques-uns, merci 😉

  10. Benoit Gaillat dit :

    Merci, attention juste à pas mettre le bazar dans ton analytics et à garder un profil vierge juste « au cas ou »:)

  11. jb gabellieri dit :

    Dans le cas d’une annulation à posteriori effectuée par un webservice, on peut dans une optique de perfection, utiliser UniversalAnalytics, de manière à envoyer l’événement d’annulation avec le même ID d’user que celui qui a passé la commande = l’annulation parfaite. Logiquement on est cependant sensé utiliser un identifiant anonyme, mais bref, ça fonctionne très bien dans la pratique. 😉

  12. Benoit Gaillat dit :

    Ok, je vais tester avec universal analytics. Merci !

  13. romainboyer dit :

    et vous avez trouvé quoi ? pour expliquer la perte d’info ?

  14. Thierry Kolton dit :

    Un autre moyen est d’utiliser un outil tel UserReplay (sans Tags) qui enregistre tous les parcours Web et qui permet de définir des marqueurs liés à des événements précis et donc de retrouver les commandes réelles, les annulations, etc…..

  15. Celine Montheard dit :

    On n’a malheureusement jamais réussi à expliciter la raison exacte de cette perte soudaine. En travaillant un peu sur l’intégration Ogone et le tracking GA on a réussi à la faire baisser jusqu’à 15%. Pour espérer atteindre les 0% de perte, on regardait plutôt du côté de solutions alternatives du type passer au paiement intégré sur le site, ou changement du mode de tracking.
    J’ajouterai que nous avions consulté des experts GA qui ne nous ont jamais pointé vers la solution détaillée dans cet article : je saurai à qui faire appel si une problématique similaire se présente à nouveau !

  16. Quentin P dit :

    Bonjour je suis a la recherche de conseils ou d’un prestataire pour implémenter proprement un tracking Universal Analyics sur un Prestashop avec deux pages de remerciement différentes : une pour la CB et une pour Paypal.

  17. Bonjour,
    Cette option pré-suppose que la commande est insérée dans le BO avant le débranchement chez le partenaire financier. Ma solution e-commerce (Zencart fork d’OsCommerce recustomisée) est conçue différemment : elle ne committe la commande que lors de l’IPN (Instant Payment Notification) de Paypal. L’IPN Paypal est un processus Paypal qui appelle une URL de mon site déclenchée par Paypal avec une gestion du timeout (soumission par Paypal pendant 4 jours à intervalle de plus en plus espacé tant que l’URL du site marchand ne retourne pas un code 200 = OK). Donc je vais avoir du mal à éliminer les abandons de commande qui n’existeront jamais dans mon BO. Pire, j’ai peur d’avoir un cumul de stats (je ne sais pas comment GA réagit) sur un même n° de commande (une commande annulée suivie d’une commande validée avec un même n° de commande). Je vais essayer et mettre sous surveillance. Est ce que les solutions actuelles (Presta / Magento) créent systématiquement la commande au préalable ? Dans quel statut se trouve les commandes dont le paiement n’a pas été effectué ? En espérant avoir bien compris …

  18. Sylvain@achat vin bio dit :

    en fait j’ai essayé de déplacer le script GA sur la page précédant la confirmation de la commande. Et Zencart est tellement bien foutu que cela impacte l’affichage et les valeurs transmises. Donc machine arrière toute. Il serait temps que je songe à migrer ;o)

  19. Bruno dit :

    Comment tu renvois en php une information à Google Analytics ? Tu peux pas exécuter du code javascript faut le passage d’un browser non ?

  20. Vincent dit :

    La perte d’info arrive lorsque le client n’arrive pas sur la page success, ce qui peut arriver de plusieurs manières : le client quitte la page de paiement (ogone, banque, ..) avant d’être redirigé par exemple.
    Universal Analytics permet la communication de serveur à serveur, ce qui permet de ne plus être dépendant de ces aléas. Une extension magento qui gère cela : http://restaurant.web-cooking.net/seo/magento-google-universal-analytics.html

  21. Petit update sur cet article, avec le protocole de mesure on peut mesurer le Ca back office et Cross Canal de façon très simple . Je bosse sur l’article qui va expliquer tout ça

  22. Bastien dit :

    Bonjour,

    Merci Benoît pour cet article très clair. J’ai le pb sur un client MAgento où environ 30% des commandes ne passaient pas. Utilisant Payzen, ces gens là ne reviennent a priori pas sur le site donc pas d’evt envoyés à analytics de finalisation de la commande. Très problématique pour le suivi des sources de revenu (naturel/adwords/facebook/…)

    Je vais mettre en oeuvre ta solution.

    Je suis par contre étonné qu’aucun plugin Magento/prestashop ne propose les modifs que tu suggères (envoi analytics en pré paiement et ajout du script sur le bouton d’annulation de la commande en BO). Peut être un truc à développer.

  23. Bastien : il y a des plugin maintenant qui font ça. Il y a même plus simple : passer par le protocole de mesure et envoyer les transactions directement depuis le back office. Nous n’avons pas encore écrit l’article sur le sujet mais on va y travailler !

  24. Axel dit :

    Bonjour,
    Merci pour cet article, mais j’aurais une question de non expert : comment fait-on pratiquement pour que le code de la transaction soit envoyé sur la page de paiement ? Quelles sont les manip à réaliser ?
    Merci 🙂

  25. @Axel : il faut l’insérer sur le code HTML de la page . Sur Prestashop ou Magento c’est souvent dans les fichiers templates du site donc.

Laisser une réponse