Comment contourner la limite des 1 M d’événements de l’export Google Analytics 4/BigQuery ?

Avant de commencer, voici 2 formations gratuites en rapport avec la question traitée dans cet article qui pourraient vous intéresser :

Formation sur Google Analytics 4 (2023)

Formation sur Google Big Query (2023)

Allez, c’est parti ! 🤓

Comme vous le savez sûrement déjà, Google propose une connexion native entre BigQuery et Google Analytics 4. Cette connexion vous permet d’exporter tous les événements bruts d’une propriété Google Analytics 4 dans BigQuery. Voici une documentation sur le sujet :

https://support.google.com/analytics/answer/9358801?hl=fr

Malheureusement, une limite de 1 000 000 d’événements exportés dans BigQuery par jour est fixée par Google. Ainsi, une propriété enregistrant un nombre important d’événements se retrouve avec des données brutes incomplètes dans BigQuery. Sans surprise, cette perte est problématique si vous voulez utiliser ces données à des fins de visualisations ou d’activations avancées (marketing automation).

Il est possible d’activer l’export en flux continu (moyennant un léger coût supplémentaire), afin d’obtenir les événements du jour quasiment en temps réel et sans limites sur la journée. Cependant, cette solution n’est pas optimale, car les données issues de cet export ne sont pas complètes.

Ainsi, cet export en flux continu est utile pour alimenter des visualisations/activations très basiques en temps réel, mais n’est pas suffisant dans la majeure partie des cas un peu plus complexes. Google indique d’ailleurs qu’il est préférable d’interroger les tables journalières events_YYYYMMDD plutôt que la table générée par l’export en flux continu events_intraday_YYYYMMDD.

Voici les 4 solutions que nous avons identifiées pour contourner la limite des 1 000 000 d’événements concernant l’export automatique des événements Google Analytics 4 dans BigQuery :

Solution 1 : Passer sur Google Analytics 4 360

Cette solution est envisageable, cependant la licence Google Analytics 4 360 n’est pas dans le budget de tous les annonceurs (50k$ / an minimum).

Sachez que Google Analytics 4 360 est également soumis à une limite sur le nombre d’événements exportés dans BigQuery par jour, mais elle est beaucoup plus haute.

La documentation officielle ne dit pas le nombre exact, mais indique une limite fixée à “des milliards d’événements”. Ce qui est probablement suffisant pour la plupart des annonceurs.

Solution 2 : Envoyer moins d’événements dans BigQuery

Il est possible d’envoyer moins d’événements afin de rester sous la limite des 1 000 000.

Pour diminuer le nombre d’événements exportés dans BigQuery par jour, vous pouvez filtrer les événements envoyés en ne gardant que les plus importants.

Voici les désavantages de cette solution :

• Elle peut ne pas être suffisante ;
• Elle n’est pas viable dans le temps si votre nombre d’événements augmente tous les mois.

Solution 3 : Créer plusieurs propriétés Google Analytics 4

Créer plusieurs propriétés afin de repartir sur ces dernières les événements exportés dans BigQuery par jour est une solution envisageable. Cependant, cela peut vite devenir compliqué en termes de gouvernance, d’organisation, etc. Cette solution peut ne pas être suffisante et n’est pas viable dans le temps non plus. Elle peut également induire des problèmes dans la modélisation des données (attribution, comptage des sessions, etc) car les données sont plus complexes à réconcilier (user_id, etc).

Solution 4 : Envoyer en parallèle les hits directement depuis un conteneur Google Tag Manager Server-Side dans BigQuery

Cette solution consiste à envoyer les hits souhaités, au format qui vous arrange le plus, en continu, directement depuis une balise située sur un conteneur Google Tag Manager Server-Side.

Le seul coût non négligeable est celui de l’infrastructure (les serveurs) pour assurer le bon fonctionnement de Google Tag Manager Server-Side. Le coût pour écrire dans BigQuery est très faible (environ 0,05 $ pour 600 000 hits). Cette solution reste beaucoup moins onéreuse que Google Analytics 4 360.

Néanmoins, cette solution nécessite des compétences techniques (SQL) pour transformer les données brutes envoyées (hits) et reconstruire le mieux possible certaines dimensions et métriques (source, medium, device, etc). L’idée est de reproduire la transformation de données réalisée par Google Analytics 4 afin de ressortir le même schéma de donnée que celui des tables journalières de l’export automatique des données Google Analytics 4 dans BigQuey.

Simo Ahava a publié un article très intéressant sur le sujet :

https://www.simoahava.com/analytics/write-to-google-bigquery-from-gtm-server-container/

OWOX a créé une balise Google Tag Manager Server-Side permettant d’envoyer des hits dans BigQuery. Voici l’article expliquant comment la déployer étape par étape :

https://support.owox.com/hc/en-us/articles/6231018188052-Google-Analytics-4-RawData-to-BigQuery-OWOX-Tag-for-GTM-Server-Side