Création de rapports sur les paramètres personnalisés dans Google Analytics : application + Web

Dans Google Analytics : Application + Web, vous collectez événements. Un événement diffère d’un autre événement par la Nom il utilise. Un événement qui porte le nom page_view est différent, disons, d’un événement portant le nom file_download.

Ce sont tous des trucs banals. Tu sais ça.

Cependant, le changement fondamental introduit par App + Web, par rapport à Universal Analytics, est la façon dont paramètres d’événement sont collectés et traités.

Cela devient plus compliqué qu’il ne devrait l’être. La complication provient du fait qu’il existe plusieurs composants dans la façon dont App + Web gère les paramètres d’événement, notamment :

• Temps de collecte des données – limitation du nombre de paramètres pouvant être collecté avec le coup.
• Temps de traitement des données – les événements sont traités et les paramètres et leurs valeurs sont affichés dans les vues de flux en temps réel. Un maximum de 25 paramètres personnalisés inclus dans le hit sont mis à la disposition des rapports et le Exportation BigQuery (en supposant que vous l’ayez activé pour votre propriété Application + Web).
• Temps de rapport des données – pour pouvoir réellement segmenter et rendre compte de ces paramètres, vous devez les activer en tant que paramètres personnalisés dans vos rapports. C’est l’objet principal de l’article que vous lisez.

Collecte de données – limite de paramètres

Google Analytics : App + Web a la même limitation que Google Analytics pour Firebase (ce qui est logique, car ils partagent la même infrastructure technique) – vous ne pouvez que envoyer Jusqu’à 25 paramètres d’événement personnalisés par coup. C’est en plus de les paramètres collectés automatiquement (tels que page_location pour le page_view un événement).

Par exemple, j’ai ici un événement personnalisé avec 26 paramètres personnalisés :

Lorsque cette balise est déclenchée sur la page Web, les 26 paramètres personnalisés sont expédié avec le coup.

Dans l’interface de reporting App + Web, seuls 25 paramètres personnalisés sont mis à disposition. Ce qui le rend encore plus malheureux, c’est qu’il ne semble pas y avoir de modèle discernable pour lequel le paramètre est supprimé. Dans l’exemple ci-dessous, le paramètre param21 est celui qui a été abandonné.

La prochaine fois que j’ai envoyé l’événement, c’était param04 qui a été abandonné. Il me semble que l’abandon des événements est complètement aléatoire, ce qui est dommage. Je me serais attendu à un tri alphabétique et à une troncature de la tête ou de la queue de la liste.

Dans tous les cas, vous devez en être conscient. Si vous souhaitez traiter les paramètres d’événement dans l’interface utilisateur de création de rapports Application + Web, vous devez vous assurer d’envoyer un maximum de 25 paramètres d’événement personnalisés par hit.

Traitement des données – temps réel

Lorsque vous envoyez des hits avec des paramètres personnalisés, vous pourrez voir les paramètres dans des rapports en temps réel.

Les DebugView est un endroit idéal pour déboguer les paramètres personnalisés. Si vous utilisez Google Tag Manager, le fait d’accéder au mode Aperçu de GTM automatiquement signaler les accès Application + Web comme provenant d’un appareil de débogage.

Recherchez votre agent utilisateur dans la liste Déboguer les appareils, puis cliquez sur l’événement que vous souhaitez analyser. Les paramètres seront affichés dans l’un des widgets DebugView.

Vous pouvez également voir les paramètres dans le Temps réel rapport (StreamView dans le jargon Firebase).

Choisir Événements comme filtre, puis cliquez sur le Meilleurs événements widget, recherchez votre événement personnalisé et développez ses paramètres.

Vous pouvez également trouver les paramètres dans le Tous les évènements rapport, en supposant que les événements ont été collectés il y a suffisamment longtemps pour apparaître dans le rapport. Après avoir cliqué sur le nom de l’événement pour accéder à son tableau de bord, vous pouvez voir un Temps réel widget où vous pouvez choisir de filtrer par nom de paramètre.

Comme indiqué précédemment, ceux-ci sont tous soumis à la limite de 25 paramètres dans la collecte de données. Tous les rapports de l’interface utilisateur de création de rapports Google Analytics : application + Web affichent la liste tronquée.

Traitement des données – Exportation BigQuery

Une fois de plus, je professe mon amour pour Google BigQuery. Activer l’exportation BigQuery pour vos données Google Analytics : Application + Web est la chose la plus intelligente que vous puissiez faire aujourd’hui, alors ne tardez pas !

L’exportation BigQuery vous donne les données brutes de votre collection de données Application + Web.

Il est soumis au même Limitation de 25 paramètres personnalisés par coup comme interface de rapport, mais vous n’avez pas à vous soucier de activation paramètres personnalisés pour les rapports dans BigQuery : tous les paramètres et leurs valeurs par appel sont collectés dans BQ.

Rapport de données – activation des paramètres personnalisés

Et maintenant, nous arrivons à la viande de cet article.

Google Analytics : App + Web vous donne 50 paramètres de texte et 50 paramètres numériques que vous pouvez activer comme paramètres personnalisés dans vos rapports. C’est par événement et par projet.

Cela signifie que si vous souhaitez inclure vos paramètres personnalisés dans vos rapports en tant que leurs propres widgets, et si vous souhaitez les utiliser dans les rapports d’analyse (tels que l’exploration), vous devez d’abord permettre ces paramètres pour les rapports.

Chaque fois que vous activez un paramètre pour un événement, vous épuisez le quota disponible pour votre projet. Donc, si vous voulez utiliser page_location dans vos rapports personnalisés, vous devez l’activer pour page_view événement en tant que paramètre de texte, et maintenant vous avez 49 paramètres de texte restant à activer dans votre projet.

Le kicker est que si vous activez custom_parameter_01 pour un événement nommé my_custom_eventil épuisera le quota de 1. Ensuite, si vous souhaitez utiliser custom_parameter_01 avec un autre événement, par exemple my_other_eventvous devez également l’activer pour CELA, et il épuisera à nouveau le quota de 1.

Ces quotas sont assez stricts, et j’espère qu’ils seront levés. Si ce n’est pas le cas, vous aurez au moins l’exportation BigQuery sur laquelle vous appuyer.

Quoi qu’il en soit, à permettre paramètres personnalisés, vous devez accéder à Événements -> Tous les évènementspuis cliquez sur le petit menu d’action à la fin de la ligne avec le nom de l’événement.

Note! Cela signifie que vous devez d’abord collecter l’événement avant de pouvoir activer ses paramètres. Espérons qu’il sera possible à un moment donné d’activer les paramètres pour les événements qui n’ont pas encore été collectés.

Dans ce menu, choisissez Modifier les rapports sur les paramètres.

Vous pouvez toujours cliquer sur le Rapport sur les paramètres en haut du rapport Tous les événements pour afficher une liste des événements pour lesquels des paramètres personnalisés sont activés, et vous pouvez cliquer sur le nom de l’événement pour modifier les paramètres.

Une fois que vous voyez le sélecteur de paramètre, vous pouvez rechercher le nom du paramètre dans la liste. La liste affichera tous les paramètres qui ont été collectées avec l’événement donné dans la plage de dates sélectionnée.

Si vous trouvez le paramètre, sélectionnez-le et cliquez sur AJOUTER.

Vous pouvez également ajouter un paramètre qui n’apparaît pas dans la liste. Tapez simplement son nom dans le champ de recherche et cliquez sur Ajouter.

Une fois que vous avez ajouté le paramètre, vous pouvez définir son taperce qui a un impact sur ce que vous pouvez réellement faire avec le paramètre dans les rapports.

Une fois que vous êtes satisfait, cliquez sur Sauver pour enregistrer les modifications.

Rappelez-vous, il y a un quota – prenez vos décisions avec soin!

Archivage d’un paramètre

Lorsque vous modifiez des paramètres, vous pouvez également choisir de archive un paramètre pour libérer du quota.

Note! Si vous archivez un paramètre, il est n’est plus disponible dans les rapports. Le changement est donc rétroactif – les données seront ne pas être récupérable.

L’export BigQuery est, encore une fois, votre meilleur ami, car l’archivage d’un paramètre ne le supprimera pas des tables BigQuery que vous avez déjà collectées.

Résumé

J’espère que ce guide a réussi à faire la lumière sur le fonctionnement des paramètres d’événement dans App + Web. L’accent a été spécifiquement mis sur paramètres personnaliséscar ils semblent être la plus grande source de confusion.

Il est important de vous débarrasser de l’analogie avec les dimensions personnalisées et les statistiques personnalisées dans Universal Analytics. Les rapports personnalisés dans Application + Web présentent des différences fondamentales par rapport à l’ancien Google Analytics, en particulier dans la manière dont le même nom de paramètre dans différents événements est traité comme une entité différente à chaque fois, et dans la manière dont l’archivage d’un paramètre le supprime également de vos données collectées.

Comme pour Universal Analytics, les paramètres personnalisés ne sont pas rétroactifs, ils ne commenceront donc à collecter des données dans les rapports qu’après avoir été activés par événement.

Je ne sais pas encore quoi penser des paramètres personnalisés. Dans l’interface de création de rapports, ils sont étrangement handicapés par les quotas et le processus de suppression strict et rapide, mais dans l’exportation BigQuery, ils sont vraiment précieux.

Nous verrons comment les paramètres personnalisés évoluent à mesure que la version bêta arrive à maturité ; Je pense qu’ils joueront un rôle important dans la décision de migrer d’Universal Analytics vers App + Web.