Wie man SQL Data Explorer zur Analyse von Spieldaten verwendet

Sehen Sie sich unsere Sammlung von Rezepten im SQL Cookbook an, um die reichhaltigen Daten in UGS zu erkunden. Beachten Sie, dass UGS die Snowflake Variante von SQL verwendet.

Eine der Abfragen im Kochbuch betrachtet Missionsstatistiken. Lassen Sie uns diesen Code anpassen, um einen schnellen Blick auf die Missionsausfallraten in unserem fiktiven Spiel zu werfen. Dies verwendet benutzerdefinierte Ereignisse, die wir erstellt haben, um das Engagement der Spieler mit Missionen zu verfolgen, mit unserem missionID-Parameter.

Für diese Abfrage verwenden wir die Standard-Ereignistabelle. Diese Tabelle enthält detaillierte Daten für jedes Ereignis, das in unserem Spiel aufgezeichnet wurde.

Beachten Sie, dass wir hier einen Datumsfilter verwendet haben, um unsere Abfrage zu begrenzen und sie effizient zu halten. Ohne diese Begrenzung würde die Abfrage über die vollen 365 Tage von Daten laufen, die standardmäßig in SQL Data Explorer abfragbar sind. Außerdem ist es immer effizienter, anzugeben, an welchen Spalten Sie interessiert sind, anstatt SELECT * zu verwenden.

Phrasen wie EVENT_JSON:missionID::INTEGER erscheinen einschüchternd, aber wenn Sie 'missionID' eingeben und die Autovervollständigung verwenden, generiert SQL Data Explorer die JSON-Syntax für Sie – vorausgesetzt, Sie haben diesen Parameter in Ihrem eigenen Spiel eingerichtet.

Nach dem Ausführen der Abfrage können wir unsere Ergebnisse darstellen, um die Geschichte in den Daten zu sehen. Diagramme unterstützen derzeit bis zu zwei Y-Achsen und eine X-Achse. Achsenbeschriftungen können einfach mit dem 'as'-Ausdruck in Ihrer SQL-Abfrage umbenannt werden; in diesem Fall erhält unsere Y-Achse den Namen, den wir definiert haben: „Spieler haben % gescheitert“.

Wir sehen, dass mehr als einer von drei Spielern in unserer ersten Mission (missionID 0) gescheitert ist, sodass wir die Missionsschwierigkeit anpassen können, um den Benutzern ein positiveres erstes Erlebnis zu bieten.

Tipp: Wenn Sie einige NULL-Werte in Ihren Daten haben und feststellen, dass dies dazu führt, dass eine Achse seltsam aussieht, verwenden Sie coalesce(yourParameter, 0), um die Lücken zu füllen.

Wenn wir eine Abfrage ausführen, erhalten wir eine Tabelle mit unseren Ergebnissen. Fügen Sie PLATFORM zu unserer Abfrage hinzu; im obigen Bild sehen Sie, wie die Tabelle jetzt aussieht. Beachten Sie die Schaltfläche ‚Pivot‘ auf der rechten Seite. Dies ist nützlich, um unsere Daten umzuformen, ohne unsere Abfrage neu schreiben zu müssen.

In unserem Beispiel könnten wir das Pivot-Tool verwenden, um unsere Daten so anzupassen, dass PLATFORM in den Zeilen und MISSIONID in den Spalten steht.

Die Anpassung der Tabelle zeigt, dass es nur geringe Unterschiede bei den Missionsfehlern zwischen den Plattformen gab.

Wenn Ihr Spiel zunehmend erfolgreich wird und Ihre Spielerbasis wächst, stellen Sie möglicherweise fest, dass selbst einfache Abfragen eine erhebliche Zeit in Anspruch nehmen.

Angenommen, Sie möchten diese grundlegende Abfrage gegen Ihre Daten ausführen:

Sie könnten erwarten, dass sie relativ schnell ausgeführt wird, aber bei einem großen Datensatz ist das nicht immer der Fall. Nutzen Sie die Struktur unseres Lagers und die Tatsache, dass user_ids als Hash gespeichert werden, um eine schnelle Methode zu verwenden, um die Anzahl der einbezogenen Benutzer zu reduzieren und die Abfragegeschwindigkeit zu erhöhen.

Hier teilen wir unsere Benutzer in 100 pseudo-zufällig zugewiesene und nummerierte Eimer auf und betrachten den Eimer Nummer 63.

Das Hinzufügen dieses Codes zu einfachen Abfragen wird nicht viel Unterschied machen, aber wenn wir die rechnerische Komplexität erhöhen, wird das Filtern von Daten auf diese Weise immer kritischer. Selbst in unserem fiktiven Spiel haben wir festgestellt, dass diese überarbeitete Version unserer Abfrage 75 % schneller lief als die ursprüngliche. Das spart Zeit und Geld, um Einblicke in Stichproben von Benutzern zu erhalten, ohne gesamte Datensätze verarbeiten zu müssen.

In den obigen Abfragen haben wir count(distinct…) verwendet, um die Anzahl unserer einzelnen Spieler und Ereigniskombinationen zu berechnen. Eine Möglichkeit, unsere Abfragegeschwindigkeit zu verbessern, wenn wir keine 100%ige Genauigkeit bei unseren Ergebnissen benötigen, besteht darin, approximate_count_distinct zu verwenden. Unsere vorherige Abfrage wird zu:

Bis jetzt haben wir nur die Haupttabelle EVENTS verwendet. Da diese Tabelle detaillierte Daten zu jedem Ereignis enthält, das wir in unserem Spiel hatten, ist sie die umfangreichste Tabelle. Um unsere Abfragen zu verbessern, können wir kleinere Objekte verwenden, um unsere Abfragen effizienter auszuführen.

Lassen Sie uns das Glossar-Panel ansehen, um die Tabellen zu erkunden, die wir zum Abfragen zur Verfügung haben.

Neben EVENTS finden wir hier alle aggregierten Tabellen, die für Abfragen verfügbar sind. Diese sind alle sofort einsatzbereit mit UGS.

• Die USERS-Tabelle enthält eine einzelne Zeile pro Spieler zusammen mit ihren Lebenszeitmetriken im Spiel, wie z.B. Ereigniszahlen, Gesamtspielzeit, Gesamtausgaben usw.
• FACT_USER_SESSIONS_DAY enthält Daten zu jeder Sitzung für jeden Spieler.
• FACT_EVENT_TYPE_USERS_DAY besteht aus einer Zeile für jedes Ereignis, das ein Spieler an jedem Tag gesendet hat, zusammen mit einer Gesamtzahl.
• FACT_WAU_USERS und FACT_MAU_USERS enthalten Profildaten für Benutzer, die an einem bestimmten Tag in der vorherigen Woche oder im vorherigen Monat gespielt haben.

Zwischen FACT_EVENT_TYPE_USERS_DAY und FACT_USER_SESSIONS_DAY können Sie wahrscheinlich über 80 % der meisten Abfragen zu kleineren Objekten beantworten.

Zum Beispiel haben wir in unserer ersten Abfrage die Mission-Fehlerraten betrachtet. Wir könnten auch FACT_EVENT_TYPE_USERS_DAY verwenden, um die Gesamtfehlerraten an jedem Tag zu berechnen, mit der Anzahl der in dieser Tabelle gespeicherten EVENTS.

Wir werden auch eine dieser Tabellen in unserer nächsten Abfrage verwenden:

Verwenden Sie diese Abfrage, um den Ereignisstrom für Spieler zu sehen, die bestimmte Kriterien erfüllen. Es ist nützlich für QA und Debugging, da Sie – durch die Verwendung der oben genannten USERS-Tabelle – jedes Mal einen anderen Benutzer erhalten, wenn Sie sie ausführen.

Wenn Sie beispielsweise vermuten, dass Ereignisse für Spieler, die eine bestimmte Version Ihres Spiels installiert haben, nicht korrekt aufgezeichnet werden, können Sie die folgende Abfrage ausführen. Was zurückkommt, ist der Ereignisstrom eines zufälligen Spielers, der die Spielversion ausführt, die anscheinend Probleme hat. Tun Sie dies ein paar Mal, und Sie können schnell Muster in den Daten erkennen.

Tipp: Wenn Sie mehrere Zeilen auskommentieren möchten, verwenden Sie die Tastenkombination STRG+/

Sie sind möglicherweise daran gewöhnt, SQL-Abfragen in anderen Sprachen als Snowflake zu schreiben – zum Beispiel, wenn Sie das vorherige deltaDNA Data Mining-Tool verwendet haben, haben Sie wahrscheinlich Abfragen in Vertica geschrieben.

Sie können jetzt auf neu definierte Variablen verweisen, ohne sie zuerst in einem Common Table Expression (CTE) einfügen zu müssen. Zum Beispiel wird diese Abfrage erfolgreich im SQL Data Explorer ausgeführt – aber im ursprünglichen deltaDNA hätte sie einen Fehler „Spalte ‚rice‘ existiert nicht“ ausgelöst:

In SQL Explorer steckt viel Potenzial. Es gibt noch viel mehr in UGS Analytics zu entdecken, einschließlich vieler Diagrammoptionen wie Tortendiagramme und gestapelte Balkendiagramme. Direct Access gibt Ihnen direkten Zugriff auf Ihre Analytics-Daten über Snowflake.

Um Ihre Erkenntnisse zu beschleunigen und Unterstützung beim Erstellen Ihrer Abfragen und Dashboards zu erhalten, kontaktieren Sie uns.

Weiterführende Literatur

• UGS Analytics-Dokumentation
• SQL Cookbook
• Einführung von Funnels und SQL Daten-Explorer
• Snowflake SQL-Funktionsreferenz
• UGS-Preise