Infrastructure d'analytics de jeu : construire ou acheter ?

L'infrastructure d'analytics de jeu est l'ensemble des systèmes qui collectent les événements de votre jeu et de ses serveurs, les stockent et les transforment en rapports. Vous pouvez la construire vous-même chez un fournisseur cloud ou payer un outil qui la fait tourner pour vous. Ce guide présente les éléments d'un pipeline, ce que coûte son fonctionnement, la version minimale qui vaut la peine d'être construite et comment choisir entre construire et acheter.

Qu'est-ce qu'un pipeline d'analytics de jeu ?

Un pipeline d'analytics de jeu transporte un événement, comme le résultat d'un match ou un niveau terminé, du jeu jusqu'à un rapport. La plupart des pipelines ont les mêmes éléments :

Un petit pipeline peut regrouper plusieurs éléments. Un grand pipeline en ajoute d'autres, comme un traitement en temps réel pour des tableaux de bord en direct.

Le travail absent du schéma

Un schéma d'architecture montre où vont les événements. Il ne montre pas le travail qui garde les données justes :

• Conception des événements : décider quoi enregistrer et ce que signifie chaque champ, puis le modifier d'une version du jeu à l'autre sans casser les anciens rapports.
• Envoi depuis le jeu : regrouper les événements par lots, relancer les requêtes qui échouent et conserver les événements pendant que le joueur est hors ligne.
• Événements en double : les nouvelles tentatives envoient certains événements deux fois, il faut donc un moyen de les reconnaître.
• Identifiants dans le build du jeu : tout ce qui est livré dans un jeu peut être extrait, donc la clé du jeu ne doit pouvoir qu'envoyer des événements. Voir quel token d'API votre jeu doit utiliser.
• Vie privée : enregistrer le consentement du joueur, puis retrouver et supprimer ses données quand il le demande.
• Les rapports eux-mêmes : la rétention, les entonnoirs et le taux de victoire par version du jeu sont des requêtes que quelqu'un doit écrire, vérifier et tenir à jour. Le guide pour équilibrer un jeu avec des données montre le soin que demande un seul rapport de taux de victoire.

Ces coûts sont surtout du temps d'ingénierie, et ils durent tant que le jeu est en ligne.

Le Game Analytics Pipeline d'AWS

AWS publie une architecture prête à l'emploi appelée Guidance for Game Analytics Pipeline on AWS. Vous la déployez dans votre propre compte AWS avec AWS CDK ou Terraform. Elle comprend :

• Une API REST construite avec API Gateway, Lambda et DynamoDB, qui accepte les événements des clients du jeu, des serveurs du jeu et des services backend.
• Une pile de données au choix : un data lake dans S3 (tables Hive ou Iceberg) traité avec Glue et interrogé avec Athena, ou Redshift Serverless comme data warehouse.
• Une analytics en temps réel en option avec Kinesis Data Streams, Managed Service for Apache Flink et OpenSearch.

L'estimation d'AWS, datée d'août 2025 pour la région US East (N. Virginia), pour 100 événements de 1 Ko par seconde (259,2 millions d'événements par mois) :

AWS présente ces chiffres comme des estimations approximatives et recommande de faire vos propres tests. La plupart des services sont facturés à l'usage, donc un jeu avec moins de trafic paie moins.

AWS publie cette architecture comme du code d'exemple, fourni tel quel. Une fois qu'elle est déployée, votre équipe la fait tourner : les mises à jour, la surveillance et les correctifs sont à votre charge. Elle couvre la collecte, le stockage et les requêtes, avec des requêtes Athena d'exemple pour des questions courantes sur les jeux, mais elle n'inclut pas de tableaux de bord. Vous branchez vous-même un outil de tableaux de bord comme QuickSight.

Le plus petit pipeline qui vaut la peine d'être construit

Si votre jeu a déjà un serveur et une base de données, le plus petit pipeline est une table et du SQL. Le serveur écrit une ligne d'événement chaque fois que quelque chose se produit :

CREATE TABLE game_events (
  id bigserial PRIMARY KEY,
  player_id text NOT NULL,
  game_version text NOT NULL,
  name text NOT NULL,
  properties jsonb NOT NULL DEFAULT '{}',
  created_at timestamptz NOT NULL DEFAULT now()
);

Ensuite, une requête répond à une question. Celle-ci calcule le taux de victoire par personnage pour chaque version du jeu, avec le résultat de chaque match enregistré comme 1 pour une victoire et 0 pour une défaite :

SELECT
  game_version,
  properties->>'character' AS character,
  round(avg((properties->>'result')::int), 3) AS win_rate,
  count(*) AS games
FROM game_events
WHERE name = 'match_finished'
GROUP BY game_version, character
ORDER BY game_version, character;

Cela fonctionne bien pour un petit jeu, et les données restent dans une base que vous sauvegardez déjà. Cette approche atteint ses limites quand :

• Les requêtes d'analytics ralentissent la base de données dont le jeu dépend.
• Les questions arrivent plus vite que quiconque n'a le temps d'écrire les requêtes.
• Une autre personne que l'auteur des requêtes doit lire les résultats.

Ce que coûte construire par rapport à acheter

Construire a deux coûts : la facture cloud, et le temps d'ingénierie pour construire le pipeline et le maintenir en marche. Pour un petit studio, la facture cloud est souvent le plus faible des deux.

Acheter a un seul coût, l'abonnement, et beaucoup d'outils sont gratuits à petite échelle :

• GameAnalytics : gratuit, sans limite d'utilisateurs actifs mensuels (MAU).
• Google Analytics for Firebase : gratuit.
• Unity Analytics : gratuit jusqu'à 50 000 MAU, puis facturé par MAU.
• Game Stats AI : gratuit pour 1 000 enregistrements suivis par mois, avec des formules payantes à partir de 19 $ par mois.

La comparaison des outils d'analytics de jeu donne les prix, les moteurs pris en charge et l'accès aux données brutes de chacun.

Quand construire votre propre pipeline

Construire est le meilleur choix quand :

• Vous avez déjà une équipe data ou un data warehouse que quelqu'un maintient.
• Vous avez besoin des données du jeu au même endroit que d'autres données de l'entreprise, comme celles du marketing ou du support.
• Votre volume est assez élevé pour qu'une tarification par joueur ou par événement coûte plus cher que votre propre pipeline.
• Vous avez des exigences de localisation ou de propriété des données qu'aucun fournisseur ne respecte.

Quand utiliser un outil

Un outil est le meilleur choix quand :

• Personne dans l'équipe ne peut s'occuper d'un pipeline de façon continue.
• Vos questions sont les plus courantes : rétention, revenus, progression ou taux de victoire.
• Vous voulez des rapports pendant le développement et au lancement, pas après la fin d'un projet data.

Gardez la possibilité de changer

Quel que soit votre choix, quelques habitudes rendent un changement ultérieur peu coûteux :

• Définissez votre propre format d'événements. Documentez vos événements et leurs champs, et gardez cette définition dans votre code, pas dans le tableau de bord d'un fournisseur.
• Envoyez les événements depuis votre serveur quand c'est possible. Changer une destination sur un serveur demande un déploiement. La changer dans le jeu demande un nouveau build et la mise à jour des joueurs.
• Vérifiez comment récupérer vos données. Certains outils incluent l'export des données brutes dans toutes les formules, d'autres seulement dans les formules supérieures (Unity Analytics exige Snowflake), et d'autres seulement via une API.

Game Stats AI est conçu pour cela. Il accepte les événements via une API REST sans schéma à enregistrer au préalable, et à partir de la formule Studio, un endpoint d'ingestion sur mesure accepte le format de payload que votre jeu ou votre serveur envoie déjà. Si vous construisez votre propre pipeline plus tard, ou si vous en avez déjà un, votre serveur peut envoyer les mêmes événements aux deux. Les rapports sont lisibles via l'API avec un token serveur.

Questions fréquentes

Qu'est-ce que l'infrastructure d'analytics de jeu ?

Les systèmes qui collectent les événements d'un jeu et de ses serveurs, les stockent et les transforment en rapports. Elle comprend en général un endpoint d'ingestion, un stream ou une file d'attente, un stockage dans un data lake ou un data warehouse, un moteur de requêtes et des tableaux de bord.

Combien coûte un pipeline d'analytics de jeu ?

AWS estime son Game Analytics Pipeline à environ 66 à 92 $ par mois pour un data lake, ou environ 253 $ pour Redshift, à 100 événements par seconde, plus environ 771 $ pour l'analytics en temps réel. Il faut y ajouter le temps d'ingénierie pour le construire et le maintenir. Beaucoup d'outils d'analytics sont gratuits à petite échelle.

Un studio indépendant doit-il construire sa propre analytics ?

En général, pas au début. Sauf si le studio a déjà quelqu'un qui maintient des systèmes de données, un outil fournit des rapports plus tôt. Si le jeu a un serveur, écrire les événements dans une table de base de données est un bon début, et vous pourrez passer à un pipeline plus grand plus tard.

Que comprend le Game Analytics Pipeline d'AWS ?

Une API REST pour les événements, un data lake dans S3 avec Glue et Athena ou un data warehouse Redshift, et une analytics en temps réel en option avec Kinesis, Apache Flink et OpenSearch. Vous le déployez dans votre propre compte AWS avec AWS CDK ou Terraform et vous le maintenez vous-même.