Comience a explorar sus datos
Utilice el Explorador de datos de Unity Gaming Services (UGS) para filtrar y utilizar sus datos en función de métricas o eventos, y agruparlos por plataforma, país o versión.
Con conocimientos básicos de SQL (lenguaje de consulta estructurado), puede mejorar su análisis y profundizar en sus datos utilizando el Explorador de datos SQL dentro de UGS. Utilice esta función para crear y ejecutar consultas, trazar resultados en diferentes tipos de visualizaciones, agregar visualizaciones a paneles personalizados y exportar sus datos para usarlos con otras herramientas de análisis. Busque SQL Data Explorer en el panel UGS Analytics del Unity Dashboard.
Russell Young, uno de los consultores de análisis de Unity, tiene consejos e ideas para comenzar sus aventuras en SQL Data Explorer.
Vea nuestra colección de recetas en el Libro de recetas de SQL para explorar los datos enriquecidos de UGS. Tenga en cuenta que UGS utiliza la versión Snowflake de SQL.
Una de las consultas del libro de cocina analiza las estadísticas de la misión. Adaptemos ese código para echar un vistazo rápido a las tasas de fracaso de las misiones en nuestro juego de simulación. Esto utiliza eventos personalizados que hemos creado para rastrear la participación de los jugadores en las misiones, con nuestro parámetro MissionID.
Para esta consulta, usaremos la tabla EVENTOS predeterminada. Esta tabla incluye datos granulares para cada evento registrado en nuestro juego.
Tenga en cuenta que aquí utilizamos un filtro de fecha para limitar nuestra consulta y mantenerla eficiente. Sin este límite, la consulta se ejecutaría durante los 365 días completos de datos que se pueden consultar de forma predeterminada en SQL Data Explorer. Además, siempre es más eficiente especificar qué columnas le interesan en lugar de usar SELECT *.
Frases como EVENT_JSON:missionID::INTEGER parecen intimidantes, pero si escribes 'missionID' y usas el autocompletado, SQL Data Explorer genera la sintaxis JSON por ti, asumiendo que tienes ese parámetro configurado en tu propio juego.
Después de ejecutar la consulta, podemos trazar nuestros resultados para ver la historia en los datos. Actualmente, los gráficos admiten hasta dos ejes Y y un eje X. Se puede cambiar fácilmente el nombre de las etiquetas de los ejes utilizando la expresión 'as' en su 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 (ID de misión 0), por lo que podemos ajustar la dificultad de la misión para brindarles a los usuarios una primera experiencia más positiva.
Consejo: Si tiene algunos valores NULL en sus datos y descubre que esto hace que un eje se vea extraño, use coalesce(yourParameter, 0) para completar los espacios en blanco.
Cuando ejecutamos una consulta, obtenemos una tabla de nuestros resultados. Agregue PLATAFORMA a nuestra consulta; En la imagen de arriba, verás cómo se ve la tabla ahora. Observe el botón 'Pivotar' a la derecha. Esto es útil para remodelar nuestros datos sin necesidad de reescribir nuestra consulta.
En nuestro ejemplo, podríamos usar la herramienta dinámica para modificar nuestros datos y obtener PLATAFORMA en las filas y MISSIONID como columnas.
Modificar la tabla muestra que hubo poca diferencia en los fracasos de las misiones entre plataformas.
A medida que su juego se vuelve cada vez más exitoso y su base de jugadores crece, es posible que incluso las consultas más simples tarden mucho tiempo en ejecutarse.
Supongamos que desea ejecutar esta consulta básica con sus datos:
Es de esperar que se ejecute con bastante rapidez, pero con un gran conjunto de datos no siempre es así. Aproveche la forma de nuestro almacén y el hecho de que los user_ids se almacenan como un hash para utilizar un método rápido para reducir la cantidad de usuarios incluidos y aumentar la velocidad de consulta.
Aquí, estamos dividiendo a nuestros usuarios en 100 depósitos numerados y asignados pseudoaleatoriamente y observando el depósito número 63.
Agregar este código a 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 de simulación, descubrimos 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 de muestra sin tener que procesar conjuntos de datos completos.
En las consultas anteriores, utilizamos count(distinct...) para calcular nuestra cantidad de jugadores individuales y combinaciones de eventos. Una forma de mejorar nuestra velocidad de consulta, si no necesitamos una precisión del 100% en nuestros resultados, es utilizar approx_count_distinct. Nuestra consulta anterior se convierte en:
Hasta ahora sólo hemos estado usando la tabla principal 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 utilizar objetos más pequeños para ejecutar nuestras consultas de manera más eficiente.
Echemos un vistazo al panel Glosario para explorar las tablas que tenemos disponibles para consultar.
Además de EVENTOS, aquí encontramos todas las tablas agregadas disponibles para consulta. Todos ellos están disponibles de fábrica con UGS.
- La tabla USUARIOS contiene una sola fila por jugador junto con las métricas de su vida en el juego, como el recuento de eventos, el tiempo total de juego, el gasto total, etc.
- FACT_USER_SESSIONS_DAY incluye datos de cada sesión para cada jugador.
- FACT_EVENT_TYPE_USERS_DAY consta de una fila para cada evento que un jugador ha enviado cada día, junto con un recuento total.
- FACT_WAU_USERS y FACT_MAU_USERS incluyen datos de perfil de los usuarios que jugaron durante la semana o el 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, analizábamos las tasas de fracaso de las misiones. También podríamos usar FACT_EVENT_TYPE_USERS_DAY para calcular las tasas de fallas generales cada día, con el recuento NUMBER_OF_EVENTS almacenado en esta tabla.
También usaremos una de estas tablas en nuestra próxima consulta:
Utilice esta consulta para ver el flujo de eventos de los jugadores que cumplen con criterios específicos. Es útil para el control de calidad y la depuración porque, al utilizar la tabla USUARIOS mencionada anteriormente, obtendrá un usuario diferente cada vez que la ejecute.
Si, por ejemplo, sospechas que los eventos no se registran correctamente para los jugadores que instalaron una determinada versión de tu juego, puedes ejecutar la siguiente consulta. Lo que regresa es el flujo de eventos de un jugador aleatorio que ejecuta la versión del juego y que parece estar experimentando problemas. Haga esto varias veces y rápidamente podrá comenzar a detectar patrones en los datos.
Consejo: Si desea comentar varias líneas, utilice el método abreviado de teclado CTRL+/
Es posible que esté acostumbrado a escribir consultas SQL en idiomas distintos de Snowflake; por ejemplo, si utilizó la herramienta de minería de datos deltaDNA anterior, probablemente escribió consultas en Vertica.
Ahora puede hacer referencia 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 correctamente en SQL Data Explorer, pero en el deltaDNA original, habría generado un error de "columna 'arroz' no existe":
Hay mucho potencial en SQL Explorer. Hay mucho más por descubrir en UGS Analytics, incluidas muchas opciones de gráficos, como gráficos circulares y de barras apiladas. Direct Access le brinda acceso directo a sus datos de Analytics a través de Snowflake.
Para acelerar sus conocimientos y obtener ayuda para crear sus consultas y paneles, contáctenos.
Otras lecturas