Analytics

Suivre le comportement de navigation dans Google Analytics

Dernière mise à jour le 22 mai 2019: Ajout de l’expiration des onglets actuellement ouverts.

Dans cet article, Jethro Nederhof de la renommée de Snowflake Analytics et moi-même vous présenterons quelques API de navigateur Web assez soignées. Le but de ces API est d’en savoir plus sur comment l’utilisateur a navigué jusqu’à la page actuelleet que se passe-t-il avec les onglets de leur navigateur ?.

Nouvelles dimensions personnalisées pour le comportement de navigation

Il y a tellement de choses que vous pouvez faire avec ces nouvelles informations. Vous pouvez construire correct rapports de chemin de navigation, plutôt que de se fier aux rapports de flux flous et souvent incohérents de Google Analytics. Vous pouvez identifier la façon dont les visiteurs interagissent avec votre contenu à l’aide des onglets du navigateur – une information cruciale si vous voulez faire des têtes ou des queues du temps de Google Analytics sur les métriques de page, par exemple. Vous pouvez voir combien de redirections ont été impliquées dans l’action de navigation en cours.

Les origines de cet article se trouvent dans un certain nombre d’endroits, y compris un défi impromptu lancé par Yehoshua Coren sur Twitter (avec également de grandes contributions de Marek Lecián) :

Cependant, la principale source d’inspiration est venue de Measure Slack, où une discussion similaire sur le navigateur à onglets a eu lieu :

Mesurer le jeu

L’idée de Jethro a lancé le bal dans mon esprit, alors je l’ai contacté immédiatement et lui ai demandé s’il voulait co-écrire cet article. Il s’est avéré qu’il avait réfléchi à de nombreuses idées différentes pour le suivi du comportement de navigation, nous avons donc rapidement esquissé les grandes lignes de cet article, et ce que vous lisez maintenant est le produit final.

Je considère les améliorations introduites dans cet article tout aussi nécessaires que celles que j’ai introduites il y a longtemps dans mon article Améliorer la collecte de données avec quatre dimensions personnalisées. Une fois que vous aurez fini d’implémenter ces scripts, je suis sûr que vous serez d’accord.

Comme dit, cet article est co-écrit par Jethro et moi. Étant donné que je suis l’éditeur, toutes les erreurs et erreurs sont entièrement de ma faute, et tout commentaire sarcastique doit être dirigé contre moi et non vers mon généreux partenaire dans le crime (naturellement, tous les commentaires sarcastiques seront supprimés, mais je les lirai et promets d’être insulté).

Table des matières

Table des matières

[+show] [–hide]

Vous pouvez passer directement au chapitre Solutions, mais je vous recommande de lire d’abord la théorie. À tout le moins, assurez-vous de lire le chapitre Mises en garde, car il y a quelques pièges dont vous devez être conscient si vous implémentez cette solution.

Ah, merde. Lisez-le en entier, voulez-vous ?

1. Le pourquoi et le comment (théorie)

Le Web, par défaut, est apatride. Votre comportement de navigation se limite à la page actuelle uniquement, et il est difficile de scruter par programmation le passé (peu importe le futur).

Des outils comme Google Analytics essaient de donner un sens à ce gâchis sans état en collectant des informations dans un ordre chronologique. Vous envoyez un page vuepuis vous envoyez un autre page vue. Google Analytics interprète cela comme un comportement de navigation où vous avez d’abord consulté la première page, puis la deuxième page. C’est logique, non ?

Mais qu’en est-il si vous avez ouvert la deuxième page dans un onglet et même jamais jeté un coup d’œil? GA l’interprète toujours comme une page en cours de visualisation.

Et si vous rechargé la page en cours ? GA l’interprète toujours comme une étape de navigation.

Et si vous appuyiez sur le bouton retour du navigateur pour revenir à la page précédente ? Google Analytics ne fait aucune distinction – il ne sait pas si vous avez cliqué sur un lien, tapé l’URL dans la barre d’adresse ou utilisé le bouton de retour. C’est tout pareil.

Rapport sur le flux de comportement de Google Analytics

Les rapports de flux tentent de donner un sens à ce gâchis en alignant tout dans un modèle de navigation (le « flux »). Mais les rapports sont assez difficiles à interpréter, car ils montrent parfois des séquences dont vous êtes certain qu’elles ne devraient pas être possibles, manquent de détails nécessaires, et ils ne vous donnent pas vraiment un moyen robuste d’interroger les informations ou de créer un rapport de flux approprié. toi même.

Et la navigation par onglets est toujours un problème. Chaque onglet initie une nouvelle “session” dans le navigateur (à ne pas confondre avec une session Google Analytics). Ainsi, lorsque GA essaie de vous expliquer que tout s’inscrit dans un flux de navigation linéaire, la vérité est en réalité plus complexe : chaque onglet initie un nouveau bifurquer de navigation !

Écoulement linéaire vs embranchement

Ajoutez à cela le fait que dans Google Analytics, “Referral” est un terme réservé pour l’attribution des campagnes. Ainsi, lorsque vous naviguez sur le site, la page de référence n’est pas envoyée lors de la navigation sur le site. Cela serait très utile pour déchiffrer les chemins de navigation, puisque le Chemin de la page précédente la dimension fait ne pas représentent nécessairement la page précédente consultée (uniquement la page précédente pour laquelle une page vue a été envoyée). Pour donner un sens à ce désordre, envoyer la chaîne de référence dans une dimension personnalisée est une bonne pratique.

Rapport de référence

Il existe bien sûr d’autres solutions de suivi plus granulaires. Snowplow, par exemple, vous permet de suivre les données au niveau des hits comme vous le souhaitez. Vous pouvez inclure des informations de référence, si vous le souhaitez. Cependant, puisque vous approchez Snowplow avec les limitations des requêtes SQL, dès que le parcours de navigation commence à boucler ou comporte plusieurs pages, les jointures que vous auriez besoin de faire deviennent frustrantes et complexes et, par conséquent, assez lourdes sur de grandes quantités. de données.

Nous avons donc eu ce problème d’outils d’analyse imposant une séquence linéaire à un modèle de navigation non linéaire pendant quelques décennies, depuis l’introduction de la navigation par onglets au tournant du millénaire.

Ce que nous proposons dans cet article est d’ajouter une autre couche à la taxonomie du schéma plutôt rigide de Google Analytics pour le comportement de navigation.

À PARTIR DE: Users > Sessions > Hits
POUR: Users > Sessions > Tabs > Hits

Ce comportement de navigation serait encodé directement dans Dimensions personnaliséesvous n’avez donc pas à déduire le comportement du modèle de page vue de GA ; vous pouvez plutôt interroger directement les informations de navigation !

1.1. L’API PerformanceNavigation

L’API que nous allons utiliser pour identifier le comportement de navigation s’appelle PerformanceNavigation. Il est livré avec deux propriétés en lecture seule : performance.navigation.type et performance.navigation.redirectCount.

L’histoire d’origine de cette API est fermement ancrée dans la difficulté de mesurer les performances d’un chargement de page Web donné. Les redirections, le décalage du réseau et les ressources mises en cache (localement, côté serveur, dans les CDN) contribuent tous à la complexité de ce que l’agrégat performance de n’importe quel chargement de page donné est.

Événements PerformanceTiming

Pour aider à comprendre cette complexité, les navigateurs Web implémentent le PerformanceNavigation API. Les deux propriétés exposées par l’API se trouvent sous le global window.performance.navigation interface, et ils contiennent les informations suivantes :

Paramètre Détail La description
redirectCount Le nombre de 3XX Les redirections HTTP sont passées par le navigateur lors du chargement de la page.
type Un entier représentant la façon dont la page a été chargée.
0 Navigation normale, saisie de l’URL, clic sur un lien, ouverture d’un signet, entrée via un lien d’application, etc.
1 La page a été actualisée/rechargée alors qu’elle était déjà ouverte dans l’onglet du navigateur.
2 La page a été extraite de l’historique du navigateur à l’aide du bouton Précédent ou Suivant.
255 Tout autre moyen de naviguer vers la page.

Les 255 la valeur est intéressante, car elle est assez peu documentée. Dans les tests, il semble n’émerger qu’avec le navigateur Firefox, lorsque la page passe par un côté client actualiser, soit en utilisant window.location.replace() ou alors <meta name="refresh">. Notez que cela va à l’encontre de la spécification W3C, qui stipule clairement que les redirections côté client devraient être contenu dans l’un des types de navigation habituels.

Maintenant, même si nous mentionnons comment cette API a probablement été conçue pour donner plus d’informations sur les mesures de synchronisation des performances, où elle vraiment shines découvre les chemins de navigation empruntés par les utilisateurs sur votre site.

1.2. Stockage du navigateur

Depuis que les onglets de navigateur ont été introduits pour le plus grand plaisir des visiteurs du site et des utilisateurs de navigateurs Web, ils ont été une source d’agacement pour les analystes Web.

Dans Google Analytics, par exemple, nous ne savons tout simplement pas (par défaut) quelle est la situation des onglets d’une page donnée. Nous ne savons pas si la page a été ouverte dans un nouvel onglet, d’une part, car vous ne pouvez pas attacher d’auditeurs au menu contextuel du clic droit, et le suivi des clics sur le bouton central de la souris ne donne pas une idée complète de la portée du phénomène.

Menu contextuel

La beauté de l’analyse Web est que lorsque nous ne pouvons pas suivre les choses directement (si un utilisateur a soumis un formulaire, par exemple), nous pouvons les suivre indirectement (chargement de page d’une page de “merci”). Alors peut-être pouvons-nous également utiliser cette même approche indirecte avec les onglets du navigateur ?

Si nous pouvons attribuer un identifiant à chaque onglet que l’utilisateur ouvre dans le site Web actuel, nous pouvons identifier des séquences de navigation individuelles ! Ceci peut être réalisé en vérifiant par rapport à un magasin de données commun si l’ID d’onglet donné existe déjà, auquel cas le chargement de la page s’est produit dans un onglet qui était déjà ouvert, et vice versa.

Cependant, grâce encore à l’apatridie du web, se pose le problème de la persistance. Nous ne pouvons pas simplement utiliser une propriété JavaScript globale pour stocker l’ID de l’onglet, car cela est démoli lorsque l’utilisateur décharge la page en rechargeant ou en naviguant vers une autre page.

Biscuits et localStorage sont “trop” persistants, car ils ne sont réinitialisés que lorsqu’ils sont effacés manuellement (localStorage) ou leur date d’expiration (cookies). Nous voulons uniquement stocker l’ID d’un onglet tant que cet onglet existe.

Stockage des sessions

Entrer sessionStorage! Il s’agit d’une API de stockage de navigateur unique pour chaque onglet de votre navigateur Web. En stockant l’ID de l’onglet dans sessionStoragenous pouvons toujours vérifier si l’onglet a déjà un ID (onglet existant), ou si nous devons en générer un nouveau (nouvel onglet).

Combinez cela avec quelques localStorage logique, où nous gardons un décompte du nombre d’ID d’onglets générés, sans oublier de supprimer tout ID d’onglet une fois cet onglet fermé, et nous pouvons également obtenir un nombre assez fiable d’onglets ouverts sur votre site Web à tout moment.

Donc, maintenant, nous nous rapprochons d’avoir tous les morceaux à portée de main. Une fois que nous avons combiné les métadonnées de navigation par onglets avec celles fournies par le PerformanceNavigation API, nous pouvons obtenir un bel ensemble de dimensions personnalisées qui exposent de nombreuses informations intéressantes sur la façon dont vos visiteurs naviguent sur votre site.

2. Mises en garde

Ah, il y a abondance de mises en garde. Les solutions ci-dessous reposent sur un certain nombre de composants fragiles, qui peuvent facilement être endommagés en raison de la façon dont les navigateurs agissent différemment dans certaines circonstances.

2.1. Navigation inter-domaines

Si votre suivi couvre plusieurs domaines, chaque domaine obtiendra son propre ID d’onglet. C’est parce que sessionStorage et localStorage sont limités au domaine courant uniquement. Et si votre domaine actuel navigue entre les protocoles HTTP et HTTPS, alors celles obtiendront également leurs propres stockages. Vous pouvez résoudre ce problème en utilisant des paramètres d’URL sur les limites de domaine pour transmettre les métadonnées d’un domaine à l’autre, mais c’est quelque chose que vous devrez comprendre par vous-même.

2.2. Firefox et Chrome deviennent voyous

Un autre sujet de préoccupation est que Firefox et Chrome ne respectent pas la spécification selon laquelle les cookies de session et sessionStorage ne devrait exister que tant que l’onglet est actif. Une fois le navigateur fermé, ces magasins de session doivent être purgés.

Sur Chrome et Firefox, cependant, si vous ouvrez le navigateur et que vous avez le Affichez vos fenêtres et onglets de la dernière fois (Firefox) ou Continuez là où vous vous étiez arrêté (Chrome) activés, les magasins de session sont également restaurés ! Ainsi, même si l’onglet fait close, en restaurant l’onglet c’est comme si l’onglet n’avait jamais été fermé.

Paramètres Firefox et Chrome

C’est nul. Nous ne pouvons pas faire grand-chose à ce sujet.

De plus, et c’est intéressant, lorsque vous restaurez des onglets ou continuez là où vous vous étiez arrêté, le navigateur prétend que le type de navigation était BACK/FORWARDce qui signifie que cela équivaut à restaurer des onglets avec l’utilisation du bouton Précédent ou Suivant du navigateur.

Ça craint aussi. Et nous ne pouvons pas faire grand-chose à ce sujet non plus.

2.3. Firefox et son dilemme d’actualisation côté client

Ensuite, il y a le problème avec l’implémentation de Firefox OTHER comme type de navigation si une actualisation côté client est effectuée. C’est malheureux, mais heureusement, cela ne gâche pas trop les choses, car ce comportement est contenu uniquement dans ce type de navigation particulier.

En plus de tout cela, parce que toute la granularité de la distinction entre BACK et FORWARD doit être codé à l’aide d’un chemin d’accès des pages visitées par l’utilisateur, il lui suffit d’effacer manuellement le sessionStorage pour casser toute la configuration (au moins, tant que l’onglet est ouvert).

Effacer tous les outils de développement

C’est pourquoi, au début de la solution, vous avez la possibilité de NE PAS suivre en détail les pressions sur les boutons arrière et avant. Dans ce cas, la chaîne BACK/FORWARD est envoyé à Google Analytics en cas d’appui sur l’un ou l’autre des boutons. Ce n’est pas aussi détaillé, mais cela vous indique quand même si l’utilisateur a navigué à l’aide de ces boutons (ou, comme mentionné ci-dessus, si les onglets ont été restaurés après le redémarrage du navigateur).

Notre hypothèse est qu’avec plus de données, les moyennes convergeront vers un ensemble de données plus fiable. Ainsi, les idiosyncrasies telles que les onglets restaurés ou les utilisateurs effaçant le stockage disparaîtront dans les données à mesure que de plus en plus de pages vues seront accumulées.

2.4. Prise en charge du navigateur

Il y a aussi la question de la prise en charge du navigateur, mais contrairement à ce que prétendent certaines ressources en ligne, la prise en charge de PerformanceNavigation est assez bien pris en charge dans Chrome et Safari.

2.5. Applications d’une seule page

Vous pouvez implémenter cette solution pour les applications d’une seule page, mais dans ce cas, vous devez ajouter un type de navigation personnalisé supplémentaire appelé VIRTUALou quelque chose de similaire, si la navigation était une transition d’une seule page et non un chargement de page approprié.

Notez que window.performance.navigation.type Est-ce que ne pas mise à jour lorsque l’utilisateur utilise les boutons Précédent / Suivant du navigateur et que la transition se fait d’un état d’application d’une seule page à un autre. Vous auriez donc besoin de coder la logique pour l’utilisation en arrière / en avant lorsqu’aucun chargement de page n’est enregistré.

3. Solutions

OK, passons aux bonnes choses ! Dans ce chapitre, nous allons présenter la solution technique dans Google Tag Manager (balise HTML personnalisée) qui orchestre le tout. En plus de cela, chaque sous-section détaillera comment envoyer l’information respective à Google Analytics en tant que dimension personnalisée. Fondamentalement, tout ce que vous aurez à modifier est votre balise de vue de page principale, car c’est la seule qui enverra ces données à Google Analytics.

3.1. La balise HTML personnalisée

Première, créer une nouvelle balise HTML personnaliséeet ajoutez le code suivant dans.

<script>   (function() {          // Set to false if you only want to register "BACK/FORWARD"     // if either button was pressed.     var detailedBackForward = true;          // Set expiration of tab count in milliseconds. The recommended default is     // 72 hours (259200000 ms). Set to 0 if you don't want to expire the tab count.     var expireTabs = 259200000;          if (!!window.Storage) {        var openTabs  = JSON.parse(localStorage.getItem('_tab_ids')) || [],           tabId     = sessionStorage.getItem('_tab_id'),           navPath   = JSON.parse(sessionStorage.getItem('_nav_path')),           curPage   = document.location.href,           newTab    = false,           origin	= document.location.origin;        var tabCount,           redirectCount,           navigationType,           prevInStack,           lastInStack,           payload,           expiration,           newTabId;        var clearExpired = function(tabs) {                  if (expireTabs === 0) { return tabs; }         return tabs.filter(function(tab) {           try { 	        expiration = parseInt(tab.split('_')[1], 10);     	    return expiration > (new Date().getTime());           } catch(e) {             return false;           }         });                };              var updateTabExpiration = function(tabId) {                  if (expireTabs === 0) { return tabId; }         try {           newTabId = tabId.split('_');           expiration = parseInt(newTabId[1], 10);           if (expiration > new Date().getTime()) {             return tabId;           } else {             newTabId = newTabId[0] + '_' + (new Date().getTime() + expireTabs);             sessionStorage.setItem('_tab_id', newTabId);             return newTabId;           }         } catch(e) {           return tabId;         }              };              var getBackForwardNavigation = function() {                  if (detailedBackForward === false) {           return 'BACK/FORWARD';         }          if (navPath.length < 2) {           return 'FORWARD';         }          prevInStack = navPath[navPath.length-2];         lastInStack = navPath[navPath.length-1];          if (prevInStack === curPage || lastInStack === curPage) {           return 'BACK';         } else {           return 'FORWARD';         }        };        var removeTabOnUnload = function() {          var index;          // Get the most recent values from storage         openTabs = JSON.parse(localStorage.getItem('_tab_ids')) || [];         tabId    = sessionStorage.getItem('_tab_id');          openTabs = clearExpired(openTabs);                  if (openTabs.length && tabId !== null) {           index = openTabs.indexOf(tabId);           if (index > -1) {             openTabs.splice(index, 1);           }           localStorage.setItem('_tab_ids', JSON.stringify(openTabs));         }        };        var generateTabId = function() {          // From https://stackoverflow.com/a/8809472/2367037         var d = new Date().getTime();         if (typeof performance !== 'undefined' && typeof performance.now === 'function'){           d += performance.now(); //use high-precision timer if available         }         return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function (c) {           var r = (d + Math.random() * 16) % 16 | 0;           d = Math.floor(d / 16);           return (c === 'x' ? r : (r & 0x3 | 0x8)).toString(16);         }) + (expireTabs > 0 ? '_' + (new Date().getTime() + expireTabs) : '');        };              var validNavigation = function(type, newTab) {                  // Return false if new tab and any other navigation type than         // NAVIGATE or OTHER. Otherwise return true.         return !(newTab === true && (type !== 0 && type !== 255));              };        if (tabId === null) {         tabId = generateTabId();         newTab = true;         sessionStorage.setItem('_tab_id', tabId);       } else {         tabId = updateTabExpiration(tabId);       }                     openTabs = clearExpired(openTabs);         if (openTabs.indexOf(tabId) === -1) {         openTabs.push(tabId);         localStorage.setItem('_tab_ids', JSON.stringify(openTabs));       }        tabCount = openTabs.length;        if (!!window.PerformanceNavigation) {         navPath = navPath || [];         redirectCount = window.performance.navigation.redirectCount;         // Only track new tabs if type is NAVIGATE or OTHER         if (validNavigation(window.performance.navigation.type, newTab)) {           switch (window.performance.navigation.type) {             case 0:               navigationType = 'NAVIGATE';               navPath.push(curPage);               break;             case 1:               navigationType = 'RELOAD';               if (navPath.length === 0 || navPath[navPath.length-1] !== curPage) {                 navPath.push(curPage);               }               break;             case 2:               navigationType =...
Source : www.simoahava.com

Articles similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page
Index