Gamification Metriken: DAU/WAU, Partizipation, Abschlussrate

Gamification funktioniert nur dort, wo ihre Wirkung durch Zahlen bestätigt wird. Im Folgenden finden Sie eine Systemanalyse von drei grundlegenden Metriken, ohne die es unmöglich ist, Missionen, Events und Belohnungen zu verwalten: DAU/WAU, Teilnehmerrate (Teilnahme) und Abschlussrate (Abschluss).

1) DAU/WAU und „Stickness“

Bestimmungen

DAU (Daily Active Users) - die Anzahl der eindeutigen Benutzer mit einer gezielten Aktion pro Tag (Login, Client-Start, Einsatz/Spin, Missionsausführung usw.).

WAU (Weekly Active Users) - einzigartige Benutzer mit gezielter Aktivität in den letzten 7 Tagen.

DAU/WAU (Stickiness) - Anteil der „täglich Aktiven“ unter den „Wöchentlichen“.

[
\text{DAU/WAU} = \frac{\text{DAU}}{\text{WAU}} \quad (0\ldots1)
]

Wie zu interpretieren

0,15-0,25 ist eine grundlegende „gesunde“ Stickerei für Unterhaltungsprodukte mit einem nicht-täglichen Muster.

0,25-0,35 ist ein gutes Niveau bei regelmäßigen Einsätzen und einfachem Einstieg.

💡 0,35 - starke Verhaltens- „Klebrigkeit“, in der Regel mit täglichen Aufgaben, Streak 'ax und motivierenden Belohnungen.

Wichtig: Bewertung im Querschnitt der Segmente (Anfänger, Re-aktiviert, zahlend, Mid-Core, High-Value). Die Gesamtzahl verdeckt leicht die Probleme.

Häufige Verzerrungen

Inflation durch Bonustage. Ein einzelnes „Hype“ -Event wird die DAU erhöhen, aber den DAU/WAU-Trend am Horizont von 4-8 Wochen nicht verbessern.

Falsche Multiaktivität. Bots/doppelte Konten. Obligatorische Deduplizierung über device-fingerprint + KYC-Signale.

Änderung der „Zielaktion“. Wenn Sie die Regel „Wer gilt als aktiv“ ändern, fixieren Sie das Datum und erstellen Sie eine „Metrik 2“. 0».

2) Teilnahmequote (Teilnahmequote)

Bestimmung

Anteil der Nutzer, die sich in einem Gamification-Zyklus (Event/Mission/Turnier) unter der Zielgruppe angemeldet haben.

Grundformeln:

[
\text{Participation (gross)}=\frac{# \text{users_with_event_open}}{# \text{eligible_audience}}
]

[
\text{Participation (net)}=\frac{# \text{users_started_progress}}{# \text{eligible_audience}}
]

Gross sind alle, die die Veranstaltung gesehen und auf „mitmachen“ geklickt haben.

Net - diejenigen, die tatsächlich mit der Ausführung begonnen haben (z. B. die ersten X-Punkte/Spins/Quest-Schritte).

Der richtige „Denominator“

„Eligible audience“ im Voraus aufzeichnen: zum Beispiel alle Benutzer, die in den letzten 14 Tagen ≥1 einmal aktiv waren und in Geo/Regeln fallen.

Betrachten Sie separat die Reach-Kommunikation (Push, In-App, E-Mail). Geringe Beteiligung oft = geringe Reichweite.

Normen und Richtlinien

Netzbeteiligung 12-25% für Massenleichtereignisse.

5-12% für „Hardcore“ -Events mit Eintrittsschwelle (Einzahlung/Level).

30% + wird in Microsprints für warme Segmente (D1-D7 Anfänger, re-engaged) erreicht.

3) Abschlussrate (Fertigstellung)

Bestimmung

Anteil der Teilnehmer, die die Mission/Kette/Veranstaltung abgeschlossen haben.

[
\text{Completion Rate}=\frac{# \text{users_completed}}{# \text{users_started}}
]

Abarten

Per-Task-Abschluss - Abschluss bestimmter Schritte in der Kette (T1, T2,...).

Vollkettenabschluss - Komplettierung der gesamten Linie.

Time-bounded completion - Fertigstellung vor Ablauf der Frist.

Interpretation

Normen hängen von der Länge und dem „Preis“ der Aufgaben ab.

Einfache Einzelmission: 60-85%.

Kette von 3-5 Schritten: 35-60%.

Lange Quest 7-10 Schritte: 18-35%.

Nachlassen der Erfüllung in späten Schritten ist nicht immer schlecht. Dies kann ein bewusster Monetarisierungs-/Komplexitätstrichter sein. Es ist wichtig, dass Net Uplift positiv bleibt und die RG-Metriken im grünen Bereich liegen.

4) Bündel von Metriken: „gesehen → begonnen → abgeschlossen“

Bauen Sie einen einzigen Trichter:

1. Reichweite: Sie haben ein Event gesehen.

2. Teilnahme (gross/net): eingetragen/gestartet.

3. Progression: Anteil der erreichten T1/T2/.../Tn (mit Timings).

4. Vervollständigung: abgeschlossen.

5. Value: ΔDAU/WAU, ΔRetention, ΔARPPU, ΔAvg Deposit, Bonus Cost%, Net Uplift.

Dies ermöglicht es Ihnen, "Lecks' zu fangen: niedrige Reichweite, Eintrittsbarrieren, Knick in der Komplexität der Schritte 2-3, UX-Dips (schlechte Sichtbarkeit des Fortschritts).

5) Analytik: Segmentierung und Kohorten

Empfohlene Schnitte:

Stage: Anfänger D0-D7, zurückgegebene R7-R30, konstante P30.
Monetisierung: zahlungsunfähig, neu zahlend (NPP), wieder zahlend (RPP), hoher Wert.
Kanal/Geo/Plattform: Web/iOS/Android, Länder/Regulierungen.
Inhalt: Art der Mission (XP, Spins, Deposit), Volatilität der Spiele, Schwellenwerte.

Für jede Gruppe sind DAU/WAU, participation, completion, ARPPU, Bonus Cost per Active - vor/während/nach dem Event (D-Fenster, W-Fenster) zu erfassen.

6) Experimentelles Design: beweisen das Inkrement

Holdout-Kontrolle: Ein Teil des Publikums sieht die Veranstaltung nicht (oder sieht den „Schnuller“).

Randomized Invitation: zufällige Verteilung von Einladungen, reach.

Geo/Channel Split: Wenn der Rand verboten ist - ordentliches Matching.

Messfenster: Effekt „während“ und Post-Event-Tail (7-14 Tage).

Letzte Metriken: Δ DAU/WAU, Δ Participation/Completion, Δ ARPPU (Net of Bonus), Retention D7/D30, Net Uplift.

7) DWH/Ereignisse: minimales Datenschema

Ereignisse (Beispiel):

`session_start {user_id, ts, platform}`
`mission_view {user_id, mission_id, ts}`
`mission_join {user_id, mission_id, ts}`
`mission_progress {user_id, mission_id, step, value, ts}`
`mission_complete {user_id, mission_id, ts}`
`purchase/deposit {user_id, amount, ts}`
`spin/bet {user_id, game_id, bet, win, ts}`

Verzeichnisse:

`missions {mission_id, type, start_at, end_at, rules, segment, min_requirement, reward_type}`
`users {user_id, geo, platform, signup_at, payer_flag, segments}`

8) Berechnungsbeispiele (SQL-Sketche)

DAU für das Datum d:

sql
SELECT DATE(ts) AS d, COUNT(DISTINCT user_id) AS dau
FROM session_start
WHERE DATE(ts) =:d
GROUP BY 1;

WAU für die Woche, die mit dem Datum d endet:

sql
SELECT COUNT(DISTINCT user_id) AS wau
FROM session_start
WHERE ts >=:d - INTERVAL '6 day' AND ts <:d + INTERVAL '1 day';

DAU/WAU (stickiness):

sql
WITH dau AS (
SELECT COUNT(DISTINCT user_id) AS dau
FROM session_start
WHERE DATE(ts) =:d
), wau AS (
SELECT COUNT(DISTINCT user_id) AS wau
FROM session_start
WHERE ts >=:d - INTERVAL '6 day' AND ts <:d + INTERVAL '1 day'
)
SELECT dau::float / NULLIF(wau,0) AS dau_wau FROM dau, wau;

Teilnahme (net) an der Mission:

sql
WITH elig AS (
SELECT user_id
FROM users
WHERE last_active_at >=:d - INTERVAL '14 day'
), started AS (
SELECT DISTINCT user_id
FROM mission_progress
WHERE mission_id =:m AND ts BETWEEN:start AND:end
)
SELECT COUNT(DISTINCT s. user_id)::float / NULLIF(COUNT(DISTINCT e. user_id),0) AS participation_net
FROM elig e
LEFT JOIN started s ON s. user_id = e. user_id;

Erfüllungsquote nach Mission:

sql
WITH started AS (
SELECT DISTINCT user_id
FROM mission_progress
WHERE mission_id =:m AND ts BETWEEN:start AND:end
), completed AS (
SELECT DISTINCT user_id
FROM mission_complete
WHERE mission_id =:m AND ts BETWEEN:start AND:end
)
SELECT COUNT(DISTINCT c. user_id)::float / NULLIF(COUNT(DISTINCT s. user_id),0) AS completion_rate
FROM started s
LEFT JOIN completed c USING (user_id);

9) Design, das Partizipation und Vollendung beeinflusst

Sichtbarkeit: Banner über der „Faltlinie“, Abzeichen auf dem Symbol „Missionen“, Fortschrittsbalken auf dem Hauptbildschirm.

Klarheit der Regeln: 1 Bildschirm = 1 Schlüsselziel, Beispiele für „wie man X Punkte erzielt“.

Mikro-Belohnungen auf dem Weg: Beutedrops für T1/T2/T3 → unterstützen die Motivation.

Eintrittsschwelle: Übertreiben Sie die Anforderungen im ersten Schritt nicht; Komplizieren Sie, wie Sie Fortschritte machen.

Timing: kurze Sprints (2-24 h) für heiße Segmente, wöchentliche Bögen - für Masse.

Dynamische Hinweise: „Bis zur Belohnung verbleiben 120 Punkte ≈ 8 Runden à 15“.

10) Anti-Verzerrung und Datenqualität

Deduplizierung: device-fingerprint + KYC-Flags zur Bekämpfung von Multiaccounting.

Anomalien: Bursts started ohne Fortschritt → Tracking-Bugs; completion> gestartet → Duplikate.

Schema-Freeze: Alle Änderungen an Geschäftsregeln - nur durch die Versionierung von Metriken.

Zeit-Debugging: Speichern Sie' event _ time' und 'ingest _ time'; Zeitzonenverschiebungen sind eine häufige Ursache für „Löcher“.

11) Dashboard: Was täglich zu zeigen

1. Stickness: DAU, WAU, DAU/WAU (Trend 8 Wochen, Median nach Segmenten).

2. Der Trichter iwenta: Reach → Participation gross/net → T1/T2/... → Completion.

3. Qualität: Ausfälle (Bounce), durchschnittliche Zeit bis zum T1/T2, Tracking-Fehler.

4. Wert: Δ ARPPU (Net of Bonus), Δ Avg Deposit, Bonus Cost%, Net Uplift.

5. Segmente: Schnitt durch stage/geo/platform/payer-status.

6. Alerts: participation drop> X pp., completion fail in step, DAU/WAU Abweichung vom saisonalen Modell.

12) Häufige Fehler

Zählen Sie die Teilnahme an der „gesamten Basis“ und ignorieren Sie die eligible-Filter.

Stören Sie die Teilnahme von Gross und Net, indem Sie Schlussfolgerungen „im Durchschnitt“ ziehen.

Optimieren Sie nur die Fertigstellung, indem Sie die Komplexität überschätzen und das Engagement reduzieren.

Sich blind über das Wachstum der DAU freuen, ohne zu prüfen, ob die Stickness (DAU/WAU) und der Post-Effekt gewachsen sind.

Ignorieren Sie die Kosten für Boni/Preise, indem Sie die ARPPU- Δ falsch interpretieren.

13) Start und Bewertung Checkliste

Ereignisse und Denominatoren (eligible audience) sind definiert.
Business rules for DAU/WAU/participation/completion (v1. 0).
Konfiguriert holdout/rand für increment.
Dashboard in Schnitten von Segmenten, Plattformen, Geo.
Alerts Qualität und Betrugsbekämpfung.
Endnote: Δ DAU/WAU, Δ Participation/Completion, Δ ARPPU (net), Net Uplift, Post-Effekt 7-14 Tage.

Die DAU/WAU zeigt die Gewohnheit und „Klebrigkeit“ des Produkts, die Teilnahme - die Fähigkeit des Events, die Zielgruppe einzubeziehen, und die Vollendung - die Qualität der Balance von Komplexität und Belohnung. Zählen Sie sie nach einheitlichen Regeln, speichern Sie Versionen, überprüfen Sie das Wachstumsinkrement und den Preis des Wachstums. Gamification wäre dann ein vorhersehbares Werkzeug und keine Lotterie.