Cómo usar SQL Data Explorer para analizar datos de juegos

Consulta nuestra colección de recetas en el SQL Cookbook para explorar los ricos datos en UGS. Ten en cuenta que UGS utiliza el sabor de SQL Snowflake.

Una de las consultas del libro de cocina analiza las estadísticas de misiones. Adaptamos ese código para echar un vistazo rápido a las tasas de fracaso de misiones en nuestro juego ficticio. Esto utiliza eventos personalizados que hemos creado para rastrear el compromiso de los jugadores con las misiones, con nuestro parámetro missionID.

Para esta consulta, utilizaremos la tabla de EVENTOS por defecto. Esta tabla incluye datos granulares para cada evento registrado en nuestro juego.

Ten en cuenta que usamos un filtro de fecha aquí para limitar nuestra consulta y mantenerla eficiente. Sin este límite, la consulta se ejecutaría sobre los 365 días completos de datos que son consultables por defecto en SQL Data Explorer. Además, siempre es más eficiente especificar qué columnas te interesan en lugar de usar SELECT *.

Frases como EVENT_JSON:missionID::INTEGER parecen intimidantes, pero si escribes 'missionID' y usas autocompletar, SQL Data Explorer genera la sintaxis JSON para ti, suponiendo que tienes ese parámetro configurado en tu propio juego.

Después de ejecutar la consulta, podemos graficar nuestros resultados para ver la historia en los datos. Los gráficos actualmente soportan hasta dos ejes Y y un eje X. Las etiquetas de los ejes se pueden renombrar fácilmente usando la expresión 'as' en tu consulta SQL; en este caso, nuestro eje Y toma el nombre que definimos: “Jugadores fallaron %”.

Vemos que más de uno de cada tres jugadores ha fallado en nuestra primera misión (missionID 0), por lo que podemos ajustar la dificultad de la misión para ofrecer a los usuarios una experiencia inicial más positiva.

Consejo: Si tienes algunos valores NULL en tus datos y encuentras que esto hace que un eje se vea extraño, usa coalesce(yourParameter, 0) para llenar los espacios en blanco.

Cuando ejecutamos una consulta, obtenemos una tabla de nuestros resultados. Agrega PLATAFORMA a nuestra consulta; en la imagen de arriba, verás cómo se ve la tabla ahora. Nota el botón ‘Pivotar’ a la derecha. Esto es útil para reestructurar nuestros datos sin necesidad de reescribir nuestra consulta.

En nuestro ejemplo, podríamos usar la herramienta de pivote para ajustar nuestros datos y obtener PLATAFORMA en las filas y MISIONID como las columnas.

Ajustar la tabla muestra que hubo poca diferencia en los fallos de misión entre plataformas.

A medida que tu juego se vuelve cada vez más exitoso y tu base de jugadores crece, podrías encontrar que incluso consultas simples tardan un tiempo significativo en ejecutarse.

Digamos que quieres ejecutar esta consulta básica contra tus datos:

Podrías esperar que se ejecute bastante rápido, pero con un conjunto de datos grande, eso no siempre es el caso. Aprovecha la forma de nuestro almacén y el hecho de que los user_ids se almacenan como un hash para usar un método rápido que reduzca el número de usuarios incluidos y aumente la velocidad de la consulta.

Aquí, estamos dividiendo a nuestros usuarios en 100 cubos asignados y numerados pseudoaleatoriamente y mirando el cubo número 63.

Agregar este código en consultas simples no hará mucha diferencia, pero a medida que aumentamos la complejidad computacional, filtrar datos de esta manera es cada vez más crítico. Incluso en nuestro juego ficticio, encontramos que esta versión revisada de nuestra consulta se ejecutó un 75% más rápido que la original. Esto ahorra tiempo y dinero para obtener información sobre subconjuntos de usuarios sin tener que procesar conjuntos de datos completos.

En las consultas anteriores, usamos count(distinct…) para calcular nuestro número de jugadores individuales y combinaciones de eventos. Una forma de mejorar la velocidad de nuestra consulta, si no necesitamos un 100% de precisión con nuestros resultados, es usar approximate_count_distinct. Nuestra consulta anterior se convierte en:

Hasta ahora, solo hemos estado utilizando la tabla principal de EVENTOS. Como esta tabla contiene datos granulares sobre cada evento que hemos tenido en nuestro juego, es la tabla más extensa. Para mejorar nuestras consultas, podemos usar objetos más pequeños para ejecutar nuestras consultas de manera más eficiente.

Echemos un vistazo al panel del Glosario, para explorar las tablas que tenemos disponibles para consultar.

Junto a EVENTOS, aquí encontramos todas las tablas agregadas disponibles para consultar. Todas estas están disponibles directamente con UGS.

• La tabla de USUARIOS contiene una sola fila por jugador junto con sus métricas de vida en el juego, como conteos de eventos, tiempo total de juego, gasto total, etc.
• FACT_USER_SESSIONS_DAY incluye datos sobre cada sesión de cada jugador.
• FACT_EVENT_TYPE_USERS_DAY consiste en una fila para cada evento que un jugador ha enviado cada día, junto con un conteo total.
• FACT_WAU_USERS y FACT_MAU_USERS incluyen datos de perfil para usuarios que jugaron dentro de la semana o mes anterior en un día determinado.

Entre FACT_EVENT_TYPE_USERS_DAY y FACT_USER_SESSIONS_DAY, probablemente puedas responder más del 80% de la mayoría de las consultas sobre objetos más pequeños.

Por ejemplo, en nuestra primera consulta, estábamos observando las tasas de fallos de misiones. También podríamos usar FACT_EVENT_TYPE_USERS_DAY para calcular las tasas de fallos generales cada día, con el conteo de NUMBER_OF_EVENTS almacenado en esta tabla.

También utilizaremos una de estas tablas en nuestra próxima consulta:

Usa esta consulta para ver el flujo de eventos para jugadores que cumplen con criterios específicos. Es útil para QA y depuración porque, al usar la tabla de USUARIOS mencionada anteriormente, obtendrás un usuario diferente cada vez que la ejecutes.

Si, por ejemplo, sospechas que los eventos no se están registrando correctamente para los jugadores que instalaron una cierta versión de tu juego, puedes ejecutar la consulta a continuación. Lo que regresa es el flujo de eventos de un jugador aleatorio que ejecuta la versión del juego que parece estar experimentando problemas. Haz esto unas cuantas veces, y puedes comenzar a detectar patrones en los datos rápidamente.

Consejo: Si deseas comentar varias líneas, usa el atajo de teclado CTRL+/.

Es posible que estés acostumbrado a escribir consultas SQL en lenguajes distintos a Snowflake; por ejemplo, si usaste la herramienta de minería de datos deltaDNA anterior, probablemente escribiste consultas en Vertica.

Ahora puedes referirte a variables recién definidas sin necesidad de incluirlas primero en una expresión de tabla común (CTE). Por ejemplo, esta consulta se ejecuta con éxito en SQL Data Explorer, pero en el deltaDNA original, habría generado un error de "la columna 'rice' no existe":

Hay mucho potencial en SQL Explorer. Hay mucho más por descubrir en UGS Analytics, incluyendo muchas opciones de gráficos como gráficos de pastel y gráficos de barras apiladas. Acceso Directo te da acceso directo a tus datos de Analytics a través de Snowflake.

Para acelerar tus conocimientos y obtener apoyo para construir tus consultas y paneles, contáctanos.

Lectura adicional

• Documentación de UGS Analytics
• Recetario SQL
• Presentación de Funnels y SQL Data Explorer
• Referencia de funciones SQL de Snowflake
• Precios de UGS