Recommendation Engine bei den Österreichischen Lotterien: Architektur, ALS-Modell und Cloud-Datenfluss aus Patricks Tech Talk

Kontext: „Recommendation Engine“ mit Patrick (Österreichische Lotterien)

In der Session „Recommendation Engine“ stellte Patrick von den Österreichischen Lotterien die Reise von der ersten Idee bis zum produktionsreifen Empfehlungsdienst vor. Aus der Perspektive von DevJobs.at war besonders spannend, wie deutlich das Team zwei Realitäten miteinander verzahnte: eine stark regulierte Domäne mit DSGVO-Anforderungen und eine datengetriebene, experimentierfreudige ML-Umsetzung in der Cloud.

Gleich zu Beginn machte Patrick klar, warum diese Initiative intern umsetzbar war: Die IT der Österreichischen Lotterien zählt rund 200 Mitarbeitende und versteht sich als interner IT-Dienstleister für die Business Lines. Entwicklung und Infrastruktur sind die zwei größten Abteilungen – und die Entwicklung ist groß, weil „wir alles In-House entwickeln“. Das gilt für Spielsysteme ebenso wie fürs Data Warehouse. Dieser Inhouse-Fokus zog sich als roter Faden durch den gesamten Vortrag – und erklärt, warum die Teams Modelle wie ALS schnell iterieren und gleichzeitig Systemerweiterungen für die Ausspielung beim Endnutzer selbst bauen konnten.

Was ist eine Recommendation Engine?

Das Ziel ist bekannt: Nutzerinnen und Nutzern passende Inhalte anzeigen – analog zu Amazon oder Netflix. Patrick skizzierte dafür die Grundlagen: Feedback lässt sich grob in zwei Kategorien trennen.

• Explizites Feedback: Sterne-Bewertungen, „gefällt mir/gefällt mir nicht“, klare Präferenzen pro Produkt.
• Implizites Feedback: abgeleitete Präferenz über Verhalten – zum Beispiel „wie oft wurde ein Spiel gespielt“ oder „welche Seiten wurden angeklickt“.

Der für den Vortrag wesentliche Punkt: Im impliziten Setting kann man aus Nicht-Interaktionen nicht auf Ablehnung schließen. Wenn ein User ein Spiel nicht gesehen oder nicht gespielt hat, kann das schlicht Unkenntnis sein. Genau in diesem Spannungsfeld hat das Team gearbeitet.

Zwei Ansätze: Content-Based vs. Collaborative Filtering

Patrick trennte die Methodik in zwei Hauptfamilien:

• Content-Based: „Ich empfehle ähnliche Produkte.“ Wer Spiel A konsumiert, erhält Vorschläge, die A ähnlich sind.
• Collaborative Filtering: „Ich finde ähnliche User und empfehle, was diese konsumiert haben.“

Für den ersten Wurf setzten die Österreichischen Lotterien auf Collaborative Filtering. Der Fokus lag damit auf Beziehungen zwischen Nutzern und Spielen – nicht auf Beschreibungsmerkmalen der Spiele.

Inhouse-Kompetenz als Beschleuniger

Die Entwicklungsabteilung (rund 100 Personen) gliedert sich in drei Bereiche:

• Lotto-System: Eigenentwicklung der Software rund um Terminals (C++), Spielverarbeitung im Backend (Java) und Frontends (z. B. Euromillionen, Lotto, Online-Plattformen) in TypeScript/React.
• Online-Systeme: TIP3 und Win2day, gänzlich inhouse entwickelt und auf einer gemeinsamen Plattform in Java realisiert.
• Data-Competence-Center: Heimat von Patrick und seinem Data-Science-Team. Verantwortlich für DWH, Konzernreporting und die Cloud-Transformation. Sprachen/Tools: u. a. SQL, dbt (Data Build Tool) und Python.

Diese Struktur erklärt die Geschwindigkeit vom Offline-Prototypen bis zur Online-Ausspielung: Sobald das Modell trug, konnten die Teams die Spielsysteme „aussteuern“, um pro User personalisierte Empfehlungen anzuzeigen.

Vorarbeit: Rechtliches, Infrastruktur und Berechtigungen

Bevor Daten in die Cloud durften, stand ein intensiver Schulterschluss mit der Legal-Abteilung an. Patrick betonte, wie wichtig die Abstimmung zu „wie werden Daten verwaltet, gespeichert und welche Daten dürfen verwendet werden“ war – alles DSGVO-konform.

Gleichzeitig brauchte es enge Koordination mit der Infrastruktur-Abteilung: Streaming in die Cloud, ein schlüssiges Berechtigungssystem und die Nutzbarkeit von Infrastructure as Code. Erst diese Fundamente machten das eigentliche Daten- und Modellprojekt möglich.

Der Datenfluss in die Cloud: Oracle, S3 und CDC-Streaming

Patrick zeichnete den End-to-End-Pfad präzise nach:

• Quellsystem: Oracle-Datenbank
• Batchload in die AWS-Cloud: initial auf Amazon S3
• Laufendes Streaming via Change Data Capture: über AWS Database Migration Service (DMS) und Debezium in die Cloud

Plattformseitig lag die Lösung auf AWS. Für Datenaufbereitung und Analytics nutzt das Team Databricks; die Aufbereitung erledigen Data Engineers mit dbt auf Basis eines Layer-Modells.

Datenmodellierung mit der Medaillen-Architektur

Die dbt-Pipelines folgen der „Medaillen-Architektur“:

• Bronze: Rohdaten, wie sie anfallen
• Silber: bereits aggregierte/aufbereitete Daten
• Gold: fertige, geschäftsnahe Sichten für Business Lines und Reporting

Für die Recommendation-Engine bildet der Gold-Layer die vertrauenswürdige Ausgangsbasis, auf der PySpark/Databricks-Modelle trainiert und später täglich aktualisiert werden können.

Das erste Modell: ALS (Alternating Least Squares)

Das Team startete mit ALS, einer Matrixfaktorisierung. Patrick erklärte das Prinzip mit einer leicht verständlichen Matrix: Nutzer auf der vertikalen Achse, Spiele auf der horizontalen. In den Zellen stehen Bewertungen – in der Demo als explizite Ratings, „zur Veranschaulichung“. Die weißen Felder sind „unbekannt“.

Die Idee: Die große Matrix wird in zwei kleinere zerlegt – eine User-Matrix und eine Spiele-Matrix – mit latenten Features. Über die vorhandenen (bekannten) Werte lassen sich die Faktoren lernen. Führt man anschließend die Matrizen wieder zusammen, kann man die weißen Felder „auffüllen“ und damit vorhersagen, was ein Nutzer zu einem Spiel sagen würde.

Wichtig: Produktiv arbeitet das Team nicht mit expliziten Bewertungen, sondern mit implizitem Feedback. Die zentrale Größe ist die Anzahl der Spieltransaktionen – also „wie oft hat ein User etwas gespielt“. Dieses implizite Signal fließt in das ALS-Training ein.

Train-Test-Split: Leave-One-Out statt 80/20

Statt eines klassischen 80/20-Splits setzte das Team auf Leave-One-Out pro User. Vorgehen:

• Für jede Nutzerin/jeden Nutzer wird genau ein gespieltes Spiel „zur Seite gelegt“.
• Dieses Spiel bildet das Test-Set.
• Das Modell sieht den entfernten Eintrag nicht und wird ohne ihn trainiert.

Das erlaubt eine Evaluierung via Hitrate: Im Trockentraining (offline) wird geprüft, ob das entfernte Spiel innerhalb der empfohlenen Liste für den jeweiligen User auftaucht. Wenn ja, trifft die Engine das Nutzerinteresse in diesem konkreten, realistischen Szenario.

Baselines: Top-Spiele und Zufall

Bevor das ALS-Modell „zum User darf“, schuf das Team Vergleichswerte:

• Random: jedem User zufällige Spiele vorschlagen
• Top: jedem User die global besten Spiele vorschlagen

Wenig überraschend schnitt Random am schlechtesten ab. Top-Spiele waren deutlich besser – aber das ALS-Modell lag „zum Glück“ vorne. Diese Baselines halfen, die Wirksamkeit des kollaborativen Ansatzes messbar zu belegen.

Von Offline zu Online: Ausspielung je User

Der Weg von der Offline-Hitrate zur Online-Aussteuerung führte durch die Anwendungslandschaft. Die Spielsysteme mussten erweitert werden, damit einzelne Nutzerinnen und Nutzer jeweils eigene Vorschlagslisten erhalten. Der Inhouse-Stack war hier der entscheidende Enabler: Das Team konnte die Anforderungen nahtlos in die entsprechenden Entwicklungsbereiche geben und die Ausspielung integrieren.

Das Ergebnis der Recommendation-Engine ist eine pro Nutzer generierte Spieleliste, sortiert nach Priorität. Bei implizitem Feedback spielt eine „Konfidenz“ die Rolle der Priorisierung: Wie sicher ist die Engine, dass das vorgeschlagene Spiel zum bisherigen Verhalten passt?

Tägliches Training und Stabilität der Empfehlungen

Patrick adressierte eine praktische Frage: „Bekommt ein User jeden Tag etwas anderes?“ Antwort: „Die Wahrheit liegt irgendwo dazwischen.“

• Es gibt User, bei denen sich die Liste täglich stärker verändert – je nach Spielverhalten.
• Über die Gesamtheit gesehen ist es eher ein „langsam rollendes“ System: Ein Großteil der Spiele bleibt vom Vortag zum nächsten Tag gleich.

Trotzdem trainiert das Team täglich. Der Grund ist handfest: Täglich kommen neue User hinzu, und es werden regelmäßig neue Spiele gelauncht. Was beim Training nicht vorhanden war (neue User/neue Spiele), kann das Modell weder bewerten noch empfehlen. Die tägliche Aktualisierung stellt sicher, dass das System „am Puls“ der Daten bleibt.

Online-Experiment: A/B-Testing und Aktivitätsmessung

Mit der Online-Ausspielung startete das Team klassisches A/B-Testing. Nutzerinnen und Nutzer werden in Gruppen geteilt; anschließend misst das Team die Aktivität, um festzustellen, wie gut die Empfehlungen wirken. Patrick blieb bewusst beim Core-Konzept: Onlinesplitting plus Aktivitätsmetrik – genau das, was man im produktiven Alltag braucht, um Hypothesen zu prüfen.

Iterationspfad: Vom homogenen Bereich bis Near-Real-Time

Am Ende fasste Patrick die Evolution zusammen:

1. Start mit ALS und einer homogenen Gruppe von Spielen – bewusst nicht die gesamte Spielpalette, sondern ein überschaubarer, in sich ähnlicher Bereich für den ersten End-to-End-Durchlauf.
2. Erweiterung um weitere Modelle: zusätzliche Filtering-Ansätze und Content-Modelle. Ziel: prüfen, ob und wie sich ein Hybrid-Modell bauen lässt, das je nach User oder global besser funktioniert.
3. Ausbau auf alle Spielbereiche: inklusive solcher mit anderen Spielmechaniken – erfordert konzeptionell neue Herangehensweisen.
4. Near-Real-Time-Ansatz: möglichst schnell während einer Session reagieren, idealerweise mit verbesserten Vorschlägen basierend auf dem aktuellen Sessionverhalten.

Dieser Pfad zeigt deutlich, wie das Team Validierung, Risikomanagement und Mehrwert balanciert: erst schmal und tief, dann breiter, schließlich schneller.

Technische Eckpfeiler: Tools und Verantwortlichkeiten

Die im Vortrag genannten Bausteine noch einmal verdichtet:

• Plattform: AWS
• Datenquelle: Oracle
• Storage: Amazon S3 (Batchload)
• Streaming: Change Data Capture via AWS DMS und Debezium
• Verarbeitung/Analytics: Databricks (PySpark für das Modell)
• Datenaufbereitung: dbt nach Medaillen-Architektur (Bronze/Silber/Gold)
• Organisation: Entwicklungsabteilung (Lotto-Systeme C++/Java/TypeScript/React; Online-Systeme TIP3/Win2day auf Java-Plattform), Data-Competence-Center (SQL, dbt, Python)
• Compliance & IT: DSGVO-Abstimmung mit Legal, Berechtigungssystem und IaC mit Infrastruktur

Diese Übersicht ist nicht nur Technologie-Liste, sondern macht transparent, dass die Recommendation-Engine eine Querdisziplin ist: Recht, Daten, Plattform, Modellierung und Anwendungsentwicklung mussten reibungslos ineinandergreifen.

Lessons Learned für Engineering-Teams

Auch ohne Code-Demos ließ sich aus Patricks Vortrag eine Reihe pragmatischer Lehren mitnehmen:

• Implizites Feedback verlangt Sorgfalt in der Auswertung. „Nicht gesehen“ heißt nicht „nicht gemocht“. Das Team umgeht diese Falle, indem es Nutzungsintensität (z. B. Spieltransaktionen) als Signal nutzt und Evaluation so gestaltet, dass echte Nutzungssituationen abgebildet werden.
• Leave-One-Out ist ein starkes, anschauliches Evaluierungssetup. Es zwingt das System, das „nächste sinnvolle Spiel“ zu finden – nicht nur gute Durchschnittswerte zu liefern.
• Baselines sind Pflicht. Der Vergleich gegen Random und „Top-Spiele für alle“ verankert Modellgewinne in greifbaren Größenordnungen.
• Offline-Validierung ist nur der Anfang. „Damit der User die Recommendation sehen kann“, mussten die Spielsysteme erweitert werden. Ohne Application-Integration bleibt jede Engine im Labor.
• Tägliches Training ist kein Luxus, sondern Notwendigkeit. Neue User und neue Spiele sind in einem Matrixfaktorisierungssetup entscheidend – was das Modell beim Training nicht gesehen hat, kann es nicht empfehlen.
• Inhouse-Ownership ist ein Wettbewerbsvorteil. Die Kombination aus eigenentwickelten Systemen, zentralem Data-Competence-Center und klarer Infrastrukturabstimmung beschleunigt von der Idee bis zur Ausspielung.

Warum ALS als Einstieg sinnvoll war

Patrick begründete die Wahl nicht mit Buzzwords, sondern mit Passung: ALS ist ein zeitbewährter Ansatz für kollaborative Szenarien mit implizitem Feedback und skaliert auf Benutzer-Item-Matrizen. Gerade weil keine expliziten Bewertungen vorliegen, passt der Faktorisierungsansatz gut – er extrahiert latente Faktoren, die über bloße Count-Signale hinaus Muster erfassen.

Gleichzeitig erlaubte ALS einen schnellen Start in einer homogenen Spielegruppe. Damit minimierte das Team Risiko und Komplexität: erst Verifikation in einem kontrollierten Subset, dann der Schritt zu weiteren Modellen und schließlich zu heterogenen Spielmechaniken.

Stabilität vs. Reaktionsfähigkeit

Die Frage nach „jeden Tag komplett anders?“ zeigt einen wichtigen Engineering-Trade-off. Aus dem Vortrag nehmen wir mit:

• Eine gewisse Stabilität der Listen ist wünschenswert – Nutzerinnen und Nutzer sollen nicht das Gefühl haben, das System springt.
• Gleichzeitig ist Reaktionsfähigkeit entscheidend – neue Spiele und frische Interaktionen müssen in die Empfehlung einfließen.

Die Lösung der Österreichischen Lotterien liegt in täglichen Läufen mit beobachtbar „langsamer Drift“ im Durchschnitt – plus dem Zielbild, in eine Near-Real-Time-Fähigkeit hineinzuarbeiten.

Ausblick: Hybrid-Modelle und Sessionsensitivität

Der skizzierte Fahrplan zeigt, dass Collaborative Filtering nicht das Ende ist. Content-Modelle können gerade bei Cold-Start-Situationen helfen (neue Spiele, neue User) oder die Vielfalt in den Empfehlungen erhöhen. Ein Hybrid aus beidem ist der logische nächste Schritt – in Patricks Worten: „verheiraten“, was separat gut funktioniert.

Mit dem Near-Real-Time-Approach zielt das Team schließlich auf den Session-Moment: Was können wir dem User „jetzt“ anbieten, das auf seinem aktuellen Verhalten basiert? Das ist kein Ersatz des Tages-Trainings, sondern eine Ergänzung – Reaktionsfähigkeit dort, wo sie die größte Wirkung hat.

Fazit: Ein klarer, reproduzierbarer Pfad zur produktiven Personalisierung

Patrick zeigte, wie man eine Recommendation Engine von der Datenquelle über die Cloud bis zur Ausspielung robust aufzieht – ohne Schlenker, aber mit den nötigen Abstimmungen: Legal für DSGVO, Infrastruktur für Streaming, Berechtigungen und IaC, Data Engineering für dbt/Medallion, Data Science für ALS/Implizitmodellierung und die Entwicklungsteams für die Produktintegration.

Für uns als DevJobs.at war „Recommendation Engine“ deshalb ein lehrreiches Praxisbeispiel: erst ein tragfähiger Offline-Proof über Leave-One-Out und Hitrate, dann Baselines und Vergleich, anschließend die technische und organisatorische Brücke in die operativen Systeme – und schließlich der Einstieg in A/B-Tests. Die weitere Roadmap über Hybrid-Modelle, alle Spielbereiche und Near-Real-Time zeigt eine wohldefinierte, inkrementelle Produktstrategie.

Wer auf der Suche nach einer Blaupause ist, findet sie in diesem Vortrag: klein starten, sauber evaluieren, früh integrieren, regelmäßig trainieren und auf Sessionnähe hinarbeiten. Oder, um Patricks Kern in einem Satz zu fassen: Aus implizitem Verhalten zuverlässige, täglich frische Empfehlungen formen – und sie dorthin bringen, wo Nutzerinnen und Nutzer sie sehen.

Zum Schluss erinnerte Patrick daran, dass es bei „Livejobs“ offene Stellen gibt – ein klarer Hinweis, dass dieser Ansatz weiter ausgebaut wird. Wer Engineering mit Produktnähe, Cloud-Datenpfaden und ML-Methodik vereinen möchte, findet hier ein Umfeld, in dem genau das gelebt wird.

• 

  

  Martin, Abteilungsleiter Development bei Österreichische Lotterien

  Der Abteilungsleiter Development bei den Österreichischen Lotterien Martin gibt im Interview einen Überblick über die wesentlichen Eckpunkte der selbst organisierten Devteams, wie dort das Recruiting abläuft und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen

• 

  

  Oscar, System Engineer Backup & Storage bei Österreichische Lotterien

  Oscar von den Österreichischen Lotterien spricht im Interview über seinen Weg in der IT bis hin zu seinem aktuellen Job neben dem Studium und gibt Tipps für Beginner.

  Jetzt ansehen
• 

  

  Sylvia, Senior Agile Developer bei Österreichische Lotterien

  Sylvia von den Österreichischen Lotterien spricht im Interview über ihren Anfang mit dem Programmieren in der Schule, was das Besondere an ihrer aktuelle Arbeit ist und gibt Tipps für Neueinsteiger.

  Jetzt ansehen
• 

  

  Philipp, System Engineer Linux bei Österreichische Lotterien

  Philipp von den Österreichischen Lotterien erzählt im Interview über seine Anfänge in der IT, den Arbeitsalltag in seinem Beruf als System Engineer und was seiner Meinung nach für den Einstieg wichtig ist.

  Jetzt ansehen
• 

  

  Andreas, System Engineer Digital Workplace bei Österreichische Lotterien

  Andreas von den Österreichischen Lotterien erzählt im Interview über seinen technischen Background in der Schule, was seine Arbeit als System Engineer Digital Workplace umfasst und gibt Tipps für Neueinsteiger.

  Jetzt ansehen