En este artículo, hablaré sobre análisis de productos en nuestro estudio, IT Territory. El artículo consta de tres partes. En el primero le diré cómo está organizado el departamento de análisis de productos, quiénes son sus empleados, qué hacen y por qué todo es solo eso y no de otra manera. En la segunda parte, describiré ejemplos de técnicas que hemos desarrollado y aplicado a todos los proyectos. En la tercera parte, daré algunos consejos que pueden hacer la vida más fácil y ayudar a trabajar de manera más eficiente.

Ahora nuestro estudio opera 11 proyectos de juegos móviles, dos más están en desarrollo. Estamos enfocados en el mercado móvil y creamos juegos midcore de shareware, principalmente con una economía cerrada. El estudio se ocupa de todo el espectro de trabajo, desde el desarrollo hasta la promoción y la operación. El personal de 240 personas, oficinas en Moscú y Voronezh.

Para comprender el lugar del departamento de análisis de productos en la estructura del estudio, propongo mirar este diagrama simplificado:



El departamento de análisis de productos es el departamento satélite de los equipos de proyecto, junto con los departamentos de pruebas, operación y marketing. Trabajamos muy de cerca con todos los proyectos, les proporcionamos los resultados de nuestro trabajo y recibimos información de los equipos sobre la situación actual, los planes y las prioridades. Pero al mismo tiempo informamos a la gerencia del estudio.

1. ¿Quién es analista de producto?

Es parte de un departamento separado, con cada analista asignado a un proyecto o franquicia específica. Trabaja con el equipo del proyecto, realiza tareas y ayuda a la toma de decisiones en el equipo y en la gestión. El analista usa activamente el producto, de lo contrario no tendrá experiencia de usuario, un componente muy importante que es necesario para el trabajo. Al mismo tiempo, el analista es consciente de todos los procesos, es decir, comprende qué problemas y tareas enfrenta el proyecto ahora, y dirige sus esfuerzos para resolverlos.

1.1. Enfoque analítico

Creemos que tenemos un enfoque sistemático para la analítica en nuestro estudio.



En el diseño clásico, el análisis forma parte de los equipos de proyecto. Esa persona está muy inmersa en el proyecto, lo conoce a fondo. Como regla general, los analistas de diferentes equipos prácticamente no se comunican entre sí.

En nuestro sistema, existe el papel del jefe del departamento, que traduce los requisitos, métodos y herramientas. Es decir, todos los analistas en todos los proyectos utilizan enfoques universales documentados y probados, pero no se limitan solo a ellos. Para nosotros, este es un cierto mínimo, sobre la base del cual podemos obtener un examen más privado y profundo. Los empleados pueden usar herramientas y enfoques que no se mencionan en los métodos estándar. A su vez, el jefe del departamento controla los resultados del trabajo de los analistas, y dado que él mismo es el especialista más competente, agrega al equipo su experiencia y conocimiento.

Una ventaja importante de este enfoque es que los analistas son fungibles. A menudo sucede que una persona ha estado trabajando en el mismo proyecto durante años y finalmente se quema, su mirada está "borrosa". En tal situación, transferirlo a otro proyecto suele ser muy difícil, porque el analista tiene un conocimiento específico sobre el proyecto y su infraestructura, que nadie más tiene. Pero cuando los métodos y requisitos son los mismos, después de un poco de capacitación, las personas pueden moverse entre proyectos, dándoles nuevas experiencias y desafíos.

1.2. Tareas principales

Las principales tareas del analista en nuestro departamento:

• Análisis de los cambios de KPI a medida que se desarrolla el producto .
• Detección y estudio de anomalías .
• Busque cuellos de botella y puntos de crecimiento . Esta es una tarea muy importante que le permite a una persona desarrollarse profesionalmente. Él mismo establece hipótesis, las verifica, encuentra nueva información que nadie más ve y, por lo tanto, adquiere experiencia que ningún líder dará.
• Apoyo a la decisión . Ayudamos a los miembros del equipo a responder sus preguntas.
• Soporte y desarrollo de infraestructura analítica .

Te contaré más sobre el último punto. La infraestructura consta de los siguientes niveles:



En el primer nivel está la base de datos del proyecto, en la que registramos todos los datos, y nosotros mismos utilizamos su réplica para eliminar los riesgos del proyecto.

En el segundo nivel, tenemos un almacenamiento basado en Hadoop, donde transferimos información de las bases de datos del proyecto para el análisis histórico de volúmenes muy grandes.

El siguiente nivel son los complementos sobre el repositorio para ejecutar código. Aquí puede implementar cualquier transformación de datos compleja que no podamos implementar utilizando las herramientas de los niveles anteriores.

En el último nivel, tenemos visualización. Históricamente, el software propietario, QlikView, ha sido responsable de ello. Y Excel es un clásico, para tareas rápidas siempre lo usamos.

1.3. Analista de Producto Competencias

Destacamos la siguiente lista:

• SQL y lenguajes similares;
  
• arquitectura de base de datos;
  
• lenguajes de programación (Python, R, Scala);
  
• matemática y estadística matemática;
  
• lógica y pensamiento de producto;
  
• capacidad de defender la posición de uno;
  
• Habilidades de comunicación.
  

Quiero enfatizar los dos últimos puntos. En general, se acepta que el analista es introvertido con un coeficiente intelectual superior a 130, que prepara informes de 50 páginas sobre lo que está sucediendo en su área de responsabilidad. Pero, de hecho, en nuestro paradigma, el analista es la persona que impulsa los problemas y los puntos de crecimiento que descubre. Es difícil en el equipo convencer a la gente de que has encontrado algo importante, porque todos están comprometidos en su propia tarea prioritaria. Pero simplemente transmitir esta información y olvidarse de ella, tal posición no nos conviene. Por lo tanto, es muy importante que el analista pueda construir relaciones en el equipo, encontrar formas de defender su posición y sus conclusiones, y "impulsar" la implementación de sus recomendaciones.

2. Métodos

Ahora hablaré un poco sobre ejemplos de técnicas que transmitimos a los empleados del departamento de análisis. En nuestra opinión, los tres pilares de un exitoso producto gratuito son economía, retención y monetización. Para cada una de estas entidades, en el departamento de análisis, se desarrollan métodos para evaluar y comparar con otros proyectos. Se pueden dividir en tres grandes grupos:

• Métodos de evaluación inicial del producto . Enfoques que son relevantes en las primeras etapas de la vida de un producto, cuando todavía no hay un núcleo, y solo hay un nuevo juego en el que una audiencia acaba de comenzar a aparecer.
  
• Métodos para evaluar cambios en un proyecto con un núcleo . Se utilizan para evaluar los cambios en las nuevas versiones del juego, el efecto de agregar funciones y ediciones, tanto en KPI como en el rendimiento del producto en su conjunto.
  
• Métodos de estudio de anomalías . Los desarrollamos para una reacción típica a situaciones anormales comunes con indicadores de producto. Hay ciertos enfoques, qué y en qué orden necesita analizar para encontrar rápidamente las causas más probables y comenzar a resolver el problema.
  

Hablaré sobre las anomalías en otro momento, y hoy hablaremos sobre la evaluación inicial y el análisis de los cambios utilizando el clásico proyecto F2P con una economía cerrada.

2.1. Técnicas de evaluación inicial

Ejemplos de técnicas de evaluación inicial:

• Retención
  
• CARPU (LTV) para mercados clave;
  
• FPE (conversión en el pago);
  
• conversión de inicio fijo (tutorial);
  
• puntos de progreso que causan la retirada;
  
• puntos de progreso que estimulan los pagos;
  
• entrada y salida de recursos en el contexto de progreso y / o vida útil;
  
• WinRate primeros intentos + número de intentos antes de completar con éxito.
  

Te contaré un poco más sobre varios de ellos.

2.1.1 La economía de los primeros días de vida.

Acabamos de lanzar un nuevo producto en el lanzamiento y queremos evaluar el estado actual de la economía de divisas. Hay una forma bastante simple de una evaluación de alto nivel del equilibrio de la demanda de dicho recurso. Deje que el gasto acumulado en el juego en los primeros días de vida se vea así:



El eje X representa el ciclo de vida. El ingreso acumulado es gratuito, es decir, nuestros gastos totales exceden el ingreso específico por usuario. Por lo tanto, tenemos una escasez de este recurso, que está cerrado por la compra. Este es el primer corte más general. Luego lo dividimos en fuentes y buscamos de dónde proviene el aumento del ingreso gratuito. La regla general es: si los gastos exceden los ingresos gratuitos, tendrá una demanda. Puede ajustar su volumen utilizando la relación de gastos e ingresos gratuitos. Si su ingreso gratuito cubre el costo unitario por usuario, lo más probable es que solo paguen aquellos cuyos costos son muy altos. Es decir, usuarios muy leales, pero no la masa total.

2.1.2 Conversión de progreso

Uno de los aspectos más importantes para un juego es la retención primaria. En los primeros minutos después de la instalación, las personas se familiarizan con el juego y deciden si lo jugarán o no. La mayoría de los proyectos pierden la mitad de la audiencia en los primeros 30 minutos. ¿Cómo puedo encontrar rápidamente problemas para retener a mi audiencia? En relación con el progreso, hacemos esto usando un embudo clásico:



Creamos un gráfico del número de usuarios que alcanzan ciertos puntos clave. El gráfico muestra caídas pronunciadas en los puntos 4, 10 y 20. Si calcula la conversión relativa de un punto a otro, verá inmediatamente caídas en las que la conversión cae bruscamente en relación con los puntos vecinos. Las razones son diferentes: problemas en UX, el problema de elegir entre diferentes modos, cuando los usuarios no van de acuerdo con su estrategia, sino que van a PvP u otros modos, complejidad, fallas técnicas, etc. Pero en general, estos son los puntos a los que debe prestar atención de inmediato, ya que provocan que los usuarios se vayan o no actúen en la curva de progreso de su elección.

2.1.3 Atención y puntos de pago

Aquí hay un proyecto de ejemplo en el que estos puntos son muy pronunciados:



En ciertos puntos en el progreso de los jugadores, ocurren estallidos de pagos y retiros de usuarios. La razón es que en estos momentos las personas se enfrentan al hecho de que es imposible avanzar más en el juego hasta que acumules un cierto número de puntos. Como resultado, los débiles se van, y aquellos que quieren vencer mal el juego y al mismo tiempo ahorrar tiempo, usan funciones pagas.

Una vez recibida esta información, el equipo debe trabajar en el saldo para perder la menor cantidad de personas posible, pero al mismo tiempo, maximizar o ahorrar pagos.

2.1.4. Cuestiones importantes de monetización

El tema de la monetización es muy extenso. Abordamos cada proyecto individualmente y creemos que la monetización proviene del diseño, y no es un enfoque universal que pueda aplicarse en todas partes. En resumen, nuestros métodos pueden expresarse en las preguntas que hacemos, y los puntos de aplicación de los esfuerzos dependerán de las respuestas a estas preguntas.

¿Qué producto convierte mejor a un usuario en uno que paga? Teníamos un proyecto que "disparó" muy bien al principio. Pero solo unos meses después de recibir el largometraje, después de digerir un volumen suficientemente grande de la audiencia, el proyecto de ingresos comenzó a caer, y bastante en serio. Tenía un buen agarre para el proyecto de midcore, y el juego era bastante difícil. No tuvimos suficiente masa salarial para llevar el proyecto a una meseta financiera debido a los pagos de la audiencia central.

Decidimos que necesitamos romper la primera barrera de pago para la mayoría de los usuarios. Elegimos contenido exclusivo que no se había vendido ni por la moneda del juego ni por dinero, y le pusimos el precio más bajo posible. Naturalmente, este contenido no era un ultimátum y no cubría todas las necesidades del jugador. Comenzando a ofrecerlo desde el comienzo de la monetización asequible en el juego, de un solo golpe aumentamos la cuota de pago en un tercio, mientras mantenemos la factura promedio.

Cuanto antes entre el usuario en la categoría de pago, mayor será la parte integral de sus ingresos en el juego. Tenga en cuenta que cada juego tendrá su propio contenido que resuelva mejor este problema. Si en otros juegos haces lo mismo en la frente, entonces no puedes adivinar. Es muy importante entender que una persona realmente aprecia en el juego qué contenido se demandará en esta etapa, y cómo evitar un golpe a la economía y el equilibrio en general.

¿Qué proporción de usuarios se convierten a pagar en las etapas posteriores del juego? Si tiene muchos pagadores nuevos después del día 30 de su vida, lo más probable es que reciba menos dinero. Estas personas han estado jugando durante un mes, ya han cumplido sus objetivos a corto y mediano plazo. Pero al mismo tiempo, no tenían la motivación suficiente para comenzar a pagar. Y en las etapas posteriores, ella apareció de repente. Permítame recordarle que si un usuario realiza una conversión tardía, sus ingresos específicos disminuirán en comparación con la situación si se convirtió en los primeros días del proyecto. Por lo tanto, es necesario encontrar motivación para que los jugadores se conviertan a pagar en una etapa temprana.

¿Cuántos usuarios se convierten en dos compras, tres, etc.? Si creamos un producto que convierte perfectamente a los usuarios en una etapa temprana y obtenemos muchos pagadores nuevos, entonces surge la siguiente barrera. Entre dicho producto y el resto de sus ofertas puede haber una gran brecha en el precio, y para los usuarios que compraron un buen producto por un dólar, todas las demás ofertas parecerán no rentables. En tal situación, es necesario pensar en la cadena: ¿cuál será el próximo paso del jugador que debería convertirse en un pagador de pleno derecho? Si compra un producto muy rentable a bajo precio, es necesario presentar diversas ofertas para él que aumenten gradualmente el tamaño del cheque, pero al mismo tiempo cada vez que le brinden al usuario una nueva calidad.

¿Existe una estrategia clara para aumentar el tamaño de los cheques? No basta con convertir a los usuarios, porque es obvio que esas personas se compraron a sí mismas con una oferta bastante barata. Es importante construir correctamente una estrategia para que cada producto posterior en demanda esté en una categoría de precio diferente. No estoy hablando de inmediato sobre sumas grandes, pero tiene una métrica como el cheque promedio para el pagador. Una persona que se ha convertido de una oferta barata debe ser llevada a esto. Esto es posible, y la mayoría de las personas se niegan a pagar por razones psicológicas.

¿Existe un proceso de rechazo de pagos mientras se mantiene la actividad? En muchos juegos, en las etapas posteriores de la vida del proyecto, los jugadores se adaptan a la economía, ajustan sus necesidades a sus capacidades y pasan a la etapa de no pagar o comprar lo mínimo. Aquí debes trabajar en términos de diseño de juegos. Esto puede significar que el juego es demasiado monótono y a largo plazo, con muy pocos desafíos motivadores. Sin embargo, debido al núcleo de usuarios, el juego puede crecer muy bien y desarrollarse como un proyecto empresarial.

Por supuesto, estos no son todos los aspectos importantes del enfoque de la monetización, sin embargo, el trabajo adicional dependerá en gran medida de los matices del producto.

2.2. Evaluación de cambio de producto

Ahora hablemos de los métodos para evaluar los cambios en el producto. Esto es:

• [Todos los métodos de evaluación inicial] +
  
• métricas de monetización de flujo: DPU, ARPPU, ARPDAU;
  
• minuto de retención rodante;
  
• entrada y salida de recursos en dinámica;
  
• Tasa de rotación;
  
• duración promedio de estadía en la solicitud;
  
• dinámica de actividades clave;
  
• balance de recursos disponibles.
  

Me detendré en algunas de las técnicas.

2.2.1. Minuto de retención rodante

La retención continua por minuto es una buena manera de comprender rápidamente si hay algún problema técnico o de diseño al comienzo, en los primeros minutos del juego.
Veamos el cronograma del primer proyecto:



Curva logarítmica, todo está claro: cuanto más tiempo haya estado un jugador en el juego, es menos probable que se vaya. El segundo proyecto también es saludable, pero el resultado es ligeramente mejor. Después de una hora de juego, tenemos más usuarios. Y luego hicimos cambios en el segundo proyecto que rompió algo: el horario cambió.

Es importante aquí que tengamos una sección en la que la dependencia de la probabilidad de abandonar el tiempo que pasa en el juego cambie dramáticamente. Tal imagen sugiere que hemos roto algo. Quizás el juego comenzó a funcionar de manera inestable, o arruinamos la experiencia del usuario. En cualquier caso, debes averiguar qué están haciendo los jugadores en estos momentos de la vida del juego y encontrar la fuente de deterioro en la retención.

2.2.2. Tasa de rotación o tasa de salida

Llamamos a Churn Rate un poco diferente de lo que la industria quiere decir con este término. Cuando surgió la tarea de evaluar el flujo de salida de una audiencia activa precisamente, es decir, era necesario proceder no desde el registro, sino desde la actividad del núcleo actual de usuarios, "se nos ocurrió" nuestra tasa de rotación. Lo calculamos así: para cada fecha contamos los jugadores que estuvieron activos y luego vemos cuántos de ellos ya no se registraron durante un cierto tiempo, es decir, abandonaron el juego. Entonces obtenemos la probabilidad estadística de que un jugador se vaya con los parámetros dados en un día determinado.

Por lo general, analizamos el flujo de salida por nivel, edad, estado de pago. Un fuerte aumento en la métrica sugiere que la probabilidad de que los jugadores abandonen este segmento ha aumentado, y hay que buscar razones. Si la tasa de rotación aumenta constantemente después de una actualización notable, tiene sentido hacer sonar la alarma.

2.2.3. Entrada y salida de recursos

La idea es casi la misma que en el caso de la metodología para evaluar la economía de un nuevo proyecto, solo que ahora tenemos un núcleo que tiene ciclos de juego para obtener y gastar recursos.



La línea amarilla es gastos, la línea negra es ingreso gratis. Hay una gran diferencia entre ellos, los ingresos son más bajos que los gastos. Delta es un déficit que crea demanda para nuestros recursos comercializados. Conocí varios proyectos en los que la situación era completamente opuesta: se monetizan solo a expensas de los grandes usuarios que pagan. En términos generales, si los costos unitarios de un recurso monetizado exceden el ingreso gratuito específico, entonces esta es una economía sana y escasa.

3. Consejos

3.1. Suavizado de tendencias a largo plazo

Supongamos que estamos siguiendo algún parámetro importante. Por ejemplo, LTV (ARPU acumulativo) durante 30 días para una nueva audiencia. Es difícil trabajar con ellos. Es muy sensible a los grandes pagadores, tiene una gran dispersión, por lo que su agenda para cohortes sucesivas en dinámica parecerá completamente no representativa. Podemos dividir este parámetro por meses o grupos, pero esto no es exactamente lo que queremos ver en la dinámica.

Hay consejos simples sobre cómo analizar dichos indicadores de manera más eficiente: aplicamos suavizado deslizante. Para hacer esto, en cada punto consideramos el valor total del parámetro junto con varios anteriores. La ventana para suavizar puede ser diferente: 7 días, 30 días o más. Cuanto más grande es la ventana, más suave es la dinámica y menos influencia de las fluctuaciones, pero a más largo plazo debe haber tendencias para poder verlas claramente.



Tenemos un buen indicador fácil de percibir que conserva el significado físico. Al mismo tiempo, es fácil notar una disminución al final del gráfico.

3.2. Pruebas A / B

Realmente amamos las pruebas A / B. Tenemos un proyecto en el que realizamos 70 pruebas A / B completas en solo 2 años. Si resumimos nuestra experiencia en cierta compresión, podemos decir lo siguiente:

• Las pruebas A / B son la forma más honesta (realista) de probar hipótesis.
  
• Es mejor hacerlo en una nueva audiencia. Si prueba una función que la audiencia anterior ya ha visto y luego le muestra una nueva opción, la percepción y la reacción no serán las mismas que para las personas que no vieron la función. Lo más probable es que la reacción sea negativa y pública, y puede afectar los resultados de la prueba. Solo en casos individuales, con diferencias que no son obvias para los jugadores o en situaciones específicas, se pueden realizar pruebas en toda la audiencia.
  
• . , . , , . A/B-.
  
• A/B-, , . , , .
  
• A/B-. . A/B-. , .
  
• A/B-, , . , . , . .
  

3.3.

, -. , , . , , .

, :



, , . , ? , , .



, , , . , , , .

, - :

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

4.

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