Consultez notre collection de recettes dans le livre de cuisine SQL pour explorer les données riches d'UGS. Notez que UGS utilise la version Snowflake de SQL.

L'une des requêtes du livre de cuisine porte sur les statistiques des missions. Adaptons ce code pour examiner rapidement les taux d'échec des missions dans notre jeu fictif. Cela utilise les événements personnalisés que nous avons créés pour suivre l'engagement des joueurs dans les missions, avec notre paramètre missionID.

Pour cette requête, nous utiliserons la table EVENTS par défaut. Ce tableau contient des données granulaires pour chaque événement enregistré dans notre jeu.

Notez que nous avons utilisé un filtre de date pour limiter notre requête et la rendre plus efficace. Sans cette limite, la requête porterait sur l'ensemble des 365 jours de données interrogeables par défaut dans SQL Data Explorer. En outre, il est toujours plus efficace de spécifier les colonnes qui vous intéressent plutôt que d'utiliser SELECT *.

Des phrases comme EVENT_JSON:missionID::INTEGER semblent intimidantes, mais si vous tapez "missionID" et que vous utilisez la saisie semi-automatique, SQL Data Explorer génère la syntaxe JSON pour vous - en supposant que vous ayez configuré ce paramètre dans votre propre jeu.

Après avoir exécuté la requête, nous pouvons tracer nos résultats pour voir l'histoire des données. Les graphiques prennent actuellement en charge jusqu'à deux axes Y et un axe X. Les étiquettes des axes peuvent facilement être renommées à l'aide de l'expression "as" dans votre requête SQL ; dans ce cas, notre axe Y prend le nom que nous avons défini : "Les joueurs ont échoué %".

Nous constatons que plus d'un joueur sur trois a échoué dans notre première mission (missionID 0). Nous pouvons donc ajuster la difficulté de la mission pour donner aux utilisateurs une première expérience plus positive.

Conseil : Si vous avez des valeurs NULL dans vos données et que vous trouvez qu'elles donnent un aspect étrange à un axe, utilisez coalesce(yourParameter, 0) pour remplir les blancs.

Lorsque nous exécutons une requête, nous obtenons un tableau de nos résultats. Ajoutez PLATFORM à notre requête ; dans l'image ci-dessus, vous verrez à quoi ressemble maintenant la table. Remarquez le bouton "Pivot" à droite. Ceci est utile pour remodeler nos données sans avoir à réécrire notre requête.

Dans notre exemple, nous pourrions utiliser l'outil pivot pour modifier nos données afin d'obtenir PLATFORM dans les lignes et MISSIONID dans les colonnes.

En modifiant le tableau, on constate qu'il y a peu de différence entre les plates-formes en ce qui concerne les échecs des missions.

Au fur et à mesure que votre jeu connaît un succès grandissant et que votre base de joueurs s'élargit, vous pouvez constater que même les requêtes simples prennent beaucoup de temps.

Supposons que vous souhaitiez exécuter cette requête de base sur vos données :

On peut s'attendre à ce qu'il s'exécute assez rapidement, mais ce n'est pas toujours le cas avec un grand ensemble de données. Profitez de la forme de notre entrepôt et du fait que les user_ids sont stockés sous forme de hachage pour utiliser une méthode rapide permettant de réduire le nombre d'utilisateurs inclus afin d'augmenter la vitesse de la requête.

Ici, nous répartissons nos utilisateurs en 100 groupes numérotés de manière pseudo-aléatoire et nous examinons le groupe numéro 63.

L'ajout de ce code dans des requêtes simples ne changera pas grand-chose, mais au fur et à mesure que nous augmentons la complexité des calculs, le filtrage des données de cette manière devient de plus en plus critique. Même dans notre jeu fictif, nous avons constaté que cette version révisée de notre requête était 75 % plus rapide que l'originale. Cela permet d'économiser du temps et de l'argent en obtenant des informations sur des sous-ensembles d'utilisateurs sans avoir à traiter des ensembles de données entiers.

Dans les requêtes ci-dessus, nous avons utilisé count(distinct...) pour calculer le nombre de joueurs individuels et de combinaisons d'événements. Une façon d'améliorer la vitesse des requêtes, si nous n'avons pas besoin d'une précision de 100 % dans nos résultats, est d'utiliser approximate_count_distinct. Notre requête précédente devient :

Jusqu'à présent, nous n'avons utilisé que le tableau principal EVENTS. Ce tableau contient des données granulaires sur tous les événements qui se sont produits dans notre jeu, c'est donc le tableau le plus complet. Pour améliorer nos requêtes, nous pouvons utiliser des objets plus petits afin d'exécuter nos requêtes plus efficacement.

Jetons un coup d'œil au panneau Glossaire, afin d'explorer les tables que nous pouvons interroger.

Outre EVENTS, nous trouvons ici tous les tableaux agrégés disponibles pour l'interrogation. Tous ces éléments sont disponibles prêts à l'emploi avec UGS.

• Le tableau UTILISATEURS contient une seule ligne par joueur avec les mesures de sa durée de vie dans le jeu, telles que le nombre d'événements, le temps de jeu total, les dépenses totales, etc.
• FACT_USER_SESSIONS_DAY comprend des données sur chaque session pour chaque joueur.
• FACT_EVENT_TYPE_USERS_DAY se compose d'une ligne pour chaque événement envoyé par un joueur chaque jour, ainsi que d'un décompte total.
• FACT_WAU_USERS et FACT_MAU_USERS comprennent les données de profil des utilisateurs qui ont joué au cours de la semaine ou du mois précédent, un jour donné.

Entre FACT_EVENT_TYPE_USERS_DAY et FACT_USER_SESSIONS_DAY, vous pouvez probablement répondre à plus de 80 % de la plupart des requêtes portant sur des objets plus petits.

Par exemple, dans notre première requête, nous avons examiné les taux d'échec des missions. Nous pourrions également utiliser le tableau FACT_EVENT_TYPE_USERS_DAY pour calculer les taux d'échec globaux chaque jour, avec le nombre NUMBER_OF_EVENTS stocké dans ce tableau.

Nous utiliserons également l'une de ces tables dans notre prochaine requête :

Cette requête permet d'afficher le flux d'événements pour les joueurs qui répondent à des critères spécifiques. Il est utile pour l'assurance qualité et le débogage car - en utilisant le tableau USERS mentionné ci-dessus - vous obtiendrez un utilisateur différent à chaque fois que vous l'exécuterez.

Si, par exemple, vous soupçonnez que des événements ne sont pas enregistrés correctement pour les joueurs qui ont installé une certaine version de votre jeu, vous pouvez exécuter la requête ci-dessous. Ce qui revient, c'est le flux d'événements d'un joueur aléatoire utilisant la version du jeu qui semble rencontrer des problèmes. Répétez cette opération plusieurs fois et vous commencerez rapidement à repérer des schémas dans les données.

Conseil : Si vous souhaitez commenter plusieurs lignes, utilisez le raccourci clavier CTRL+/

Vous avez peut-être l'habitude d'écrire des requêtes SQL dans d'autres langages que Snowflake - par exemple, si vous avez utilisé l'ancien outil de Data Mining deltaDNA, vous avez probablement écrit des requêtes dans Vertica.

Vous pouvez désormais faire référence à des variables nouvellement définies sans devoir les inclure au préalable dans une expression de table commune (CTE). Par exemple, cette requête s'exécute avec succès dans SQL Data Explorer - mais dans le deltaDNA original, elle aurait généré une erreur "column 'rice' does not exist" (la colonne 'rice' n'existe pas) :

Le potentiel de SQL Explorer est considérable. Il y a bien plus à découvrir dans UGS Analytics, y compris de nombreuses options graphiques telles que les diagrammes en étoile et les diagrammes à barres empilées. L'accès direct vous permet d'accéder directement à vos données analytiques via Snowflake.

Pour accélérer vos analyses et obtenir de l'aide pour élaborer vos requêtes et vos tableaux de bord, contactez-nous.

Pour en savoir plus

• Documentation UGS Analytics
• Livre de cuisine SQL
• Présentation de Funnels et de SQL Data Explorer
• Référence de la fonction SQL Snowflake
• Prix de l'UGS