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, 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 (merci à mes estimés collègues data ingénieux) 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).
Pour les gros radins plus curieux, la quantité de données précise peut tout à fait être obtenue mathématiquement, puisque le poids en base dépend du type de données stockées, doc touffue mais très intéressante à lire :
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.
Donc, prenons un site qui collecte 10 millions d’events par mois (ce qui est déjà pas mal). 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 (on divise donc par 1,4), 78 Go de données.
Parmi ces 78Go de données, et en partant du principe que le même nombre d’events est collecté par mois :
- 3 mois de données, soit 19,5Gb à 0.02$ par GB
- 9 mois de données, soit 58,5Gb à 0.01$ par GB
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). Je vous invite à l’adapter à votre site, mais je pense que vous pouvez vous le permettre.
Si on se base sur l’ACPM, on constate par exemple qu’au dernier pointage, Le Figaro collecte environ 600 millions de pages vues (dont 95% provient a priori de l’auto refresh qui se déclenche au bout de 1,6 secondes, mais c’est un autre débat). 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, avec une approximation très grossière du volume total de hits, mais vous voyez l’idée, c’est absolument dérisoire.
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 (également dispo sur la doc de BQ sus-mentionnée) 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 à l’heure où j’écris ces lignes.
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. Et par payer, cette fois on ne se parle plus d’acheter un menu kebab frites, mais d’acheter le fond de commerce du kebab, les murs, et de gérer le ravalement de façade de l’immeuble. 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, juste derrière la position de la CNIL sur GA4 depuis juillet 2023, les milieux autorisés parlent d’un package aux alentours de 50 000 eurodollars annuels (ce qui vous amène également d’autres avantages absolument indispensables comme des associations à Salesforce, un support de grande qualité ou la création de subproperties). Oui, je sais, ça fait un petit billet.
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 (avez-vous vraiment besoin de tracker l’autoscroll de votre caroussel en homepage ?), ou, si vous êtes un vrai aventurier de l’analytics, du sharding de streams entre différents sites, pays ou autre (ce qui peut poser des questions de réconciliation, mais bon on a rien sans rien).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 le lien en premier commentaire 🚀” je lui pète les genoux vends une presta Piwik Pro, parce qu’il existe un outil pour les gens qui ne sont vraiment pas prêts à faire leur deuil de GA3 et que dans l’absolu ça reste un outil de qualité.
L’auteur : Aristide Riou
Consultant tracking & expert GA4 chez UnNest
Mon credo : aider les gens à résoudre des problèmes avec les données en brisant les silos entre le monde des affaires et la technologie.
Avec plus de 10 ans d'expérience en marketing digital, développement fullstack, et gestion des données, je travaille sur tous les aspects des projets liés aux données. J'ai travaillé pour des sites de commerce électronique (My M&M's, Cdiscount), des agences (Wunderman, BBDO), et des entreprises mondiales (Mercedes, Procter & Gamble, Danone).
✉️ Me contacter : aristide.riou@unnest.co