In Tribune expert

En février dernier, Alexandre NABOKOV a abordé dans son article la question de migrer sur le nouvel outil : Google Analytics App + Web property. Le but fût de vous présenter les nouveaux concepts qui différencient App + Web de son prédécesseur Universal Analytics, sorti en 2013. Cette présentation débouche sur une recommandation, pour l’instant, de l’employer uniquement sur App (l’outil continue d’évoluer). Cependant, il faut garder une approche agnostique quant à son arrivée future également sur le Web.

Effectivement, dû à une pluralité grandissante des systèmes (App, SPA, CMS, etc.), il n’y a pas de méthode de taggage idéale pouvant convenir à chacun d’entre eux. C’est tout de même le défi que se lance App + Web qui veut s’adapter de manière plus générale via un emploi uniquement d’événements et leurs paramètres.

Pour rappel, la propriété App + Web s’associe à “Google Analytics pour Firebase” (ou “GA4F”) afin de collecter les données.

L’outil GA4F (ou App + Web) comporte une approche nouvelle sur la visualisation de page/écran + événement en brisant ce concept fondamental issu de Universal Analytics. On cherche ici à obtenir une vision directe sur les “activités” de l’utilisateur avant de regarder quels écrans/pages vues sont vues ou quels clics sont effectués.

Les types de résultats tels que les événements personnalisés et les pages vues sont consolidés en événements

Pour mieux comprendre le propos, voici les définitions des anciens événements versus les nouveaux :

  • Un “événement” dans Universal Analytics représente toute action de suivi en dehors des pages vues : clic, impression, envoi de formulaire, erreur, etc.
  • Un “événement” dans Google Analytics pour Firebase (GA4F) a un concept plus large : “…any distinct action occurring at a distinct time associated with a user” (source). On peut l’apparenter à un “hit” sur Universal Analytics, voir une “activité” de l’utilisateur.

Maintenant que nous comprenons mieux ce que sont les événements, voyons les meilleures pratiques à adopter lors de leurs installations via GA4F.

De bonnes pratiques pour éviter les erreurs courantes

Le maître mot est de faire attention à ne pas reproduire certaines habitudes prises avec Universal Analytics, voici quelques recommandations pour bien démarrer un nouveau projet de taggage :

Organiser ses projets Firebase et propriétés App + Web

Il faut garder à l’esprit que Firebase comporte une vaste gamme de solution en plus de l’Analytics. Dans une structure d’entreprise, cela signifie que plusieurs équipes différentes peuvent être amenées à intervenir sur l’outil. Par conséquent, il serait mal avisé d’avoir un même projet Firebase pour des apps ou sites totalement différents.

De plus, l’outil possède une logique avec ses restrictions qui risquent de vous complexifier la tâche :

  • Utiliser des noms d’événements uniques pour suivre les conversions avec l’option “Mark as conversion” (source).
  • Dans l’interface utilisateur, vous ne pouvez activer que 50 paramètres d’événements textuels et 50 paramètres numériques personnalisés pour tous vos événements (source). Si vous passez le même paramètre sur deux événements, il compte deux fois !

Il n’est plus question ici d’avoir uniquement un même événement “click” qui, suivant sa valeur dans un paramètre personnalisé (par exemple “lead submitted”), vous permettra de retrouver vos informations sur les conversions. S’ajoute la restriction sur le nombre de paramètres personnalisés pouvant être activés. Avoir un trop grand nombre de sites et Apps différents et donc des événements uniques avec leurs paramètres associés paraissent peu envisageables dans un même projet si on souhaite un taggage enrichit.

Ces contraintes impliquent aussi de faire attention sur le nombre d’événements distincts définis. Pour le moment, vous êtes limité à 500 noms d’événement distincts (source). Cela peut surcharger la lecture dans votre interface utilisateur. Pour conclure, vous pouvez prévoir d’avoir des noms d’événements génériques sur les actions que les utilisateurs entreprennent (clic, video_play, etc.) et utiliser des événements distincts pour les actions que vous considérez comme plus importantes (conversions). Il est aussi possible d’envisager des doublons entre le taggage de vos événements génériques et celui des événements distincts.

Par ailleurs, la connexion à la propriété App + Web se fait au niveau du projet Firebase. Suivant l’évolution de l’outil, il sera peut-être envisageable d’avoir une réconciliation des données de vos sites et apps à ce niveau (Rollup). À moins que le choix de Google se porte sur des réconciliations au niveau de BigQuery.

Utilisez les événements suggérés lorsque cela est possible

L’automatisation du taggage des événements suggérés (voir la liste complète ici) permet un gain de temps pour le Digital Analyste, comme pour le développeur. Par exemple sur mobile, si vous configurez correctement vos UIViewController (iOS) ou Activity (Android) suivant une nomenclature définie, l’événement suggéré “screen_view” capturera automatiquement des paramètres supplémentaires tels que le titre et le nom de la page (source). Cela permettra d’autant plus d’alléger vos plans de taggage et intégrations en vous concentrant sur les autres événements.

Le scope de variables utilisateur avec les User Properties

Avec Universal Analytics, nous pouvons définir nos dimensions personnalisées suivants trois principaux scopes : hit, session et utilisateur (voir la signification des scopes ici). Le paramètre d’événement reprenant le scope du hit, il aurait été inconcevable de ne pas avoir de paramètres au moins sur un scope utilisateur. C’est là qu’interviennent les User Properties ! Tout en étant décorrélées des événements, ce sont elles qui vont nous apporter des informations relatives à notre utilisateur (is_logged,  favorite_food,  etc.). Il faudra donc penser sur quelles activités elles devront apporter une nouvelle valeur.

Pour revenir au concept de session d’avoir un délai d’expiration de 30 minutes, il ne disparaît pas dans les propriétés App + Web. Cependant, de nouvelles mesures ont été ajoutées comme “Engaged Sessions” (dans le rapport “Comportement”). Pour une meilleure compréhension de l’enjeu, ces mesures ont été documentées par Krista Seiden.

Et bien-sûr, créer et maintenir une bonne documentation

Une bonne documentation est essentielle. Même si vous ne configurez qu’un seul site Web ou App, il n’y a aucun autre moyen de s’assurer que votre code de suivi fait ce qu’il est censé faire. Une personne se doit donc d’écrire quelque part les instructions de taggage. Et si vous gérez des données de plusieurs dispositifs, c’est encore plus important. En revanche, rien de nouveau par rapport à Universal Analytics. Une bonne documentation claire et cohérente a toujours été la meilleure arme du Digital Analyste pour mener à bien sa mission.

Le point ici est qu’il faut parfois repenser de zéro cette documentation pour ne pas repartir d’une logique que l’on pouvait avoir avec Universal Analytics. Communément appelé “plan de taggage”, il se doit d’inclure :

  • Les “Business requirements” du métier et ainsi les questions auxquelles les données Analytics collectées répondront.
  • Les listes d’événements, paramètres et user properties (avec une description pour chacun) que vous souhaitez utiliser pour répondre aux exigences business. Prévoir aussi une partie pour expliquer et configurer les événements suggérés.
  • Informations relatives au projet (utile quand vous en gérez plusieurs).
  • Un plan de recette afin de valider que vos données sont correctement configurées.
  • Une bonne idée, surtout si ce n’est pas toujours les mêmes qui intègrent, est d’inclure les instructions pour l’équipe de développement dans le même document.

Si vous êtes à la recherche d’un template, j’ai trouvé l’exemple de Ken Williams que vous pouvez copier et modifier pour ne pas partir d’une feuille blanche.

Conclusion

Vous l’aurez compris, les propriétés App + Web associées à Firebase apporteront un bouleversement dans notre manière d’interpréter les données digitales. Bien sûr, ce que nous avons appris et maîtrisé sur Universal Analytics ne partira pas pour autant à la poubelle. Il faudra pourtant prendre le virage sur ce changement de logique qui se veut plus accessible aux autres sources de données (autre que Digital) et imaginer, espérer, se convaincre… qu’un jour tous nos systèmes d’informations communiqueront sans efforts et complexités ! Gardez à l’esprit que ces innovations peuvent nous apporter plus de temps pour des analyses avancées et ainsi démontrer l’impact réel du Digital sur le Business.

Un peu de philosophie de vie pour finir : n’oublions surtout pas de continuer à apprendre et à nous renouveler que ce soit dans nos domaines respectifs ou en élargissant avec de nouvelles compétences. Cela représente une des clés de notre épanouissement dans le travail qui, il faut le reconnaître, prend une part importante dans nos vies.

Recommended Posts
Nous contacter

AVISIA