Lorsque l’on programme des évènements, pour Google Analytics, l’on ne cherche, généralement, qu’une mesure précise de l’interaction des utilisateurs d’un site avec les principaux contenus proposés.
Les rapports disponibles, par défaut, donnent un grand nombre d’informations, quant à la pertinence de ce contenu. Seulement, chaque site ayant ses propres objectifs, devra les tracer par évènements.
Dès lors, l’ajout d’évènements permettra de mesurer les actions au clic, l’envoi de formulaire, la profondeur de défilement des pages… La simplicité de leur programmation et l’efficacité de leur mesure amènent un grand nombre de sites à développer l’analyse des clics via Analytics.
Tracer les catégories du menu les plus cliquées semble particulièrement intéressant pour améliorer la navigation des utilisateurs. Compter les créations de compte, les inscriptions aux newsletters, permet aussi de créer des objectifs sur évènements et mesurer financièrement l’implication d’un internaute, donc sa valeur réelle.
Outre la nécessité d’avoir une arborescence efficace, dans l’organisation de ses évènements pour que la lecture statistique soit possible, claire et utile, il faut également bien penser l’utilité de ses évènements.
En effet, certaines actions mesurées, ne sont pas forcément preuves d’une volonté d’interaction d’un internaute sur un site. Les remonter apporte des informations qui peuvent être très utiles pour l’analyse, mais aussi provoquer des pertes ou de mauvais calculs de la part de Google.
La principale perte concerne le taux de rebond. Sa définition par Google correspond à la vue d’une page de destination d’un site web, qu’un internaute va quitter sans avoir interagit avec elle.
Le simple affichage de la balise Analytics, de l’envoi d’un hit de page vue déclenche la session. Si aucun autre hit n’est compté dans cette session, elle entre dans le calcul du taux de rebond.
A contrario, deux hits successifs dans une même session annulent son taux de rebond. Cette donnée est cependant très importante, pour constater l’intérêt du contenu pour les visiteurs. Un taux faible montrera sa forte adéquation avec les attentes et les recherches des utilisateurs. Un taux fort sera plus certainement la marque d’un faible attrait du site.
Le problème des évènements c’est qu’ils peuvent déclencher un hit. Lorsqu’ils sont programmés, et le plus souvent, l’interaction est comptée. Beaucoup pensent qu’il est préférable qu’elle le soit. Peut-être pensent-ils que refuser son comptage comme interaction ne donnerait aucun résultat dans la vue des évènements sur Analytics.
Or ce comptage n’a qu’une utilité, celle de considérer le hit envoyé comme une interaction susceptible d’annuler le taux de rebond.
Un clic sur un bouton, un menu, l’envoi d‘un formulaire annulent logiquement le rebond, dans la mesure où la portée du clic permet un lead ou l’ouverture de différentes pages (donc annulation de facto du rebond pour ladite session).
Mais d’autres évènements, concernant plutôt l’affichage que le clic, peuvent, eux, perturber la vision réelle de ce rebond. La mesure de la profondeur de défilement en est l’exemple le plus frappant.
Sauf à considérer que voir l’intégralité d’une page constituerait un engagement de l’internaute, le comptabiliser peut tout simplement anéantir le rebond. Sur la plupart des sites aujourd’hui, les pages sont dynamiques. Leur longueur dépend de la quantité de contenu. Or des pages intermédiaires peuvent être si courtes, qu’elles déclenchent immédiatement un hit de scroll.
Imaginons qu’un tel évènement ait été programmé, se déclenchant à 50% et 100%. Sur une page sans grand contenu, il est alors probable qu’un hit soit immédiatement envoyé, au chargement de la page, sans la moindre action de l’internaute, simplement parce que cette page est trop courte pour nécessiter un scroll avant l’envoi du hit. Le taux de rebond de cette page serait nul, quand bien même elle ne déclencherait aucun autre hit et serait en réalité une page principale de sortie.
Un hit ne découlant d’aucune action réelle de l’internaute devrait alors ne pas être comptabilisé comme une interaction, surtout s’il ne concerne que l’affichage et non le clic.
Un simple oubli dans la configuration fera grandement baisser le taux de rebond, donnant une impression faussée de l’intérêt du site. Dans certains cas, se tromper peut permettre à de mauvais consultants, de tricher sur l’impact réel de leurs actions et optimisations.
Aussi, lors de la programmation d’un évènement, il est indispensable de se poser la question de l’utilité de le comptabiliser ou non, de sa portée exacte de la mesure recherchée, pour éviter de fausser l’analyse globale.
Lorsque l’on programme des évènements, pour Google Analytics, l’on ne cherche, généralement, qu’une mesure précise de l’interaction des utilisateurs d’un site avec les principaux contenus proposés.
Les rapports disponibles, par défaut, donnent un grand nombre d’informations, quant à la pertinence de ce contenu. Seulement, chaque site ayant ses propres objectifs, devra les tracer par évènements.
Dès lors, l’ajout d’évènements permettra de mesurer les actions au clic, l’envoi de formulaire, la profondeur de défilement des pages… La simplicité de leur programmation et l’efficacité de leur mesure amènent un grand nombre de sites à développer l’analyse des clics via Analytics.
Tracer les catégories du menu les plus cliquées semble particulièrement intéressant pour améliorer la navigation des utilisateurs. Compter les créations de compte, les inscriptions aux newsletters, permet aussi de créer des objectifs sur évènements et mesurer financièrement l’implication d’un internaute, donc sa valeur réelle.
Outre la nécessité d’avoir une arborescence efficace, dans l’organisation de ses évènements pour que la lecture statistique soit possible, claire et utile, il faut également bien penser l’utilité de ses évènements.
En effet, certaines actions mesurées, ne sont pas forcément preuves d’une volonté d’interaction d’un internaute sur un site. Les remonter apporte des informations qui peuvent être très utiles pour l’analyse, mais aussi provoquer des pertes ou de mauvais calculs de la part de Google.
La principale perte concerne le taux de rebond. Sa définition par Google correspond à la vue d’une page de destination d’un site web, qu’un internaute va quitter sans avoir interagit avec elle.
Le simple affichage de la balise Analytics, de l’envoi d’un hit de page vue déclenche la session. Si aucun autre hit n’est compté dans cette session, elle entre dans le calcul du taux de rebond.
A contrario, deux hits successifs dans une même session annulent son taux de rebond. Cette donnée est cependant très importante, pour constater l’intérêt du contenu pour les visiteurs. Un taux faible montrera sa forte adéquation avec les attentes et les recherches des utilisateurs. Un taux fort sera plus certainement la marque d’un faible attrait du site.
Le problème des évènements c’est qu’ils peuvent déclencher un hit. Lorsqu’ils sont programmés, et le plus souvent, l’interaction est comptée. Beaucoup pensent qu’il est préférable qu’elle le soit. Peut-être pensent-ils que refuser son comptage comme interaction ne donnerait aucun résultat dans la vue des évènements sur Analytics.
Or ce comptage n’a qu’une utilité, celle de considérer le hit envoyé comme une interaction susceptible d’annuler le taux de rebond.
Un clic sur un bouton, un menu, l’envoi d‘un formulaire annulent logiquement le rebond, dans la mesure où la portée du clic permet un lead ou l’ouverture de différentes pages (donc annulation de facto du rebond pour ladite session).
Mais d’autres évènements, concernant plutôt l’affichage que le clic, peuvent, eux, perturber la vision réelle de ce rebond. La mesure de la profondeur de défilement en est l’exemple le plus frappant.
Sauf à considérer que voir l’intégralité d’une page constituerait un engagement de l’internaute, le comptabiliser peut tout simplement anéantir le rebond. Sur la plupart des sites aujourd’hui, les pages sont dynamiques. Leur longueur dépend de la quantité de contenu. Or des pages intermédiaires peuvent être si courtes, qu’elles déclenchent immédiatement un hit de scroll.
Imaginons qu’un tel évènement ait été programmé, se déclenchant à 50% et 100%. Sur une page sans grand contenu, il est alors probable qu’un hit soit immédiatement envoyé, au chargement de la page, sans la moindre action de l’internaute, simplement parce que cette page est trop courte pour nécessiter un scroll avant l’envoi du hit. Le taux de rebond de cette page serait nul, quand bien même elle ne déclencherait aucun autre hit et serait en réalité une page principale de sortie.
Un hit ne découlant d’aucune action réelle de l’internaute devrait alors ne pas être comptabilisé comme une interaction, surtout s’il ne concerne que l’affichage et non le clic.
Un simple oubli dans la configuration fera grandement baisser le taux de rebond, donnant une impression faussée de l’intérêt du site. Dans certains cas, se tromper peut permettre à de mauvais consultants, de tricher sur l’impact réel de leurs actions et optimisations.
Aussi, lors de la programmation d’un évènement, il est indispensable de se poser la question de l’utilité de le comptabiliser ou non, de sa portée exacte de la mesure recherchée, pour éviter de fausser l’analyse globale.