Les erreurs d’interprétation les plus fréquentes dans Google Analytics (partie 1)

Google Analytics est un formidable outil. Complet, puissant et gratuit, il est indispensable pour tout possesseur de site web qui souhaite savoir ce qui se passe sur son site et qui souhaite améliorer ses performances en l’adaptant toujours plus à ses visiteurs clé. Si dans l’ensemble, un utilisateur novice ou intermédiaire peut avoir une idée assez correcte de pas mal de choses grâce aux nombreux rapports standards délivrés par l’outil, certaines métriques ne reflètent pas forcément ce que leur nom laisse supposer et certains rapports peuvent prêter à confusion, entraînant des erreurs d’interprétation qui peuvent parfois être fâcheuses. Voyons les plus fréquentes.

Fréquence / Nombre de sessions

frequence-nombre-de-sessionsLe nombre de sessions indiquées provient des cookies implantés dans le navigateur de vos visiteurs. Ceux-ci gardent la trace de chaque visite effectuée sur votre site. L’intérêt du rapport est de voir la fidélité de vos visiteurs.

Dans l’exemple ci-contre, 3558 visiteurs ont fait une première visite durant la période étudiée. Si vous vérifiez le rapport Nouveaux vs connus, vous pouvez d’ailleurs voir que ce nombre correspond bien au nombre de nouveaux visiteurs.

Mais c’est ici qu’il faut faire attention. Ca ne signifie pas que 3558 visiteurs ont fait uniquement 1 visite sur votre site. Cela signifie qu’ils ont fait leur première visite sur cette période. Mais ils peuvent l’avoir visité 3 fois sur cette même période. Et si c’est le cas, ils vont également être comptabilisés dans la ligne des visiteurs à 2 sessions et dans celle des visiteurs à 3 sessions. C’est ce que l’on appelle la duplication.

Le problème vient de la manière dont google Analytics va comptabiliser les sessions. Peut être qu’une majorité de visiteurs ont fait 2 visites et qu’une petite poignée seulement sont revenus beaucoup plus. On ne peut pas savoir le nombre de visites par nombre d’utilisateurs. C’est pourtant l’interprétation que la majorité des gens font de ce rapport.

Pour savoir si les tendances données par ce rapport sont justes et si vous pouvez vous appuyer dessus, vous allez devoir vérifier s’il est soumis fortement à duplication ou pas. Pour ce faire, vérifiez si le nombre total de sessions pour la période est proche du nombre d’utilisateurs. Si c’est le cas, vous pouvez faire confiance au rapport. Les chiffres, sans être parfaits, vous retranscrivent la vraie tendance. Dans le cas contraire, ce rapport est faussé et je vous conseille de ne pas baser vos analyses dessus.

Dernière chose concernant ce rapport. Jusqu’à 8 visites, une ligne est égale à une visite supplémentaire. Mais à partir de 9, on groupe. 9-14, 15-25, etc…
Quasiment pour chaque site, on a l’impression d’avoir un groupe de visiteurs ultra fidèles qui reviennent de nombreuses fois dans ces tranches la (souvent de 9 à 14 d’ailleurs).

Il s’agit d’une illusion créée par la duplication. Si un visiteur a effectivement fait 14 visites, 5 sessions seront comptabilisées pour lui tout seul dans la ligne 9-14. Si la ligne était éclatées en lignes d’une seule visite supplémentaire, la tendance suivrait la même décroissance que les lignes du dessus.

Nombre de sessions par page

Imaginons que vous vouliez évaluer les performances des 10 meilleures pages de votre site. Pour une période donnée, vous souhaitez connaître le nombre d’utilisateurs qui les ont vues, le nombre de sessions dans lesquelles elles ont été incluses et le nombre de fois ou elles ont été vues.

Le nombre d’utilisateurs vous donne le chiffre et la part que cela représente par rapport au nombre total d’utilisateurs sur la période. Le nombre de sessions dans lesquelles la page est incluse est à comparer au nombre d’utilisateurs. Si le nombre de sessions est beaucoup plus élevé cela signifie que globalement la page est vue une nouvelle fois quand les utilisateurs reviennent. Et vice versa. Ce sont donc des insights intéressants.

Ces données n’étant pas accessible dans les rapports standards, vous créez donc un rapport personnalisé

rapport-top-pages-sessions

C’est alors que vous remarquez quelque chose de bizarre. Pour certaines pages, vous constatez un nombre de sessions très inférieur au nombre d’utilisateurs, ce qui techniquement est impossible puisqu’un utilisateur fait au moins une session. Explications…

Pour bien comprendre, il faut saisir la manière dont Google comptabilise les métriques. Lors d’une session, Google va compter une page vue pour chaque page affichée, y compris si l’on voit plusieurs fois la même. Il va compter une consultation unique pour chaque page vue indépendamment du nombre de fois on on l’aura vue. Il va compter une entrée au moment ou l’on voit la première page et une sortie au moment on l’on voit la dernière page. Jusqu’à la rien d’anormal.

Maintenant LA question. Comment Google comptabilise les sessions ? Et bien, la réponse est simple. Une session est comptabilisée une seule fois lors de l’ouverture de la première page de cette session.

La logique voudrait que lors de l’édition d’un rapport tel que celui-qui nous intéresse, Google attribue une session à chacune des pages (même si en définitive, le total serait toujours une seule session). C’est d’ailleurs ce qu’il fait pour les utilisateurs. Mais ce n’est pas le cas. En fait, la métrique sessions reflète les entrées pour la page (à quelques exceptions près). C’est une incohérence, c’est comme ça. En conséquence, vous ne devez pas utiliser la métrique session lorsque vous éditez un rapport sur les pages.

Mais comment donc connaître le nombre de sessions dans lesquelles nos top pages ont été incluses ? Et bien vous devez regarder à la place le nombre de consultations uniques. En effet, cette métrique est comptée une seule fois pour chaque page dans une session. Elle reflète donc le nombre de sessions dans lesquelles la page a été vue.

rapport-top-pages-consultations-uniques

Temps moyen par page / Durée moyenne des sessions

Toujours dans l’optique d’analyser les performances de vos top pages, cette fois-ci en terme d’engagement, vous souhaitez maintenant voir la durée moyenne que les visiteurs passent sur celles ci et la durée moyenne des sessions dans lesquelles elles sont inclues. Vous pourrez ainsi savoir si les utilisateurs prennent le temps de les lire comme il faut et de voir si elles sont vues par des visiteurs qui restent longtemps, et donc intéressés.

Vous faites de nouveau un rapport personnalisé et encore une fois, les données vous paraissent bizarres. Comment la durée moyenne des sessions peut elle être inférieure au temps moyen passé sur la page… ?

rapport-temps-pages

Pour répondre à cette question, vous devez comprendre la manière dont Google mesure le temps. En fait, celui-ci ne connaît jamais le temps qu’un utilisateur passe à regarder la dernière page de leur visite sur votre site.

En effet, la durée de consultation d’une page correspond au temps écoulé entre l’entrée sur cette page et l’entrée sur une nouvelle page. Or sur la dernière page, du fait qu’il n’y a pas de page suivante, le temps est inconnu (et donc enregistré à 0) et la durée de session se termine lorsqu’ils ouvrent la dernière page.

Ainsi, pour des sessions ou les utilisateurs ne consultent qu’une seule page (ce que l’on appelle un rebond), la durée de session est de 0. Ce n’est pas parce que Google sait qu’il sont partis immédiatement, c’est simplement qu’il ne sait pas mesurer la durée avant que l’utilisateur ne parte. Dans ce cas, le système considère ce manque de donnée comme signifiant 0.

Cela peut être 2 secondes ou 10 minutes, Google ne sait pas donc c’est un 0. Est ce que l’utilisateur a lu la page ? Peut être, peut être pas. Tout ce que nous savons c’est qu’il n’a pas regardé d’autres page sur votre site durant les 30 minutes suivantes (durée d’une session par défaut). Devez vous considérer qu’ils sont partit sans lire la page ? Non. Il y a d’ailleurs quelques techniques que l’on peut utiliser pour voir si les visiteurs lisent nos pages ou s’ils rebondissent réellement.

Il est par exemple possible de définir plusieurs événements basés sur le taux de scroll de la page. Par exemple un événement si l’on arrive à la moitié de la page, un pour la fin d’un article et un pour l’extrême bas de la page. En utilisant cette technique pour ce blog, j’ai découvert que pour mes articles (qui ont un taux de rebond moyen aux alentours de 90%), près de 50% des utilisateurs les lisent en entier, 25% en lisent plus de la moitié et 25% rebondissent réellement. C’est beaucoup mieux pas vrai !

Revenons en à la métrique temps moyen passé par page. Si la page n’est pas la dernière de la visite, le temps est mesuré. Si la page est celle de sortie, le temps sur la page est égal à 0.

Google Analytics en tient compte pour calculer le temps moyen par page et supprime l’influence du manque de données pour la page de sortie. Ainsi, il calculera le temps moyen passé sur une page avec la formule : Somme du temps mesuré pour chaque visiteur sur cette page / (nombre de fois ou la page a été vue – nombre de fois ou cette page a été la page de sortie).

Ainsi, si une page n’a pas un taux de sortie élevé, alors le temps moyen sur cette page est plutôt juste et un bon reflet de la réalité. Par contre, si cette page est une porte de sortie régulière, vous ne pourrez pas avoir confiance dans la durée moyenne parce que la moyenne se basera sur une faible portion des utilisateurs totaux.

Parlons maintenant de la durée moyenne de session. Cette métrique n’a pas la même capacité à ignorer l’effet de sortie des pages. Chaque session a une page de sortie, et s’il n’y a pas beaucoup de pages dans la visite, les pertes de temps liées à cette page de sortie peuvent avoir un import fort sur le total. Dans le cas extrême d’un rebond, GA compte une session de 0 seconde.

Pour calculer la durée de session moyenne, Google utilise la formule : Durée moyenne de session = Somme des durées de toutes les sessions / nombre total de sessions. Ce calcul est donc fortement influencé par le manque de mesure de temps des pages de sortie, spécialement pour les sites avec des faibles valeur de pages par session.

Pour cette raison, utiliser la durée de session moyenne comme indicateur de performance n’est pas recommandé vu comme le nombre de pages vues par sessions, le nombre de rebonds et le nombre de sessions peuvent influencer la métrique.

Ainsi, si comme mon site, le votre a un taux de rebond important , la durée de session moyenne est donc faible et bien souvent inférieure au temps moyen par page !

Voila, on s’arrête la pour aujourd’hui. Mais je vous prépare déjà un autre article de la même trempe. On y parlera notamment d’attribution et de trafic direct. Keep in touch !

Nos compétences

specialiste-agree-analyticsChablais Web, Agence certifiée Google Analytics en Haute Savoie s’occupe pour vous du reporting, de l’analyse et de l’interprétation des données issues de Google Analytics.

Vous recevez chaque jour, semaine ou mois (selon votre activité) un reporting qui vous donne des informations, pas des données. Le but est que vous puissiez prendre des décisions éclairées. Notre job est de vous fournir des tableaux de bord d’action. Ainsi, vous comprenez rapidement les performances et vous pouvez lancer des actions.

Pour plus d’informations, n’hésitez pas à nous contacter !

Auteur : Bruno Guyot

Expert en marketing digital & Générateur de business par des campagnes data-driven. J'aide les agences et les entreprises à accroitre leur business par la mise en place de mécanismes de tracking évolués. La récolte des données va nourrir une stratégie digitale et des campagnes à haute performance. Parmi les leviers technologiques utilisés : Analytics, Tag Management, Adwords, Facebook, LinkedIn, Twitter.

15 réflexions sur « Les erreurs d’interprétation les plus fréquentes dans Google Analytics (partie 1) »

  1. Bonjour,

    J’ai moi-même un gros taux de rebond, 60%, avec notamment des pages très populaires à 70% et + qui l’augmente beaucoup.
    J’aimerais bien en savoir plus sur votre technique du
    « Il est par exemple possible de définir plusieurs événements basés sur le taux de scroll de la page. Par exemple un événement si l’on arrive à la moitié de la page, un pour la fin d’un article et un pour l’extrême bas de la page. En utilisant cette technique pour ce blog, j’ai découvert que pour mes articles (qui ont un taux de rebond moyen aux alentours de 90%), près de 50% des utilisateurs les lisent en entier, 25% en lisent plus de la moitié et 25% rebondissent réellement. C’est beaucoup mieux pas vrai ! »

    Merci 🙂

    1. Bonjour,

      J’espérais que quelqu’un me pose la question ! Le principe du tracking de contenu avancé par événements est celui décrit dans cet article. La méthode ne peut toutefois pas être décrite en 2 minutes en commentaire. Toutefois, je comptais en faire un billet. Du coup, disons que je vais le faire en priorité. Je vais poster la suite du présent article début de semaine (à ne pas manquer, encore plus intéressant) et début de semaine suivante je posterai un article sur la méthode complète pour mettre en place les événements et leurs mesures. Et je vous enverrai un email avec le lien de l’article. Vendu ? 😉

      1. Bonjour, avez vous pu écrire le billet sur le paramétrage du tracking de contenu avancé par évenement, pour mesurer le taux de scroll des pages ?

        Merci !

        1. Bonjour,

          Merci pour votre commentaire. Je n’ai pas fais d’article spécifique sur le sujet mais la mise en place est expliquée dans un post que j’ai écris oui. Ici : https://www.bruno-guyot.com/google-tag-manager-v2-le-guide-francophone-le-plus-complet-partie-4.php. Dans ce guide, le tracking du taux de scroll est mis en place sur WordPress par le biais de Google Tag Manager et d’un module Google Tag Manager pour WordPress. La procédure pas à pas y est détaillée 🙂

  2. Bonjour,

    J’ai l’impression que tel que vous le décrivez, le rapport Fréquence / Nombre de sessions se rapproche fortement d’une analyse de cohorte, en tous cas celle proposée actuellement en beta sur GA, basée sur la date d’acquisition.

    Quelles seraient les différences d’usage entre les deux rapports ?

    Merci pour cet article,
    Stéphane

    1. Bonjour Stéphane,

      Les rapports Fréquence / Nombre de sessions et cohortes sont différents. Le premier se base sur des sessions et nous donne le nombre de sessions répétées (1 fois, 2 fois, 3 fois, etc…). Le second se base sur des utilisateurs (en réalité sur un cookie dans un navigateur particulier sur un appareil particulier, à moins d’utiliser une vue User-ID) et nous donne une proportion d’utilisateurs qui reviennent chaque jour, semaine, mois en fonction d’un jour, semaine, mois d’acquisition.

      L’usage du rapport Fréquence / Nombre de sessions. Je pense qu’il faut s’en servir pour les tendances et pour comparer des périodes (la comparaison mensuelle est un classique), des segments (sessions avec transactions, sessions par type d’appareil, sessions en provenance de telle source de trafic, etc…). Ce n’est pas parce qu’on ne peut pas savoir le nombre de visites des utilisateurs qu’on ne peut pas utiliser les tendances et les améliorer. Je te conseille ce post d’Anna Lewis pour aller plus loin à ce propos.

      Pour ce qui est des cohortes (dans le cadre d’une étude de fidélité), l’intérêt que j’y trouve va être de pouvoir voir très vite si la nouvelle fonctionnalité d’engagement que j’ai mis sur le blog tel jour a un impact sur la rétention des utilisateurs dont la première visite se fait à partir de ce jour la par rapport aux utilisateurs dont la première visite s’est faite les jours d’avant. Par exemple… Y a pas mal d’articles sympas sur les cohortes. Pour n’en donner que quelques uns tu as :
      http://www.lunametrics.com/blog/2015/02/06/google-analytics-cohort-analysis/ de Sayf Sharif
      http://cutroni.com/blog/2015/02/06/using-cohort-report/ de Justin Cutroni
      https://megalytic.com/blog/using-the-cohort-analysis-report-in-google-analytics-to-optimize-lead-generation de Megalytics

      Et pour aller plus loin en général sur l’analyse de la fidélité, j’ai apprécié ce post : http://moz.com/blog/customer-loyalty-metrics-google-analytics

      Voilou 😉

    1. Merci Benjamin,

      Et merci pour le complément. Ça fait partie des sources que j’ai utilisées et c’est vrai qu’à tort, je ne fais pas beaucoup de liens vers les sources. Je ne fais pas beaucoup de liens tout court d’ailleurs… Bref! ^^

  3. Bonjour,
    J’ai une question sur le rapport Analyse de flux de visiteur. Si on prend le taux d’abandon d’une page d’accueil, celui ci devrait être égal au taux de rebond de la page. Or ce n’est pas le cas, donc il y a quelque chose qui m’échappe. Se peut-il que les sessions arrivées par la page d’accueil et comptées comme abandons aient pu voir plusieurs pages? Dans ce rapport quelle est la définition de page d’accueil, première interaction, Deuxième interaction etc…
    Merci de votre aide.
    j’ai déjà posé cette question dans le centre aide de GA sans succès

    1. Bonjour,

      Je viens de passer 3 heures à tordre le problème en long en large et en travers. J’ai fouillé partout, testé plein de trucs. Rien n’y fait, je n’ai pas d’explication claire. C’est peut être lié à une différence de scope entre le rapport flux et le rapport page de destination. Le premier est selon moi au scope utilisateur tandis que le second doit être de niveau session. Autre piste, la métrique abandon utilisée dans les rapport flux n’est accessible nulle part ailleurs (y compris pour faire un rapport personnalisé et n’est pas définie dans la documentation sauf erreur). Il serait logique qu’elle calcule autre chose que les sorties ou les rebonds (sinon pourquoi l’appeler autrement?). Bref, un lièvre a été déterré je crois 😉

      1. Bonjour,
        Merci pour votre réponse et désolée pour ma réponse tardive… Je n’avais pas reçu d’alerte quant à votre réponse.
        Après des heures de recherche, j’ai compris d’où venait la différence. Pour info, la solution à mon pb. En fait, on ne peut pas comparer (sauf dans certains cas) taux de rebond et taux d’abandons sur une page d’entrée. Dans mon cas, le taux de rebond ne prend pas en compte le déclenchement des événements (ce que je ne savais pas au moment de l’analyse) car ils sont déclenchés automatiquement et ne comptent pas comme des rebonds. Donc on peut avoir un abandon sur la page d’entrée sans qu’il soit compté comme rebond si déclenchement d’un événement sur cette page. J’ai donc toujours un taux d’abandon supérieur au taux de rebond.

        1. En fait au moment ou l’on crée un évenement, on peut choisir s’il impacte le taux de rebond ou non. Moi j’ai par exemple un événement qui me prévient quand un visiteur a scrollé 25% de la page et qui lorsqu’il se déclenche impact mon taux de rebond. A contrario j’ai aussi un évènement qui se déclenche lorsque l’utilisateur scrolle environ 150px et commence la lecture de la page. Celui la n’impacte pas le taux de rebond. Merci en tout cas d’être revenu partager 😉

  4. Hello Bruno,

    Ce commentaire n’est pas un hasard, je rencontre un cas particulier et j’ai repensé à ton article ! Merci d’ailleurs pour ton travail et ces retours toujours très utiles. Saurais-tu définir précisément l’indicateur (qui pourtant parait simple) de sessions avec événement ? Dans un dashboard personnalisé le nombre de sessions avec événement est plus élevé que le nombre de sessions tout court. Ce qui n’est à priori pas possible.

    Merci beaucoup pour ton aide !

  5. Salut Bruno,
    Merci pour cet article.
    Mon esprit étroit cale sur la différence entre vues uniques et utilisateurs.
    Je comprend bien la différence entre les sessions, les pages vues. Mais entre vues uniques et utilisateurs je ne comprends pas comment une vue unique peut être supérieure au nombre d’utilisateurs… Tu sauras surement m’éclairer…
    Merci d’avance.

    1. J’ai oublié de préciser que je ne voyais pas la différence à la hauteur d’une page. Une page en question sur mon site a plus de vues uniques que d’utilisateurs.
      Je ne parle pas de la globalité d’un site qui pour moi est dans ce cas logique.
      Merci d’avance 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *