Como usar o SQL Data Explorer para analisar dados de jogos

Veja nossa coleção de receitas no SQL Cookbook para explorar os ricos dados em UGS. Observe que o UGS utiliza o sabor Snowflake do SQL.

Uma das consultas do livro de receitas analisa as estatísticas de missões. Vamos adaptar esse código para dar uma olhada rápida nas taxas de falha de missões em nosso jogo fictício. Isso usa eventos personalizados que criamos para rastrear o envolvimento dos jogadores com as missões, com nosso parâmetro missionID.

Para esta consulta, usaremos a tabela de EVENTOS padrão. Esta 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 sobre os 365 dias completos de dados que são consultáveis por padrão no SQL Data Explorer. Além disso, é sempre mais eficiente especificar 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 a autocompletação, o SQL Data Explorer gera a sintaxe JSON para você – assumindo que você tenha esse parâmetro configurado em seu próprio jogo.

Após executar a consulta, podemos plotar nossos resultados para ver a história nos dados. Os gráficos atualmente 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; neste caso, nosso eixo Y recebe o nome que definimos: “Jogadores falharam %”.

Vemos que mais de um em cada três jogadores falhou em nossa primeira missão (missionID 0), então podemos ajustar a dificuldade da missão para dar aos usuários uma experiência inicial mais positiva.

Dica: Se você tiver alguns valores NULL em seus dados e descobrir que isso faz com que um eixo pareça estranho, use coalesce(yourParameter, 0) para preencher as lacunas.

Quando executamos uma consulta, obtemos uma tabela de nossos resultados. Adicione a PLATAFORMA à nossa consulta; na imagem acima, você verá como a tabela está agora. Observe o botão ‘Pivot’ à direita. Isso é útil para reestruturar nossos dados sem precisar reescrever nossa consulta.

Em nosso exemplo, poderíamos usar a ferramenta de pivotagem para ajustar nossos dados para obter PLATAFORMA nas linhas e MISSIONID como colunas.

Ajustar a 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 descobrir que até mesmo consultas simples levam um tempo significativo para serem executadas.

Vamos supor que você queira executar esta consulta básica em seus dados:

Você pode esperar que ela seja executada rapidamente, mas com um grande conjunto de dados, isso nem sempre é o caso. Aproveite a forma do nosso armazém 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 baldes pseudo-aleatoriamente atribuídos e numerados e olhando para o balde número 63.

Adicionar este código em consultas simples não fará muita diferença, mas à medida que aumentamos a complexidade computacional, filtrar dados dessa maneira se torna cada vez mais crítico. Mesmo em nosso jogo fictício, descobrimos que esta versão revisada de nossa consulta foi 75% mais rápida do que a original. Isso economiza tempo e dinheiro para obter insights sobre subconjuntos de usuários sem precisar processar conjuntos de dados inteiros.

Nas consultas acima, usamos count(distinct…) para calcular nosso número de jogadores individuais e combinações de eventos. Uma maneira de melhorar a velocidade da nossa consulta, se não precisarmos de 100% de precisão com nossos resultados, é usar approximate_count_distinct. Nossa consulta anterior se torna:

Até agora, temos usado apenas a tabela principal de EVENTOS. Como esta tabela contém dados granulares sobre cada evento que tivemos em nosso jogo, é a tabela mais extensa. Para melhorar nossas consultas, podemos usar objetos menores para executar nossas consultas de forma mais eficiente.

Vamos dar uma olhada no painel de Glossário, para explorar as tabelas que temos disponíveis para consultar.

Juntamente com os EVENTOS, aqui encontramos todas as tabelas agregadas disponíveis para consulta. Todas estão disponíveis prontamente com UGS.

• A tabela USUÁRIOS contém uma única linha por jogador, juntamente com suas métricas 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 para cada jogador.
• FACT_EVENT_TYPE_USERS_DAY consiste em uma linha para cada evento que um jogador enviou a cada dia, junto com uma contagem total.
• FACT_WAU_USERS e FACT_MAU_USERS incluem dados de perfil para usuários que jogaram na semana ou mês anterior em um determinado dia.

Entre FACT_EVENT_TYPE_USERS_DAY e FACT_USER_SESSIONS_DAY, você pode provavelmente responder a 80%+ da maioria das consultas sobre objetos menores.

Por exemplo, em nossa primeira consulta, estávamos analisando as taxas de falha de missões. Também poderíamos usar o FACT_EVENT_TYPE_USERS_DAY para calcular as taxas de falha geral a cada dia, com a contagem de NUMBER_OF_EVENTS armazenada nesta tabela.

Também usaremos uma dessas tabelas em nossa próxima consulta:

Use esta consulta para ver o fluxo de eventos para jogadores que atendem a critérios específicos. É útil para QA e depuração porque – ao usar a tabela USUÁRIOS mencionada acima – você obterá um usuário diferente toda vez que executá-la.

Se, por exemplo, você suspeitar que os eventos não estão sendo registrados corretamente para jogadores que instalaram uma certa versão do seu jogo, você pode executar a consulta abaixo. O que retorna é o fluxo de eventos de um jogador aleatório executando a versão do jogo que parece estar enfrentando problemas. Faça isso algumas vezes e você pode rapidamente começar a identificar 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 idiomas diferentes de Snowflake – por exemplo, se você usou a ferramenta anterior de Mineração de Dados deltaDNA, provavelmente escreveu consultas em Vertica.

Agora você pode se referir a variáveis recém-definidas sem precisar incluí-las primeiro em uma expressão de tabela comum (CTE). Por exemplo, esta consulta é executada com sucesso no SQL Data Explorer – mas no deltaDNA original, teria gerado um erro "coluna 'rice' não existe":

Há muito potencial no SQL Explorer. Há muito mais para descobrir em UGS Analytics, incluindo muitas opções de gráficos, como gráficos de pizza e gráficos de barras empilhadas. Acesso Direto oferece acesso direto aos seus dados de Analytics através do Snowflake.

Para acelerar suas percepções e obter suporte na construção de suas consultas e painéis, entre em contato conosco.

Leitura adicional

• Documentação do UGS Analytics
• Livro de receitas SQL
• Apresentando os Funis e o SQL Data Explorer
• Referência de funções SQL do Snowflake
• Preços do UGS