Web analytics
 

« Retour à l'accueil du blog

Retour sur la Conversion Conference Paris (5/5), Guillaume Eouzan (Mindfruits Web Accademy), Julien Babin (Keyade) et Jérôme Angeard (LSF): Piloter et optimiser sa landing page par les web analytics

Guillaume, Julien et Jérôme sont intervenus sur la thématique pilotage des landing pages et du trafic par les web analytics.

N’hésitez pas à prendre contact directement avec eux pour récupérer le support de présentation. Voici de manière succincte les principaux enseignements.

1- La méthodologie « let’s go to e-market»  de Mindfruits Web Accademy

Pourquoi avoir une méthodologie ? Cela permet de fixer des objectifs. L’efficacité web est dans le détail, et les critères et les techniques évoluent en permanence.

Il y a 3 axes pour optimiser sa conversion : au global (toutes sources confondues), par source, par attribution/parcours.

Axe 1 : l’optimisation du taux de conversion global

Il faut, pour optimiser ce taux, analyser les freins génériques présents sur le site ainsi que les points de rassurance (la qualité des photos, la page livraison, la mise en avant des avis …). Cette primo analyse a pour but de retirer les freins globaux à l’évolution de votre taux de conversion global.

La mauvaise qualité des visuels est un de ces micro-freins

Axe 2 : l’analyse de la source

Comment travailler sur les leviers de conversion ? Il faut travailler source par source, dans le temps, en structurant bien les choses. En effet vous ne disposez pas d’une source de trafic globale mais d’une multitude de sources de trafic et donc d’une multitude de taux de conversion tous très variables, analysables par source. Chaque source est optimisable intrinsèquement.

Axe 3 : analyse par modèle d’attribution / parcours

Une conversion ne provient pas toujours d’une seule visite et donc d’une seule source qui a converti, mais provient souvent de plusieurs visites d’un même internaute. C’est ce que l’on appelle le mutitouch et qui justifie de proposer des modèles d’attribution des conversions qui vont au-delà de l’attribution à la dernière source de trafic.

Il est important, de ce point de vue, de voir comment les différents leviers interagissent entre eux jusqu’à la conversion.

2- L’étude de cas Meetic – Keyade

Cette étude de cas permet de présenter le lien entre acquisition et conversion. Un test a été réalisé en France pour le display et le SEA. La question était de savoir comment changer la landing page du site (avec le formulaire d’inscription) sans perdre en performance. Le résultat de ce test est que le formulaire en 2 étapes fonctionne mieux (vs le formulaire initial en une seule étape).

Ensuite un data mining par source est possible : pour un mot clé précis, la page gagnante n’est pas toujours la même.

D’où l’invention d’un système pour optimiser la landing page, pour que chaque source de trafic ait sa landing optimale au sens de la conversion.

3- Suivi des intégrations Google Analytics – LSF Interactive

Avant d’analyser les données Google Analytics collectées sur une landing page (le tracking de cette page pouvant être très fin), il faut veiller à la qualité de cette donnée par une recette attentive. Pour cela il faut regarder le code source, les cookies, et voir si les filtres ont bien été appliqués.

Google Analytics propose différentes fonctionnalités permettant d’affiner le suivi et notamment :

  • Filtres et segments avancés
  • Pages vues virtuelles ou événements

Vous avez donc à votre disposition de nombreux outils pour piloter votre trafic vers la bonne landing page, et optimiser celle-ci.



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 admin

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.



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