Quelle quantité de données manque dans Analytics ? Et autres trous noirs analytiques

Si vous avez déjà comparé deux implémentations d’analyses sur le même site, ou comparé vos analyses avec ce que votre entreprise rapporte dans les ventes, vous avez probablement remarqué que les choses ne correspondent pas toujours. Dans cet article, j’expliquerai pourquoi les données manquent sur vos plateformes d’analyse Web et l’ampleur de l’impact potentiel. Certains des problèmes que je couvre sont en fait assez faciles à résoudre et ont un impact décent sur le trafic – il n’y a jamais eu de moyen plus simple d’atteindre vos objectifs trimestriels. 😉

Je vais me concentrer sur GA (Google Analytics), car c’est le fournisseur le plus couramment utilisé, mais la plupart des plates-formes d’analyse sur page ont les mêmes problèmes. Les plates-formes qui s’appuient sur les journaux de serveur évitent certains problèmes mais sont assez rares, donc je ne les couvrirai pas en profondeur.

Remarque : Notre configuration de test (plusieurs trackers et GA personnalisée)

Sur Distilled.net, nous avons une propriété Google Analytics standard fonctionnant à partir d’une balise HTML dans GTM (Google Tag Manager). De plus, au cours des deux dernières années, j’ai exécuté trois implémentations supplémentaires simultanées de Google Analytics, conçues pour mesurer les écarts entre différentes configurations.

(Si vous êtes simplement intéressé par mes conclusions, vous pouvez ignorer cette section, mais si vous souhaitez en savoir plus sur la méthodologie, continuez à lire. De même, ne vous inquiétez pas si vous ne comprenez pas certains détails ici – le les résultats sont plus faciles à suivre.)

Deux de ces implémentations supplémentaires – une dans Google Tag Manager et une sur la page – exécutent des copies hébergées localement et renommées du fichier JavaScript de Google Analytics (par exemple, www.distilled.net/static/js/au3.js, au lieu de www.google- analytics.com/analytics.js) pour les rendre plus difficiles à repérer pour les bloqueurs de publicités. J’ai également utilisé des fonctions JavaScript renommées (“tcap” et “Buffoon”, plutôt que le “ga” standard) et des trackers renommés (“FredTheUnblockable” et “AlbertTheImmutable”) pour éviter d’avoir des trackers en double (ce qui peut souvent causer des problèmes).

Cela a été inspiré à l’origine par les meilleures pratiques de l’ère 2016 sur la façon d’obtenir votre configuration Google Analytics au-delà des bloqueurs de publicités. Je ne trouve pas l’article original maintenant, mais vous pouvez en voir un très similaire de 2017 ici.

Enfin, nous avons (“DianaTheIndefatigable”), qui a juste un tracker renommé, mais utilise le code standard autrement et est implémenté sur la page. Il s’agit de compléter l’ensemble de toutes les combinaisons de GTM modifiés et non modifiés et de trackers sur la page.

Deux des trackers modifiés sur la page de Distilled, comme on le voit sur https://www.distilled.net/

Dans l’ensemble, ce tableau résume nos configurations :

J’ai testé leur fonctionnalité dans divers environnements de navigateur/bloc de publicités en surveillant les pages vues apparaissant dans les outils de développement de navigateur :

Raison 1 : bloqueurs de publicités

Les bloqueurs de publicités, principalement en tant qu’extensions de navigateur, gagnent en popularité depuis un certain temps déjà. Cela concernait principalement les utilisateurs à la recherche de meilleures performances et UX sur des sites chargés de publicités, mais ces dernières années, un accent accru sur la confidentialité s’est également glissé, d’où la possibilité de blocage des analyses.

Effet des bloqueurs de publicités

Certains bloqueurs de publicité bloquent les plateformes d’analyse Web par défaut, d’autres peuvent être configurés pour le faire. J’ai testé le site de Distilled avec Adblock Plus et uBlock Origin, deux des extensions de navigateur de bureau les plus populaires pour bloquer les publicités, mais il convient de noter que les bloqueurs de publicités sont également de plus en plus répandus sur les smartphones.

Voici comment les configurations de Distilled se sont comportées :

(Tous les chiffres indiqués datent d’avril 2018)

On dirait que ces configurations modifiées n’ont pas fait grand-chose!

Données perdues à cause des bloqueurs de publicité : ~10 %

L’utilisation du bloqueur de publicités peut être comprise entre 15 et 25 % selon la région, mais bon nombre de ces installations seront des configurations par défaut d’AdBlock Plus, qui, comme nous l’avons vu ci-dessus, ne bloque pas le suivi. Les estimations de la part de marché d’AdBlock Plus parmi les bloqueurs de publicités varient de 50 à 70 %, les rapports les plus récents tendant davantage vers le premier. Donc, si nous supposons qu’au plus 50 % des bloqueurs de publicités installés bloquent les analyses, cela laisse votre exposition à environ 10 %.

Raison 2 : le navigateur “ne suit pas”

Il s’agit d’une autre fonctionnalité motivée par la confidentialité, cette fois des navigateurs eux-mêmes. Vous pouvez l’activer dans les paramètres de la plupart des navigateurs actuels. Il n’est pas obligatoire pour les sites ou les plates-formes d’obéir à la demande “ne pas suivre”, mais Firefox offre une fonctionnalité plus puissante sous le même ensemble d’options, que j’ai décidé de tester également.

Effet de “ne pas suivre”

La plupart des navigateurs offrent désormais la possibilité d’envoyer un message “Ne pas suivre”. J’ai testé les dernières versions de Firefox & Chrome pour Windows 10.

Encore une fois, il ne semble pas que les configurations modifiées fassent beaucoup de travail pour nous ici.

Données perdues en raison de « ne pas suivre » : < 1 %

Seule la « protection contre le pistage » de Firefox Quantum, introduite en février, a eu un effet sur nos traqueurs. Firefox a une part de marché de 5 %, mais la protection contre le suivi n’est pas activée par défaut. Le lancement de cette fonctionnalité n’a eu aucun effet sur la tendance du trafic Firefox sur Distilled.net.

Raison 3 : Filtres

C’est un peu évident, mais les filtres que vous avez configurés dans vos analyses peuvent intentionnellement ou non réduire les niveaux de trafic signalés.

Par exemple, un filtre excluant certaines résolutions d’écran de niche que vous pensez être principalement des robots ou du trafic interne entraînera évidemment une légère sous-déclaration de votre configuration.

Données perdues à cause des filtres : ???

L’impact est difficile à estimer, car la configuration variera évidemment d’un site à l’autre. Je recommande d’avoir une vue “maître” en double et non filtrée au cas où vous vous rendriez compte trop tard que vous avez perdu quelque chose que vous n’aviez pas l’intention de perdre.

Raison 4 : GTM vs on-page vs mal placé sur la page

Google Tag Manager est devenu un moyen de plus en plus populaire de mettre en œuvre l’analyse ces dernières années, en raison de sa flexibilité accrue et de la facilité d’apporter des modifications. Cependant, j’ai remarqué depuis longtemps qu’il peut avoir tendance à sous-déclarer les configurations sur la page.

J’étais également curieux de savoir ce qui se passerait si vous ne suiviez pas les directives de Google lors de la configuration du code sur la page.

En combinant mes chiffres avec des chiffres du site de mon collègue Dom Woodman (vous êtes les bienvenus pour le lien, Dom), qui utilise un module complémentaire d’analyse Drupal ainsi que GTM, j’ai pu voir la différence entre Google Tag Manager et le code mal placé sur la page (juste en bas de la balise ), j’ai ensuite pondéré cela par rapport à mes propres données Google Tag Manager pour obtenir une image globale des 5 configurations.

Effet de GTM et code mal placé sur la page

Trafic en pourcentage du niveau de référence (mise en œuvre standard de Google Tag Manager) :

Il y a quelques principaux plats à emporter ici:

• Le code sur la page signale généralement plus de trafic que GTM
• Le code modifié est généralement dans une marge d’erreur, à l’exception du code GTM modifié sur Internet Explorer (voir note ci-dessous)
• Un code d’analyse mal placé vous coûtera jusqu’à un tiers de votre trafic par rapport à un code sur la page correctement implémenté, selon le navigateur (!)
• Les configurations personnalisées, conçues pour obtenir plus de trafic en évitant les bloqueurs de publicités, ne font rien de tel.

Il convient également de noter que les implémentations personnalisées ont en fait généré moins de trafic que les implémentations standard. Pour le code sur la page, c’est dans la marge d’erreur, mais pour Google Tag Manager, il y a une autre raison – parce que j’ai utilisé des profils non filtrés pour la comparaison, il y a beaucoup de spam de bot dans le profil principal, qui se fait principalement passer pour Internet Explorateur. Notre profil principal est de loin le plus spammé, et sert également de référence ici, donc la différence entre le code sur la page et Google Tag Manager est probablement un peu plus grande que ce que je signale.

J’ai aussi fractionné les données par mobile, par curiosité :

Trafic en pourcentage du niveau de référence (mise en œuvre standard de Google Tag Manager) :

L’autre point à retenir ici semble être que les navigateurs mobiles, comme Internet Explorer, peuvent avoir du mal avec Google Tag Manager.

Données perdues à cause de GTM : 1 à 5 %

Google Tag Manager semble vous coûter un montant variable en fonction de la composition des navigateurs et des appareils qui utilisent votre site. Sur Distilled.net, la différence est d’environ 1,7 % ; cependant, nous avons un public exceptionnellement chargé de bureau et féru de technologie (pas beaucoup d’Internet Explorer !). Selon la verticale, cela pourrait facilement gonfler jusqu’à la plage de 5%.

Données perdues en raison d’un code mal placé sur la page : ~10 %

Sur Teflsearch.com, l’impact du code mal placé sur la page était d’environ 7,5 %, par rapport à Google Tag Manager. En gardant à l’esprit que Google Tag Manager lui-même sous-déclare, la perte totale pourrait facilement être de l’ordre de 10 %.

Tour bonus : données manquantes des canaux

Je me suis concentré ci-dessus sur les domaines où vous pourriez manquer complètement de données. Cependant, il existe également de nombreuses façons dont les données peuvent être déformées ou des détails peuvent manquer. Je vais les couvrir plus brièvement, mais les principaux problèmes sont le trafic sombre et l’attribution.

Trafic sombre

Le trafic sombre est un trafic direct qui n’est pas vraiment venu directement – ce qui devient généralement de plus en plus courant. Les causes typiques sont :

• Campagnes non taguées dans les e-mails
• Campagnes non taguées dans les applications (en particulier Facebook, Twitter, etc.)
• Biologique mal représenté
• Données envoyées à partir d’implémentations de suivi bâclées (qui peuvent également apparaître comme des références automatiques)

Il convient également de noter la tendance à un trafic véritablement direct qui, historiquement, aurait été organique. Par exemple, en raison de la saisie semi-automatique de navigateur de plus en plus sophistiquée, de l’historique multi-appareils, etc., les utilisateurs finissent par “taper” une URL qu’ils auraient recherchée dans le passé.

Attribution

J’ai écrit à ce sujet plus en détail ici, mais en général, une session dans Google Analytics (et toute autre plate-forme) est une construction assez arbitraire – vous pourriez penser qu’il est évident de savoir comment un groupe de résultats doit être regroupé en une ou plusieurs sessions , mais en fait, le processus repose sur un certain nombre d’hypothèses assez discutables. En particulier, il convient de noter que Google Analytics attribue généralement le trafic direct (y compris le trafic sombre) à la source non directe précédente, s’il en existe une.

Discussion

J’ai été assez surpris par certaines de mes propres découvertes lors de la recherche de cet article, mais je suis sûr que je n’ai pas tout compris. Pouvez-vous penser à d’autres façons dont les données peuvent finir par manquer à l’analyse ?