Para un estudio de videojuegos, los datos han dejado de ser un informe de fin de mes. Que un jugador se quede, cuánto gasta y dónde se atasca en un nivel se decide en los eventos que el juego envía cada segundo. El detalle es que la analítica de jugadores rara vez falla a nivel de idea y casi siempre falla a nivel de ingeniería: escala, calidad del dato y si el equipo aguanta el ritmo de la producción.
Por nuestra experiencia, lo difícil no es decidir qué medir, sino entregar un pipeline que soporte el tráfico de toda la base de jugadores y ponga números fiables en manos del equipo a tiempo. Aunque aquí no mostremos un caso de éxito con un dashboard de retención terminado, tenemos a la gente que hace esto y competencia real en procesamiento de streams, incluido un proyecto de gaming construido sobre Apache Kafka. Este artículo enseña cómo abordamos el problema.
¿Por qué cuesta tanto domar los datos de un juego?
Un juego es una de las fuentes de datos más exigentes con las que se topará un equipo de analítica. La escala puede ser extrema: un título móvil popular puede emitir miles de millones de eventos al día, y cada sesión de jugador son decenas de eventos, desde el inicio de nivel hasta la microtransacción. A eso se suma la variedad: un evento de compra no se parece en nada a uno de combate, y el esquema se mueve con cada parche.
Los datos de juego son además densos en tiempo y contexto. Un toque suelto significa poco; solo una secuencia de eventos dentro de una sesión cuenta la historia del jugador. Por eso la telemetría en crudo necesita un modelo que organice los eventos en sesiones, niveles y cohortes antes de que nadie vea un gráfico. Sin él, el equipo se ahoga en datos que no se comparan con nada.
¿Cómo se construyen el pipeline de eventos y la telemetría del jugador?
El cimiento es la telemetría de juego, el contrato de eventos entre el cliente del juego y el backend. Lo diseñamos versionado y tolerante al cambio, porque el esquema de level_completed de hoy tiene que convivir con una versión de hace tres parches. Los eventos fluyen desde el cliente y el servidor de juego hacia una capa de ingesta, y desde ahí hacia el procesamiento de streams.
El corazón de esa capa suele ser el streaming construido sobre Apache Kafka. Kafka amortigua los eventos entrantes, los reparte en topics (compras, progresión, sesiones) y permite que varios consumidores lean el mismo stream de forma independiente. Sobre esa base construimos:
- la capa de ingesta de eventos (SDK de cliente, API de recogida, validación de esquema),
- el procesamiento de streams (Kafka, agregaciones al vuelo, enriquecimiento de eventos),
- un almacén analítico (un warehouse o un data lake para consultas ad hoc),
- una capa de servicio que alimenta dashboards y modelos.
Al separar el stream del almacén, los mismos eventos alimentan en paralelo un informe en vivo y un entrenamiento de modelo, sin bloquearse entre sí.
¿Qué dashboards de embudo y retención dan al equipo una imagen real?
Cuando los datos fluyen, el equipo los necesita en una forma que lleve a decisiones. Construimos los dashboards en torno a las dos preguntas que quitan el sueño a un director de producto: dónde perdemos jugadores y si vuelven. El embudo de onboarding muestra en qué paso de la primera sesión caen los jugadores; a menudo una sola pantalla de tutorial decide el destino de una instalación que ha costado una campaña de marketing.
El segundo eje es la retención por cohortes. Cortamos las cifras estándar de D1, D7 y D30 por fecha de instalación, canal de adquisición y versión del juego, para distinguir el efecto de un parche del de una campaña. Esa vista convierte un vago «la retención ha bajado» en un concreto «la cohorte de la última actualización cae en D7 en el jefe nuevo».
¿Cómo se levanta una infraestructura de tests A/B?
Las decisiones dentro del juego merecen resolverse con datos y no con instinto, lo que convierte la infraestructura de tests A/B en un asunto de ingeniería propio. Necesitas una capa que asigne jugadores a variantes (determinista y estable entre sesiones), un mecanismo de feature flags que cambie de variante sin publicar una build nueva, y rigor estadístico del lado del análisis. Lo conectamos al pipeline de eventos para que la exposición a una variante sea en sí misma un evento, lo que permite medir con honestidad el efecto del cambio sobre la conversión o la duración de sesión. Sin esa disciplina, los tests producen números en los que no se puede confiar.
¿Cómo se reportan el balanceo y la economía del juego?
Un juego free-to-play es una economía viva, y sus informes de balanceo económico son tanto analítica como herramienta de diseño. Seguimos los flujos de moneda del juego, el ritmo de ganar y gastar recursos, la inflación de recompensas y los puntos donde los jugadores chocan contra un muro. Desglosamos las fuentes y los sumideros de moneda por segmento, porque el juego no se juega igual para una ballena que paga que para alguien que no paga. Un buen informe de economía permite a un diseñador ajustar una tasa de drop o el precio de un objeto antes de que un balanceo roto arrastre la retención y los ingresos.
¿Cómo funcionan los modelos de predicción de churn?
La parte más interesante empieza cuando pasas de describir a predecir. La predicción de churn es un modelo de machine learning que estima, a partir del comportamiento de un jugador, la probabilidad de que deje de jugar. Construimos las features desde el stream de telemetría: frecuencia de sesiones, tendencia del tiempo de juego, ritmo de progresión, reacción a las derrotas, historial de compras. El modelo (desde la regresión y el gradient boosting hasta redes sobre secuencias de eventos) devuelve una puntuación que el equipo de CRM convierte en acción: una oferta, una notificación, un reto ajustado al momento.
Un modelo así vale algo solo cuando es operativo y no una diapositiva de una presentación. Por eso lo diseñamos para desplegarlo desde el principio: reentrenamiento periódico, monitorización de la deriva de datos y un bucle en el que el éxito de una acción de retención vuelve al modelo como una feature más.
¿Por qué la calidad del dato lo decide todo?
Cada dashboard y cada modelo valen solo lo que valen los eventos que los alimentan. Por eso tratamos la calidad del dato como una capa propia, no como un añadido. Vigilamos unas cuantas cosas:
- validación de esquema en la ingesta, para que un evento roto de una build nueva no envenene los informes,
- tratamiento de duplicados y de eventos tardíos, habituales en una conexión móvil inestable,
- definiciones de métrica coherentes, para que «jugador activo» signifique lo mismo en todos los equipos,
- monitorización de volumen que avise cuando el flujo de eventos se calla de golpe o se dispara.
Es un trabajo ingrato y sin glamur, y decide si la dirección se fía de los números.
¿Qué competencias aportamos para la analítica de jugadores?
Formamos el equipo en torno a la etapa concreta, no «por si acaso». En los proyectos de datos y streaming solemos cubrir:
- un ingeniero de datos que construye el pipeline de eventos y el streaming (Kafka, procesamiento de streams),
- un analytics engineer / de warehouse que modela los datos para el reporting,
- un data scientist / ingeniero de ML que se hace cargo de los modelos de predicción de churn,
- un analista de producto que conecta los datos con las preguntas de negocio del estudio.
La fuerza detrás de esta alineación es el RITS Group: competencia en Big Data y procesamiento de streams, más nuestros equipos de AI/LLM/datos, que entregan proyectos de IA, LLM y machine learning. Ese respaldo nos permite cubrir tanto la ingeniería de datos como la capa de modelos.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia que suma competencias allí donde al equipo del estudio le faltan o no da abasto. En la práctica, nuestros ingenieros se enchufan al pipeline existente y lo desarrollan en lugar de reescribirlo todo desde cero. Tenemos experiencia real construyendo streaming de eventos sobre Apache Kafka, incluido un proyecto de gaming, y en proyectos de Big Data y ML a lo largo del Grupo. Verificamos las competencias antes de empezar y formamos el equipo según la etapa concreta: levantar un pipeline desde cero pide una alineación distinta que añadir un modelo de churn a una analítica que ya funciona. Trabajamos en una zona horaria cercana, así que el equipo se suma a tus code reviews y reuniones sin una rampa larga.
¿Por dónde empezar con la analítica de jugadores y la telemetría?
Empieza por la única pregunta de negocio que más duele, por ejemplo «por qué perdemos jugadores en la primera semana», y por los eventos que necesitas para responderla. Eso define la forma de tu telemetría, la arquitectura del pipeline y los roles que necesitas, antes de invertir en modelos. Las diferencias entre modelos de colaboración las tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Estás construyendo la analítica de jugadores o la telemetría de tu juego? Hablemos, te asignamos un equipo y una arquitectura a la escala de tus datos.
Construye con nosotros la analítica de jugadores y la telemetría