Le taux de rebond d’Analytics ne sert à rien : changez-le!
Je vais en faire bondir plus d'un, mais le taux de rebond de Google Analytics ne sert strictement à rien. Pire encore, il fausse vos statistiques et vous induit en erreur !
Pourquoi ? Parce qu'il est un doublon de la variable "visites à une page", et parce qu'il considère au même niveau une visite d'une page pendant 2 secondes ou pendant 5 minutes. Hors ces deux cas sont très différents du point de vue de l'efficacité de votre site.
Heureusement, on peut modifier facilement la manière dont Google Analytics gère le taux de rebond.
Tout savoir sur le taux de rebond
Qu'est ce qu'un rebond ?
Le taux de rebond, c'est le taux de visites à une page. Il se calcule au niveau d'une page, par source de trafic, par campagne, par mot clé, par affilié, ...
En résumé, cela mesure le nombre de visites qui se sont arrêtés prématurément. C'est un indicateur clé sur n'importe quel site Internet : plus il est élevé, moins le site correspond aux besoins des visiteurs, et moins il a y de chances de générer du business.
Normalement, un taux de rebond élevé signifie que la page d'entrée du visiteur n'est pas pertinente. C'est vrai, mais c'est faux..
Pourquoi le taux de rebond d'Analytics ne sert à rien
C'est un raisonnement faussé que nous livre Google Analytics et les autres outils de Webanalytics. Il me suffit de prendre quelques exemples pour le prouver :
- Une page de contact peut avoir un taux de rebond très élevé : j'arrive dessus, je récupère les coordonnées et je pars.
- La page d'accueil car le visiteur connaît déjà les articles plus anciens, et repart s'il n'y a pas de nouveautés. C'est typiquement le cas de blogs qui s'arrêtent de publier pendant plusieurs jours/semaines.
- Je suis un site de design qui publie des tutoriaux pour réaliser des trucs géniaux (comme créer une page plan de site sur WordPress). Les visiteurs vont conserver la fenêtre du navigateur ouverte longtemps pour reproduire le tutoriel et n'iront pas forcément sur une seconde page.
J'appelle cela des faux rebonds. Certes, dans ces trois cas, l'internaute aurait pu ou aurait dû aller plus loin, mais il est vital de différencier ceux qui partent en moins de 5 secondes et ceux qui partent après 5 minutes.
En plus, Google Analytics comptera systématiquement une visite avec rebond comme une visite de 0 secondes... Pas besoin de vous faire un dessin pour expliquer à quel point cela va fausser les statistiques de votre site... Il vous faut donc le changer au plus vite !
Le taux de rebond d'Analytics doit être modifié !
Par contre, prenons aussi un contre exemple : je suis un site E-commerce. Un visiteur arrive sur une page produit, y reste 5 minutes et repart. Dans ce cas-là, j'aurai tendance à dire qu'il y a un rebond réel puisque la finalité d'une boutique n'est pas de présenter un produit, mais bel et bien de vendre.
Définir le bon taux de rebond
La méthode
La méthode pour modifier le taux de rebond d'Analytics est simple : une ligne de code à ajouter dans votre code analytics. Définissez ensuite le nombre de secondes directement dans le javascript pour faire varier la durée au bout de laquelle vous considérez une visite comme un faux rebond.
Pour le code Analytics traditionnel, je ne donnerais pas la solution. Pourquoi ? Parce qu'il vous faut migrer vers le nouveau code (l'ancien n'est d'ailleurs plus disponible dans l'interface Google Analytics...)
Pour le code Analytics asynchrone : ajoutez puis ajustez la ligne SetTimeout.
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXXX-XX']);
_gaq.push(['_trackPageview']);
setTimeout('_gaq.push([\'_trackEvent\', \'Pas de rebond\', \'Plus de 060 seconds\'])',60000);
(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); })(); </script>
Retrouver l'ancien taux de rebond
La méthode donnée ci-dessus n'est évidemment pas de moi. Mais ceux qui ont trouvé cette solution ne sont pas allés assez loin. Comme vous pouvez le constater, cela va modifier de manière définitive votre taux de rebond. Impossible de faire marche arrière, sauf avec un double code Google Analytics sur chaque page (mais je ne vous le conseille pas).
Il existe heureusement un moyen pour retrouver le taux de rebond initial et de le comparer avec votre nouveau taux de rebond. Il va falloir jouer sur les segments avancés situés en haut à droite.
Segments avancés de Google Analytics
Cliquez sur la liste déroulante, puis sur "Créer un segment avancé" à gauche. Le critère sera Pages vues => Egal à => 1
Créez un segment avec Pages Vues = 1
Ensuite, sélectionnez votre segment avancé et comparez-le avec le segment "Toutes les visites". Utilisez la ligne % du total pour connaître l'ancien taux de rebond dans chaque rapport.
Votre nouveau taux de rebond
Et vous allez avoir des surprises. Sur SeoMix, je passe de 70% à 13% de taux de rebond global, et de 32% à 25% pour le taux de rebond de ma page d'accueil, avec un timeout à 20 secondes. Vous pourrez toujours avoir un accès direct à votre ancien taux de rebond global en consultant l'onglet Nombre de page visitées...
Choisir le bon timing du taux de rebond
A vous de choisir le bon timing pour la lecture de votre page. Plus vos articles seront longs, plus il faudra l'allonger. Et là, c'est un peu au petit bonheur la chance comme on dit.
On peut cependant envisager de modifier le timing de manière dynamique. Par exemple, on récupère dans une variable le nombre de mots d'un article. Selon les différents articles que j'ai pu lire, on estime entre 220 et 240 mots par minute, soit entre 3,5 et 4 mots par seconde. Ça donnerait par exemple des taux de rebond de 14 à 16 secondes pour 50 mots, 28 à 32 secondes pour 100 mots ou encore 56 à 64 secondes pour 200 mots.
Et une fois de plus, vous pouvez vous baser sur un code très utile, qui permet dans le loop de WordPress de renvoyer le nombre de mots. La première ligne renvoi le nombre total de mots, la deuxième le nombre total sans les tags html. En ce qui me concerne, la variation entre les deux codes est énorme (de 2500 à 1500 sur certains articles).
<?php echo str_word_count(strip_tags($post->post_content));?>
Libre à vous d'utiliser ce chiffre pour adapter votre timeout de taux de rebond.
En ce qui me concerne, je l'ai défini de cette manière : j'ai ajouté à mon code plusieurs timeout, de 20 à 180 secondes par tranche de 20 secondes. Et j'ai regardé les données pour voir quel timing serait le plus pertinent. En ce qui me concerne, voilà ce que ça donne :
Taux de rebond selon la durée de visite
Ensuite, j'ai fait une autre étude. J'ai pris la liste des mots clés organique. J'ai ensuite mis en corrélation le temps passé, les mots clés et les contenus des articles sur lesquels ils ont arrivé sur SeoMix. Et j'ai donc tenté de voir à partir de quelle durée de sortie une visite était crédible. En ce qui me concerne, je pense régler le timeout du taux de rebond à 40 secondes.
Les défauts du nouveau taux de rebond
Bien entendu, la méthode ne sera jamais parfaite. Je vais là aussi prendre deux exemples :
- J'ouvre le site, mais suis dérangé par une tierce personne. Je laisse mon navigateur ouvert. Quand je reviens, je le ferme. C'est un rebond réel qui s'affiche dans les statistiques d'Analytics comme un non rebond.
- Je navigue sur pas mal de site. J'ouvre donc 3 onglets. Je vais lire chaque onglet l'un après l'autre. Là aussi, même cas de figure.
Autre défaut, la méthode va compter un timeout pour chaque page visitée. Donc si le visiteur voit une page, pas de soucis. S'il en voit deux, il y aura deux évènements pour une seule visite... Il faut donc regarder la colonne évènements uniques, et pas les évènements totaux (donc regardez la deuxième colonne). Malgré ces défauts, je trouve que le jeu en vaut la chandelle. Reste à définir le bon timing pour un rebond.
N'hésitez pas si vous avez des remarques ou des critiques à faire. J'avoue que je vais à tâtons pour mes différentes modifications et optimisations de Google Analytics.
Mes sources :
- Définir le taux de rebond réel dans Analytics (Referenceur.ma)
- The Real Bounce Rate (Padicode)
- Qu'est ce que le taux de rebond ? (Ramenos Blog)
- Display Post Word Count (WpRecipes)
Voici les thématiques abordées par Le taux de rebond d’Analytics ne sert à rien : changez-le!:
- Filtre Google Analytics -
- Google Analytics -
- Moteur de recherche Google - Rebond -
- ROI -
- Taux de rebond -
- Webanalytics
11 commentaires sur Le taux de rebond d’Analytics ne sert à rien : changez-le!
Le juge - Le 17 juin 2010, 21:45
superbe article, Bookmarké et qui va de plus etre mis en place avec nes comptes analytics…
Beau boulot! et merci pour le code!
Nicolas - Le 23 juin 2010, 11:30
Très pertinent, j’avoue ne jamais avoir penser à mettre cela directement dans mes analytics, ça sera je pense plus claire et simple, pour définir ce fameux taux de rebond négatif ou positif.
Merci !
kinaze - Le 24 novembre 2010, 16:19
Merci pour cet article! C’est un excellent complément à cet autre article à propos de la moyenne optimale d’un taux de rebond: http://bit.ly/anRrIE . Je vous invite finalement à utiliser le “plugin” gaAddons que vous trouverez sur http://gaaddons.com/. Celui-ci vous permettra de définir rapidement et simplement votre taux de rebond réel avec la méthode asynchrone. Fortement recommandé!
Masamune - Le 24 décembre 2010, 13:22
Je vais enfin faire chuter ce taux de rebond a 70+% x’).
Un grand merci !
Par contre je n’ai pas trop compris pour l’adaptation dynamique à WordPress, comment différencier la page d’accueil d’une page avec un article, puisque dans une grand majorité des thèmes le code GA est inclus dans une page header.php, elle même incluse sur la page d’accueil et sur les articles en solo..
Si on doit faire du cas par cas en dynamique y’a plus vraiment d’intérêt ^^’. Ou alors tester l’url dans le javascrit (si c’est la page d’accueil, rebond fixe ?)
Daniel Roch - Le 25 décembre 2010, 19:42
Les thèmes de WordPress permettent de gérer des variables en php à inclure ou non dans les codes javascripts. Il existe notamment des fonctions toutes faites pour détecter où est le visiteur (if is_category, if is_single, …).
Masamune - Le 25 décembre 2010, 23:32
Yep j’ai vu ca en mettant en place le fil d’Ariane en dur comme tu le conseilles.
Ça marche impeccable d’ailleurs, bravo et encore merci ;)
Masamune - Le 28 décembre 2010, 01:28
En quelques jours je suis passé de 80% de taux de rebond a 40-50%.
Ça me parait déjà plus réaliste :)
Encore merci à toi !
Cédric - Le 28 janvier 2011, 11:57
Je vais tenter de mettre en action les paramètres que tu délivres :)
Est-ce que Google aurait prit en compte ce mauvais fonctionnement du taux de rebond et aurait fait le nécessaire pour corriger le tir ?
Rick44 - Le 04 février 2011, 06:31
Bonjour,
Un article bien ficelé et qui nous apprend vraiment quelque chose d’intéressant contrairement à d’autres.
De toutes façons les statistiques, on peut leurs faire dire ce que l’on veut et je pense que trop de stats peuvent nous induire en erreur.
Et comme tu le dis si bien dans ton article, si en plus analytics fausse les chiffres, ce n’est pas la peine de focaliser la dessus.
Personnellement, je ne vais plus regarder mon taux de rebond de la même manière.
En fait je préfère me baser sur les commentaires plutôt que sur le taux de rebond, c’est bien plus parlant.
Qu’en pensez-vous ?
Amicalement,
Rick44
Jguiss - Le 30 novembre 2011, 10:24
Merci pour ces infos, exactement le Tx de rebond est à prendre avec précaution…
Je ne sais pas si je prendrais la peine de faire toutes tes modifications mais peut être vais je essayer sur un site pour voir. Merci pour l’article :)
Agence Axekap - Le 29 décembre 2011, 11:20
Excellent article. Jusqu’à maintenant j’utilisais le marquage d’événements par ex un téléchargement pdf, un clic sur un lien externe, le lancement d’une vidéo, etc… mais pas encore un événement au bout d’un temps programmé. Les inconvénients que j’entrevoie sont l’aspect définitif des modifications sur le marqueur principal GA sur l’historique des données et bien évidemment des soucis pour le benchmarking entre sites.