Google Analytics – Des données parfaites, pérennes et impressionnantes FTW

Salut les mozzers !

Je suis fier de dire que j’ai assisté à la récente (et franchement étonnante) Conférence SearchLove London, et que j’en suis ressorti avec des idées et des projets vraiment passionnants. L’un des principaux objectifs de la conférence était de déterminer comment nous pouvons changer notre comportement et nos processus pour faciliter les choses pour “faire avancer les choses” – en particulier avec les grands clients ou les grandes organisations – et une série d’idées connexes touchant à l’optimisation du taux de conversion, linkbait, campagnes et création de liens en général. C’est tout impressionnant. Cependant…

Beaucoup de ces choses ont besoin d’être achetées. Les PDG et les clients doivent pouvoir comprendre (ou se sentir rassurés par des feuilles de calcul convaincantes) que leur investissement va rapporter avant de libérer du budget, et nous devons donc nous assurer que nous sommes responsables. L’un des enseignements les plus excitants de la conférence était l’idée que nous devrions essayer de lancer des campagnes de « grandes idées » aux gars au sommet, mais commencer petit avec des exemples d’exécution et de réussite pour justifier un investissement plus important. Cela ne devrait pas être sorcier, mais comprenez ceci – de suivi, de reporting, d’analyse, d’analyse et l’intégrité des données n’ont pas été mentionnés une seule fois à SearchLove London. Si je n’ai pas de compte Google Analytics bien configuré qui me permettra de mesurer l’impact de mon travail et d’afficher un retour sur investissement clair, j’aurai du mal à obtenir l’adhésion dont j’ai besoin pour l’obtenir. [awesome campaign idea / pesky site issue / indexation problem / linkbait / infographic launch] trié. Il y a une hypothèse sous-jacente ici que nous sommes tous dans une position où c’est facile, réalisable et déjà en place ; et je ne suis pas convaincu que ce soit le cas.

Je vais lever la main et admettre que je suis un perfectionniste des données. Je deviens nerveux s’il y a des données dans mon compte Google Analytics que je connaître n’est pas correct, et je fais toujours pression pour le rendre plus propre, meilleur et finalement plus exploitable. Mais ce n’est pas une bizarrerie académique; Si je fais des recommandations à des clients, qui à leur tour investissent de l’argent dans des changements et des améliorations, je ne peux pas me permettre que les informations que je fournis soient basées sur des données erronées. Étant donné que c’est le cas, et étant donné que dans une plus ou moins grande mesure, nous devons tous (ou du moins devrions être) justifier nos idées et nos résultats avec un retour sur investissement mesurable, pourquoi les données de tant de comptes Google Analytics sont-elles si choquantes fragmentées, configuré de manière sous-optimale et tout simplement désordonné ?

Donc, voici l’affaire – je vais passer en revue un tas d’idées et de conseils que vous pouvez partir et mettre en œuvre, et je peux travailler pour surmonter un peu ma névrose en sachant que les données que vous collectez sont exactes et utile. Commençons petit.

Exclusion des requêtes d’URL

Vous avez tous vu des rapports comme celui-ci dans votre compte Google Analytics. Ce sont des pages tout en bas de mes rapports de contenu, et nous examinons les URL et les pages vues :

Il y a deux choses ici qui vraiment enrouler moi. Je reçois de petits filets de visites sur des pages via des services tiers tels que Google Translate, des services de mise en cache et Facebook (et qui sait quoi d’autre) qui fragmentent mes données en ajoutant des paramètres de requête arbitraires. Il n’y a que quelques visites ici, mais celles-ci s’additionnent, ce qui entraîne deux problèmes :

1. Ce rapport est pénible à parcourir et à utiliser, car il est plein de détritus. Je peux probablement vivre avec ça, cependant, mais;

2. je ne sais pas combien réel visites que mes pages ont eues, car il y a un pourcentage arbitraire qui finit par être fragmenté dans ce gâchis et signalé comme un contenu différent.

Peu m’importe si le visiteur est venu via Google Translate dans ce contexte ; bien sûr, c’est intéressant et utile, mais il ne faut pas confondre avec mes données de consommation de pages. Naha. #1 dans le tableau, qui est une demande pour une page avec du spam Facebook dans l’URL, devrait faire partie du même ensemble de données que le reste des informations sur la page en question ; le fait que les données de cette page se trouvent à qui sait combien d’endroits signifie que je ne vois pas une image représentative des performances, et qu’à tout moment un pourcentage arbitraire des informations réelles et réelles sur la façon dont les utilisateurs sont l’interaction avec cette page est perdue – ou du moins enterrée. Si cette information était consolidée (tout en préservant le fait que la visite est venue via les services de traduction via un autre rapport), alors je saurais que j’ai effectivement eu X visiteurs de plus sur la page en question, et ma compréhension de la façon dont ils consomment mon contenu pourrait changer un peu en conséquence.

Maintenant, je t’entends pleurer, c’est facile à réparer. je peux utiliser le ‘Exclure les paramètres de requête d’URL‘ dans le profil pour supprimer simplement ces paramètres des rapports et consolider les informations sur cette page. Cela fonctionne à merveille si vous n’avez rien de mieux à faire de votre temps que de fouiller constamment au fond de vos analyses – le problème ici est que vous ne résolvez pas le problème, vous ne faites que nettoyer les symptômes ; il n’y a rien qui arrête plus que cela se produise.

Prenons un exemple pour démontrer pourquoi ce n’est pas vraiment une solution.

Si j’accède à votre site avec un paramètre d’URL arbitraire, par exemple : example.com/great-page/?messyjunkinyoururl=truequi s’affichera sous la forme d’un rapport sur le contenu différent de exemple.com/grande-page/ de la manière que nous avons explorée ci-dessus. Ceci est facilement supprimé via l’ajout d’une chaîne d’exclusion pour désordrejunkinvotreurl, mais comprenez bien : il n’existe aucun moyen de détecter facilement et de manière proactive ce type de fragmentation. À moins que vous ne passiez énormément de temps à surveiller vos rapports de contenu, les recommandations que vous faites sur la base des données peuvent être considérablement faussées simplement parce que vous n’avez peut-être pas remarqué que 50 % de vos visites sur une page provenaient d’une URL comprenant paramètres de requête inattendus. Que se passe-t-il si les données complètes et consolidées brossent un tableau très différent qui contredit les recommandations que vous avez faites ? Cauchemar!

Il existe également deux limitations strictes à cet outil. Il existe un nombre fini de paramètres que vous pouvez supprimer (je crois que c’est 50), et les paramètres eux-mêmes sont sensibles à la casse. Cela ne prendra pas longtemps avant que vous n’ayez plus la possibilité d’éponger vos données, puis vous reviendrez à la case départ.

Même sans ces limitations, ce n’est pas une solution ; chaque crawler, scraper, syndicator, bolt-on, intégration et outil tiers dans le monde va ajouter des indésirables propriétaires à vos rapports de contenu, et vous ne saurez jamais ce qui se passe. Il est difficile de justifier votre formidable campagne de référencement auprès du PDG lorsque vous ne pouvez pas dire quelles pages les internautes parcourent sur votre site ; plus difficile encore de prendre une mauvaise décision à cause d’une mauvaise information et d’en parler plus tard.

L’utilisation de l’exclusion de paramètres vous donnera des données consolidées et excellentes comme celles ci-dessus, mais seulement tant que vous les maintenez de manière proactive.

Il y a un autre défi ici, à savoir que le même type de problème de contenu dupliqué auquel nous sommes confrontés en tant que référenceurs s’applique ici aussi. Si une page est accessible via plusieurs URL (peu importe les chaînes de requête), elle sera signalée comme ces plusieurs pages, plutôt que comme une seule entité. Ce n’est pas (généralement *) réparable avec l’exclusion de la chaîne de requête et nécessite une approche différente.

* Si vous avez un système d’URL fortement axé sur les requêtes, il peut y avoir des scénarios dans lesquels vous pouvez essayer des règles d’exclusion intelligentes, mais il s’agit d’une solution un peu “sale” et ne s’appliquera qu’à un très petit nombre de sites Web.

Élagage agressif avec des noms de page virtuels

Une autre approche consiste à tricher un peu, et c’est l’approche adoptée par de nombreuses autres solutions de suivi.**

** Il y a une discussion intéressante ici pour savoir si les tentatives de Google Analytics pour promouvoir la simplicité et la facilité d’utilisation du produit ont nui à la qualité des données collectées parce que les gens ne savent pas qu’une installation standard est généralement de la foutaise, mais c’est une conversation pour une autre fois !

L’approche est que plutôt que d’utiliser et de s’appuyer sur l’URL de la page, chaque page se voit attribuer un nom. Désormais, lorsque quelqu’un visite cette page, quelle que soit l’URL utilisée, les données sont automatiquement consolidées dans le rapport pour ce nom de page.

Tout ce que j’ai à faire est de modifier mon code Google Analytics pour ajouter une valeur de nom de page, ce que je peux faire en modifiant le code suivant :

_gaq.push([‘_trackPageview’]); devient _gaq.push([‘_trackPageview’, ‘NAME OF PAGE’]);

À condition que “NOM DE LA PAGE” soit inséré manuellement ou par programmation dans la balise (par exemple, modification du code HTML de chaque page pour les sites simples/statiques, ou sur les sites complexes définissant des règles de comportement afin que différents types de pages génèrent des pages cohérentes et précises noms), chaque fois que cette balise se déclenche, elle utilise cette valeur au lieu de l’URL. Bingo ! Nous avons nettoyé tous ces paramètres indésirables, et tout est propre et brillant ; l’URL utilisée pour accéder à la page n’affecte pas le rapport.

C’est sympa! Si vous avez un CMS avec une certaine flexibilité, ou des développeurs qui vous doivent des faveurs, nous pouvons aller un peu plus loin en commençant à lui appliquer une structure intelligente… peut-être quelque chose comme ceci :

Tout ce que nous avons fait ici, c’est que le CMS identifie le type de page que je consulte et utilise des règles prédéfinies pour préfixer proprement ces informations au nom de la page. Désormais, je peux rechercher et trier en fonction de différents types et classifications de contenu, et même configurer des rapports, des segments et des filtres personnalisés pour ne m’afficher que des types de contenu spécifiques.

Il y a un autre avantage très intéressant à cette approche, c’est que si l’URL d’une page change (par exemple, après une redirection 301), à condition que le type et le nom de la page restent les mêmes, le rapport continuera à associer les données de cette page à la même entrée, permettant des données propres et cohérentes tout au long de la période de redirection. Sans cela, si une URL change, vous constaterez que l’ancienne arrête le suivi et que la nouvelle commence le suivi en tant que page différente. Il est difficile d’analyser le comportement à travers ces transitions !

Mais attendez, pendant que nous avons résolu le problème initial de la fragmentation. il y a de gros inconvénients à cette approche…

1. Nous avons supprimé tous les rapports basés sur les URL dans Google Analytics, tels que les rapports sur les pages (car aucune de ces pages ne représente des URL réelles).

2. Nous avons interrompu la possibilité de visiter des URL via Google Analytics (car aucune de ces pages ne représente des URL réelles).

3. Nous avons créé un système qui doit être maintenu en permanence chaque fois que le site change ou grandit, sinon nous sommes de retour là où nous étions à l’origine avec un mélange de rapports de pages fragmentés.

Le point trois est le tueur ici – que se passe-t-il si nous introduisons la pagination ? Et si nous changions le fonctionnement du filtrage ou de l’ordonnancement du contenu ? Qu’en est-il de la catégorisation, des taxonomies et des nouveaux types de contenu ? Tout ce que nous aimerions enregistrer sur notre contenu doit être explicitement conçu, mis en œuvre et maintenu, sinon nous n’avons pas réussi à résoudre le problème initial des données confuses, ou (sans doute pire) incorrectement consolidé les données. Par exemple, si nous introduisons du contenu paginé dans des zones du site Web et ne créons pas de nouvelles règles sur la façon dont les noms de page dans ces scénarios doivent être créés, nous constaterons que tous les résultats paginés (par exemple, page 2, page 3 , etc.) sont soit regroupés dans un rapport sur une seule page, soit qu’ils se rabattent sur l’utilisation d’URL, ce qui nous ramène tous les deux à la case départ.

Suivi canonique

A chaque nouvelle solution GA que j’envisage, je jongle entre ces deux implémentations ; visez-vous haut pour une solution propre qui nécessite du temps de réflexion et une planification supplémentaire à maintenir (noms de page), ou visez-vous bas et engagez-vous dans une solution fragmentée que vous pouvez consacrer du temps au nettoyage de printemps périodiquement (par défaut) ? La complexité du site Web et les ressources disponibles seront prises en compte dans cette décision, mais cela ressemble toujours à un sale compromis car aucun des deux n’est jamais parfait, et il est difficile de tenir compte des ressources et des exigences futures.

Ce dont nous avons besoin, c’est d’une sorte de système qui offre un hybride des deux; une maintenance minimale, mais des données propres, avec le moins d’inconvénients possible ; et je pense avoir trouvé la solution…

En tant que référenceurs, nous avons tous passé l’année dernière à construire et à mettre en œuvre la solution parfaite dans un autre domaine. Nous ont un système qui nous permet de consolider et de rassembler la valeur en un seul endroit sous la forme de balise d’URL canonique. Que se passe-t-il si nous utilisons la valeur de cette balise comme valeur du nom de page dans notre solution de suivi ?

_gaq.push([‘_trackPageview’, ‘CANONICAL URL’]);

Bingo. Il s’agit de notre solution la meilleure des deux, où toute URL consultée sera signalée comme l’URL canonique de cette page, résolvant le problème de la fragmentation des requêtes et des rapports de contenu en double. Cela nous ramène à nos rapports d’origine basés sur des URL, mais garantit qu’ils seront propres et consolidés sans avoir besoin d’un entretien constant. Il maintient également la fonctionnalité des rapports sur la page, des hyperliens dans les rapports, etc.

Il y a, sans surprise, quelques considérations cependant :

• Votre configuration d’URL canonique doit être parfaitement propre, sinon les pages rapporteront avec la mauvaise URL canonique (entraînant potentiellement plus de fragmentation, plutôt que moins).

• Les nouvelles fonctionnalités, les types de page et le comportement nécessiteront toujours une certaine considération (mais ils le feraient déjà du point de vue de l’URL canonique, de toute façon, donc ce n’est pas un travail supplémentaire).

• Il peut y avoir des cas marginaux où l’URL canonique n’est pas l’URL que vous souhaitez signaler.***

***Tels que des scénarios de canonisation avancés tels que la pagination, où vous pouvez canoniser une page “tout afficher”, mais souhaitez voir des rapports de contenu sur des pages paginées individuelles, auquel cas vous aurez besoin d’une logique au cas par cas pour sortir une valeur alternative.

La cerise sur le gâteau – visibilité et responsabilité

Nous devons savoir si cela fonctionne bien, sinon nous ne sommes pas mieux lotis que d’être dans une position où les données sont fragmentées et de prendre des décisions dont nous ne sommes pas sûrs qu’elles soient justes. Les solutions de nom de page et de nom de page canonique présentent toutes deux un risque d’élagage excessif invisible, où les données sont trop nettoyées et consolidées ou aux mauvais endroits, mais nous n’avons aucun moyen de le repérer ou de le savoir.

Afin de maintenir la visibilité du niveau et des types de consolidation que nous effectuons, nous pouvons utiliser un emplacement variable personnalisé au niveau de la page pour enregistrer l’URL de la page en question, puis créer des rapports personnalisés pour le comparer au nom de la page. ou nom de page canonique. Essayez de donner un coup de fouet au code suivant juste avant la ligne trackPageview :

_gaq.push([‘_setCustomVar’,1,’URL Requested’,window.location.pathname,3]);

Vous pouvez désormais utiliser des rapports personnalisés dans Google Analytics pour comparer les pages (en tant que dimension principale) aux URL demandées (en tant que dimension secondaire) et voir facilement où le nom de page canonique est différent du nom de page demandé.

La plupart du temps, cela montrera que le nom de page canonique fait son travail et qu’il se présente comme une seule page lorsqu’il est demandé avec des paramètres désagréables ; cependant, cela vous permettra également d’identifier les scénarios dans lesquels soit la mauvaise page est enregistrée, soit il existe des possibilités d’appliquer des conventions de dénomination plus avancées (comme l’exemple de pagination traité plus haut dans cet article).

Parfait!

Nous sommes maintenant dans une position où votre solution de suivi se maintient (au moins, plus qu’elle ne le ferait autrement) directement en ligne avec votre stratégie de balisage canonique, et enregistre tous les scénarios où vous consolidez correctement (ou incorrectement) les données qui aurait autrement été partout. J’ai constaté des changements significatifs quelques jours après sa mise en œuvre dans ma compréhension du comportement de consommation des pages, qui ont influencé les recommandations que j’ai faites sur les actions visant à améliorer les performances.

Si vous retenez une chose du message, j’aimerais que ce soit Google Analytics ne marche pas en tant que solution prête à l’emploi si vous souhaitez réellement vous fier aux données et les utiliser pour prendre des décisions. Si vous achetez une licence Omniture, vous vous attendez à passer des semaines (voire des mois) à aligner l’installation et la configuration sur votre site Web et les exigences de suivi ; tout autant de soin doit être accordé à votre installation Google Analytics pour vous assurer qu’elle vous donne les bonnes informations avec le bon degré d’intégrité. Ce n’est pas parce qu’il est gratuit et facile qu’il ne nécessite pas une stratégie d’installation et de maintenance soigneusement élaborée.