Como usar o SQL Data Explorer para analisar dados de jogos
Comece a explorar seus dados
Use o Unity Gaming Services (UGS) Data Explorer para filtrar e usar seus dados com base em métricas ou eventos e agrupá-los por plataforma, país ou versão.
Com conhecimentos básicos de SQL (Structured Query Language, Linguagem de Consulta Estruturada), você pode aprimorar sua análise e se aprofundar nos dados usando o SQL Data Explorer dentro do UGS. Use esse recurso para criar e executar consultas, plotar resultados em diferentes tipos de visualizações, adicionar visualizações a painéis personalizados e exportar seus dados para uso com outras ferramentas de análise. Localize o SQL Data Explorer no painel UGS Analytics do Unity Dashboard.
Russell Young, um dos consultores de análise da Unity, tem dicas e ideias para começar suas aventuras no SQL Data Explorer.
Consulte nossa coleção de receitas no SQL Cookbook para explorar a riqueza de dados do UGS. Observe que o UGS usa a variante Snowflake do SQL.
Uma das consultas do livro de receitas examina as estatísticas da missão. Vamos adaptar esse código para dar uma olhada rápida nas taxas de falha de missão em nosso jogo de simulação. Isso usa eventos personalizados que criamos para rastrear o envolvimento dos jogadores com as missões, com nosso parâmetro missionID.
Para essa consulta, usaremos a tabela EVENTS padrão. Essa tabela inclui dados granulares para cada evento registrado em nosso jogo.
Observe que usamos um filtro de data aqui para limitar nossa consulta e mantê-la eficiente. Sem esse limite, a consulta seria executada em todos os 365 dias de dados que são consultáveis por padrão no SQL Data Explorer. Além disso, é sempre mais eficiente especificar em quais colunas você está interessado, em vez de usar SELECT *.
Frases como EVENT_JSON:missionID::INTEGER parecem intimidadoras, mas se você digitar "missionID" e usar o preenchimento automático, o SQL Data Explorer gerará a sintaxe JSON para você - supondo que você tenha esse parâmetro configurado em seu próprio jogo.
Depois de executar a consulta, podemos plotar nossos resultados para ver a história nos dados. Atualmente, os gráficos suportam até dois eixos Y e um eixo X. Os rótulos dos eixos podem ser facilmente renomeados usando a expressão "as" em sua consulta SQL; nesse caso, nosso eixo Y recebe o nome que definimos: "Os jogadores falharam %".
Vemos que mais de um em cada três jogadores falhou em nossa primeira missão (missionID 0), portanto, podemos ajustar a dificuldade da missão para proporcionar aos usuários uma primeira experiência mais positiva.
Dica: Se você tiver alguns valores NULL em seus dados e achar que isso faz com que um eixo pareça estranho, use coalesce(yourParameter, 0) para preencher os espaços em branco.
Quando executamos uma consulta, obtemos uma tabela com nossos resultados. Adicione PLATFORM à nossa consulta; na imagem acima, você verá como a tabela está agora. Observe o botão "Pivot" à direita. Isso é útil para reformular nossos dados sem a necessidade de reescrever nossa consulta.
Em nosso exemplo, poderíamos usar a ferramenta pivô para ajustar nossos dados para obter PLATFORM nas linhas e MISSIONID nas colunas.
O ajuste da tabela mostra que houve pouca diferença nas falhas de missão entre as plataformas.
À medida que seu jogo se torna cada vez mais bem-sucedido e sua base de jogadores cresce, você pode perceber que até mesmo consultas simples levam um tempo significativo para serem executadas.
Digamos que você queira executar essa consulta básica em seus dados:
É de se esperar que ele seja executado rapidamente, mas com um grande conjunto de dados nem sempre é esse o caso. Aproveite o formato do nosso warehouse e o fato de que os user_ids são armazenados como um hash para usar um método rápido para reduzir o número de usuários incluídos e aumentar a velocidade da consulta.
Aqui, estamos dividindo nossos usuários em 100 compartimentos numerados e atribuídos de forma pseudoaleatória e analisando o compartimento número 63.
Adicionar esse código a consultas simples não fará muita diferença, mas, à medida que aumentamos a complexidade computacional, filtrar dados dessa forma é cada vez mais importante. Mesmo em nosso jogo de simulação, descobrimos que essa versão revisada da nossa consulta foi executada 75% mais rápido do que a original. Isso economiza tempo e dinheiro para obter insights sobre subconjuntos de amostras de usuários sem precisar processar conjuntos de dados inteiros.
Nessas consultas acima, usamos count(distinct...) para calcular nosso número de jogadores individuais e combinações de eventos. Uma maneira de aumentar a velocidade da consulta, se não precisarmos de 100% de precisão nos resultados, é usar approximate_count_distinct. Nossa pergunta anterior passa a ser:
Até agora, estávamos usando apenas a tabela principal EVENTS. Como essa tabela contém dados granulares sobre cada evento que tivemos em nosso jogo, ela é a tabela mais extensa. Para melhorar nossas consultas, podemos usar objetos menores para executar nossas consultas com mais eficiência.
Vamos dar uma olhada no painel Glossário, para explorar as tabelas que temos disponíveis para consulta.
Juntamente com EVENTS, aqui encontramos todas as tabelas agregadas disponíveis para consulta. Todos esses recursos estão disponíveis imediatamente com o UGS.
- A tabela USERS contém uma única linha por jogador, juntamente com suas métricas de tempo de vida no jogo, como contagem de eventos, tempo total de jogo, gasto total etc.
- FACT_USER_SESSIONS_DAY inclui dados sobre cada sessão de cada jogador.
- FACT_EVENT_TYPE_USERS_DAY consiste em uma linha para cada evento que um jogador enviou por dia, juntamente com uma contagem total.
- FACT_WAU_USERS e FACT_MAU_USERS incluem dados de perfil de usuários que jogaram na semana ou no mês anterior em um determinado dia.
Entre FACT_EVENT_TYPE_USERS_DAY e FACT_USER_SESSIONS_DAY, você provavelmente pode responder a mais de 80% da maioria das consultas em objetos menores.
Por exemplo, em nossa primeira consulta, estávamos analisando as taxas de falha da missão. Também poderíamos usar o FACT_EVENT_TYPE_USERS_DAY para calcular as taxas gerais de falha a cada dia, com a contagem NUMBER_OF_EVENTS armazenada nessa tabela.
Também usaremos uma dessas tabelas em nossa próxima consulta:
Use essa consulta para ver o fluxo de eventos dos jogadores que atendem a critérios específicos. É útil para controle de qualidade e depuração porque, ao usar a tabela USERS mencionada acima, você terá um usuário diferente a cada vez que o executar.
Se, por exemplo, você suspeitar que os eventos não estão sendo registrados corretamente para os jogadores que instalaram uma determinada versão do seu jogo, poderá executar a consulta abaixo. O que aparece é o fluxo de eventos de um jogador aleatório executando a versão do jogo que parece estar com problemas. Faça isso algumas vezes e você poderá começar a identificar rapidamente os padrões nos dados.
Dica: Se você quiser comentar várias linhas, use o atalho de teclado CTRL+/
Você pode estar acostumado a escrever consultas SQL em linguagens diferentes do Snowflake - por exemplo, se você usou a ferramenta anterior de mineração de dados deltaDNA, provavelmente escreveu consultas no Vertica.
Agora é possível fazer referência a variáveis recém-definidas sem precisar incluí-las primeiro em uma expressão de tabela comum (CTE). Por exemplo, essa consulta é executada com êxito no SQL Data Explorer, mas no deltaDNA original, ela teria gerado um erro "a coluna 'rice' não existe":
Há muito potencial no SQL Explorer. Há muito mais a ser descoberto no UGS Analytics, incluindo várias opções de gráficos, como gráficos de pizza e de barras empilhadas. O Direct Access lhe dá acesso direto aos dados do Analytics por meio do Snowflake.
Para acelerar seus insights e obter suporte para criar suas consultas e painéis, entre em contato conosco.
Leitura adicional