Dans cet article, je vais essayer de clarifier la fonctionnalité compréhensible du protocole de mesure dans Google Analytics 4.
Le protocole de mesure est un moyen d’envoyer des événements à Google Analytics 4 directement à partir d’une machine capable d’envoyer des requêtes HTTP (comme un serveur Web). Il s’agit d’une méthode de collecte alternative aux bibliothèques côté client de Google Tag et du SDK Firebase.
Le protocole de mesure dans GA4 est très différent de son prédécesseur dans Universal Analytics. Dans Universal Analytics, le protocole de mesure était les mécanisme de collecte, le même protocole étant utilisé pour les hits de bibliothèque côté client et les hits de serveur à serveur.
Dans GA4, MP est vraiment sa propre chose. Il est complètement découplé des bibliothèques côté client et fonctionne avec un schéma différent, un ensemble de règles différent et un profil de données différent dans les rapports.
L’une des questions urgentes avec le protocole de mesure était de savoir s’il était possible d’insérer des événements dans le passé afin qu’ils soient associés à la bonne session.
Dans cet article, je vais vous montrer que oui, c’est possible. Continuer à lire.
Résumé rapide
Pour envoyer un hit de protocole de mesure avec succès et l’associer à la bonne session, vous devez mettre en place trois éléments :
- Les identité du clientque vous pouvez obtenir auprès de BigQuery (
user_pseudo_id), les_gacookie ou en utilisant le modèle personnalisé de l’API GTAG GET. - Les ID de sessionque vous pouvez obtenir à partir de BigQuery (paramètre d’événement nommé
ga_session_id), les_ga_<measurement ID>cookie ou en utilisant l’API GTAG GET. - Les horodatage (en microsecondes) de l’événement, défini sur un maximum de 72 heures dans le passé, mesuré à partir du moment où vous envoyez la demande de protocole de mesure.
L’horodatage doit être choisi de sorte qu’il se produise pendant que la session (représentée par l’ID de session) est toujours active.
Si vous avez ces trois éléments en place, l’événement que vous envoyez sera associé au source/support de la session de la session active.
Utilisez Google BigQuery pour trouver les paramètres
J’espère que je me suis maintenant établi comme le fanboy ultime de Google BigQuery. Je n’ai jamais gardé le secret que je pense que c’est le seul moyen réellement utile d’accéder aux données de Google Analytics 4. Nous avons même construit un cours en ligne sur Simmer autour de ce processus de réflexion.
Pour accéder aux trois paramètres répertoriés dans le chapitre précédent, BigQuery est inestimable. Tant que vous pouvez identifier la session que vous souhaitez augmenter, il n’y a pas grand-chose d’autre à faire.
Par exemple, voici la requête que j’ai utilisée pour trouver la session exacte dans laquelle je veux insérer mon hit.
SELECT user_pseudo_id, event_timestamp, event_name, event_params FROM `project.dataset.table` WHERE user_pseudo_id = '1871825471.1628513380' AND (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id' ) = 1674465678
Les WHERE clause spécifie l’ID client (user_pseudo_id) et ID de session (imbriqué event_params[].ga_session_id), et je peux ensuite utiliser la liste des événements pour trouver le “slot” correct pour mon horodatage.
Les event_timestamp le champ est déjà en microsecondes, donc si je veux que mon événement de protocole de mesure soit ajouté après un événement spécifique, je dois juste m’assurer que l’horodatage que j’ai défini dans le hit du protocole de mesure est supérieur à cela.
Une autre raison pour laquelle j’ai choisi cette session particulière comme exemple est que si vous regardez la page_view événement, vous pouvez voir que ses paramètres d’événement indiquent que la session est marquée avec le linkedin.com / referral valeurs source/support.
Envoyez le coup
Pour tester cela, j’ai utilisé l’incroyable outil Event Builder. Il vous permet de faire tourner le protocole de mesure en générant le hit pour vous. Vous devrez bien sûr fournir tous les paramètres requis en suivant la documentation.
Dans Event Builder, j’ai ajouté le Clé secrète de l’APIles ID de mesureles identité du clientles Nom de l’événementet le horodatage dans leurs champs obligatoires.
Fait important, le horodatage a été fixé à quelques microsecondes après les page_view événement que j’ai vu dans BigQuery. Cela permet de s’assurer que la session “démarre” correctement du point de vue de BigQuery. Vous souhaiterez bien sûr positionner cet événement de sorte qu’il soit logiquement placé dans l’entonnoir auquel il appartient. Par exemple, si vous envoyez achat événements, vous souhaiterez placer l’événement après la collecte des événements de paiement.
Enfin, dans Détails de l’évènement j’ai ajouté un page_location (ce n’est pas nécessaire – cela faisait partie d’un autre test que j’exécutais) ainsi que le ID de session J’ai reçu de BigQuery (ou des cookies de l’utilisateur).
Une fois prêt, j’ai cliqué sur le Valider l’événement bouton, suivi de Envoyer à GA.
Rapports en temps réel
Tout d’abord, l’événement apparaît dans le Temps réel rapports dans GA4.
Ceci est intéressant pour deux raisons.
Tout d’abord, l’événement était expédié en temps réel, mais son horodatage réel remonte à quelques jours.
Deuxièmement, la documentation du protocole de mesure indique que si vous souhaitez voir le hit apparaître dans les rapports en temps réel, il doit engagement_time_msec paramètre – cela ne semble pas être vrai.
Rapports standards
Après avoir attendu quelque 24 heures pour faire bonne mesure, j’ai construit un simple Forme libre Rapport d’exploration, où j’ai filtré le nom de l’événement avec son Source/support de la session évaluer. Voici à quoi cela ressemblait :
Cela a confirmé que l’événement était associé à la session source et le support auquel il a été envoyé à l’aide du paramètre d’horodatage.
BigQuery
Enfin, ma source ultime de vérité, j’ai exécuté à nouveau la même requête que ci-dessus, et voici ce que j’ai vu :
L’événement est placé exactement là où je voulais le placer.
En regardant cela, vous pouvez voir une mise en garde majeure en ce qui concerne le protocole de mesure :
Les événements n’héritent pas des propriétés de “la session”.
Il n’y a pas de “portée de session” en ce qui concerne la sortie BigQuery. Au lieu de cela, les événements sont affichés avec les paramètres de leurs demandes réelles.
Ainsi, en regardant simplement le rapport BigQuery, il serait impossible de déterminer si l’attribution de la source/du support de la session a réellement fonctionné, car BigQuery n’a pas la capacité de vous dire quelle était la source/le support d’une session donnée.
C’est pourquoi j’ai été obligé de passer par l’interface utilisateur de Google Analytics 4 pour voir si l’alignement fonctionnait réellement (et il l’a fait !).
Résumé
Cet article était une preuve de concept pour vous montrer que le protocole de mesure pour les sessions Est-ce que travail – comme le dit la documentation.
Vous avez besoin de trois paramètres pour cela : l’ID client, l’ID de session et l’horodatage (en microsecondes) du hit.
BigQuery est un excellent outil pour tester des choses, mais si vous souhaitez intégrer cette méthode à votre moteur de vente ou à quelque chose de plus sophistiqué, vous devrez récolter les paramètres requis à partir des cookies de l’utilisateur ou de l’endroit où vous stockez ces valeurs.
Enfin, je tiens à souligner un point extrêmement important concernant Google Analytics et le protocole de mesure :
Google Analytics n’est pas censé être une représentation exacte de TOUTES LES DONNÉES. Vous pouvez utiliser l’outil comme vous le souhaitez, bien sûr, mais c’est un analyse marketing un service. C’est censé te dire la performance de vos campagnes marketing en fonction du trafic sur votre site Web (ou votre application).
En d’autres termes, utiliser le protocole de mesure pour envoyer des hits hors ligne (ou côté serveur) à Google Analytics lorsque ces hits ne peuvent pas être associés à un utilisateur ou à une session réels n’est qu’une mauvaise idée. Il ajoute un parcelle de bruit à l’ensemble de données, et ces hits seront isolés du reste des données comportementales collectées par GA.
J’espère que vous avez apprécié cet article. Faites-moi savoir dans les commentaires si vous avez des questions. Je n’ai pas testé toutes les permutations (comme ce qui se passe si vous envoyez l’événement à un moment où l’ID de session n’était plus une session active), donc si vous faites vos propres tests, j’aimerais en savoir plus il.
