Reichweite / ROBLOX
Roblox-Shoptrichter: wiederholte Besuche und Kaufergebnisse trennen
Plane die Analyse eines Shops, den ein Spieler mehrmals in einer Spielsitzung öffnet. Trenne Versuche mit funnelSessionId, definiere beobachtbare Schritte und verwechsle eine Produktansicht nicht mit einem bestätigten Kauf.
Eine Frage zum wiederkehrenden Ablauf wählen #
Stelle dir einen Shop mit Übungsgegenständen vor: Ein Spieler öffnet das Fenster, betrachtet eine Karte, schließt es und kehrt später zurück. Ein einzelner Eintrag „Shop besucht“ erklärt diese beiden Versuche nicht. Der erste kann nach der Ansicht enden, der zweite eine Kaufanfrage erreichen. Frage deshalb, an welchem Schritt einzelne Besuche aufhören weiterzugehen.
Wir verwenden den fiktiven Trichter PracticeShop für die Planung einer zukünftigen Spielanalyse. Er ist kein Leistungsbericht unserer Spiele. Es wurden keine AnalyticsService-Ereignisse versendet, Käufe ausgeführt oder Spielcodes geändert. Gemessene Konversionszahlen gibt es hier nicht. Zuerst müssen Bedeutung eines Versuchs und seiner Schritte feststehen, danach ihre Beobachtung.
Anfang und Ende eines Versuchs festlegen #
Beschreibe, welche bestätigte Shopöffnung einen neuen Versuch beginnt. Definiere anschließend Schließen, Wechsel zwischen Bereichen und Rückkehr. Der Wechsel einer Produktkarte kann zum selben Besuch gehören; das entscheidet dein Projekt. Erzeuge nicht für jedes Bild der Oberfläche oder jede Auswahländerung einen weiteren Versuch.
Im Beispiel endet Versuch A beim Schließen, und erneutes Öffnen beginnt Versuch B. Diese Grenze lässt sich mit gewöhnlichen Handlungen prüfen. Halte sie zusammen mit der Trichterversion fest. Ändert sich die Grenze später, brauchen alte und neue Ereignisse eine Erklärung, statt scheinbar denselben unveränderten Ablauf zu beschreiben.
Bild in voller Größe öffnen ↗Spieler und Versuch unterschiedlich identifizieren #
Bei einem wiederkehrenden Trichter verbindet funnelSessionId die Schritte eines Versuchs und trennt ihn vom nächsten Versuch desselben Spielers. Eine Spielsitzung kann mehrere Shopbesuche enthalten. Derselbe Spieler und derselbe Versuch sind daher unterschiedliche Beziehungen, die im Protokoll erhalten bleiben sollen.
A und B in der Zeichnung sind nur Übungsbezeichnungen, keine wirklichen Kennungen. Ein neuer ausgewählter Ablauf benötigt eine neue ID; seine folgenden Schritte verwenden dieselbe ID. Zwei gegensätzliche Fehler sind wichtig: Eine dauerhafte ID vermischt Besuche, während eine neue ID für jeden Schritt die Folge zerreißt. Prüfe beides vor der Interpretation eines Diagramms.
Bild in voller Größe öffnen ↗Ein Wörterbuch beobachtbarer Schritte erstellen #
Gib jedem Schritt Nummer, kurzen Namen und genaue Abschlussbedingung. Beispielhaft bedeutet ShopOpened die vereinbarte Öffnung, ItemViewed die Anzeige der ausgewählten Karte und CheckoutRequested den Beginn des vorgesehenen Kaufablaufs. Es sind Beispielnamen. Zwei Entwickler sollen denselben Zeitpunkt für die zulässige Ereignisaufzeichnung verstehen.
Ein letzter Schritt GrantConfirmed bedeutet bestätigte Ausgabe nur bei einer getrennt geprüften Kauf- und Ausgabefunktion. Tastendruck, geöffnetes Zahlungsfenster oder geschlossenes Fenster erfüllen ihn nicht. Ist diese Funktion noch nicht bereit, endet der Übungstrichter bei der Ansicht. Eine ehrliche begrenzte Messung hilft mehr als eine vollständig aussehende Folge mit erfundenem Abschluss.
| Beispielschritt | Was bestätigt wird |
|---|---|
| ShopOpened | Vereinbarte Öffnung |
| ItemViewed | Ausgewählte Karte angezeigt |
| CheckoutRequested | Kaufablauf gestartet |
| GrantConfirmed | Nur bestätigte Ausgabe |
Die Serverquelle des Ereignisses bestimmen #
Laut Dokumentation werden diese Analyseereignisse vom Server in veröffentlichten Spielen gesendet, nicht aus Studio oder vom Client. Trenne deshalb eine Oberflächenbeobachtung von der Serverentscheidung über einen zulässigen Schritt. Eine gemeldete Produktansicht muss beispielsweise zu einem vorhandenen Versuch und erlaubten Schritt passen, nicht zu einer beliebigen Clientnummer.
Erstelle eine Zuordnung aus Bedingung, bestätigender Serverlogik, Schrittnummer und ID. Der Artikel enthält keinen fertigen Shop oder universellen Validator. Die Zuordnung macht offene Entwicklungsarbeit sichtbar. Spielhandlung und Analysebeobachtung sind ebenfalls verschieden: Das Protokollieren eines Schritts darf nicht selbst einen Gegenstand ausgeben oder ein Recht darauf erzeugen.
Wiederholungen desselben Schritts prüfen #
Eine Produktkarte kann im selben Versuch erneut angezeigt werden. Die Dokumentation beschreibt, dass der Trichter das erste Auftreten eines wiederholten Schritts berücksichtigt, wiederholte Sendungen aber weiterhin das Ratenlimit belasten. Ein Diagramm ohne doppelte Zählung beweist deshalb weder einen einmaligen Handleraufruf noch sparsame Verarbeitung.
Plane getrennte Fälle für dieselbe Karte, eine andere Karte und das erneute Öffnen des Shops. Das sind drei verschiedene Handlungen. Notiere jeweils ID und Schrittnummer und vergleiche sie mit der gewählten Ablaufgrenze. Sende keine bedeutungslosen Wiederholungen, nur damit ein Bericht aktiv wirkt; jede Beobachtung braucht einen nachvollziehbaren Anlass.
Übersprungene Schritte richtig einordnen #
Ein später Schritt kann frühere Schritte im Trichterbericht automatisch vervollständigen. Das beweist nicht, dass deine Handler alle früheren Handlungen tatsächlich beobachtet haben. Werden Ausgaben angezeigt, aber Öffnungen selten protokolliert, prüfe zuerst Reihenfolge und Sendebedingungen, bevor du Spielerverhalten daraus ableitest.
Plane einen Fall mit fehlendem frühen Schritt und halte das erwartete Berichtsverhalten getrennt vom Protokoll tatsächlicher Aufrufe fest. Das ist kein Anlass für erfundene Erfolge. Ziel ist das Erkennen eines defekten Pfads oder einer unvollständigen Beobachtung. Bekannte Spielhandlungen und Schlussfolgerungen des Analysewerkzeugs aus einem späteren Ereignis bleiben getrennt.
Zwei Besuche anhand des Protokolls verfolgen #
Im ersten vorgeschlagenen Ablauf öffnet der Spieler den Shop, sieht einen Gegenstand und schließt ohne Kauf. Im zweiten öffnet er erneut und beginnt den vorgesehenen Kaufprozess. Das Protokoll soll A und B sowie die Reihenfolge innerhalb jedes Versuchs zeigen. Eine Kaufanfrage ist weiterhin weder Zahlung noch Ausgabe.
Halte pro Versuch Übungskennung, Anfang, verwendete Schritte und Abschlussgrund fest. Eine Ausgabe wird erst nach eigener Bestätigung protokolliert. Die Tabelle enthält Plan und Erwartungen, keine ausgeführten Spielszenarien. Das Versenden prüft der Autor in einer passenden veröffentlichten Umgebung. Für diesen Artikel wurden keine wirklichen Analyseereignisse versendet.
Berichte nach Version und Zeitraum lesen #
Vergleiche den Bericht mit Schrittwörterbuch und Ablaufversion. Nach einer veränderten Öffnungsdefinition oder Umbenennung wähle einen passenden Zeitraum und markiere die Aktualisierung. Ein gemischter Zeitraum kann einen Bedeutungswechsel verbergen, obwohl Schrittnummern unverändert bleiben.
Die Dokumentation begrenzt die Erfassung auf die zehn zuletzt verwendeten einzigartigen funnelSessionId-Werte pro Spieler und Trichter. Verwende das Verfahren nicht als unbegrenztes Versuchsarchiv und nutze keine alte ID zum Fortsetzen eines längst geschlossenen Besuchs. Eine Untersuchung braucht echte Daten und eine verständliche Stichprobe. Beides fehlt hier; steigende Käufe werden nicht behauptet.
Eine klare Spezifikation weitergeben #
Übergebe Frage, Versuchsgrenzen, Wörterbuch, Serverbedingungen, ID-Regeln und die zwei vorgeschlagenen Besuchsprotokolle. Ergänze noch nicht ausgeführte Prüfungen. Ein anderer Chat kann so die Analyse umsetzen, ohne die Bedeutung von Kauf zu erraten oder Spielsitzung und Shopbesuch zu vermischen.
Ein Messplan garantiert keine höheren Verkäufe und ersetzt keine Ausgabelogik. Websiteziele beobachten andere Handlungen und bestätigen keine Käufe im Spiel. Diese Anleitung bietet eigene Zeichnungen und vorgeschlagene Prüfungen, ohne Zahlungen, gemessene Konversionen oder Änderungen unserer Spiele. Prüfe die Umsetzung vor der Interpretation ihrer Beobachtungen.
| Spezifikation | Festhalten |
|---|---|
| Grenze | Anfang und Ende des Versuchs |
| Wörterbuch | Nummer, Name und Bedingung |
| Quelle | Bestätigende Serverlogik |
| Version | Datum und Bedeutungsänderung |
Originalquellen
Roblox Creator Hub — Funnel eventsRoblox Creator Hub — AnalyticsService API
