Dans cet article, je parlerai de l'analyse de produits dans notre studio, IT Territory. L'article se compose de trois parties. Dans la première, je vais vous expliquer comment le département d'analyse de produit est organisé, qui sont ses employés, ce qu'ils font et pourquoi tout est juste cela et pas autrement. Dans la deuxième partie, je décrirai des exemples de techniques que nous avons développées et appliquées à tous les projets. Dans la troisième partie, je donnerai quelques conseils qui peuvent sérieusement faciliter la vie et aider à travailler plus efficacement.

Maintenant, notre studio gère 11 projets de jeux mobiles, deux autres sont en développement. Nous nous concentrons sur le marché mobile et créons des jeux midware shareware, principalement avec une économie fermée. Le studio s'occupe de tout l'éventail des travaux - du développement à la promotion et à l'exploitation. Le personnel de 240 personnes, des bureaux à Moscou et à Voronej.

Pour comprendre la place du département analytique produit dans la structure du studio, je propose de regarder ce schéma simplifié:



Le département d'analyse de produit est le département satellite des équipes de projet, ainsi que les départements de test, d'exploitation et de marketing. Nous travaillons en étroite collaboration avec tous les projets, leur fournissons les résultats de notre travail et recevons des équipes des informations sur la situation actuelle, les plans et les priorités. Mais en même temps, nous rendons compte à la direction du studio.

1. Qui est analyste produit?

Il fait partie d'un département distinct, chaque analyste étant affecté à un projet ou une franchise spécifique. Il travaille avec l'équipe de projet, effectue des tâches et aide à la prise de décision dans l'équipe et dans la gestion. L'analyste utilise activement le produit, sinon il n'aura pas d'expérience utilisateur - un élément très important qui est nécessaire pour le travail. Dans le même temps, l'analyste est conscient de tous les processus, c'est-à-dire qu'il comprend les problèmes et les tâches auxquels le projet est confronté actuellement, et dirige ses efforts pour les résoudre.

1.1. Approche analytique

Nous pensons que nous avons une approche systématique de l'analyse dans notre studio.



Dans la conception classique, l'analyse fait partie des équipes de projet. Une telle personne est très profondément plongée dans le projet, il la connaît parfaitement. En règle générale, les analystes de différentes équipes ne communiquent pratiquement pas entre eux.

Dans notre système, il y a le rôle du chef de département, qui traduit les exigences, les méthodes et les outils. Autrement dit, tous les analystes de tous les projets utilisent des approches universelles documentées et éprouvées, mais ne s'y limitent pas uniquement. Pour nous, il s'agit d'un certain minimum, sur la base duquel nous pouvons obtenir un examen plus privé et approfondi. Les employés peuvent utiliser des outils et des approches qui ne sont pas mentionnés dans les méthodes standard. À son tour, le chef de département contrôle les résultats du travail des analystes et, étant lui-même le spécialiste le plus compétent, il ajoute à l'équipe son expérience et ses connaissances.

Un avantage important de cette approche est que les analystes sont fongibles. Il arrive souvent qu'une personne travaille sur le même projet depuis des années et finisse par s'épuiser, son regard est «flou». Dans une telle situation, le transférer vers un autre projet est généralement très difficile, car l'analyste a des connaissances spécifiques sur le projet et son infrastructure, que personne d'autre n'a. Mais lorsque les méthodes et les exigences sont les mêmes, après un peu de formation, les gens peuvent être déplacés entre les projets, leur donnant une nouvelle expérience et des défis.

1.2. Tâches principales

Les principales tâches de l'analyste de notre département:

• Analyse des changements de KPI au fur et à mesure du développement du produit .
• Détection et étude des anomalies .
• Recherchez les goulots d'étranglement et les points de croissance . Il s'agit d'une tâche très importante qui permet à une personne de se développer professionnellement. Il établit lui-même des hypothèses, les vérifie, trouve de nouvelles informations que personne d'autre ne voit et acquiert ainsi une expérience qu'aucun leader ne donnera.
• Aide à la décision . Nous aidons les membres de l'équipe à répondre à leurs questions.
• Support et développement d'infrastructures analytiques .

Je vais vous en dire plus sur le dernier point. L'infrastructure comprend les niveaux suivants:



Au premier niveau se trouve la base de données du projet, dans laquelle nous enregistrons toutes les données, et nous-mêmes utilisons sa réplique pour éliminer les risques pour le projet.

Au deuxième niveau, nous avons un stockage basé sur Hadoop, où nous transférons des informations à partir de bases de données de projets pour l'analyse historique de très gros volumes.

Le niveau suivant est constitué de modules complémentaires sur le référentiel pour l'exécution de code. Ici, vous pouvez implémenter toutes les transformations de données complexes que nous ne pouvons pas implémenter à l'aide des outils des niveaux précédents.

Au dernier niveau, nous avons la visualisation. Historiquement, le logiciel propriétaire, QlikView, en était responsable. Et Excel est un classique, pour les tâches rapides, nous l'utilisons toujours.

1.3. Compétences des analystes de produits

Nous mettons en évidence la liste suivante:

• SQL et langages similaires;
  
• architecture de base de données;
  
• langages de programmation (Python, R, Scala);
  
• mathématiques et statistiques mathématiques;
  
• logique et réflexion sur les produits;
  
• capacité à défendre sa position;
  
• compétences en communication.
  

Je veux souligner les deux derniers points. Il est généralement admis que l'analyste est un introverti avec un QI supérieur à 130, qui prépare des rapports de 50 pages sur ce qui se passe dans son domaine de responsabilité. Mais en fait, dans notre paradigme, l'analyste est la personne qui est le moteur des problèmes et des points de croissance qu'il découvre. Il est difficile dans l'équipe de convaincre les gens que vous avez trouvé quelque chose d'important, car chacun est engagé dans sa propre tâche prioritaire. Mais simplement transmettre ces informations et les oublier - une telle position ne nous convient pas. Par conséquent, il est très important pour l'analyste de pouvoir établir des relations dans l'équipe, de trouver des moyens de défendre sa position et ses conclusions et de «conduire» la mise en œuvre de ses recommandations.

2. Méthodes

Je vais maintenant parler un peu d'exemples de techniques que nous diffusons aux employés du département analytique. À notre avis, les trois piliers d'un produit free-to-play réussi sont l'économie, la rétention et la monétisation. Pour chacune de ces entités, au sein du département analytique, des méthodes sont développées pour évaluer et comparer avec d'autres projets. Ils peuvent être divisés en trois grands groupes:

• Méthodes d'évaluation initiale du produit . Approches pertinentes aux premiers stades de la vie d'un produit, alors qu'il n'y a pas encore de cœur et qu'il n'y a qu'un nouveau jeu dans lequel un public commence à peine à apparaître.
  
• Méthodes d'évaluation des changements dans un projet avec un noyau . Ils sont utilisés pour évaluer les changements dans les nouvelles versions du jeu, l'effet de l'ajout de fonctionnalités et de modifications, à la fois sur les KPI et sur les performances du produit dans son ensemble.
  
• Méthodes d'étude des anomalies . Nous les développons pour une réaction typique à des situations anormales courantes avec des indicateurs de produit. Il existe certaines approches, quoi et dans quel ordre vous devez analyser afin de trouver rapidement les causes les plus probables et de commencer à résoudre le problème.
  

Je parlerai des anomalies une autre fois, et aujourd'hui nous parlerons de l'évaluation initiale et de l'analyse des changements à l'aide du projet F2P classique avec une économie fermée.

2.1. Techniques d'évaluation initiale

Exemples de techniques d'évaluation initiale:

• Rétention
  
• CARPU (LTV) pour les marchés clés;
  
• FPE (conversion en payant);
  
• conversion de démarrage fixe (tutoriel);
  
• points de progrès entraînant le retrait;
  
• les points de progrès qui stimulent les paiements;
  
• entrée et sortie de ressources dans le contexte de progrès et / ou de durée de vie;
  
• WinRate premières tentatives + nombre de tentatives avant la réussite.
  

Je vais vous en dire un peu plus sur plusieurs d'entre eux.

2.1.1. L'économie des premiers jours de la vie

Nous venons de lancer un nouveau produit dans la version et voulons évaluer l'état actuel de l'économie en devises fortes. Il existe un moyen assez simple d'évaluer au plus haut niveau l'équilibre de la demande pour une telle ressource. Laissez les dépenses cumulées dans le jeu dans les premiers jours de la vie ressembler à ceci:



L'axe X représente le cycle de vie. Le revenu cumulé est gratuit, c'est-à-dire que nos dépenses totales dépassent le revenu spécifique par utilisateur. Nous avons donc une pénurie de cette ressource, qui est fermée par l'achat. Il s'agit de la première coupe la plus générale. Ensuite, nous le divisons en sources et cherchons d'où vient l'augmentation du revenu gratuit. La règle générale est la suivante: si les dépenses dépassent le revenu gratuit, vous aurez une demande. Vous pouvez ajuster son volume en utilisant le ratio des dépenses et des revenus gratuits. Si votre revenu gratuit couvre le coût unitaire par utilisateur, alors très probablement, seuls ceux dont les coûts sont très élevés paieront. Autrement dit, des utilisateurs très fidèles, mais pas la masse totale.

2.1.2 Conversion des progrès

L'un des aspects les plus importants d'un jeu est la rétention primaire. Dans les premières minutes après l'installation, les gens se familiarisent avec le jeu et décident s'ils le joueront ou non. La plupart des projets perdent la moitié de l'audience dans les 30 premières minutes. Comment puis-je trouver rapidement des problèmes pour fidéliser mon public? En ce qui concerne le progrès, nous le faisons en utilisant un entonnoir classique:



Nous construisons un graphique du nombre d'utilisateurs qui atteignent certains points clés. Le graphique montre des baisses prononcées aux points 4, 10 et 20. Si vous calculez la conversion relative d'un point à un autre, vous verrez immédiatement des creux dans lesquels la conversion chute fortement par rapport aux points voisins. Les raisons sont différentes: problèmes en UX, problème de choix entre différents modes, lorsque les utilisateurs ne vont pas selon votre stratégie, mais vont en PvP ou autres modes, complexité, défaillances techniques, etc. Mais en général, ce sont les points auxquels vous devez immédiatement faire attention, car ils incitent les utilisateurs à quitter ou à ne pas agir sur la courbe de progression de votre choix.

2.1.3 Points d'entretien et de paiement

Voici un exemple de projet dans lequel ces points sont très prononcés:



À certains moments de la progression des joueurs, des éclats de paiements et des retraits d'utilisateurs se produisent. La raison en est qu'à ces moments-là, les gens sont confrontés au fait qu'il est impossible d'aller plus loin dans le jeu jusqu'à ce que vous accumuliez un certain nombre de points. En conséquence, les faibles quittent, et ceux qui veulent mal battre le jeu et en même temps gagner du temps, utilisent des fonctionnalités payantes.

Après avoir reçu ces informations, l'équipe doit travailler sur le solde afin de perdre le moins de personnes possible, mais en même temps, maximiser ou économiser les paiements.

2.1.4. Problèmes importants de monétisation

Le problème de la monétisation est très vaste. Nous abordons chaque projet individuellement et croyons que la monétisation vient de la conception et n'est pas une approche universelle qui peut être appliquée partout. En résumé, nos méthodes peuvent être exprimées dans les questions que nous posons, et les points d'application des efforts dépendront des réponses à ces questions.

Quel produit convertit le mieux un utilisateur en un produit payant? Nous avions un projet qui "tournait" très bien au départ. Mais quelques mois seulement après avoir reçu le long métrage, après avoir digéré un volume suffisamment important d'audience, le projet de revenus a commencé à baisser, et assez sérieusement. Il avait une bonne prise pour le projet midcore, et le gameplay était assez difficile. Nous n'avons pas eu suffisamment de masse salariale pour amener le projet sur un plateau financier en raison des paiements du public principal.

Nous avons décidé que nous devions franchir la première barrière de paiement pour la plupart des utilisateurs. Nous avons choisi un contenu exclusif qui n'avait été vendu ni pour la monnaie du jeu ni pour de l'argent, et nous avons mis le prix le plus bas possible. Naturellement, ce contenu n'était pas un ultimatum et ne couvrait pas tous les besoins du joueur. Commençant à l'offrir au tout début de la monétisation abordable dans le jeu, d'un seul coup, nous avons augmenté la part du paiement d'un tiers, tout en maintenant la facture moyenne.

Plus tôt l'utilisateur entre dans la catégorie du paiement, plus grande sera l'intégralité de ses revenus dans le jeu. Veuillez noter que chaque jeu aura son propre contenu qui résout le mieux ce problème. Si dans d'autres jeux de faire la même chose sur le front, alors vous ne pouvez pas deviner. Il est très important de comprendre qu'une personne apprécie vraiment dans le jeu quel contenu sera demandé à ce stade, ainsi que la façon d'éviter un coup à l'économie et à l'équilibre globaux.

Quelle proportion d'utilisateurs se convertit au paiement dans les derniers stades du jeu? Si vous avez beaucoup de nouveaux payeurs après le 30e jour de votre vie, vous recevrez probablement moins d'argent. Ces gens jouent depuis un mois, ils ont déjà atteint leurs objectifs à court et moyen terme. Mais en même temps, ils n'avaient pas assez de motivation pour commencer à payer. Et dans les derniers stades, elle est soudainement apparue. Permettez-moi de vous rappeler que si un utilisateur convertit tard, ses revenus spécifiques diminueront par rapport à la situation s'il s'est converti dans les premiers jours du projet. Par conséquent, il est nécessaire de trouver une motivation pour que les joueurs se convertissent au paiement à un stade précoce.

Combien d'utilisateurs sont convertis en deux achats, trois, etc.? Si nous avons créé un produit qui convertit parfaitement les utilisateurs à un stade précoce et que nous obtenons beaucoup de nouveaux payeurs, la prochaine barrière se pose. Entre un tel produit et le reste de vos offres, il peut y avoir un grand écart de prix, et pour les utilisateurs qui ont acheté un bon produit pour un dollar, toutes les autres offres sembleront non rentables. Dans une telle situation, il faut penser à la chaîne: quelle sera la prochaine étape du joueur qui devrait devenir un payeur à part entière? S'il achète un produit très rentable à moindre coût, il faut lui proposer des offres diverses qui augmenteront progressivement la taille du chèque, mais en même temps à chaque fois donner à l'utilisateur une nouvelle qualité.

Existe-t-il une stratégie claire pour augmenter la taille des chèques? Il ne suffit pas de convertir les utilisateurs, car il est évident que ces personnes se sont achetées à une offre assez bon marché. Il est important de construire correctement une stratégie afin que chaque produit ultérieur demandé soit dans une catégorie de prix différente. Je ne parle pas immédiatement de grosses sommes, mais vous avez une métrique comme le chèque moyen pour le payeur. Une personne qui s'est convertie d'une offre bon marché doit y être amenée. C'est possible et le plus souvent, les gens refusent de payer pour des raisons psychologiques.

Existe-t-il un processus de refus des paiements tout en maintenant l'activité? Dans de nombreux jeux aux derniers stades de la vie du projet, les joueurs s’adaptent à l’économie, ajustent leurs besoins à leurs capacités et passent à l’étape de non-paiement ou d’achat du strict minimum. Ici, vous devez travailler en termes de conception de jeux. Cela peut signifier que le gameplay est trop monotone et à long terme, trop peu de défis motivants. Cependant, en raison du noyau d'utilisateurs, le jeu peut très bien se développer et se développer en tant que projet d'entreprise.

Bien sûr, ce ne sont pas tous les aspects importants de l'approche de la monétisation, mais les travaux ultérieurs dépendront largement des nuances du produit.

2.2. Évaluation du changement de produit

Parlons maintenant des méthodes d'évaluation des changements dans le produit. C’est:

• [Toutes les méthodes d'évaluation initiale] +
  
• métriques de monétisation de flux: DPU, ARPPU, ARPDAU;
  
• rétention de roulement minute;
  
• entrée et sortie de ressources en dynamique;
  
• Taux de désabonnement;
  
• durée moyenne de séjour dans la demande;
  
• dynamique des activités clés;
  
• équilibre des ressources disponibles.
  

Je m'attarderai sur certaines techniques.

2.2.1. Minute Rolling Retention

La Rolling Retention par minute est un bon moyen de comprendre rapidement s'il y a des problèmes techniques ou de conception au début, dans les premières minutes du jeu.
Regardons le calendrier du premier projet:



Courbe logarithmique, tout est clair: plus un joueur est en jeu depuis longtemps, moins il a de chances de partir. Le deuxième projet est également sain, mais le résultat est légèrement meilleur. Après une heure de jeu, nous avons plus d'utilisateurs. Et puis nous avons apporté des modifications au deuxième projet qui a cassé quelque chose - le calendrier a changé.

Il est important ici d'avoir une section sur laquelle la dépendance de la probabilité de quitter le temps passé dans le jeu change radicalement. Une telle image suggère que nous avons cassé quelque chose. Peut-être que le jeu a commencé à fonctionner de manière instable, ou nous avons ruiné l'expérience utilisateur. Dans tous les cas, vous devez savoir ce que font les joueurs dans ces moments de la vie du jeu et trouver la source de la détérioration de la rétention.

2.2.2. Taux de désabonnement ou taux de sortie

Nous appelons le taux de désabonnement un peu différent de ce que l'industrie entend par ce terme. Lorsque la tâche s'est posée d'évaluer précisément la sortie d'un public actif, c'est-à-dire qu'il fallait procéder non pas à partir de l'inscription, mais à partir de l'activité du noyau actuel d'utilisateurs, nous avons «trouvé» notre taux de désabonnement. Nous le calculons comme ceci: pour chaque date, nous comptons les joueurs qui étaient actifs, puis voyons combien d'entre eux ne se sont plus connectés pendant un certain temps, c'est-à-dire qu'ils ont quitté le jeu. Nous obtenons donc la probabilité statistique qu'un joueur reparte avec les paramètres donnés un certain jour.

Habituellement, nous analysons les sorties par niveau, âge, statut de paiement. Une forte augmentation de la métrique suggère que la probabilité que les joueurs quittent ce segment a augmenté, et vous devez rechercher des raisons. Si le taux de désabonnement augmente régulièrement après une mise à jour notable, il est logique de déclencher l'alarme.

2.2.3. Entrées et sorties de ressources

L'idée est à peu près la même que dans le cas de la méthodologie pour évaluer l'économie d'un nouveau projet, seulement maintenant nous avons un noyau qui a des cycles de jeu pour obtenir et dépenser des ressources.



La ligne jaune représente les dépenses, la ligne noire représente les revenus gratuits. Il y a une grande différence entre eux, les revenus sont inférieurs aux dépenses. Le delta est un déficit qui crée une demande pour nos ressources échangées. J'ai rencontré plusieurs projets dans lesquels la situation était complètement opposée: ils ne sont monétisés qu'au détriment des gros utilisateurs payants. En termes généraux, si vos coûts unitaires pour une ressource monétisée dépassent le revenu gratuit spécifique, il s'agit d'une économie saine et rare.

3. Conseils

3.1. Lissage de tendance à long terme

Supposons que nous suivions un paramètre important. Par exemple, LTV (ARPU cumulé) pendant 30 jours pour un nouveau public. C'est difficile de travailler avec. Il est très sensible aux gros payeurs, a une grande dispersion, donc son calendrier de cohortes successives en dynamique sera complètement non représentatif. Nous pouvons décomposer ce paramètre par mois ou par groupes, mais ce n'est pas tout à fait ce que nous voulons voir dans la dynamique.

Il existe des conseils simples pour analyser ces indicateurs plus efficacement: nous appliquons le lissage glissant. Pour ce faire, à chaque point, nous considérons la valeur totale du paramètre ainsi que plusieurs précédents. La fenêtre de lissage peut être différente: 7 jours, 30 jours ou plus. Plus la fenêtre est grande, plus la dynamique est fluide et moins l'influence des fluctuations, mais à plus long terme, il doit y avoir des tendances pour les voir clairement.



Nous avons un bon indicateur, facilement perceptible, qui conserve un sens physique. En même temps, il est facile de remarquer une diminution à la fin du graphique.

3.2. Tests A / B

Nous aimons vraiment les tests A / B. Nous avons un projet dans lequel nous avons effectué 70 tests A / B à part entière en seulement 2 ans. Si nous résumons notre expérience dans une certaine compression, nous pouvons dire ce qui suit:

• Les tests A / B sont la façon la plus honnête (réaliste) de tester des hypothèses.
  
• Il vaut mieux les faire dans un nouveau public. Si vous testez une fonctionnalité que l'ancien public a déjà vue, puis lui montrez une nouvelle option, la perception et la réaction ne seront pas les mêmes que pour les personnes qui n'ont pas vu la fonctionnalité. Très probablement, la réaction sera négative et publique, et peut affecter les résultats du test. Ce n'est que dans des cas individuels, avec des différences qui ne sont pas évidentes pour les joueurs ou dans des situations spécifiques, que des tests peuvent être effectués sur l'ensemble du public.
  
• . , . , , . A/B-.
  
• A/B-, , . , , .
  
• A/B-. . A/B-. , .
  
• A/B-, , . , . , . .
  

3.3.

, -. , , . , , .

, :



, , . , ? , , .



, , , . , , , .

, - :

• -, . «ARPU ».
  
• baseline. . « », , .
  
• . .
  
• . , . - , , , . .
  
• . , , - , .
  
• . , ? - .
  
• . - . , , . , , , . , , , . , - . , -, . , , .
  

4.

1. — !
   
2. !
   
3. , !
   
4. A/B- !
   
5. !