Utilisez Unity Gaming Services (UGS) Data Explorer pour filtrer et utiliser vos données en fonction des métriques ou des événements, et les regrouper par plateforme, pays ou version.
Avec des connaissances de base en SQL (Structured Query Language), vous pouvez améliorer votre analyse et approfondir vos données en utilisant SQL Data Explorer à l'intérieur de l'UGS. Utilisez cette fonctionnalité pour construire et exécuter des requêtes, tracer des résultats dans différents types de visualisations, ajouter des visualisations à des tableaux de bord personnalisés, et exporter vos données pour les utiliser avec d'autres outils d'analyse. Trouvez SQL Data Explorer dans le panneau d'analytique UGS du Unity Dashboard.
Russell Young, l'un des consultants en analytique de Unity, a des conseils et des idées pour commencer vos aventures avec SQL Data Explorer.
Voir notre collection de recettes dans le SQL Cookbook pour explorer les riches données dans UGS. Notez qu'UGS utilise la version Snowflake de SQL.
Une des requêtes du livre de recettes examine les statistiques de mission. Adaptation de ce code pour jeter un coup d'œil rapide aux taux d'échec des missions dans notre jeu fictif. Cela utilise des événements personnalisés que nous avons créés pour suivre l'engagement des joueurs avec les missions, avec notre paramètre missionID.
Pour cette requête, nous utiliserons la table EVENTS par défaut. Cette table inclut des données granulaires pour chaque événement enregistré dans notre jeu.
Notez que nous avons utilisé un filtre de date ici pour limiter notre requête et la rendre efficace. Sans cette limite, la requête s'exécuterait sur l'ensemble des 365 jours de données qui sont interrogeables par défaut dans SQL Data Explorer. De plus, 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 utilisez l'autocomplétion, SQL Data Explorer génère la syntaxe JSON pour vous - à condition que vous ayez ce paramètre configuré dans votre propre jeu.
Après avoir exécuté la requête, nous pouvons tracer nos résultats pour voir l'histoire dans les 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 en utilisant l'expression 'as' dans votre requête SQL ; dans ce cas, notre axe Y prend le nom que nous avons défini : « Pourcentage de joueurs échoués ».
Nous voyons que plus d'un joueur sur trois a échoué dans notre première mission (missionID 0), donc nous pouvons affiner la difficulté de la mission pour donner aux utilisateurs une première expérience plus positive.
Astuce : Si vous avez des valeurs NULL dans vos données et que cela rend un axe étrange, 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 le tableau maintenant. Remarquez le bouton ‘Pivot’ à droite. Ceci est utile pour remodeler nos données sans avoir besoin de réécrire notre requête.
Dans notre exemple, nous pourrions utiliser l'outil de pivot pour ajuster nos données afin d'obtenir PLATFORM dans les lignes et MISSIONID comme colonnes.
Ajuster le tableau montre qu'il y avait peu de différence dans les échecs de mission entre les plateformes.
À mesure que votre jeu devient de plus en plus réussi et que votre base de joueurs grandit, vous pourriez constater que même des requêtes simples prennent un temps significatif à s'exécuter.
Disons que vous voulez exécuter cette requête de base sur vos données :
Vous pourriez vous attendre à ce qu'elle s'exécute assez rapidement, mais avec un grand ensemble de données, ce n'est pas toujours le cas. Profitez de la structure de notre entrepôt et du fait que les user_ids sont stockés sous forme de hachage pour utiliser une méthode rapide afin de réduire le nombre d'utilisateurs inclus et d'augmenter la vitesse de la requête.
Ici, nous divisons nos utilisateurs en 100 seaux pseudo-aléatoirement assignés et numérotés et regardons le seau numéro 63.
Ajouter ce code dans des requêtes simples ne fera pas beaucoup de différence, mais à mesure que nous augmentons la complexité computationnelle, filtrer les 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 s'exécutait 75 % plus rapidement que l'originale. Cela permet de gagner du temps et de l'argent pour obtenir 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 notre nombre de joueurs individuels et de combinaisons d'événements. Une façon d'améliorer la vitesse de notre requête, si nous n'avons pas besoin d'une précision à 100 % avec nos résultats, est d'utiliser approximate_count_distinct. Notre requête précédente devient :
Jusqu'à présent, nous n'avons utilisé que la table principale des ÉVÉNEMENTS. Comme cette table contient des données granulaires sur chaque événement que nous avons eu dans notre jeu, c'est la table la plus étendue. Pour améliorer nos requêtes, nous pouvons utiliser des objets plus petits pour exécuter nos requêtes plus efficacement.
Jetons un œil au panneau Glossaire, pour explorer les tables que nous avons disponibles pour interroger.
Aux côtés des ÉVÉNEMENTS, ici nous trouvons toutes les tables agrégées disponibles pour l'interrogation. Celles-ci sont toutes disponibles prêtes à l'emploi avec UGS.
Entre FACT_EVENT_TYPE_USERS_DAY et FACT_USER_SESSIONS_DAY, vous pouvez probablement répondre à 80%+ de la plupart des requêtes sur des objets plus petits.
Par exemple, dans notre première requête, nous examinions les taux d'échec des missions. Nous pourrions également utiliser FACT_EVENT_TYPE_USERS_DAY pour calculer les taux d'échec globaux chaque jour, avec le nombre d'événements stocké dans cette table.
Nous utiliserons également l'une de ces tables dans notre prochaine requête :
Utilisez cette requête pour voir le flux d'événements pour les joueurs qui répondent à des critères spécifiques. C'est utile pour l'assurance qualité et le débogage car – en utilisant la table UTILISATEURS mentionnée ci-dessus – vous obtiendrez un utilisateur différent chaque fois que vous l'exécutez.
Si, par exemple, vous soupçonnez que les é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 est le flux d'événements d'un joueur aléatoire exécutant la version du jeu qui semble rencontrer des problèmes. Faites cela quelques fois, et vous pouvez rapidement commencer à repérer des motifs dans les données.
Astuce : Si vous souhaitez commenter plusieurs lignes, utilisez le raccourci clavier CTRL+/
Vous êtes peut-être habitué à écrire des requêtes SQL dans des langages autres que Snowflake – par exemple, si vous avez utilisé l'outil de Data Mining deltaDNA précédent, vous avez probablement écrit des requêtes en Vertica.
Vous pouvez maintenant faire référence à des variables nouvellement définies sans avoir besoin de les inclure d'abord 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 levé une erreur "la colonne 'rice' n'existe pas" :
Il y a beaucoup de potentiel dans SQL Explorer. Il y a beaucoup plus à découvrir dans UGS Analytics, y compris de nombreuses options de graphique telles que les graphiques en secteurs et les graphiques à barres empilées. L'accès direct vous donne un accès direct à vos données d'Analytics via Snowflake.
Pour accélérer vos insights et obtenir de l'aide pour construire vos requêtes et tableaux de bord, contactez-nous.
Lectures complémentaires
