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

Eine der Kochbuchabfragen befasst sich mit Missionsstatistiken. Lassen Sie uns diesen Code anpassen, um einen kurzen Blick auf die Misserfolgsraten in unserem vorgetäuschten Spiel zu werfen. Hierfür werden benutzerdefinierte Ereignisse verwendet, die wir erstellt haben, um die Beteiligung der Spieler an Missionen mit unserem missionID-Parameter zu verfolgen.

Für diese Abfrage verwenden wir die Standardtabelle EVENTS. Diese Tabelle enthält detaillierte Daten für jedes in unserem Spiel aufgezeichnete Ereignis.

Beachten Sie, dass wir hier einen Datumsfilter verwendet haben, um unsere Abfrage einzuschränken und sie effizient zu halten. Ohne diese Einschränkung würde die Abfrage über die gesamten 365 Tage laufen, die standardmäßig im SQL Data Explorer abgefragt werden können. Außerdem ist es immer effizienter, die gewünschten Spalten anzugeben, als SELECT * zu verwenden.

Sätze 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 grafisch darstellen, um die Geschichte in den Daten zu erkennen. Diagramme unterstützen derzeit bis zu zwei Y-Achsen und eine X-Achse. Achsenbeschriftungen können mit dem Ausdruck 'as' in Ihrer SQL-Abfrage leicht umbenannt werden; in diesem Fall erhält unsere Y-Achse den von uns festgelegten Namen: "Spieler ausgefallen %".

Wir sehen, dass mehr als einer von drei Spielern bei unserer ersten Mission (missionID 0) gescheitert ist, so dass wir den Schwierigkeitsgrad der Mission anpassen können, um den Benutzern eine positivere erste Erfahrung zu ermöglichen.

Tipp: Wenn Sie einige NULL-Werte in Ihren Daten haben und feststellen, dass dies eine Achse seltsam aussehen lässt, verwenden Sie coalesce(yourParameter, 0), um die Leerstellen aufzufüllen.

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

In unserem Beispiel könnten wir das Pivot-Tool verwenden, um unsere Daten so zu verändern, dass wir PLATFORM in den Zeilen und MISSIONID in den Spalten erhalten.

Ein Blick auf die Tabelle zeigt, dass es kaum Unterschiede bei den Fehlschlägen zwischen den Plattformen gab.

Wenn Ihr Spiel immer erfolgreicher wird und Ihre Spielerbasis wächst, werden Sie vielleicht feststellen, dass selbst einfache Abfragen sehr viel Zeit in Anspruch nehmen.

Nehmen wir an, Sie möchten diese einfache Abfrage mit Ihren Daten durchführen:

Man könnte erwarten, dass sie recht schnell abläuft, aber bei einem großen Datensatz ist das nicht immer der Fall. Nutzen Sie die Form unseres Lagers und die Tatsache, dass user_ids als Hash gespeichert werden, um eine schnelle Methode zur Verringerung der Anzahl der eingeschlossenen Benutzer anzuwenden, um die Abfragegeschwindigkeit zu erhöhen.

Hier teilen wir unsere Nutzer in 100 pseudo-zufällig zugewiesene und nummerierte Buckets auf und betrachten Bucket Nummer 63.

Das Hinzufügen dieses Codes zu einfachen Abfragen wird keinen großen Unterschied machen, aber mit zunehmender Komplexität der Berechnungen wird das Filtern von Daten auf diese Weise immer wichtiger. Sogar in unserem vorgetäuschten Spiel stellten wir fest, dass diese überarbeitete Version unserer Abfrage 75 % schneller lief als das Original. Dies spart Zeit und Geld, um Einblicke in Teilmengen von Nutzern zu erhalten, ohne ganze Datensätze verarbeiten zu müssen.

In den obigen Abfragen haben wir count(distinct...) verwendet, um die Anzahl der einzelnen Spieler und Ereigniskombinationen zu berechnen. Eine Möglichkeit, unsere Abfragegeschwindigkeit zu verbessern, wenn wir keine 100%ige Genauigkeit bei unseren Ergebnissen benötigen, ist die Verwendung von approximate_count_distinct. Unsere vorherige Frage wird zu einer:

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

Werfen wir einen Blick auf das Glossar-Panel, um uns die Tabellen anzusehen, die wir abfragen können.

Neben EVENTS finden Sie hier alle Aggregatstabellen, die zur Abfrage zur Verfügung stehen. Alle diese Funktionen sind bei UGS sofort verfügbar.

• Die Tabelle BENUTZER enthält eine einzelne Zeile pro Spieler sowie dessen Lebenszeit-Metriken im Spiel, wie z. B. Anzahl der Ereignisse, 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 pro Tag gesendet hat, sowie einer Gesamtzahl.
• FACT_WAU_USERS und FACT_MAU_USERS enthalten Profildaten von Nutzern, die innerhalb der letzten Woche oder des letzten Monats an einem bestimmten Tag gespielt haben.

Mit FACT_EVENT_TYPE_USERS_DAY und FACT_USER_SESSIONS_DAY können Sie wahrscheinlich mehr als 80 % der meisten Abfragen zu kleineren Objekten beantworten.

In unserer ersten Abfrage untersuchten wir zum Beispiel die Misserfolgsquote von Missionen. Wir könnten auch die Tabelle FACT_EVENT_TYPE_USERS_DAY verwenden, um die Gesamtausfallraten für jeden Tag zu berechnen, wobei die Anzahl der NUMBER_OF_EVENTS in dieser Tabelle gespeichert wird.

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

Verwenden Sie diese Abfrage, um den Ereignisstrom für Spieler anzuzeigen, die bestimmte Kriterien erfüllen. Es ist nützlich für die Qualitätssicherung und Fehlersuche, da Sie durch die Verwendung der oben erwähnten Tabelle USERS jedes Mal einen anderen Benutzer erhalten, wenn Sie es ausführen.

Wenn Sie zum Beispiel den Verdacht haben, 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 Event-Stream eines zufälligen Spielers, der die Spielversion ausführt, bei der es Probleme zu geben scheint. Wenn Sie dies ein paar Mal machen, können Sie schnell Muster in den Daten erkennen.

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

Möglicherweise sind Sie daran gewöhnt, SQL-Abfragen in anderen Sprachen als Snowflake zu schreiben - wenn Sie zum Beispiel das frühere 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 einen gemeinsamen Tabellenausdruck (CTE) aufnehmen zu müssen. Zum Beispiel läuft diese Abfrage erfolgreich in SQL Data Explorer - aber in der ursprünglichen deltaDNA hätte sie einen Fehler "Spalte 'rice' existiert nicht" ausgelöst:

Der SQL-Explorer birgt eine Menge Potenzial. In UGS Analytics gibt es noch viel mehr zu entdecken, darunter viele Diagrammoptionen wie Torten und gestapelte Balkendiagramme. Direct Access ermöglicht Ihnen den direkten Zugriff auf Ihre Analytics-Daten über Snowflake.

Nehmen Sie Kontakt mit uns auf, um Ihre Erkenntnisse zu beschleunigen und Unterstützung bei der Erstellung Ihrer Abfragen und Dashboards zu erhalten.

Weitere Lektüre

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