L’un des mythes entourant Google Analytics est que le premier coup d’un session devrait toujours être un page vue. Cela a du sens – les sessions sont initialisées avec un atterrissage pageet ont donc besoin d’un page vue d’en avoir un.
Cependant, dans cet article, je veux vous montrer empiriquement comment ce mythe n’est que cela – un mythe.
Il y a peu d’impact perceptible si le premier appel d’une session est un événement, et GA est plus que capable d’assembler le premier événement avec la page vue suivante dans un session entité.
Les trois répercussions que j’ai pu trouver étaient :
-
Entrées et Séances ne correspond pas à la Page dimension. Voir ici pour quelques détails, aussi.
-
Flux de comportement Le rapport attribue la page d’événement en tant que “Page de destination” et la page envoyée avec la page vue en tant que “Page de démarrage”.
-
Lieu d’achèvement de l’objectif pour un objectif d’événement défini pour l’événement en question montre
(entrance)si l’événement était le premier hit de la session.
Je les explorerai plus tard dans l’article.
Configuration des tests
Voici comment j’ai testé cela. J’ai créé quatre cas de test. Chaque paire d’appels événement-page vue était contenue dans sa propre session (à l’aide de la sessionControl paramètre).
Tous les événements ont été envoyés à partir de la page /, alors que les appels de pages vues avaient toujours un paramètre de page différent. C’était principalement pour voir l’impact de l’événement page paramètre sur l’emplacement d’achèvement de l’objectif (il n’y en avait pas).
J’ai également créé un Objectif de l’événement qui correspondait à tous les événements envoyés avec ce test.
Voici les cas de test :
-
Événement non interactif comme 1er coup, page vue au
/test-event-1comme 2e coup. -
Événement interactif comme 1er coup, page vue au
/test-event-3comme 2e coup. -
Page vue au
/test-event-5comme 1er coup, événement non interactif comme 2e coup. -
Page vue au
/test-event-7comme 1er coup, événement interactif comme 2e coup.
Voici à quoi ressemblait un exemple de commande. C’est pour le première cas de test:
ga('create', 'UA-XXXXXX', {name: 'test'}); ga('test.send', 'event', 'eventFirstHit', 'nonInteractive', 'noPath', {nonInteraction: true, sessionControl: 'start', campaignSource: 'test_event_1', campaignMedium: 'test_event_1'}); ga('test.send', 'pageview', {page: '/test-event-1'}); La première ligne crée le tracker.
La deuxième ligne distribue l’événement. Vous pouvez ignorer le noPath l’étiquette et le campaignSource/Medium paramètres – ils ont juste été utilisés pour contrôler l’analyse du test dans GA.
C’est ce que le Quatrième le code du cas de test ressemblait à :
ga('create', 'UA-XXXXXX', {name: 'test'}); ga('test.send', 'pageview', {sessionControl: 'start', page: '/test-event-7', campaignSource: 'test_event_7', campaignMedium: 'test_event_7'}); ga('test.send', 'event', 'eventNotFirstHit', 'Interactive', 'noPath'); Résultats
Voici les résultats du test.
La première chose à noter est que aucun des cas de test n’a produit de session avec Landing Page (not set). C’est un faux-fuyant dont j’aborderai brièvement le sujet dans le prochain chapitre.
Cas d’essai 1
| Article | La description |
|---|---|
| 1er coup | Événement non interactif sur / |
| 2ème coup | Page vue sur /test-event-1 |
| Page de destination | /test-event-1 |
| Lieu d’achèvement de l’objectif | (entrance) |
| Métrique des sessions | /test-event-1: 0, /: 1 |
| Entrées métrique | /test-event-1: 1, /: 0 |
Cas d’essai 2
| Article | La description |
|---|---|
| 1er coup | Événement interactif sur / |
| 2ème coup | Page vue sur /test-event-3 |
| Page de destination | /test-event-3 |
| Lieu d’achèvement de l’objectif | (entrance) |
| Métrique des sessions | /test-event-3: 0, /: 1 |
| Entrées métrique | /test-event-3: 1, /: 0 |
Cas d’essai 3
| Article | La description |
|---|---|
| 1er coup | Page vue sur /test-event-5 |
| 2ème coup | Événement non interactif sur / |
| Page de destination | /test-event-5 |
| Lieu d’achèvement de l’objectif | /test-event-5 |
| Métrique des sessions | /test-event-5: 1 |
| Entrées métrique | /test-event-5: 1 |
Cas d’essai 4
| Article | La description |
|---|---|
| 1er coup | Page vue sur /test-event-7 |
| 2ème coup | Événement interactif sur / |
| Page de destination | /test-event-7 |
| Lieu d’achèvement de l’objectif | /test-event-7 |
| Métrique des sessions | /test-event-7: 1 |
| Entrées métrique | /test-event-7: 1 |
Aperçu des résultats
Comme vous pouvez le voir, même si l’événement a été envoyé en tant que premier hit d’une session, cela n’a pas provoqué l’implosion du cosmos. Google Analytics est néanmoins capable de créer la session, en traitant l’événement comme le premier coup de la session et en ajoutant normalement les accès suivants (autres événements, pages vues) à la session.
Les principaux impacts de l’envoi d’un événement en tant que premier hit d’une session sont :
-
Les Page de destination est associé à la première page vue de la séance. La page envoyée avec l’appel d’événement ne peut pas être la page de destination.
-
Lors d’une interrogation sur le Page dimension, la Entrée est toujours incrémenté pour la page envoyée avec le page vuemais le Séances la métrique est incrémentée pour le premier hit – non interactif ou interactif.
-
Lieu d’achèvement de l’objectif sera toujours l’URI du plus récent vue de la page envoyé avant que l’objectif de l’événement ne soit atteint. Si l’événement est le premier accès de la session, il n’y a pas de page vue précédente, donc l’objectif a lieu à
(entrance).
Page de destination (non définie)
L’un des faux-fuyants entourant les événements et les pages vues est que l’envoi d’un événement en tant que premier appel d’une session entraîne la Page de destination dimension montrant (not set). C’est quelque chose que Google Tag Assistant met en garde.
La page de destination sera (not set) uniquement si la session n’a enregistré AUCUNE page vue. Étant donné que la page de destination est toujours l’URI de la première page vue envoyée dans la session, une session sans page vue n’aura pas de page de destination.
Envoyer un événement comme premier hit d’une session n’implique pas automatiquement que la session n’aura pas de pages vues. Prétendre le contraire est un non séquentiel.
Notez que si vous avez quelconque événements se déclenchant sur votre page, vous risquez toujours d’avoir des sessions avec uniquement les événements. Tout ce qu’il faut, c’est que l’utilisateur fasse une pause de 30 minutes après l’envoi de la page vue, puis fasse défiler la page vers le bas, en déclenchant un événement de défilement vous avez configuré.
Cela démarrera sa propre session (puisque la précédente a expiré après que le délai de 30 minutes ait été atteint). Si cet événement de défilement n’est pas suivi d’une page vue dans le délai d’expiration de la session, l’événement sera contenu dans sa propre session avec la page de destination (not set).
Mais, si l’événement est suivi d’une page vue avant l’expiration du délai d’expiration de la session, la page de destination sera le chemin de la page vue. Rappelez-vous cela.
Session avec uniquement des événements non interactifs
De même, une séance avec uniquement les événements non interactifs aura une page de destination de (not set).
Cependant, contrairement aux sessions avec uniquement des événements interactifs (ou un mélange d’événements interactifs et non interactifs), les sessions avec uniquement des événements non interactifs ne pas incrémenter le Séances statistique, car cela nécessite un appel interactif. Ils faire incrémenter le Utilisateurs métrique, c’est pourquoi vous verrez parfois plus d’utilisateurs que de sessions.
Mais cela n’a rien à voir avec le fait que les événements se déclenchent avant la consultation de la page au démarrage d’une session.
Résumé
Comme le montrent mes tests ci-dessus, c’est OK pour qu’un événement précède l’appel de page vue lorsqu’une session démarre. Vous n’avez pas à vous précipiter sur le séquençage des balises dans Google Tag Manager pour résoudre ce “problème” – les implications ne sont pas du tout graves.
Alors pourquoi est-ce toujours averti? Eh bien, mis à part l’incompréhension du fonctionnement des sessions, il y a une graine de vérité à être prudent si vous avez des événements qui peuvent se déclencher avant la page vue sur une page donnée. C’est potentiellement dangereux si vous définissez des paramètres de campagne avec l’appel de page vue qui manque dans l’appel d’événement.
Depuis le page vue est le lien de la session de Google Analytics, il s’ensuit que le plus grand soin est apporté à s’assurer que le hit de page vue a toutes les modifications nécessaires de session, de campagne et de cookie. Cette focalisation déséquilibrée peut être problématique dans Google Tag Manager, où chaque hit a son propre objet de suivi unique, et donc les hits ne le font pas. hériter tout à partir d’un tracker commun, comme avec analytics.js et gtag.js.
En d’autres termes, vous pouvez modifier votre appel de page vue pour inclure des champs définissant la campagne tels que campaignSource et campaignMediumou vous pouvez modifier son champ Emplacement du document pour avoir Paramètres UTM ajouté manuellement à la chaîne d’URL. Ou, vous pourriez même réécrire le clientId champ dans le hit de page vue seul.
L’essentiel ici est cohérence. Toute modification des paramètres de campagne ou de session dans les hits ou tags individuels doit être appliquée à tous les hits ou tags qui peuvent se déclencher sur la même page.
Étant donné qu’un événement atteint est capable de créer et de remplir une session par lui-mêmeil est essentiel que cet événement corresponde aux paramètres de campagne de l’appel de page vue, et vice versa.
Si vous faites cela, vous éviterez que des sessions malveillantes ne démarrent simplement parce qu’un appel d’événement avait des paramètres de campagne totalement différents de l’appel de page vue. Dans Google Tag Manager, la meilleure façon d’atténuer ce problème consiste à utiliser la variable Paramètres de Google Analytics.
Pensez-vous que j’ai raté quelque chose de crucial dans ce test ? S’il vous plaît laissez-moi savoir dans les commentaires.
