Neste artigo, falarei sobre análise de produtos em nosso estúdio, Território de TI. O artigo consiste em três partes. No primeiro, mostrarei como está organizado o departamento de análise de produtos, quem são seus funcionários, o que eles fazem e por que tudo é exatamente isso e não o contrário. Na segunda parte, descreverei exemplos de técnicas que desenvolvemos e aplicamos a todos os projetos. Na terceira parte, darei algumas dicas que podem facilitar seriamente a vida e ajudar a trabalhar com mais eficiência.

Agora, nosso estúdio opera 11 projetos de jogos para dispositivos móveis, mais dois estão em desenvolvimento. Estamos focados no mercado móvel e criamos jogos midcore shareware, principalmente com uma economia fechada. O estúdio lida com todo o espectro do trabalho - do desenvolvimento à promoção e operação. O pessoal de 240 pessoas, escritórios em Moscou e Voronezh.

Para entender o lugar do departamento de análise de produto na estrutura do estúdio, proponho olhar para este diagrama simplificado:



O departamento de análise de produto é o departamento de satélite das equipes de projeto, junto com os departamentos de teste, operação e marketing. Trabalhamos em estreita colaboração com todos os projetos, fornecemos os resultados de nosso trabalho e recebemos informações das equipes sobre a situação atual, planos e prioridades. Mas, ao mesmo tempo, reportamos à gerência do estúdio.

1. Quem é analista de produto?

Faz parte de um departamento separado, com cada analista designado para um projeto ou franquia específica. Ele trabalha com a equipe do projeto, executa tarefas e ajuda na tomada de decisões na equipe e no gerenciamento. O analista usa ativamente o produto, caso contrário, ele não terá experiência do usuário - um componente muito importante que é necessário para o trabalho. Ao mesmo tempo, o analista está ciente de todos os processos, ou seja, entende quais problemas e tarefas o projeto está enfrentando agora e direciona seus esforços para resolvê-los.

1.1 Abordagem do Analytics

Acreditamos que temos uma abordagem sistemática da análise em nosso estúdio.



No design clássico, a análise faz parte das equipes de projeto. Essa pessoa está profundamente imersa no projeto, ela a conhece completamente. Como regra, analistas de equipes diferentes praticamente não se comunicam.

Em nosso sistema, há o papel do chefe do departamento, que traduz os requisitos, métodos e ferramentas. Ou seja, todos os analistas em todos os projetos usam abordagens universais comprovadas e documentadas, mas não se limitam apenas a elas. Para nós, esse é um mínimo, com base no qual podemos obter um exame mais particular e aprofundado. Os funcionários podem usar ferramentas e abordagens que não são mencionadas nos métodos padrão. Por sua vez, o chefe do departamento controla os resultados do trabalho dos analistas e, como ele próprio é o especialista mais competente, ele acrescenta à equipe sua experiência e conhecimento.

Uma vantagem importante dessa abordagem é que os analistas são fungíveis. Muitas vezes acontece que uma pessoa trabalha no mesmo projeto há anos e, eventualmente, se esgota, seu olhar está "embaçado". Em tal situação, geralmente é muito difícil transferi-lo para outro projeto, porque o analista possui conhecimento específico sobre o projeto e sua infraestrutura, o que mais ninguém possui. Porém, quando os métodos e os requisitos são os mesmos, após um pouco de treinamento, as pessoas podem ser movidas entre os projetos, proporcionando novas experiências e desafios.

1.2 Principais tarefas

As principais tarefas do analista em nosso departamento:

• A análise do KPI muda conforme o produto se desenvolve .
• Detecção e estudo de anomalias .
• Pesquise gargalos e pontos de crescimento . Esta é uma tarefa muito importante que permite que uma pessoa se desenvolva profissionalmente. Ele próprio define hipóteses, verifica-as, encontra novas informações que ninguém mais vê e, assim, ganha experiência que nenhum líder dará.
• Suporte à decisão . Ajudamos os membros da equipe a responder suas perguntas.
• Suporte e desenvolvimento de infraestrutura analítica .

Vou lhe contar mais sobre o último ponto. A infraestrutura consiste nos seguintes níveis:



No primeiro nível, está o banco de dados do projeto, no qual registramos todos os dados, e nós mesmos usamos sua réplica para eliminar os riscos do projeto.

No segundo nível, temos um armazenamento baseado no Hadoop, onde transferimos informações dos bancos de dados do projeto para análise histórica de volumes muito grandes.

O próximo nível são complementos sobre o repositório para a execução de código. Aqui você pode implementar transformações complexas de dados que não podemos implementar usando as ferramentas dos níveis anteriores.

No último nível, temos visualização. Historicamente, o software proprietário, QlikView, é responsável por isso. E o Excel é um clássico, para tarefas rápidas, sempre o usamos.

1.3 Competências de analistas de produtos

Destacamos a seguinte lista:

• SQL e linguagens similares;
  
• arquitetura de banco de dados;
  
• linguagens de programação (Python, R, Scala);
  
• matemática e estatística matemática;
  
• lógica e pensamento de produto;
  
• capacidade de defender a posição de alguém;
  
• habilidades de comunicação.
  

Eu quero enfatizar os dois últimos pontos. É geralmente aceito que o analista é um introvertido com um QI acima de 130, que prepara relatórios de 50 páginas sobre o que está acontecendo em sua área de responsabilidade. Mas, de fato, em nosso paradigma, o analista é a pessoa que é a propulsora dos problemas e pontos de crescimento que ele descobre. É difícil na equipe convencer as pessoas de que você encontrou algo importante, porque todos estão envolvidos em sua própria tarefa prioritária. Mas simplesmente passar essas informações e esquecê-las - tal posição não nos convém. Portanto, é muito importante que o analista seja capaz de construir relacionamentos na equipe, encontrar maneiras de defender sua posição e suas conclusões e "impulsionar" a implementação de suas recomendações.

2. Métodos

Agora vou falar um pouco sobre exemplos de técnicas que transmitimos para os funcionários do departamento de análise. Em nossa opinião, os três pilares de um produto free-to-play de sucesso são economia, retenção e monetização. Para cada uma dessas entidades, no departamento de analítica, são desenvolvidos métodos para avaliar e comparar com outros projetos. Eles podem ser divididos em três grandes grupos:

• Métodos de avaliação inicial do produto . Abordagens relevantes nos estágios iniciais da vida de um produto, quando ainda não existe um núcleo e existe apenas um novo jogo no qual o público acaba de começar a aparecer.
  
• Métodos para avaliar mudanças em um projeto com um kernel . Eles são usados ​​para avaliar mudanças em novas versões do jogo, o efeito de adicionar recursos e edições, tanto no KPI quanto no desempenho do produto como um todo.
  
• Métodos de estudo de anomalias . Nós os desenvolvemos para uma reação típica a situações anormais comuns com indicadores de produto. Existem certas abordagens, o que e em que ordem você precisa analisar para encontrar rapidamente as causas mais prováveis ​​e começar a resolver o problema.
  

Falarei sobre as anomalias em outro momento e hoje falaremos sobre a avaliação inicial e a análise de mudanças usando o projeto F2P clássico com uma economia fechada.

2.1 Técnicas de avaliação inicial

Exemplos de técnicas de avaliação inicial:

• Retenção
  
• CARPU (LTV) para os principais mercados;
  
• FPE (conversão em pagamento);
  
• conversão de início fixo (tutorial);
  
• pontos de progresso que causam retirada;
  
• pontos de progresso que estimulam pagamentos;
  
• entrada e saída de recursos no contexto de progresso e / ou vida útil;
  
• Primeiras tentativas do WinRate + número de tentativas antes da conclusão bem-sucedida.
  

Vou falar um pouco mais sobre vários deles.

2.1.1 A economia dos primeiros dias de vida

Acabamos de lançar um novo produto no lançamento e queremos avaliar o estado atual da economia em moeda forte. Existe uma maneira bastante simples de uma avaliação de nível superior do balanço da demanda por esse recurso. Que os gastos acumulados no jogo nos primeiros dias de vida sejam assim:



O eixo X representa o ciclo de vida. A receita acumulada é gratuita, ou seja, nossas despesas totais excedem a receita específica por usuário. Portanto, temos uma escassez desse recurso, que é fechado pela compra. Este é o primeiro corte mais geral. Depois, dividimos em fontes e procuramos de onde vem o aumento da renda livre. A regra geral é: se as despesas excederem a renda gratuita, você terá uma demanda. Você pode ajustar seu volume usando a proporção de despesas e receita gratuita. Se sua renda gratuita cobrir o custo unitário por usuário, provavelmente apenas aqueles cujos custos são muito altos pagarão. Ou seja, usuários muito leais, mas não a massa total.

2.1.2 Conversão de progresso

Um dos aspectos mais importantes para um jogo é a retenção primária. Nos primeiros minutos após a instalação, as pessoas se familiarizam com o jogo e decidem se o jogarão ou não. A maioria dos projetos perde metade da audiência nos primeiros 30 minutos. Como posso encontrar rapidamente problemas para reter meu público-alvo? Em relação ao progresso, fazemos isso usando um funil clássico:



Criamos um gráfico do número de usuários que atingem determinados pontos-chave. O gráfico mostra quedas acentuadas nos pontos 4, 10 e 20. Se você calcular a conversão relativa de ponto a ponto, verá imediatamente mergulhos nos quais a conversão cai acentuadamente em relação aos pontos vizinhos. Os motivos são diferentes: problemas no UX, o problema de escolher entre modos diferentes, quando os usuários não seguem a sua estratégia, mas acessam o PvP ou outros modos, complexidade, falhas técnicas, etc. Mas, em geral, esses são os pontos aos quais você deve prestar atenção imediatamente, pois eles provocam os usuários a sair ou a não agir na curva de progresso de sua escolha.

2.1.3 Pontos de atendimento e pagamento

Aqui está um exemplo de projeto no qual esses pontos são muito pronunciados:



Em certos pontos do progresso dos jogadores, ocorrem estouros de pagamentos e saques de usuários. A razão é que, nesses momentos, as pessoas se deparam com o fato de que é impossível avançar ainda mais no jogo até que você acumule um certo número de pontos. Como resultado, os fracos partidos e aqueles que querem vencer o jogo e ao mesmo tempo economizar tempo, usam recursos pagos.

Após receber essas informações, a equipe deve trabalhar na balança para perder o menor número possível de pessoas, mas ao mesmo tempo, maximizar ou salvar pagamentos.

2.1.4 Problemas importantes de monetização

A questão da monetização é muito extensa. Abordamos cada projeto individualmente e acreditamos que a monetização vem do design e não é uma abordagem universal que pode ser aplicada em qualquer lugar. Resumindo, nossos métodos podem ser expressos nas perguntas que fazemos, e os pontos de aplicação dos esforços dependerão das respostas a essas perguntas.

Qual produto melhor converte um usuário em pagador? Tivemos um projeto que "disparou" muito bem no início. Porém, apenas alguns meses depois de receber o recurso, após digerir um volume suficientemente grande da audiência, o projeto de receita começou a cair e com muita seriedade. Ele teve uma boa influência no projeto midcore, e a jogabilidade foi bastante difícil. Não tivemos massa de pagamento suficiente para colocar o projeto em um platô financeiro devido a pagamentos do público-alvo.

Decidimos que precisamos quebrar a primeira barreira de pagamento para a maioria dos usuários. Escolhemos o conteúdo exclusivo que não havia sido vendido nem pela moeda do jogo nem por dinheiro, e colocamos o menor preço possível. Naturalmente, esse conteúdo não era ultimato e não atendia a todas as necessidades do player. Começando a oferecê-lo no começo da monetização acessível no jogo, de uma só vez, aumentamos a parcela de pagamento em um terço, mantendo a conta média.

Quanto mais cedo o usuário entrar na categoria de pagamento, maior será a integral de sua receita no jogo. Observe que cada jogo terá seu próprio conteúdo que melhor resolve esse problema. Se em outros jogos para fazer o mesmo na testa, então você não pode adivinhar. É muito importante entender que uma pessoa realmente aprecia no jogo qual conteúdo será procurado nesse estágio, bem como evitar um golpe na economia e no equilíbrio gerais.

Qual a proporção de usuários convertidos em pagamento nas fases posteriores do jogo? Se você tiver muitos novos pagadores após o trigésimo dia de sua vida, provavelmente receberá menos dinheiro. Essas pessoas jogam há um mês e já cumpriram objetivos de curto e médio prazo. Mas, ao mesmo tempo, eles não tinham motivação suficiente para começar a pagar. E nos estágios posteriores, ela apareceu de repente. Deixe-me lembrá-lo de que, se um usuário se converter tarde, sua receita específica diminuirá em comparação com a situação se ele se converter nos primeiros dias do projeto. Portanto, é necessário encontrar motivação para que os jogadores se convertam em pagamentos em um estágio inicial.

Quantos usuários são convertidos em duas compras, três etc.? Se criamos um produto que converte perfeitamente os usuários em um estágio inicial e obtemos muitos novos pagadores, então a próxima barreira surge. Entre esse produto e o restante de suas ofertas, pode haver uma grande diferença de preço e, para os usuários que compraram um bom produto por um dólar, todas as outras ofertas parecerão não rentáveis. Em tal situação, é necessário pensar sobre a cadeia: qual será o próximo passo do jogador que deve se tornar um pagador de pleno direito? Se ele compra um produto muito lucrativo barato, é necessário apresentar diversas ofertas para ele, que aumentarão gradualmente o tamanho do cheque, mas, ao mesmo tempo, dando ao usuário uma nova qualidade.

Existe uma estratégia clara para aumentar o tamanho dos cheques? Não basta apenas converter usuários, porque é óbvio que essas pessoas se compraram com uma oferta bastante barata. É importante criar corretamente uma estratégia para que cada produto subsequente na demanda esteja em uma categoria de preço diferente. Não estou falando imediatamente de grandes somas, mas você tem uma métrica como a média do cheque do pagador. Uma pessoa que se converteu de uma oferta barata deve ser levada a isso. Isso é possível e, na maioria das vezes, as pessoas se recusam a pagar por razões psicológicas.

Existe um processo de recusar pagamentos enquanto mantém a atividade? Em muitos jogos, nos estágios posteriores da vida do projeto, os jogadores se adaptam à economia, ajustam suas necessidades às suas capacidades e passam ao estágio de não pagar ou comprar o mínimo necessário. Aqui você precisa trabalhar em termos de design de jogos. Isso pode significar que a jogabilidade é muito monótona e de longo prazo, com poucos desafios motivadores. No entanto, devido ao núcleo de usuários, o jogo pode crescer muito bem e se desenvolver como um projeto de negócios.

Obviamente, esses não são todos os aspectos importantes da abordagem da monetização; no entanto, trabalhos futuros dependerão muito das nuances do produto.

2.2 Avaliação de alterações de produtos

Agora vamos falar sobre métodos para avaliar mudanças no produto. Isto é:

• [Todos os métodos de avaliação inicial] +
  
• métricas de monetização de fluxo: DPU, ARPPU, ARPDAU;
  
• retenção de rolamento por minuto;
  
• entrada e saída de recursos em dinâmica;
  
• Taxa de rotatividade;
  
• tempo médio de permanência no aplicativo;
  
• dinâmica das principais atividades;
  
• equilíbrio de recursos na mão.
  

Vou me debruçar sobre algumas das técnicas.

2.2.1 Retenção de rolamento por minuto

A retenção do rolamento por minuto é uma boa maneira de entender rapidamente se há algum problema técnico ou de design no início, nos primeiros minutos do jogo.
Vejamos o cronograma do primeiro projeto:



Curva logarítmica, tudo está claro: quanto mais tempo o jogador estiver no jogo, menor a probabilidade de ele sair. O segundo projeto também é saudável, mas o resultado é um pouco melhor. Após uma hora de jogo, temos mais usuários. E então fizemos alterações no segundo projeto que quebrou algo - o cronograma mudou.

É importante aqui que tenhamos uma seção na qual a dependência da probabilidade de deixar o tempo gasto no jogo mude drasticamente. Essa imagem sugere que quebramos alguma coisa. Talvez o jogo tenha começado a funcionar de maneira instável, ou arruinamos a experiência do usuário. De qualquer forma, você precisa descobrir o que os jogadores estão fazendo nesses momentos da vida do jogo e encontrar a fonte de deterioração na retenção.

2.2.2 Taxa de rotatividade ou taxa de saída

Chamamos de taxa de rotatividade um pouco diferente do que a indústria entende por esse termo. Quando surgiu a tarefa de avaliar a vazão de um público precisamente ativo, ou seja, era necessário proceder não do registro, mas da atividade do núcleo atual de usuários, “criamos” nossa taxa de rotatividade. Nós calculamos da seguinte maneira: para cada data, contamos os jogadores que estavam ativos e, em seguida, vemos quantos deles não estão mais conectados durante um determinado período, ou seja, deixaram o jogo. Então obtemos a probabilidade estatística de um jogador sair com os parâmetros fornecidos em um determinado dia.

Geralmente analisamos a vazão por nível, idade, status de pagamento. Um aumento acentuado na métrica sugere que a probabilidade de jogadores deixarem esse segmento aumentou e você precisa procurar por razões. Se a taxa de rotatividade aumenta constantemente após uma atualização perceptível, faz sentido soar o alarme.

2.2.3 Entrada e saída de recursos

A idéia é a mesma que no caso da metodologia para avaliar a economia de um novo projeto, só que agora temos um núcleo que possui ciclos de jogo para obter e gastar recursos.



A linha amarela é despesas, a linha preta é renda livre. Há uma grande diferença entre eles, a renda é menor que as despesas. O delta é um déficit que cria demanda por nossos recursos negociados. Conheci vários projetos em que a situação era completamente oposta: eles são monetizados apenas à custa de grandes usuários pagantes. Em termos gerais, se os custos unitários de um recurso monetizado excederem a renda gratuita específica, será uma economia escassa e saudável.

3. Dicas

3.1 Suavização das tendências a longo prazo

Suponha que estamos seguindo algum parâmetro importante. Por exemplo, LTV (ARPU cumulativo) por 30 dias para um novo público. É difícil trabalhar com isso. Ele é muito sensível a grandes pagadores, possui uma alta dispersão; portanto, sua agenda para sucessivas coortes em dinâmica parecerá completamente não representativa. Podemos quebrar esse parâmetro por meses ou grupos, mas não é exatamente isso que queremos ver na dinâmica.

Há conselhos simples sobre como analisar esses indicadores com mais eficiência: aplicamos suavização deslizante. Para fazer isso, em cada ponto, consideramos o valor total do parâmetro junto com vários valores anteriores. A janela para suavização pode ser diferente: 7 dias, 30 dias ou mais. Quanto maior a janela, mais suave é a dinâmica e menor a influência das flutuações, mas, a longo prazo, deve haver tendências para vê-las claramente.



Temos um bom indicador facilmente percebido que mantém um significado físico. Ao mesmo tempo, é fácil notar uma diminuição no final do gráfico.

3.2 Testes A / B

Nós realmente amamos testes A / B. Temos um projeto no qual realizamos 70 testes A / B completos em apenas 2 anos. Se resumirmos nossa experiência em um certo aperto, podemos dizer o seguinte:

• Os testes A / B são a maneira mais honesta (realista) de testar hipóteses.
  
• É melhor fazê-las em um novo público. Se você testar um recurso que o público antigo já viu e depois mostrar uma nova opção, a percepção e a reação não serão as mesmas das pessoas que não viram o recurso. Provavelmente, a reação será negativa e pública e pode afetar os resultados do teste. Somente em casos individuais, com diferenças que não são óbvias para os jogadores ou em situações específicas, os testes podem ser realizados em todo o público.
  
• . , . , , . A/B-.
  
• A/B-, , . , , .
  
• A/B-. . A/B-. , .
  
• A/B-, , . , . , . .
  

3.3

, -. , , . , , .

, :



, , . , ? , , .



, , , . , , , .

, - :

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

4.

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