J’avais initialement écrit cet article sur le blog unnest insights

Nous sommes tous passés par là. Vous avez convaincu vos chers clients / managers / collègues / head of digital disruptions and artificial intelligence qu’ils devaient nous faire confiance pour ce qui est de déverser les données brutes de GA dans BigQuery, pour les 327 raisons mentionnées un peu partout dans l’internet mondial (échantillonnage, historisation, pacte entre l’UX designer de GA et Kim Jong-un…).

Vous leur avez montré que grâce à votre connaissance encyclopédique du SQL, vous allez être en mesure répliquer tout ce que faisait UA (GA3), et bien plus encore. Vous leur avez enfin expliqué avec passion à quel point ils allaient mettre la main dans le formidable écosystème GCP, avec les incroyables Cloud Functions, le délicieux Cloud Run, et le périlleux Kubernetes Engine (j’ai perdu un pari il y a quelques années, je dois écrire “Kubernetes” au moins 1 fois par article, longue histoire).

BREF. Vous avez fait votre job de consultant, votre client est convaincu, et vous n’avez plus qu’à appuyer sur le bouton magique.

Et c’est là qu’arrive la question qui fâche : “Alors oui t’es bien gentil mon p’tit bonhomme, mais ça coûte combien ta petite affaire ?”

Jusqu’à il y a peu, ma réponse était (dans l’idée) “wesh tkt fréro, même avec plusieurs millions d’events par mois, ça te coûtera le prix d’un kebab, et encore sans menu avec sauce blanche”. Et je ne disais pas ceci par feignantise intellectuelle (ni par faim de kebab, d’ailleurs), mais simplement parce que c’est, factuellement, la vérité. Si vous collectez moins de 20 millions d’events par mois, le kebab susmentionné est quelque chose dont vous vous soucierez dans 1 an grand max.

Néanmoins, par professionnalisme (et aussi parce que je sais qu’au fond certains d’entre vous sont des énormes psychopathes qui cherchent le moindre prétexte pour ne pas apprendre les 3 notions super basiques de SQL que demande de connaître BQ, oui je sais où vous habitez), je vais aller au bout de la démarche, et vous proposer une méthode rigoureuse et exhaustive pour pouvoir arbitrer avec votre département contrôle de gestion interne entre l’activation des données BQ et une nouvelle moquette pour la salle de pause de vos locaux à Montreuil.

Les coûts de stockage

Dans un premier temps, je vous invite à aller regarder succinctement la page de la doc BQ qui explique toute cette diablerie, mais n’est pas si accessible que ça pour les profanes.

Déjà, pour ceux qui l’ignoreraient, vous payez BQ de 2 façons, la première étant le volume de données que vous stockez : plus vous stockez de données, plus vous payez. Un peu comme un box de rangement quoi.

Pour ce qui est du stockage, le tarif pour le datacenter Europe est de 0.02$ par GB, sachant que les 10 premiers Go sont gratuits et que cela passe à 0,01$ par Gb par mois après 90 jours de données non modifiées.

Alors oui mais concrètement, vous allez me dire que ça vous fait une belle jambe, parce dans le métier, on parle en hit, et certainement pas en Go. On considère donc en général que, grosse maille, 1 million de lignes = 1 Go de données.

Pour s’en assurer, et parce qu’on est jamais trop prudents, on peut par exemple jeter un œil à la table de démo du Google Merchandise Store, qui compte 4,3 millions de lignes, et pèse comme vous pouvez le voir 3,34 Go, soit 1,2 millions de lignes pour 1 Go si on fait une règle de 3.

Je me suis amusé à faire tourner une requête similaire sur une implé dans laquelle je stocke beaucoup de custom parameters, et donc de champs nestés (et un peu de e-commerce, donc encore plus de nesting), et le calcul était comparable (611K events pour 500 Mo, soit 1,22 au de 1,28, l’ordre de grandeur est clairement le même).

On va donc partir sur une hypothèse volontairement très prudente (rappelez vous, nous sommes en train de parler à des contrôleurs de gestion, donc des gens fondamentalement un peu rêches), disons que 1 Go de données = 1,4 millions d’events collectés, et donc de lignes.

Le calcul rapide : Prenons un site qui collecte 10 millions d’events par mois. Au bout d’1 an, le site en question aura une table de 120 millions de lignes. En enlevant les premiers 10 Go gratuits, il faudra donc payer pour 110 millions de lignes, soit, avec notre règle pessimiste, 78 Go de données.

Cela nous donne 97 centimes par mois au bout d’1 an. Oui, moi aussi, j’ai bugué la première fois que j’ai fait ce genre de calcul. Je me suis dit que même si j’avais oublié un zéro, c’était déjà vulgairement peu cher. Et pourtant les calculs sont bons (Kevin).

Si on se base sur le classement ACPM, on constate par exemple qu’au dernier pointage, Le Figaro collecte environ 600 millions de pages vues. En étant généreux, et en arrondissant de façon très approximative à 1 milliard d’events par mois, cela ne coûterait “que” 150€ par mois au bout d’un an. Certes, ce montant n’est sans doute pas anodin, mais on se parle d’un des premiers sites du pays en termes de trafic.

Les coûts de requêtage

C’est ici que cela peut se corser et que vous allez potentiellement devoir faire un peu attention, puisque vous payez à chaque fois que vous faites une requête.

Le tarif varie selon le datacenter où vous hébergez les données, entre 5 et 8$ par TB requêté, sachant que le premier TB est gratuit. Partons sur le tarif de 5$, qui est celui du datacenter européen.

Reprenons notre site à 10 millions d’events par mois, qui aura toujours collecté 78 Go de données au bout d’1 an. Si je m’amuse à faire des SELECT * comme un petit margoulin sur cette table, une requête revient à 0,078 * 5$, soit 0,39$. Mais je peux lancer cette requête un peu plus de 12 fois “gratuitement”, je ne payerai que lorsque j’aurai dépassé le To de données.

Ce cas des coûts de requêtage peut donc être un petit sujet si vous commencez à faire totalement n’importe quoi, donc un petit rappel ne fait jamais de mal :

  • Toujours travailler sur une toute petite période d’analyse avant d’étendre son spectre.
  • Si des dashboards ou tout autre job automatique peut être amené à aller fracasser votre table de plein fouet sur de longues périodes, réfléchissez à des solutions tampons à base de vues matérialisées.
  • Bossez avec nos data eng, ils connaissent des trucs comme “débété” et “date à forme” qui vous évitent ce genre de déconvenues.

The sky is the limit

Alors oui, parlons un peu de l’éléphant dans la pièce : Google, tel un bon dealer de rez de chaussée de barre d’immeuble, vous offre la première dose, mais vous fait payer dés que vous devenez accro. Parce que si vous collectez plus d’1 million de hits par jour, vous allez devoir passer à la case GA4 360.

Et la question qui vous brûle les lèvres est bien évidemment “bah oui mais COMBIEN gros ?” ; et si le pricing d’un GA 360 est l’info la mieux planquée de tout l’internet, les milieux autorisés parlent d’un package aux alentours de 50 000 eurodollars annuels.

Si vous fleurtez dangereusement avec la limite du million, il existe bien sûr des petites tactiques de voyou permettant d’éviter / retarder le passage à la caisse, comme la désactivation de enhanced measurements, la suppression de certains events pas vraiment utiles, ou, si vous êtes un vrai aventurier de l’analytics, du sharding de streams entre différents sites.

Bref, vous n’avez en principe maintenant plus aucune excuse pour ne pas exporter vos données GA4 dans BQ, et le prochain que je surprends en flagrant délit LinkedIn de “GA4 bouh pas bien caca j’ai pas les landing pages” je lui pète les genoux vends une presta Piwik Pro.