Onboarding-Funnels in Roblox: erkennen, wo Spieler nicht weiterkommen

Mit einer Frage statt einer Grafik beginnen #

Stell dir eine Werkstatt vor: Ein Neuling nimmt ein Paket, geht zur Station und erhält eine Lieferbestätigung. Der Entwickler beobachtet kurze Sitzungen und vermutet einen zu langen Weg. Vielleicht verlässt der Spieler aber schon vorher das Spiel, versteht die Schaltfläche nicht oder bemerkt nach erfolgreicher Lieferung die Belohnung nicht. Die gesamte Sitzungsdauer unterscheidet diese Situationen nicht.

Formuliere eine konkrete Frage: Nach welcher überprüfbaren Handlung kommen die meisten Teilnehmer des Tutorials nicht mehr weiter? Damit legst du zunächst die Ereignisfolge fest und wählst anschließend das Werkzeug. Sammle nicht einfach möglichst viele Analyseereignisse. Jedes Ereignis soll eine Frage zum Verhalten beantworten, statt lediglich den Aufruf einer weiteren Funktion nachzuweisen. Ein brauchbarer Ablauf zeigt, was erreicht wurde und wo die Untersuchung beginnen sollte.

Website und Spiel beobachten unterschiedliche Handlungen #

Ein Klick auf Spielen auf einer Website bestätigt eine Linkinteraktion. Er beweist keinen Beitritt zu einem Spielserver, keinen erledigten Auftrag und keinen erhaltenen Gegenstand. Der Ablauf im Spiel benötigt eine eigene Messung. Verbinde Websitebesucher und Serverteilnehmer nicht ohne begründete Zuordnung zu einem einzigen Funnel.

Dieser Artikel behandelt Roblox-Analysen und kein neues Ziel in Yandex Metrica. Der Websitezähler bleibt unverändert. Langes Lesen eines Leitfadens berechtigt nicht zum Ereignis Tutorial abgeschlossen im Spiel. Bestätige jede Handlung dort, wo sie tatsächlich stattgefunden hat. Diese Trennung verhindert, dass eine erfolgreiche Websiteinteraktion als erfundener Spielfortschritt erscheint, und macht die Interpretation verständlicher.

Vier Stufen für die Lernwerkstatt festlegen #

Unser vorgeschlagener Ablauf lautet: Der Spieler betritt das Einführungsszenario; der Server vergibt den ersten Auftrag; der Server bestätigt die Lieferung; der Server wendet die erste Belohnung an. Das sind eigene Entwurfsbezeichnungen und keine vorgeschriebenen Roblox-Stufen. Notiere jeweils Nummer, stabilen Namen und genaues Abschlusskriterium.

Ein angezeigter Hinweis ist nicht dasselbe wie ein angenommener Auftrag. Geht es um die Verfügbarkeit des Hinweises, lässt sich seine Anzeige separat untersuchen. Ersetze damit aber nicht die Auftragsannahme. Ebenso ist eine erschienene Truhe noch keine erhaltene Belohnung. Die Planungstabelle soll erklären, welcher Serverzustand jede Stufe belegt. So kann ein anderer Entwickler die Messung prüfen, ohne die Bedeutung von abgeschlossen erraten zu müssen.

Bild in voller Größe öffnen ↗

Ereignisse im passenden Kontext senden #

Roblox dokumentiert LogOnboardingFunnelStepEvent für die Einführung und LogFunnelStepEvent für andere Funnels. Ereignisse werden serverseitig in veröffentlichten Spielen gesendet; Studio sendet sie nicht an den Dienst. Ein Test mit einem simulierten Sender belegt deshalb nicht, dass Daten im Creator Hub angekommen sind.

Trenne die Prüfung des Spielgeschehens von der Analyseübermittlung. Der Server weiß, ob der Auftrag vergeben und die Lieferung akzeptiert wurde, und kann danach die entsprechende Stufe melden. Die Client-Anforderung, Stufe vier einzutragen, ersetzt diese Bedingungen nicht. Das Lernbeispiel unten erhält eine geprüfte Stufe aus der Serverlogik statt einer beliebigen Nummer vom Gerät des Spielers. Die Spiel-Handler müssen die Aktion selbst bestätigen. Das Beispiel wurde nicht mit einem laufenden Spiel verbunden.

Der folgende Code ist ein ModuleScript namens OnboardingObserver in ServerScriptService. Ein serverseitiges Script erstellt observer = OnboardingObserver.new(function(player, step, name) AnalyticsService:LogOnboardingFunnelStepEvent(player, step, name) end). Rufe observer:RecordVerified(player, step) erst nach echter Bestätigung der Spielhandlung auf und observer:Forget(player) beim Verlassen. Das Modul verbindet kein RemoteEvent und prüft nicht die Paketlieferung. Es kontrolliert Reihenfolge 1–4 und unterdrückt Wiederholungen im aktuellen Zustand. true bedeutet nur einen fehlerfrei zurückgekehrten lokalen Aufruf, keinen Dashboard-Eingang. Nach Senderfehler liefert eine spätere Stufe OutOfOrder, bis die vorherige erfolgreich gesendet wurde: untersuche die Diagnose ohne Spielbelohnungen davon abhängig zu machen. Zustand wird nicht zwischen Servern gespeichert. Lokale Luau-Tests verwendeten einen simulierten Sender; echte Ereignisse wurden nicht gesendet.

Deklariere am Anfang des aufrufenden Server-Scripts local AnalyticsService = game:GetService("AnalyticsService") und local OnboardingObserver = require(game:GetService("ServerScriptService"):WaitForChild("OnboardingObserver")). Verbinde nach Erstellung von observer game:GetService("Players").PlayerRemoving:Connect(function(player) observer:Forget(player) end). Integriere RecordVerified in vorhandene Server-Handler für bestätigte Aktionen und behalte deren Spielprüfungen bei.

-- ModuleScript: OnboardingObserver, in ServerScriptService.
-- Call only from server logic after a verified gameplay action.
-- This module observes progress; it never grants rewards.
local Observer = {}
local names = {"EnteredWorkshop", "OrderAssigned", "DeliveryAccepted", "RewardApplied"}

function Observer.new(send)
    assert(type(send) == "function", "Sender required")
    local lastStep = {}
    local adapter = {}

    function adapter:RecordVerified(player, step)
        if player == nil then return false, "InvalidPlayer" end
        if type(step) ~= "number" or step ~= math.floor(step)
            or step < 1 or step > #names then
            return false, "InvalidStep"
        end
        local previous = lastStep[player] or 0
        if step <= previous then return false, "AlreadyObserved" end
        if step ~= previous + 1 then return false, "OutOfOrder" end
        local ok = pcall(send, player, step, names[step])
        if not ok then return false, "SendFailed" end
        lastStep[player] = step
        -- Local call completed. This is NOT a dashboard delivery receipt.
        return true, "CallCompleted"
    end

    function adapter:Forget(player)
        lastStep[player] = nil
    end

    return adapter
end

return Observer

Den Anfang nicht für eine schönere Grafik weglassen #

Laut Dokumentation beginnt der Funnel mit der ersten protokollierten Stufe. Ist dein erstes Ereignis die Belohnung, beobachtest du nur Teilnehmer, die bereits so weit gekommen sind. Daraus folgt nicht, dass alle eingetretenen Spieler die Einführung bestanden haben: Die übrigen fehlen in der gemessenen Folge.

Wähle den Anfang nach der Fragestellung. Für den gesamten Einstieg kann es der Serverbeitritt sein, für ein bestimmtes Tutorial der Zugang zu diesem Szenario. Schreibe die Definition neben die Stufen. Ändere sie zwischen Versionen nicht stillschweigend. Sonst beschreiben zwei ähnlich aussehende Grafiken verschiedene Gruppen und ihr Unterschied lässt sich nicht dem Effekt einer einzelnen Verbesserung zuordnen.

Wiederholungen und übersprungene Stufen berücksichtigen #

Roblox berücksichtigt das erste Ereignis einer wiederholten Stufe; zusätzliche Meldungen beanspruchen trotzdem das Ereignislimit. Frühere übersprungene Stufen können beim Eingang einer späteren Stufe als abgeschlossen gelten. Eine vollständig gefüllte Grafik beweist deshalb nicht automatisch, dass der Server jede erwartete Meldung gesendet hat.

Führe ein Übungsprotokoll mit Handlung, erwarteter Nummer und tatsächlich gemeldeter Nummer. Prüfe besonders Wege, bei denen alter gespeicherter Fortschritt automatisch eine Belohnung auslöst. Dieser Spieler hat möglicherweise das neue Tutorial nicht durchlaufen. Handelt es sich um einen anderen Fall, mische ihn nicht mit dem ersten Einstieg. Sende keine Erfolge nur zum Füllen eines Berichts; Definition und Protokoll sollen den tatsächlichen Weg erklären.

Die Messung vor dem Abbruchverhalten prüfen #

Bereite kontrollierte Wege vor. Ein Testspieler tritt ein und stoppt vor der Auftragsannahme. Ein zweiter nimmt den Auftrag an, liefert aber nicht aus. Ein dritter beendet das ganze Szenario. Beschreibe für jede Person die erwarteten Ereignisse und diejenigen, die nicht auftreten dürfen.

Erzeuge keine Hunderte identischer Beitritte für eine attraktive Grafik. Ein kleiner kontrollierter Test prüft die Anbindung und charakterisiert nicht die gewöhnliche Zielgruppe. Kennzeichne Testbeobachtungen in den Notizen und berücksichtige sie bei einer kleinen Stichprobe. Diese Wege sind ein Testplan, keine Behauptung bereits erfolgter Besuche. Dokumentiere tatsächliche Ergebnisse separat, sobald die passende veröffentlichte Testumgebung verfügbar ist.

Einen erfundenen Rückgang vorsichtig lesen #

Angenommen, ein erfundenes Beispiel hat 100 Einsteiger, 60 angenommene Aufträge, 45 Lieferungen und 40 erhaltene Belohnungen. Das sind keine Zahlen unserer Website oder Spiele. Vierzig Teilnehmer gingen zwischen Stufe eins und zwei nicht weiter; die vier Werte erklären die Ursache aber noch nicht.

Vielleicht wurde die Station übersehen, jemand wurde abgelenkt, ein Fehler trat auf oder das Spiel passte nicht. Wiederhole als nächsten Schritt den Übergang und untersuche Aufgabenverständlichkeit und mögliche Fehler. Erkläre nicht allein anhand der Grafik die Schaltfläche zum Verursacher. Die Messung zeigt eine Stelle zur Untersuchung. Eine Ursache benötigt weitere Beobachtungen; die Hypothese muss von den gezählten Handlungen getrennt bleiben.

Telefon und Computer sorgfältig vergleichen #

Prüfe zunächst, dass beide Geräte denselben Lernablauf bieten. Am Telefon könnte eine Leiste die Schaltfläche verdecken. Am Computer könnte ein Hinweis versehentlich geschlossen werden. Das sind unterschiedliche überprüfbare Vermutungen und keine feststehenden Aussagen über Gewohnheiten der Zielgruppe.

Roblox-Funnelfilter gelten für die erste Stufe. Ein Gerätewechsel unterwegs ordnet das gesamte Ergebnis nicht einer neuen Gruppe zu. Berücksichtige dies bei der Auswertung. Die letzte Handlung muss nicht auf dem im Filter angezeigten Gerät stattgefunden haben. Notiere bei manuellen Oberflächentests das tatsächlich verwendete Gerät gesondert. Dieses Protokoll beantwortet eine andere Frage als die Kohortenzuordnung im Analysebericht.

Eine konkrete Sache verändern #

Wähle eine überprüfbare Änderung: die Paketerklärung näher an die Station setzen, nach Annahme des Auftrags die Richtung anzeigen oder die Lieferbestätigung sichtbarer machen. Diese Vorschläge gelten für unsere erfundene Werkstatt und sind keine Änderungen an vorhandenen Spielen des Autors.

Ändere nicht gleichzeitig Weg, Belohnungen, Preise und Oberfläche, wenn du die Wirkung eines einzelnen Eingriffs verstehen möchtest. Bewahre Veröffentlichungsdatum, Szenarioversion und Stufendefinitionen auf. Vergleiche anschließend passende Zeiträume und die Zusammensetzung der Nutzergruppe. Bei wenigen Spielern können Ergebnisse stark schwanken. Es gibt keinen universellen Prozentwert für erfolgreiche Einführung. Beschreibe die tatsächliche Stichprobe und verbleibende Unsicherheit.

Bild in voller Größe öffnen ↗

Ein Messproblem erkennen #

Ist die Belohnung bei fast allen sichtbar, die Lieferung aber selten, prüfe zuerst Reihenfolge und übersprungene Stufen. Vermischen sich nach einer Aktualisierung unterschiedliche Namen, wähle einen zur gewünschten Version passenden Zeitraum. Fehlen Daten, prüfe Veröffentlichung, Serverkontext und das tatsächliche Eintreten der Abschlussbedingung.

Repariere den Bericht nicht mit erfundenen Erfolgen. Das Spiel muss auch bei fehlgeschlagener Analyseübermittlung seinen Regeln folgen: Eine Belohnung entsteht nicht durch erfolgreiches Protokollieren. Trenne den Spielvorgang von seiner Beobachtung. Ein Fehler in einem Kanal darf keinen fingierten Abschluss im anderen erzeugen. Eine hilfreiche Diagnose erklärt diesen Unterschied, statt beide Zustände in einem allgemeinen Erfolgsmerkmal zu verbergen.

Eine brauchbare Übergabe vorbereiten #

Übergebe Stufentabelle, Abschlussbedingungen, serverseitige Aufrufstellen, Veröffentlichungsdatum, Testplan und tatsächliche Beobachtungen. Liste Unbekanntes getrennt auf: nicht ausgeführte Tests, ungeprüfte Filter, kleine Stichprobe oder fehlende Daten. Ein anderer Chat kann dann weiterarbeiten, ohne Annahmen als Befunde zu behandeln.

Diese Stufe ist bereit, wenn jedes Ereignis eine klare Handlung beschreibt und die Übermittlung in der richtigen Umgebung geprüft wurde. Das beweist weder bessere Einführung noch gestiegene Spielerbindung. Der Artikel erklärt Messentwurf und Untersuchungsschritte. Für diesen Entwurf wurden weder die Analysen eines laufenden Spiels noch Websiteziele verändert. Eine spätere Implementierung braucht eigene Prüfungen und Belege.