Web analytics
 

« Retour à l'accueil du blog

Google Analytics et les iframes : stop au trafic auto-référent !

Posté dans Web analytics par Robin Brébant

Cet article est écrit par Robin Brébant, consultant au sein du pôle Analytics de Converteo. Vous avez des questions à nous poser ? Contactez-nous !

Parmi les erreurs de taggage les plus courantes lorsqu’un site utilise Google Analytics comme outil de web-analyse, les iframes sont très fréquemment cités. Un taggage déficient des iframes entraine des données faussées dans les tableaux de bord : taux de rebond, doublement des visites et des pages vues, écrasement de la source des visiteurs…

Rappel : qu’est-ce qu’un iframe?

Simple rappel : le terme « iframe»  désigne une balise  de code HTML qui permet d’intégrer une page HTML au sein d’une autre page HTML de manière transparente pour l’utilisateur final. La page contenu dans l’iframe peut-être hébergée sur le même domaine, un sous-domaine ou sur un domaine différent. Sans le savoir nous sommes soumis tous les jours aux iframes : tags publicitaires, encarts Facebook, formulaires d’inscriptions, newsletter…

Voici schématiquement le cas classique d’un iframe au taggage déficient, hébergé sur un sous-domaine ou un domaine différent de la page sur laquelle il est appelé :

Mauvais taggage d'un iframe avec Google Analytics

Le problème du taggage des iframes avec Google Analytics intervient dès que vous souhaitez suivre avec le même compte (et donc le même code UA) la page qui héberge l’iframe et l’iframe lui-même : si vous avez du trafic « auto-référent»  (vous voyez votre propre site dans vos sources de trafic) et que vous utilisez des iframes , il est possible que le taggage de vos iframes hébergés sur des sous-domaines ou sur des domaines différents soit en cause.

Dans quels cas faut-il tagguer un iframe ?

Si l’iframe n’est qu’un élément de la page (bloc de connexion par exemple), alors l’iframe ne doit pas être tracké avec une page vue virtuelle sinon votre nombre de page vue sera augmenté artificiellement et si votre iframe se trouve sur une landing page, votre taux de rebond sera complètement faussé. Vous pouvez éventuellement si vous souhaitez connaitre son nombre d’affichage le tracker à l’aide d’un évènement. Cela vous permettra alors de mener des analyses segmentés du type « Quel est le taux de conversion des visites qui incluent le chargement de tel iframe ?» .

En revanche si l’iframe est le coeur de la page alors dans ce cas, il convient de le tracker comme une page vue à part entière. La page qui contient l’iframe ne jouant alors que le rôle de « cadre» , c’est elle qui ne devra pas être trackée. Par exemple, vous incluez un module de réservation en plusieurs étapes via des iframe sur votre site vous êtes dans ce cas là. La marche à suivre est alors celle détaillée ci-dessous.

Comment tagger correctement une page avec un iframe ?

La première chose à faire est d’identifier où est hébergé l’iframe que vous souhaitez intégrer à votre page. Si l’iframe est hébergé sur un domaine ou ou sous-domaine différent de la page sur laquelle il est implémenté il faudra alors mettre en place les fonctions nécessaires au tracking multi-domaines sur les deux pages (_setDomainName() et setAllowLinker())

Une fois cette vérification effectuée et le code générique Google Analytics correctement implémenté avec la fonctionnalité multi-domaines, vous retrouverez ci-dessous le code à implémenter sur l’iframe et sur la page contenant l’iframe :

——————————–

Code générique Google Analytics à utiliser sur la page contenant l’iframe* (en remplacement du code de base)

——————————–

<script type=’text/javascript’>

// IMPORTANT : ce code n’exécute pas la fonction trackPageView() afin d’éviter de faire remonter deux pages vues pour la même page, dans notre exemple la page vue sera exécutée seulement sur  l’iframe qui est l’élément le plus important, la page qui héberge l’iframe n’étant qu’un « cadre»  vide

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXXX']); // A remplacer par le code UA de votre site

// Gestion des sous-domaines et des domaines différents
_gaq.push(['_setDomainName', '.monsite.com']); // A remplacer par le domaine réel ou est hébergé la page
_gaq.push(['_setAllowLinker', true]);

// Code de liaison page – iframe
_gaq.push(function() {
var pageTracker = _gat._getTrackerByName();
var iframe = document.getElementById(’iframe_1‘);
// Attribut ID de l’iframe
iframe.src = pageTracker._getLinkerUrl(’http://www.monsite.com/iframe.html‘);
// Url de l’iframe
});

(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>

——————————–

Code à utiliser pour appeler l’iframe dans la page

——————————–

Afin d’indiquer à Google Analytics une liaison avec un iframe, les paramètres en vert dans le code générique (voir ci-dessus) et lors de l’appel de l’iframe (voir ci-dessous) doivent correspondre. Il s’agit des deux paramètres suivants :

  • ID attribué à la balise iframe
  • URL de l’iframe

Dans cet exemple, la balise finale de l’iframe devrait donc ressembler à ceci :

<iframe id=iframe_1‘ src=’http://www.monsite.com/iframe.html>
</iframe>

——————————–

Code Google Analytics à utiliser sur l’iframe lui-même

——————————–

<script type=’text/javascript’>

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXXX']); // A remplacer par le code UA de votre site

// Gestion des sous-domaines et des domaines différents
_gaq.push(['_setDomainName', '.monsite.com']); // A remplacer par le domaine réel ou est hébergé la page
_gaq.push(['_setAllowLinker', true]);

_gaq.push(['_trackPageview']);

(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>

—————-

Vous avez certainement remarqué dans cet exemple, que la fonction trackPageView() était exécutée une seule fois (sur l’iframe) afin d’éviter d’envoyer deux pages vues à Google Analytics et de dupliquer artificiellement le nombre de pages vues dans Google Analytics.

Dans la mesure du possible il faut éviter d’envoyer deux pages vues pour une même page, dans le cas d’un iframe à vous de choisir quelle information vous souhaitez voir remontrer dans Google Analytics.



Taux de rebond très bas : toujours un bon indicateur pour votre e-commerce ?

Posté dans E-Marketing & trafic qualifié, Web analytics, e-Commerce par Adriano Mucciardi
En moyenne, près de la moitié des internautes qui accèdent à un site internet marchand repartent sans visiter plus qu’une page.
Les visites de ces internautes qui ne consultent  qu’une page du site Internet représentent le trafic  de rebond. Le taux de rebond correspond donc au trafic de visiteurs qui quittent le site Internet ayant consulté qu’une page par rapport au trafic total du site Internet.
En moyenne, le taux de rebond global d’un site Internet BtoC s’adressant au grand public varie entre 30% et 60%.

En moyenne, près de la moitié des internautes qui accèdent à un site internet marchand repartent sans visiter plus qu’une page.

Les visites de ces internautes qui ne consultent  qu’une page du site Internet représentent le trafic  de rebond. Le taux de rebond correspond donc au trafic de visiteurs qui quittent le site Internet ayant consulté qu’une page par rapport au trafic total du site Internet.

En moyenne, le taux de rebond global d’un site Internet BtoC s’adressant au grand public varie entre 30% et 60%.

taux_de_rebond_1

Il convient toutefois, d’analyser le taux de rebond de manière plus détaillée. Généralement, cette analyse s’effectue sous deux angles différents :

-          le taux de rebond par landing page, afin de comprendre l’attractivité d’une page spécifique,

-          le taux de rebond par source de trafic, afin d’analyser la pertinence d’un trafic ciblé par des actions de webmarketing (ex : référencement  naturel, campagne d’affiliation, …)

Etant donné que le trafic de rebond ne contribue pas à l’atteinte des objectifs commerciaux,  la plupart des sites marchands visent à réduire le taux de rebond au maximum. D’ailleurs, il est fréquent que les e-marchands se réjouissent lorsque leur taux de rebond est inférieur à la moyenne du marché.

Le couple « trafic ciblé / landing page » permet de maîtriser le taux de rebond

Afin de réduire le taux de rebond d’un site Internet marchand et d’optimiser la part de visites « utiles » à l’atteinte des objectifs e-commerce, les webmarketeurs travaillent notamment sur la qualité des landing pages (attractivité commerciale, ergonomie et design) et leur pertinence avec le trafic généré. C’est essentiellement ce couple « trafic ciblé / landing page » qui permet de maîtriser le taux de rebond. Aujourd’hui, la plupart des sites marchands sont capables de fournir à l’internaute une forte pertinence dans le cadre de leurs mécanismes d’acquisition de trafic web.

La cohérence entre les campagnes Adwords et les landing pages du site Internet Spartoo.com illustre parfaitement la pertinence du couple « trafic ciblé / landing page ».

taux_de_rebond_2

La notoriété de la marque de l’annonceur influence le taux de rebond

Le trafic de marque, constitué d’internautes qui connaissent la marque de l’annonceur (ex : Spartoo) et qui se rendent  volontairement sur son site Internet, aura naturellement tendance à générer un taux de rebond faible.

Dans un contexte toujours plus « cross-canal » de nombreux sites Internet marchands développent leur notoriété grâce à des actions déployées sur d’autres médias que le web (télévision, presse, radio, …). Ces actions sont capables de générer une part très importante de trafic de marque via :

- les accès directs, lorsque l’internaute renseigne directement l’adresse du site Internet dans le navigateur,

- le référencement naturel ou payant lié à des requêtes comportant une sémantique de marque (ex : « chaussures de ville Spartoo »)

Contrairement au trafic de marque,  le trafic d’acquisition de nouveaux clients génère des taux de rebond plus importants, généralement supérieurs à 35%. Les clients arrivent sur le site via des requêtes qui ne sont pas liées à la marque de l’annonceur mais notamment via des recherches liées à l’offre (ex : « chaussures de ville »). L’enjeu de l’annonceur consiste à proposer une landing page parfaitement adaptée aux attentes de l’internaute, le rassurer, capter son attention et l’inscrire rapidement dans un processus d’achat.

Lorsque la part de trafic de marque est importante par rapport au trafic d’acquisition de nouveaux clients, le taux de rebond moyen du site Internet peut s’avérer bas.

Le graphique ci-dessous montre l’écart en termes de taux de rebond entre les sites Internet de deux marques bénéficiant d’une notoriété très différente. Voyages Sncf est capable de générer une part de trafic de marque très importante et enregistre un taux de rebond moyen d’environ 15%. A l’inverse, le site Internet govoyages.com doit faire appel à une plus grande part de trafic d’acquisition de nouveaux clients afin d’alimenter son activité de vente en ligne et son taux de rebond varie autour de 35%.

taux_de_rebond_3

Un taux de rebond trop bas peut être révélateur d’un potentiel non exploité

Un taux de rebond bas peut être strictement lié à la forte notoriété d’une marque indépendamment de la qualité du dispositif web proposé aux internautes en termes de couple « trafic ciblé / landing page ». Dans ce cas, ce taux de rebond trop bas peut être révélateur d’actions de webmarketing visant des clients déjà acquis, au détriment de nouveaux clients.

Uniquement une étude plus approfondie des données de web analyse peut vous indiquer la performance réelle de votre dispositif digital en termes de capacité à retenir le trafic entrant. Ces analyses permettent d’affirmer que vous n’êtes pas en train de passer à côté d’une importante source de clients potentiels.

taux_de_rebond_4

Avant de vous réjouir d’un taux de rebond bas (inférieur à 20%), outre une vérification du paramétrage et du mode d’implémentation de votre outil de web analyse, pensez à vérifier son origine en approfondissant vos analyses. Un premier niveau d’analyse peut être effectué en étudiant les taux de rebond par source de trafic et par landing page.



Ouverture de la beta publique d’Universal Analytics

Posté dans Web analytics par Romain Créteur

Nous vous en avions parlé à notre retour du GACP Summit et avons publié une tribune détaillée sur journaldunet sur le sujet récemment. Cette fois-ci nous y sommes, Universal Analytics qui était jusqu’ici en beta privée vient de passer en beta publique. Concrètement cela signifie que pour toute nouvelle création de compte Google Analytics on vous demandera de choisir entre la version actuelle de GA et la version Universal Analytics.

Pour rappel, voici les avantages apportés par Universal Analytics :

  • une approche permettant le tracking multi-devices (non présente dans la beta actuelle…)
  • une meilleure intégration avec le tracking des applications
  • la possibilité d’intégrer des données offline dans GA (ex : conversions réalisées par un call-center)
  • réduction de l’impact sur le temps de chargement

Comment créer un compte Universal Analytics

Que vous ayez déjà un compte GA ou non, il vous faudra créer une nouvelle « web property»  pour profiter d’Universal Analytics. A la création de cette web property vous verrez l’écran ci-dessous :

Création dune nouvelle web property avec Universal Analytics

Création d'une nouvelle web property avec Universal Analytics

Google vous fournira alors le code de tracking associé, le universal.js qui remplace le ga.js

Passer à Universal Analytics nécessite donc de repartir d’un profil vierge et de mettre à jour votre plan de taggage (tous les tags sont différents avec Universal Analytics). Il est tout à fait possible (et recommandé) de maintenir un double taggage afin de conserver un certain historique et de migrer en douceur vers Universal Analytics.

Attention toutefois, toutes les fonctionnalités du ga.js ne sont pas encore active avec universal.js comme par exemple le testing (Content experiments), le remarketing ou la gestion du cross-domain tracking. Toutes ces fonctionnalités devraient toutefois être assez rapidement intégrées par Google à Universal Analytics.

Par ailleurs, cette migration peut aussi être l’occasion de réfléchir à la mise en place d’un Tag Management System comme Tag Commander ou Google Tag Manager afin de faciliter les ajouts et retraits de tags futurs.

En tant que GACP, Converteo a participé à la beta privée d’Universal Analytics depuis plusieurs mois, nous pouvons donc vous accompagner sur cette transition. N’hésitez pas à nous contacter pour en parler !



Une nouvelle gestion des devises pour Google Analytics

Posté dans Web analytics, e-Commerce par Quentin Bérard

En réponse aux demandes récurrentes de certains de ses utilisateurs, Google vient d’annoncer la mise en place d’une solution de gestion des devises dans sa solution de webanalyse.

Pour rappel, les données monétaires remontées dans les rapports e-commerce étaient jusqu’à présent exprimées dans la devise définie via l’interface de Google Analytics. L’utilisateur ne pouvait définir qu’une seule et unique devise pour chaque profil.

Currency_GA

Ce mode de fonctionnement n’altérait évidemment pas les estimations de revenus des sites dont les paiements s’effectuaient dans une seule devise. En revanche, elle posait de sérieux problèmes de cohérence lorsque le pays de navigation, et donc dans certains cas la devise de paiement, pouvaient changer d’un internaute à l’autre. Deux transactions, l’une de 100 $ (USD) et l’autre de 100 €, étaient par exemple identifiées comme ayant chacune une valeur de 100 puis étaient exprimées dans une seule et unique devise. L’interface de Google Analytics annonçait donc un CA de 200 € ou 200 $ selon la devise choisie dans le paramétrage du profil.

Les équipes de Google apportent aujourd’hui une réponse pour remédier à cette situation, profondément inconfortable pour les sites e-commerce à vocation internationale.

Un simple ajout dans le code e-commerce

Le changement majeur est opéré au niveau du code e-commerce. Il suffit désormais d’y placer un « code de devise»  avant que la fonction _trackTrans(), qui enregistre la transaction dans Google Analytics, soit exécutée :

_gaq.push(['_set', ‘currencyCode’, ‘EUR’]);

Cette instruction permet de spécifier la devise en vigueur lors de chaque transaction. Ici ‘EUR’ correspond à l’Euro. 31 monnaies locales sont actuellement supportées par Google Analytics. Veuillez trouver ici la liste des devises disponibles sous Google Analytics.

Comment alors traiter des données exprimées en devises différentes ?

Bien que distinguées grâce au code e-commerce, les données monétaires apparaissent toujours dans l’interface exprimées sous une seule et unique devise. Cependant, elles sont désormais recalculées en fonction de la devise spécifiée dans le code e-commerce et du taux de change en vigueur le jour précédant la transaction. Si l’on reprend nos deux transactions de 100 $ (USD) et de 100 €, les données remontant dans l’interface de Google Analytics sont alors différentes. Pour un taux de change de 0,75 entre le dollar et l’euro (1 $ (USD) = 0,75 €) et un paramétrage du profil en euro, Google Analytics affiche maintenant une transaction de 75 € et une autre de 100 €. Le CA est donc de 175 €.

Le taux de change est extrait des serveurs utilisés par le service de facturation de Google (Google Billing). Les nouveaux rapports créés reflètent ainsi plus précisément la performance e-commerce du site analysé.

Dès la mise en place dans le code e-commerce, il est possible de choisir d’utiliser ou non la nouvelle gestion des devises. Pour revenir à l’ancien affichage, il suffit d’utiliser les nouveaux metrics « Local»  mis à disposition par Google Analytics.

Local_revenue_GA

Ces derniers remontent toutes les transactions d’un profil sans tenir compte des taux de change. Les revenus sont alors affichés sans devises. Dans notre exemple des deux transactions à 100€ et 100$, le local revenue sera donc de 200 sans précision de l’unité monétaire.

Cette fonctionnalité de Google Analytics est d’ores-et-déjà disponible. Il convient néanmoins de l’utiliser avec précaution : si la possibilité d’avoir un suivi des revenus d’un site plus conforme à la réalité est attrayante, elle ne doit pas entraver le but premier de Google Analytics, à savoir de fournir des données pertinentes pour la webanalyse. En insérant une variable aussi volatile que le taux de change dans le calcul du CA l’utilisateur prend le risque de ne plus distinguer les variations liées à la performance e-commerce de son site de celles dont les causes sont purement monétaires.



Google Analytics et le nouveau rapport « Analyse des pages Web» 

Posté dans Web analytics par Robin Brébant

Parmi les dernières annonces et nouveautés liées à Google Analytics et notamment la sortie de « universal analytics» , un « nouveau»  rapport a fait son apparition dans Google Analytics, il s’agit du rapport « Analyse des pages Web» 

Anciennement appelé « Synthèse données/site» , cette nouvelle version du rapport est disponible dans la section « Contenu»  de la barre de menu depuis le 16 Octobre 2012 (voir image ci-contre)

Ce rapport a pour objectif principal d’afficher de manière visuelle une sorte de Clickmap qui permet de visualiser rapidement comment se comporte les internautes sur toutes les pages de votre site pendant que vous naviguez dessus à travers l’interface Google Analytics.

Nous allons voir ensemble comment fonctionne ce rapport et quelles sont les modifications majeures apportées par Google à ce rapport. Ces données sont-elles plus exploitables que précédemment?

Quelles sont les évolutions apportées par Google?

L’ancien rapport, présent dans Google Analytics sous le nom de « Synthèse données/site»  était en fait assez pauvre en information (de plus nous allons voir un peu plus tard dans cet article que les données étaient faussées ou incomplètes et donc inexploitables en l’état)

Pour rappel, la seule donnée disponible dans l’ancien rapport était le nombre de clics déclenchés par chaque élément d’une page au cours d’une visite.

Le rapport a donc été enrichi avec les données suivantes :

  • Transactions
  • Chiffre d’affaires
  • Nombre et valeur des différents objectifs
  • Indicateurs de performance (Pages vues, consultations uniques, Temps passé sur la page, temps de chargement, taux de rebond et taux de sorties)

Globalement l’idée est de base est intéressante et les modifications apportées à ce rapport sont les bienvenues, mais les données affichées sont-elles plus fiables pour autant?

L’attribution améliorée des liens, un moyen de fiabiliser les données?

Des modifications ont donc été apportées par Google pour tenter de consolider les chiffres de ce rapport grâce notamment à l’attribution améliorée des liens.

Cette nouvelle fonctionnalité permet à Google Analytics de distinguer des liens multiples sur une même page, ayant une même destination, ce qui n’était pas le cas dans l’ancienne version du rapport.

Prenons un exemple : sur votre page d’accueil vous avez deux liens vers votre rubrique « Contact» , le premier dans la barre de navigation principale de votre site et le second dans votre footer à titre de rappel. Grâce à l’implémentation de l’attribution améliorée des liens, Google Analytics sera alors capable de différencier si le clic initial vient de votre barre de navigation ou du footer de votre site. Sur l’ancienne version du rapport le nombre de clics aurait été le même sur les deux liens, ce qui rendait impossible toutes analyses car les chiffres affichés dans le rapport étaient alors complètement faussés.

La deuxième amélioration principale est la possibilité de suivre les actions déclenchées par des évènements Javascript (menus déroulants, redirections, ou bouton de recherche par exemple), certains éléments absents sur l’ancienne version du rapport car non trackés sont désormais censés être correctement suivis.

Sur le papier l’attribution améliorée des liens promet donc de gagner en précision, en offrant la possibilité de tracker tous les éléments de la page, tout en faisant la distinction entre les éléments qui ont une même destination.

Comment mettre en place l’attribution améliorée des liens?

La première chose à faire pour mettre en place ce nouveau système de comptabilisation des clics est de modifier le code Google Analytics présent sur vos pages afin d’ajouter la ligne dédiée à l’analyse des pages de votre site internet

Le code utilisé doit-être le code asynchrone, si vous utilisez encore le code synchrone profitez-en pour faire la migration !

Pour l’implémentation technique, je vous invite à consulter la documentation de Google qui est très précise et claire à ce sujet. Ce nouveau code vise à inclure une page de code Javascript ayant pour objectif de consolider les données qui remontent dans Google Analytics.

Une fois que le code Google Analytics a été modifié, il faut dans un second temps activer la fonctionnalité dans l’administration Google Analytics (Onglet Admin > Paramètres du site > il faut ensuite cocher « Utiliser l’attribution améliorée des liens»  puis cliquer sur le bouton « Appliquer» )

Capture

Comment sont récoltées les données affichées dans le rapport « Analyse des pages Web» ?

Une fois le code modifié et dès que le code Google Analytics est chargé :

  • Il ajoute un gestionnaire d’événements onclick dans le corps du document. À chaque clic, le gestionnaire vérifie si la cible des clics possède un identifiant. Si oui, il l’enregistre alors dans un cookie nommé __utmli.
    Le cookie expire au bout de 30 secondes et est utilisé sur la page suivante (voir ci-dessous).
  • Il vérifie si le cookie __utmli a été créé pour la page précédente. Si c’est le cas, il enregistre l’identifiant du lien, l’envoie via _trackPageview, puis efface le cookie.
  • Il vérifie l’identifiant de l’élément du clic cible et, s’il ne le trouve pas, escalade le DOM jusqu’à trois niveaux pour trouver un élément avec un identifiant. Par exemple :

<div id=» espace_contact» >

<a href=’/contact.html’> Contact </a>

</div>

Dans cet exemple, en cas de clic sur le lien « Contact» , le code attache l’information du id=’espace_contact’ même si l’élément help-icon ne présente aucun identifiant (car il s’agit du niveau précédent dans le DOM)
Le délai d’expiration de 30 secondes est utilisé pour réduire les risques d’attribution avec un identifiant erroné, quitte à perdre l’information d’identification si la page suivante met plus de 30 secondes à se charger.

Utiliser ce mécanisme de cookie permet de limiter l’impact sur les clics (et a un effet minime voire nul sur votre site) et n’envoie aucune autre information de suivi. Cette information est envoyée à Google Analytics via le suivi de la page suivante.
Source : Documentation Google Analytics

Une fonctionnalité qui ne remplacera jamais la mise en place d’un véritable plan de taggage

Même si cette nouvelle version permet de corriger les principaux défauts du rapport « Analyse des pages Web»  il n’en reste pas moins que ce rapport n’offre selon nous qu’un aperçu graphique de la performance d’une page mais n’a pas vocation à être un support pour des analyses chiffrées très précises comme avec l’utilisation des évènements par exemple.

Mais finalement pourquoi même avec l’attribution des liens activée dans votre compte Google Analytics, les données du rapport « Analyse des pages Web»  seraient-elles moins précises qu’en utilisant des évènements?

  • Les données peuvent être faussées ou simplement non enregistrées par l’absence d’attribut ID ou par l’utilisation d’un même ID sur les différents éléments du site. Il est donc important d’avoir une structure de page propre, qui respecte une certaine arborescence afin d’obtenir des données correctes dans le rapport.
  • Impossibilité de tracker les éléments autres que des liens ou des redirections (Quid des filtres dynamiques, des zooms sur les photos et de tous les éléments qui ne nécessitent pas de rechargement de page…)
  • Les liens vers des sites externes ou vers des fichiers PDF par exemple ne seront pas trackés
  • Le cookie n’a qu’une durée de vie de 30s, en cas de chargement trop long ou si le visiteur quitte le site au bout de quelques secondes, alors les données sont perdues !

Quelles solutions pour tracker efficacement vos pages?

Heureusement afin de tracker efficacement vos pages, il existe d’autres solutions, vous pouvez éventuellement envisager de réaliser un plan de taggage ou d’utiliser un outil de heatmap.

La première solution est donc de réaliser un plan de taggage (autrement appelé plan de marquage). Le plan de taggage a pour but de décrire page par page les éléments à mettre en place sur votre site afin d’obtenir des données précises des éléments que vous souhaitez suivre ou analyser. Ce document sert donc de base à une implémentation propre du taggage sur votre site, il résulte d’une analyse poussée de vos besoins en termes d’analyses afin d’éviter de surcharger inutilement votre site de tags JavaScript ou tout simplement d’oublier certains indicateurs importants.

Vous trouverez ci-dessous un extrait de plan de taggage réalisé par Converteo :

Exemple plan de taggage Converteo

Enfin, il est également possible d’utiliser un outil de heatmap, ce genre d’outil permet de représenter de manière graphique les zones les plus cliquées de votre site (et y compris les zones non cliquables, de manière visuelle).

Vous trouverez ci-dessous un exemple de heatmap/clickmap : les zones « chaudes»  et donc les plus cliquées sont celles représentées en rouge, les zones « froides»  étant représentées en bleu.

Ce genre d’outil permet donc d’identifier de manière rapide et graphique l’intérêt de vos visiteurs, mais il sera impossible de sortir des analyses chiffrées aussi précises qu’avec l’utilisation d’un plan de taggage. Dans certains cas l’utilisation combinée d’un plan de taggage et d’un outil de heatmap peut également s’avérer utile.

De nombreux éditeurs proposent ce genre d’outil, notamment ClickTale ou CrazyEgg avec qui nous avons déjà eu l’occasion de travailler.

Clickmap réalisée avec ClickTale

Pour conclure, même si cela prend plus de temps initialement, sur le long terme un plan de taggage solide et complet de votre site reste la meilleure solution pour mener des analyses précises sur le comportement de vos visiteurs, n’hésitez pas à nous contacter.



Page 2 sur 19«12345»...Dernière »