Cuando empezamos a desarrollar Dinopirates from Inner Space, tomábamos decisiones de diseño basándonos principalmente en intuición y en el feedback directo de quienes probaban el juego internamente. Eso funciona hasta cierto punto, pero tiene un límite claro: la intuición no escala, y el feedback directo es difícil de conseguir en volumen.

Los analytics existen para darle estructura a ese proceso. No para reemplazar el juicio de diseño, sino para apoyarlo con evidencia real de cómo la gente interactúa con un producto.

El caso clásico: e-commerce

La forma más intuitiva de entender analytics en un producto digital es mirando cómo se usan en e-commerce, donde llevan décadas perfeccionando la práctica.

Cuando alguien entra a una tienda online, recorre un camino predecible: ve un anuncio, llega al sitio, navega productos, agrega algo al carrito, y —idealmente— compra. Ese camino se llama customer journey, y en e-commerce cada paso se mide con precisión.

¿Por qué importa medirlo? Porque en algún punto de ese camino, la gente se va. Y saber dónde se va cambia completamente qué problema hay que resolver.

Si el 80% abandona en la página del producto, el problema es la presentación o el precio. Si abandona en el checkout, puede ser fricción en el proceso de pago. Si abandona en el carrito, quizás el envío sale caro. Sin datos, solo puedes adivinar cuál de esos es tu problema real.

En videojuegos aplica exactamente la misma lógica, con el juego como producto y el jugador como cliente.

El customer journey en un videojuego

El equivalente en juegos es el recorrido que hace un jugador desde que abre el juego por primera vez hasta que se convierte en alguien que lo termina, lo recomienda, o sigue jugando semanas después.

Cada juego tiene su propio journey según su género y mecánicas, pero la estructura es similar:

¿Llega al loop central?  →  ¿Lo entiende?  →  ¿Vuelve a intentarlo?  →  ¿Se engancha?

La pregunta que guía el diseño de analytics es: ¿en qué parte de ese camino se pierde la gente?

El funnel de Dinopirates

Para el Playtest de Dinopirates, definimos un funnel de conversión simple con cuatro hitos:

Game Started → First Raid → Second Raid → Survey

Cada uno de esos hitos responde una pregunta concreta:

Game Started → ¿El jugador abrió el juego y pasó la pantalla inicial? Este evento viene gratis con Unity Analytics, no requiere código adicional.

First Raid → ¿Entendió suficientemente el juego como para lanzarse a su primera Raid? Si muchos jugadores se quedan en el menú principal sin entrar a una Raid, hay un problema de onboarding o de comunicación del loop.

Second Raid → Este es el hito más revelador. Un jugador que muere en su primera Raid y decide volver a intentarlo está mostrando que el juego le generó suficiente interés para seguir. La conversión entre First y Second Raid nos dice si el core loop engancha.

Survey → Para el Playtest, el llenado de la encuesta es nuestro evento de conversión final. Nos indica qué jugadores llegaron al punto de tener una opinión formada sobre el juego.

Cuatro eventos, cuatro preguntas claras. No necesitamos medir todo para tomar decisiones útiles.

Más allá del funnel: datos agregados de los jugadores

Además de los eventos de conversión, Unity Analytics entrega automáticamente información agregada sobre quiénes son tus jugadores. Esto es valioso por razones distintas: no te dice cómo juegan, sino en qué contexto lo hacen.

Con la integración base, sin escribir ningún evento custom, puedes ver:

  • Países — desde dónde se juega. Importante para decisiones de idioma, horarios de lanzamiento, o campañas.
  • Sistema operativo — distribución de Windows, macOS, Linux en tu base de usuarios.
  • Hardware — qué CPUs y GPUs usan los jugadores. Imprescindible para saber si tus ajustes de performance tienen sentido para tu audiencia real. Si el 60% de tus jugadores tiene una GPU de gama media-baja, optimizar para high-end es prioridad equivocada.

En el caso de Dinopirates, saber la distribución de hardware del Playtest nos ayuda a calibrar los objetivos de performance antes de un eventual lanzamiento de Demo.

Medir para decidir

La idea central de este artículo es simple: los analytics son una herramienta para tomar mejores decisiones, no un fin en sí mismos.

El flujo que nos funciona:

  1. Pregunta primero: ¿qué queremos saber? Ejemplo — ¿cuántos jugadores del Playtest llegan a intentar una segunda Raid?
  2. Identifica el hito: en este caso, el evento secondRaidStart.
  3. Mide: deja correr el Playtest y observa la tasa de conversión.
  4. Decide: si el número es bajo, hay algo que no funciona entre la primera y segunda Raid. Si es alto, el core loop está haciendo su trabajo.

Sin esa pregunta previa, los datos son ruido. Con ella, son información accionable.

En el próximo artículo cubrimos la parte técnica: cómo implementar Unity Analytics en tu proyecto, cómo manejar el consentimiento del usuario correctamente, y qué datos obtienes con la integración base.