Comment mettre à jour vos rapports pour Google Analytics 4 sans prise de tête

Les utilisateurs de Google Analytics Universal (GAU) devront passer à Google Analytics 4 (GA4) à l'été 2023. Le principal problème avec cela est que le modèle de données et la logique de calcul des métriques sont radicalement différents dans GA4 par rapport à GAU. Après le passage à GA4, une partie des données historiques sera conservée dans la structure GAU, tandis que les nouvelles données seront stockées dans la structure GA4. Pour cette raison, les entreprises doivent déployer de sérieux efforts pour évaluer les mesures d'une année sur l'autre (YoY) après le changement (au moins 100 heures de travail pour les analystes de données de niveau intermédiaire).

Pour les analystes, cela signifie qu'ils passeront jour après jour à écrire et à organiser des pages de requêtes SQL pour aligner les métriques Google Analytics Universal et Google Analytics 4. Cependant, il existe un moyen de contourner cela! Les analystes peuvent créer des rapports ad hoc en quelques minutes sans réécrire constamment les requêtes SQL, et dans cet article, nous vous expliquons comment.

Universal Analytics disparaîtra le 1er juillet 2023 et sera remplacé par Google Analytics 4. Pour les clients de Google Analytics 360 (la version payante de GA), la période de transition a été prolongée jusqu'au 1er juillet 2024. Mais peu importe quelle version de GA vous utilisez, ce n'est qu'une question de temps avant que vos rapports soient mis à jour avec le nouveau schéma de données.

À la lumière de ce changement, l'une des tâches les plus difficiles pour les analystes consiste à fournir des données de Google Analytics Universal et de Google Analytics 4 dans un format unifié.

Circonstances qui compliquent cette tâche :

• La logique de calcul des métriques diffère considérablement entre GAU et GA4. Notamment, ces versions de produits calculent différemment même les métriques traditionnelles. Vous ne pouvez pas faire glisser toutes les mesures de GAU et GA4 dans un seul graphique et vous attendre à ce que tout se passe bien.
• Les schémas de données Google BigQuery sont également très différents. Universal Analytics applique des schémas de données basés sur les sessions, tandis que Google Analytics 4 dispose de schémas de données basés sur les événements.
• Les tableaux de bord incluent des métriques YoY et des tendances de saisonnalité. La question est donc de savoir comment continuer à utiliser des tableaux de bord avec toutes ces métriques.

Prenons un exemple précis. Supposons que nous ayons ce tableau de bord :

La partie la plus cruciale de ce tableau de bord est la métrique de saisonnalité, qui représente une comparaison de métriques spécifiques pour les périodes en cours et passées. Les données historiques et opérationnelles doivent être dans le même format pour prendre en charge les métriques YoY sur les tableaux de bord marketing.

Dans ce cas, le défi de l'analyste consiste à mettre à niveau les requêtes SQL héritées N+ pour fournir des rapports fiables à l'équipe marketing. Il est difficile de tester et de déboguer tout ce qui peut être affecté par des correctifs, même mineurs, apportés aux requêtes SQL.

Les risques liés à la transition doivent également être pris en compte. Après avoir transféré un rapport vers la nouvelle source (de GAU vers GA4), les analystes peuvent ne pas tenir compte des différences fondamentales dans le schéma de données et la logique de calcul des métriques. Par exemple, les sessions sont formées différemment : seule la première source d'utilisateurs est considérée dans GA4, et toutes les autres sources menant à une session sont négligées. Par conséquent, certaines sources de trafic ne seront pas visibles dans le rapport.

Au début, cela peut passer inaperçu. Mais dans deux à trois trimestres, un tableau de bord incorrect entraînera des dépenses publicitaires inefficaces, avec des fuites budgétaires de 30 % ou plus.

Préparer et créer des tableaux de bord nous rappelle Jenga. Chaque fois qu'ils doivent remplacer un bloc dans un rapport, les analystes croisent les doigts et espèrent que toute la structure ne tombera pas.

Chez OWOX, nous résolvons déjà avec succès des problèmes similaires lors du transfert des rapports de nos clients du schéma de données Universal Analytics (ou GA 360) vers le schéma de données Google Analytics 4. C'est pourquoi nous souhaitons partager notre solution et certaines requêtes SQL avec les lecteurs de notre blog. Espérons que ces informations vous aideront à transférer vos rapports sans maux de tête.

Notre approche de la préparation des rapports (quel que soit le domaine d'activité pour lequel ils sont créés) est basée sur des données brutes plutôt que modélisées.

Un modèle de données décrit les entités de données, leurs attributs et les relations entre les entités. Par exemple, les actions des utilisateurs sur le site Web sont fusionnées pour une session donnée, et un utilisateur peut effectuer plusieurs conversions en ligne dans une session.

Il existe quatre objets — Actions, Utilisateurs, Session et Conversion en ligne — et trois connexions : un à plusieurs entre les sessions et les actions, un à plusieurs entre l'utilisateur et les conversions en ligne, et un à plusieurs entre les sessions et conversions en ligne.

Le modèle de données reflète notre perception du monde réel et répond à des questions telles queSur quoi portent nos données ?Comment est-ce lié?Quelles conditions et restrictions appliquons-nous lorsque nous travaillons avec des données ?Un modèle de données est nécessaire pour que les gens se comprennent clairement.

La modélisation des données est le processus de transformation des données dans un format qui répond aux exigences de votre modèle de données.

• Augmentez la valeur et l'efficacité du travail d'analyse en :
• Accélération des modifications des structures de rapport et de la logique de calcul des métriques
• Réduire le coût de prise en charge des rapports et des tableaux de bord
• Simplifier les discussions et les approbations des rapports
• Améliorez la qualité des données dans les rapports en :
• Éviter les doublons lors de la mise en œuvre de la logique de calcul des paramètres et des métriques
• Avoir une couche de données qui est la source de données précises

Le modèle de données remplace de nombreux outils et décrit la logique d'un état, puisqu'il décrit les objets et leur logique de calcul (valable pour tous les états).

OWOX BI transforme les données brutes en un format prêt pour l'analyse, ce qui vous permet d'économiser des heures de préparation des données. Il intègre de manière transparente les données Universal Analytics et Google Analytics 4 dans vos rapports.

Voici un exemple de modèle de données créé à partir des données de Google Analytics :

Comme vous pouvez le constater, il existe plusieurs objets, notamment des sessions, des transactions, des pages et des appareils.

La chose la plus intéressante et la plus importante ici est que la structure de ces objets n'est pas interconnectée et n'a rien à voir avec les sources de données. Peu importe les sources utilisées pour remplir ces objets avec des données en direct (Matomo, Adobe, Google Analytics, etc.). Quelle que soit la source de données, le modèle renvoie les mêmes objets car le modèle de données représente votre entreprise. Il illustre les objets et les métriques du monde réel avec lesquels vous travaillez.

Voyons à quoi cela ressemble dans le monde réel.

Au lieu d'écrire des requêtes SQL sur des données brutes, telles que des sessions exportées depuis Universal Analytics ou des événements exportés depuis Google Analytics 4, vous pouvez créer des données modélisées. Il s'agit de tableaux universels et faciles à comprendre qui représentent des objets et des entités du monde réel, tels que des sessions, des utilisateurs et des pages vues.

Considérons des exemples spécifiques et des schémas de données.

Voici un exemple de données brutes. Voici des captures d'écran d'un schéma de données de Google BigQuery pour Google Analytics Universal (à gauche) et Google Analytics 4 (à droite).

Comme nous l'avons écrit plus haut, les schémas de données diffèrent. Nous devons trouver un moyen de lier ces données au tableau de bord de Google Data Studio.

D'après notre expérience, la construction de tables modélisées est le meilleur moyen de simplifier la préparation des données. Voici à quoi ils peuvent ressembler :

Ce sont les listes d'objets du modèle de données ci-dessus. Vous pouvez voir que la liste d'objets est la même pour Google Analytics 360 et Google Analytics 4.

Cela signifie que vous pouvez connecter votre requête de tableau de bord à ces données en utilisant les mêmes requêtes. La structure de cette requête est la même.

Voyons les principales raisons d'envisager de créer vos rapports sur des données modélisées plutôt que sur des données brutes.

1. Les données sont comme des fruits : vous devez les nettoyer avant de les mélanger.Les analystes collectent des données à partir de services et de systèmes disparates. Naturellement, la structure et le format de ces données varient selon les sources. Pour créer des rapports, les données provenant de différentes sources doivent être correctement fusionnées. En soi, les données téléchargées via des connecteurs ou divers services ETL sont inexactes (contenant des erreurs, des doublons et des écarts) et manquent d'une logique et d'une structure unifiées. Les données inexactes et fragmentées doivent être nettoyées et normalisées dans un format prêt pour l'analyse.

Avec OWOX BI, vous n'avez pas besoin de nettoyer, structurer et traiter manuellement les données. Le service normalisera automatiquement les données brutes dans un format prêt pour l'analyse.

2. Vous n'avez pas besoin de copier et de réécrire la logique métier pour chaque rapport ;par exemple, vous n'avez pas besoin de :

• Dédupliquer les transactions
• Filtrer le bot et le trafic interne
• Définir les règles de regroupement des canaux
• Définir des critères pour les nouveaux utilisateurs et les anciens utilisateurs
• Correction du suivi des paramètres UTM

Il ne fait aucun doute que chaque analyste de données a entendu des demandes de spécialistes du marketing telles que celles-ci : nous aimerions ajuster ou améliorer nos règles de regroupement de canaux en fonction des données historiques, ou nous aimerions identifier des critères pour les utilisateurs nouveaux et récurrents qui ne sont pas dans la façon dont cela fonctionne. dans Google Analytics, mais à notre manière ou Nous aimerions considérer comme renvoyant uniquement les utilisateurs qui ont effectué un achat au cours des six derniers mois.

Si vous créez des rapports basés sur des données brutes, toutes les transformations de données et les activités de préparation doivent être exécutées au niveau du rapport. Cela signifie que vous devez passer beaucoup de temps à copier la logique métier dans chaque rapport.

Si vous créez des rapports sur des données modélisées, vous n'avez pas besoin de copier la logique métier. Vous le créez une fois au stade de la modélisation.

3. La création de rapports basés sur des données modélisées accélère l'analyse ad hoc.Vous pouvez gagner du temps en écrivant de nouvelles transformations SQL et d'orchestration pour permettre une analyse annuelle.

4. Grâce à la modélisation des données, vous pouvez créer une seule source de vérité pour tous les rapports.Lorsque vous modifiez la source de données dans un rapport, vous n'avez plus à régler chaque requête problématique. Vous pouvez compter sur cette source pour les sessions, les transactions et les données d'événement.

5. Simplifiez la couche de rapport.Il est plus facile de créer des rapports sur des données modélisées que de traiter des champs imbriqués et des champs d'enregistrement, ainsi que d'écrire des fonctions compliquées de fenêtre ou même des fonctions d'extraction JSON.

1. Les données modélisées constituent une autre couche intermédiaire.L'adaptation prend du temps et vous devez également surveiller et déboguer les données modélisées.

2. JOIN complexes pour les normalisations.

3. Traitement supplémentaire des données.Afin de convertir des données dans un format de modèle, vous devez interroger les données. Nous vous conseillons d'utiliser une table de partition sur une date. Avec une table de partition construite autour des dimensions de date, vous ne pouvez mettre à jour que les données nécessaires. Vous n'avez pas à réécrire toutes les énormes tables et à payer pour toutes les données traitées et les gigaoctets ou téraoctets de données dans Google BigQuery. Vous pouvez simplement mettre à niveau et mettre à jour la partition dont vous avez besoin. Cette approche est plus économique que la manipulation de toutes les tables de données.

Afin de vous aider à gérer ces inconvénients, nous avons préparé des modèles SQL pour la modélisation des données Google Analytics 360 et Google Analytics 4. Vous pouvez les consulter en téléchargeant les documents supplémentaires fournis dans cet article.

Est-il facile de mettre à jour vos rapports avec le nouveau schéma de données Google Analytics 4 ? Utiliser des données modélisées. Au lieu de créer des rapports sur des données brutes, vous pouvez créer des tableaux plats universels et faciles à comprendre sur les schémas GA Universal et GA 4.

Cela éliminera le besoin de copier des données et d'insérer une logique de normalisation dans des dizaines de requêtes SQL. Vous le ferez une fois à l'étape de modélisation des données. Bien qu'il ne s'agisse pas d'une solution miracle pour chaque projet, c'est la méthode optimale pour ceux qui nécessitent régulièrement des rapports spéciaux.

Inscrivez-vous pour une démo d'OWOX BI si vous souhaitez configurer et orchestrer des tables modélisées. Nous serons heureux de partager des détails sur la façon de préparer des tableaux similaires dans vos projets en fonction de vos données.