Analíticas 101

Ponte en situación. Eres un homo ludus elit que apenas ha salido de la cueva en los últimos meses. Sueñas con código fuente y cuando miras hacia el mundo exterior hay un shader muy chungo que te hace daño en la Main Camera. Pero te acostumbras, evolucionas, porque es lo que toca, porque AL FIN, tú y tus compañeros habéis terminado vuestro juego.

Os hacéis la foto de rigor mostrando vuestra euforia, que probablemente retuitearán chorrocientas personas. Os vais a comer. A celebrar por todo lo alto. Todo a cuenta de la ingente cantidad de pasta que vais a ganar con vuestro juego. Lo de siempre. La rutina del desarrollador de juegos. Cueva y desfase a partes iguales, como los osos pardos.

¿Y entonces qué? ¿Se acabó? ¿Nos olvidamos y a otro juego?

Pues no.

El lanzamiento es sólo un hito en la vida del juego. Un hito importante, eso sí, pero no es ni mucho menos el último. Cuando lanzamos, ese juego deja de ser nuestro juego y pasa a ser del jugador. Su experiencia lo redefine. Nosotros podemos haber diseñado una experiencia y desarrollado algo que creemos que la transmitirá de forma fiel, pero eso nunca va a ocurrir. La experiencia de cada usuario será siempre única y sólo podemos aspirar a que ésta se aproxime, aunque sea mínimamente, a lo que habíamos previsto.

Por mucho que hayamos querido pulir el juego en su lanzamiento, siempre vamos a tener casos de uso que no habíamos previsto. Un buen testeo va a detectar la mayor parte de los problemas, pero probablemente no todos. El comportamiento de un usuario que sabe que está “probando” no va a ser el mismo que el de un usuario final.

En EducaGames, la experiencia que buscamos, aparte de los matices de cada juego, se resumen en dar ratos de diversión a los niños mientras se repasan e interiorizan conceptos por el camino. Nuestros diseños deben conducir al jugador a través del juego para que no se pierdan partes que creemos importantes para su aprendizaje o para contribuir a la diversión, manteniendo así la atención.

Nuestros dos primeros juegos, Monster Numbers y Dino Tim, siguen un esquema bastante lineal, con una historia que completar de principio a fin, aunque en Dino Tim se da cierta libertad para decidir en qué orden resolver los niveles. Sin embargo, Buddy School, tiene una filosofía más abierta. Su menú se presenta como un escenario jugable desde el que se puede acceder al resto de puzzles.

 

juegos educativos

Es una idea que nos encanta, y por eso lo hemos hecho, pero corremos el riesgo de desviar la atención sobre otras características que también son importantes. El minijuego del menú es la parte, digamos, menos educativa del juego. Es una prueba de habilidad que permite ganar estrellas para desbloquear otros puzles o cromos de la colección. A esos puzles, la parte educativa de Buddy School, se accede mediante botones integrados en el escenario.

Un tester examinará la escena y, probablemente, identificará los botones y entrará en cada uno de los juegos al menos una vez. Sin embargo, un usuario que haya instalado la versión gratuita y esté aún decidiendo si quedársela, puede pensar que el menú es todo lo que hay en el juego. Tal vez no se pare a interpretar que los botones abren un mundo de puzzles. O que el botón de la parte superior izquierda muestra una fantástica colección de cromos, también jugables.

Aunque a Buddy aún le queda mucho para alcanzar el millón de usuarios de Dino Tim o Monster Numbers, ya tiene un número respetable de descargas. Esto nos permite usar eventos de analíticas para conseguir datos estadísticos de usuarios reales y extraer conclusiones que den respuesta a nuestras preguntas, que son dos:

  1. ¿Les gustan a nuestros usuarios los juegos? ¿Les llegan a enganchar? ¿Cuáles les gustan más?
  2. ¿Llegan siquiera los usuarios a probar todos los juegos?

En lo primero jugará un papel muy importante que nuestro sistema de ajuste de dificultad logre mantener el “flow”, de esto hablaremos en otra ocasión. Como diría Groucho Marx, responda primero a la segunda pregunta. Para mantener jugando a los usuarios primero debemos conseguir que lleguen hasta los juegos, así que esta es la primera pregunta que intentaremos responder.

Como es un trabajo aún en curso, dejamos para más adelante nuestro análisis de los datos y los resultados conseguidos. De momento nos vamos a centrar en el apartado técnico, esperando que sirva de guía “howto” para quienes estén pensando en incluir analíticas en su juego.

El apartado técnico 🙂

Nos hemos decantado por las analíticas de Unity, debido a que son las más fáciles de integrar si el juego está hecho con este motor. El primer paso es abrir la ventana “Services” (menú Window; Services). De entre los servicios disponibles se elige Analytics y se activa el servicio. Tal vez tengamos que crear un proyecto y asociarlo a nuestra cuenta de Unity. También se nos pedirá que declaremos el tipo de audiencia a la que está dirigida la aplicación, para cumplir con la legislación de protección de datos.

Con sólo completar este paso, ya tenemos mucho. Una vez activado el servicio de analíticas en el proyecto, sin necesidad de hacer nada más, vamos a empezar a recibir información. El visor Web de analíticas de Unity (accesible a través del enlace “Go to Dashboard” de la captura anterior) nos va a dar métricas de adquisición y retención de usuarios como el DAU, MAU, DAU/MAU, jugadores activos, número de sesiones o duración de la sesión. Si tenemos, además, compras in-app implementadas con el plug-in que proporciona Unity, nos dará también métricas relativas a esas compras.

Para hacer un análisis fino del uso del juego adaptado a nuestras necesidades, necesitamos añadir eventos personalizados (custom events). El siguiente código es un ejemplo de cómo enviar el CustomEvent que hemos llamado “EdadIntroducida” con un parámetro numérico llamado “edad”. No es necesario haber creado previamente el evento en ningún sitio o haber declarado sus parámetros. La consola de analíticas de Unity recibirá y creará los eventos y clasificará sus parámetros según sean numéricos o cadenas de texto.

  public static void EnviarEdadIntroducida(int edad)
     {
         Analytics.CustomEvent("EdadIntroducida", new Dictionary<string, object> { {"edad",edad} });
     } 

El método mostrado forma parte de una clase llamada AnalyticsManager. Para enviar el evento llamamos, desde el punto que corresponda en otro script del juego, a la función AnalyticsManager.EnviarEdadIntroducida pasando como parámetro un entero (la edad). Por ejemplo:

 AnalyticsManager.EnviarEdadIntroducida (edadParseada);

El correcto envío de los eventos personalizados se puede comprobar ejecutando el juego desde el propio editor. Para ello hay que ir, usando un navegador Web, a la consola de analíticas de Unity, en la pestaña Integration y el paso Advanced Integration.

En esta página, además de algunos ejemplos de código para crear eventos personalizados, hay un área de comprobación. Todas las analíticas que se van generando desde el editor van a ir apareciendo en dicha área, que se encuentra en la parte inferior de la página. Para comprobar la correcta integración ejecutamos el juego (en el editor de Unity) y provocamos el envío del evento personalizado, en este caso lo hacemos cambiando la edad del jugador.

El evento aparece después de unos segundos en el comprobador.

Creando eventos de esta forma podemos ir almacenando datos estadísticos sobre el uso de diferentes partes de la aplicación ¿Cuántos usuarios superan un determinado nivel? ¿Cuánto tiempo les lleva llegar a un cierto punto? ¿Cuántos abandonan alguna parte del juego antes de terminarla?

Más adelante contaremos cómo hemos utilizado los eventos personalizados para responder a nuestras propias preguntas, qué decisiones hemos tomado y el resultado de todo esto.