Gamification-Schema PostgreSQL: 5 Tabellen, 12 Level

Wichtige Erkenntnisse: Ein robustes Gamifizierungs-System basiert auf einem dedizierten PostgreSQL-Schema mit 5 Tabellen, atomaren Transaktions-RPCs und einer kalibrierten Progression über 12 Level. Das Geheimnis: Gamifizierung in einem eigenen Schema isolieren, Streaks auf 365 Tage begrenzen, um Sucht zu vermeiden, und alles atomar gestalten, um die Datenkonsistenz zu gewährleisten.

Gamifizierung scheint oberflächlich einfach zu sein. Punkte, Badges, eine Bestenliste – das klingt einfach, oder? In Wirklichkeit explodiert die Komplexität, sobald man ernsthaft mit der Modellierung beginnt. Für TAMSIV wollte ich ein komplettes System: Level, Badges, Streaks, tägliche Herausforderungen, Punkthistorie und einen Aktivitäts-Feed. Alles in PostgreSQL, mit Transaktionsgarantien.

Hier ist, wie ich das Gamifizierungs-Schema von TAMSIV entworfen habe, Tabelle für Tabelle, Entscheidung für Entscheidung.

Warum ein dediziertes PostgreSQL-Schema für die Gamifizierung?

TAMSIV verwendet bereits zwei Schemata in Supabase: privat für Benutzerdaten (Aufgaben, Notizen, Ereignisse) und collaborative für Gruppenfunktionen. Ich hätte die Gamifizierungs-Tabellen zu privat hinzufügen können. Aber das habe ich nicht getan.

Das gamification-Schema ist ein dediziertes und isoliertes Schema. Warum?

• Trennung der Verantwortlichkeiten: Die Gamifizierung hat ihre eigenen RLS-Richtlinien (Row Level Security), ihre eigenen RPC-Funktionen, ihre eigenen Indizes. Keine Vermischung mit der Geschäftslogik.
• Unabhängige Entwicklung: Ich kann das Punktesystem ändern oder Badges hinzufügen, ohne das Erstellen von Aufgaben zu gefährden.
• Performance: Gamifizierungs-Abfragen (Bestenliste, Ranking, Statistiken) teilen sich keine Indizes mit Inhalts-Tabellen.
• Sicherheit: Die RLS-Richtlinien der Gamifizierung sind einfacher – ein Benutzer sieht nur seine eigenen Statistiken. Keine Gruppenberechtigungen zu verwalten.

Dieser Ansatz folgt dem von PostgreSQL empfohlenen Schema-Trennung. Jedes Schema ist ein Namespace, der Tabellen, Funktionen und Sicherheitsrichtlinien isoliert.

Welche 5 Tabellen hat das Gamifizierungs-Schema?

Das vollständige Schema basiert auf 5 miteinander verbundenen Tabellen:

1. user_stats – das Dashboard jedes Spielers

Dies ist die zentrale Tabelle. Sie speichert den aktuellen Status jedes Benutzers:

• total_points: die kumulierte Punktzahl seit Beginn
• current_level: das aktuelle Level (1 bis 12+)
• current_streak: die Anzahl der aufeinanderfolgenden Aktivitätstage
• max_streak: der persönliche Streak-Rekord
• last_activity_date: das Datum der letzten Aktivität (für die Streak-Berechnung)
• streak_freeze_count: die Anzahl der verfügbaren "Streak-Einfrierungen"

Warum das Level speichern, anstatt es dynamisch zu berechnen? Weil die Level-Überprüfung einen Vergleich mit Schwellenwerten beinhaltet, und diese Überprüfung muss atomar mit dem Hinzufügen von Punkten erfolgen. Wenn die Berechnung clientseitig erfolgen würde, bestünde die Gefahr von Inkonsistenzen.

2. user_badges – die Sammlung von Erfolgen

Eine Many-to-Many-Beziehung zwischen Benutzern und Badges. Jede Zeile speichert:

• Die Badge-ID (unter den 10 verfügbaren Badges)
• Das Erwerbsdatum
• Den Erwerbskontext (welche Aktion das Badge ausgelöst hat)

Die Badges in TAMSIV belohnen spezifische Verhaltensweisen: erste Sprachnotiz, 10 erledigte Aufgaben, 7 Tage Streak usw. Sie werden niemals entfernt – ein einmal erworbenes Badge bleibt für immer.

3. points_history – das Protokoll jedes Gewinns

Jeder Punktgewinn wird individuell protokolliert. Diese Tabelle ist unerlässlich für:

• Analytics (welche Aktionen generieren die meisten Punkte?)
• Debugging (ein Benutzer bestreitet seine Punktzahl? Wir haben die Spur)
• Tägliche Herausforderungen (Überprüfung der Bedingungen)
• Den Aktivitäts-Feed (chronologische Anzeige der Gewinne)

4. daily_challenges – eine Herausforderung pro Tag

Jeden Tag erhält jeder Benutzer eine personalisierte Herausforderung. Die Tabelle speichert:

• Den Typ der Herausforderung (X Aufgaben erstellen, Sprache verwenden, Notiz abschließen usw.)
• Das numerische Ziel (3 Aufgaben, 5 Notizen usw.)
• Den aktuellen Fortschritt
• Den Status (in Bearbeitung, abgeschlossen, abgelaufen)

Die Herausforderungen werden von einer RPC-Funktion generiert, die das Level des Benutzers berücksichtigt – ein Anfänger erhält einfachere Herausforderungen als ein Spieler auf Level 10.

5. feed_activity – der soziale Feed

Der Aktivitäts-Feed zeigt die letzten Aktionen an: erworbene Badges, erreichte Level, bemerkenswerte Streaks. Dies ist die soziale Dimension der Gamifizierung – zu sehen, dass andere Benutzer Fortschritte machen, motiviert.

Wie funktionieren die 12 Fortschrittslevel?

Das Levelsystem ist das Herzstück der Gamifizierung. Die Punkteschwellen für jedes Level:

[0, 100, 250, 500, 1000, 2000, 3500, 5500, 8000, 12000, 17500, 25000]

Diese Progression folgt einer abgeschwächten exponentiellen Kurve. Die ersten Level sind bewusst einfach:

• Level 1-3 (0 bis 250 Punkte): in 2-3 Tagen normaler Nutzung erreichbar. Dies ist die Onboarding-Phase – der Benutzer entdeckt das System und erhält schnelle Belohnungen.
• Level 4-7 (500 bis 3500 Punkte): die Engagement-Phase. 1 bis 4 Wochen. Der Benutzer hat TAMSIV in seine Routine integriert.
• Level 8-10 (5500 bis 12000 Punkte): die Meisterschaftsphase. Mehrere Monate. Diese Level sind ein Zeichen für starke Bindung.
• Level 11-12 (17500 bis 25000 Punkte): die "Achievers". Weniger als 5% der Benutzer erreichen sie.

Jenseits von Level 12? Eine mathematische Formel übernimmt: Schwelle = 25000 + (Level - 12) * 10000. Das vermeidet das Hardcodieren von Hunderten von Leveln und ermöglicht gleichzeitig eine unendliche Progression.

Diese Kalibrierung ist inspiriert von den Arbeiten von Yu-kai Chou zum Octalysis-Framework, das sofortige Belohnungen zu Beginn des Weges und eine progressive Schwierigkeit empfiehlt, um das langfristige Engagement aufrechtzuerhalten.

Warum müssen RPC-Funktionen atomar sein?

Wenn ein Benutzer eine Aufgabe in TAMSIV abschließt, muss auf der Gamifizierungsseite Folgendes passieren:

1. Die entsprechenden Punkte hinzufügen
2. Überprüfen, ob die Schwelle des nächsten Levels erreicht ist
3. Den Streak aktualisieren (aufeinanderfolgender Aktivitätstag)
4. Überprüfen, ob neue Badges freigeschaltet wurden
5. Den Fortschritt der täglichen Herausforderung aktualisieren
6. Die Punkthistorie protokollieren

Wenn Schritt 3 fehlschlägt, nachdem Schritt 1 erfolgreich war, sind die Daten inkonsistent. Deshalb sind all diese Operationen in transaktionalen PostgreSQL-Funktionen gekapselt. Entweder alles gelingt, oder alles schlägt fehl.

Die Hauptfunktion record_task_completed orchestriert alles in einer einzigen Transaktion:

• add_gamification_points – fügt Punkte hinzu und protokolliert die Historie
• check_and_update_streak – aktualisiert den Streak mit Zeitzonenverwaltung
• check_and_unlock_badges – überprüft die Bedingungen jedes Badges

Auf der Frontend-Seite ruft der GamificationService (Singleton) diese RPCs auf und verwaltet lokale Benachrichtigungen für Badges, Level und Streak-Meilensteine.

Wie verwaltet man Streaks, ohne Benutzer süchtig zu machen?

Streaks sind der mächtigste – und gefährlichste – Gamifizierungsmechanismus. Ein Streak von 100 Tagen erzeugt einen enormen Druck, ihn nicht zu "brechen". Deshalb habe ich Schutzmaßnahmen getroffen:

• Obergrenze bei 365 Tagen: Nach einem Jahr wird der Streak zurückgesetzt. Ein Streak von 500 Tagen ist keine Gamifizierung mehr – es ist Sucht durch Design.
• Streak-Einfrierungen: Der Benutzer kann seinen Streak für einen Tag "einfrieren" (Urlaub, Krankheit). Die Anzahl der verfügbaren Einfrierungen steigt mit dem Level.
• Keine Bestrafung: Das Verlieren eines Streaks zieht keine Punkte oder Badges ab. Es setzt nur den Zähler auf Null zurück.

Die Verwaltung von Zeitzonen ist ein technisches Problem. Ein Benutzer in Paris und ein Benutzer in Tokio haben nicht denselben "Tag". Die Erkennung eines Streak-Bruchs erfolgt durch den Vergleich von last_activity_date mit dem aktuellen Datum in der Zeitzone des Benutzers, nicht in UTC.

Wie konsumiert das Frontend die Gamifizierung?

Der GamificationService ist ein Singleton, der alle Frontend-Interaktionen mit dem Gamifizierungs-Schema zentralisiert:

• RPC-Aufrufe: Jede Aufgabenerledigung oder Notizerstellung löst einen Aufruf an record_task_completed oder record_memo_created aus.
• Lokale Benachrichtigungen: Über NotificationService.notifyAchievement() wird der Benutzer über Badges, Level-Ups und Streak-Meilensteine benachrichtigt.
• Optimierter Cache: Benutzerstatistiken werden lokal zwischengespeichert, um einen Supabase-Aufruf bei jeder Profilanzeige zu vermeiden.
• Echtzeit-Feed: Der Aktivitäts-Feed verwendet Supabase Realtime, um die Erfolge anderer Benutzer live anzuzeigen.

Die Integration in das Diktiergerät ist transparent: Wenn die KI eine Aufgabe per Sprache erstellt, ruft der useTaskDetail-Hook den GamificationService automatisch nach Abschluss auf. Der Benutzer muss nichts tun – die Punkte fallen natürlich an.

Welche Metriken sollten überwacht werden, um die Gamifizierung anzupassen?

Die Tabelle points_history ermöglicht eine detaillierte Analyse:

• Level-Verteilung: Wenn 80% der Benutzer auf Level 3 stecken bleiben, sind die Schwellenwerte zu hoch.
• Abschlussrate von Herausforderungen: Unter 30% sind die Herausforderungen zu schwierig. Über 90% zu einfach.
• Durchschnittlicher Streak: Ein direkter Indikator für die tägliche Bindung.
• Seltenste Badges: Badges, die niemand erhält, müssen neu bewertet werden.

Alles ist im Admin-Dashboard mit Recharts-Diagrammen sichtbar. Dies ermöglicht die Anpassung der Schwellenwerte in der Produktion ohne erneute Bereitstellung.

Wie vermeidet man die klassischen Fallstricke der Gamifizierung?

Schlecht konzipierte Gamifizierung schadet mehr als sie nützt. Hier sind die Fallstricke, die ich vermieden habe:

• Keine öffentliche Bestenliste: Öffentliche Bestenlisten demotivieren 95% der Benutzer, um die 5% an der Spitze zu motivieren. TAMSIV zeigt den persönlichen Fortschritt, nicht den Wettbewerb.
• Keine strafende Gamifizierung: Punkte für Inaktivität zu verlieren, ist ein Dark Pattern. In TAMSIV hat Inaktivität keine negativen Folgen.
• Bedeutsame Punkte: Jeder Punkt entspricht einer realen Aktion (erstellte Aufgabe, gespeicherte Notiz, aufrechterhaltener Streak). Keine kostenlosen Punkte für "Anmelden".
• Sofortiges Feedback: Badge- und Level-Up-Benachrichtigungen kommen sofort, nicht am Ende des Tages.

Wie wendest du dieses Schema auf dein eigenes Projekt an?

Wenn du ein ähnliches Gamifizierungs-System implementieren möchtest, hier sind die Prinzipien:

1. Isoliere das Schema: Mische Gamifizierung und Geschäftslogik nicht. Ein dediziertes Schema erleichtert Migrationen und Debugging.
2. Alles atomar: Jede Benutzeraktion, die die Gamifizierung beeinflusst, muss eine einzige Transaktion sein.
3. Kalibriere den Fortschritt: Teste die Level-Schwellenwerte mit realen Daten. Die ersten Level sollten in Tagen, nicht in Wochen erreichbar sein.
4. Plane die Wartung: Die Tabelle points_history wächst schnell. Plane eine Aufbewahrungs- oder Archivierungsrichtlinie.
5. Messe alles: Ohne Analytics weißt du nicht, ob deine Gamifizierung deine Benutzer motiviert oder frustriert.

FAQ

Wie lange dauert es, ein vollständiges Gamifizierungs-System zu implementieren?

Für TAMSIV dauerte das Schema und die RPCs etwa 4 Tage. Die Frontend-Integration (GamificationService, Benachrichtigungen, UI) fügte weitere 3 Tage hinzu. Am längsten dauert die Kalibrierung der Level-Schwellenwerte, die reale Nutzungsdaten erfordert.

Ist PostgreSQL für Gamifizierung geeignet oder sollte man Redis verwenden?

PostgreSQL reicht für eine App der Größe von TAMSIV völlig aus. Die Transaktionsfunktionen gewährleisten die Konsistenz, und die Indizes auf user_stats machen Abfragen schnell. Redis wäre nur für eine Echtzeit-Bestenliste mit Millionen von Benutzern nützlich – was hier nicht der Fall ist.

Wie vermeidet man, dass Gamifizierung zu einem Dark Pattern wird?

Drei Regeln: keine Bestrafung für Inaktivität, kein sozialer Druck durch öffentliche Bestenlisten und eine Obergrenze für Streaks. Gamifizierung sollte Handlungen belohnen, nicht Abwesenheit bestrafen. Das Streak-Freeze ist ein wesentlicher Sicherheitsmechanismus.

Sollten die Punkte für alle Aktionen gleich sein?

Nein. In TAMSIV bringt das Abschließen einer Aufgabe mehr als das Erstellen einer Notiz, und die Verwendung der Stimme gibt einen Bonus. Die Bewertung spiegelt den Wert jeder Aktion für den Benutzer wider. Eine flache Bewertung (alles ist 10 Punkte wert) schafft keine Verhaltenshierarchie.

Sollten Punkte in Echtzeit oder verzögert angezeigt werden?

Immer in Echtzeit. Sofortiges Feedback ist die Grundlage effektiver Gamifizierung. In TAMSIV werden Punkte sofort nach jeder Aktion angezeigt, mit einer Animation und optionalem Sound. Verzögerungen töten Dopamin.