Upselling-AI als API für Geizhals: Preis-Leistung neu gedacht und ohne klassische Filter – ein Deep-Dive in die Session mit Philipp Wissgott (danube.ai)

Kontext: Was wir in „How danube.ai built: "Eine Upselling-AI als API für Geizhals"“ gelernt haben

Wir bei DevJobs.at haben die Session „How danube.ai built: "Eine Upselling-AI als API für Geizhals"“ von Philipp Wissgott (Co‑Founder & CEO von danube.ai) verfolgt – eine kompakte, aber inhaltlich dichte Tour durch Idee, Architektur, Demo und Teamarbeit hinter einer Upselling-AI, die als API direkt in E‑Commerce‑Flows integriert wird. Wissgott verantwortet bei danube.ai die AI‑Algorithmen und führte uns durch den Ansatz, ohne klassische manuelle Filter, ohne Cookies und ohne Nutzerhistorien zu personalisierten Produktempfehlungen mit Fokus auf Preis‑Leistung zu kommen.

Die Kernaussage des Vortrags: Statt 20 Filter anzuklicken, nutzt die AI die impliziten Signale des „Referenzprodukts“ – also des Produkts, über das Nutzer:innen in den Shop kommen – und berechnet in einem Ähnlichkeitsraum eine „multidimensionale Kugel“ rund um dieses Referenzprodukt. Innerhalb dieser Kugel wählt die AI Vorschläge mit einem ähnlichen oder besseren Preis‑Leistungs‑Verhältnis aus und macht diese interaktiv steuerbar, indem man einzelne Produkteigenschaften „boostet“.

Das Problem klassischer E‑Commerce‑Filter – und warum Preis-Leistung der bessere Kompass ist

Wissgott formuliert das Problem, das viele von uns kennen: Nutzer:innen wühlen sich durch lange Filterlisten, nur um einer guten Auswahl näher zu kommen. Am Ende interessiert aber oft nicht die exakte Zahl im Preisfeld, sondern die Frage: „Ist das ein gutes Preis‑Leistungs‑Produkt für mich?“

• Klassische Filter erzwingen viele Handgriffe und Vorwissen: Preisrange, Displaygröße, Akkukapazität, Kameraauflösung usw. müssen manuell kombiniert werden.
• Relevanz ist individuell: „Leistung“ bedeutet für verschiedene Personen Unterschiedliches – etwa lange Akkulaufzeit, Aktualität des Modells, Kameraqualität oder Preisstabilität.
• Mehr Klicks, weniger Klarheit: Der Filterprozess wird zur Sucharbeit, statt zur Orientierungshilfe.

Die Hypothese von danube.ai: Es muss möglich sein, eine AI‑API zu bauen, die ohne explizite Filter und ohne Tracking‑Historie das „für dich“ passende Preis‑Leistungs‑Produkt vorschlägt. Genau damit ist das Team an Geizhals herangetreten – mit Erfolg.

Der Kern des Ansatzes: Das Referenzprodukt als reichhaltiges Signal

Statt Nutzerdaten zu sammeln, nutzt danube.ai die Startbedingung, mit der die meisten in einen Katalog eintreten: die Produktsuche. Häufig landet man über Google bereits auf einer Produktdetailseite – beispielsweise einem bestimmten Smartphone. Dieses konkrete Produkt wird zum „Referenzprodukt“.

Warum ist das wirkungsvoll?

• Es trägt bereits starke Signale über Präferenzen: Preisrange, Displaygröße, Herstellerlinie, Formfaktoren und vieles mehr.
• Es ist sofort verfügbar: Keine Cookies, kein Verlauf, keine Registrierung notwendig.
• Es ist kontextualisiert: Wer ein bestimmtes Modell sucht, ist typischerweise an einer Kategorie, einer Qualitätsklasse und einem Feature‑Profil interessiert.

Dieses Bild prägt den gesamten Algorithmus: Statt in UI‑Filtern zu denken, denkt die AI in Ähnlichkeiten. Die Kugel ist der operative Filter – nur nicht manuell gesteckt, sondern datenbasiert und dynamisch.

Die „multidimensionale Kugel“: Filtern im Ähnlichkeitsraum

Technisch übersetzt bedeutet das: Produkte werden in einem Merkmalsraum repräsentiert, in dem Ähnlichkeit geometrisch greifbar wird. Das Referenzprodukt ist der Mittelpunkt; die Kugel erfasst „benachbarte“ Produkte – also jene, die in den relevanten Dimensionen nah genug liegen.

• Keine expliziten UI‑Filter: Die Kugel übernimmt die Vorauswahl.
• Der Radius ist sinnbildlich die Toleranz für Variation: innerlich ähnlich genug, aber nicht ident.
• Innerhalb der Kugel entscheidet ein Preis‑Leistungs‑Ranking: Die AI filtert die besten Kandidaten heraus.

Das Ergebnis ist ein Upselling‑Vorschlag, der sich vertraut anfühlt („nah an dem, was ich gesucht habe“), aber bewusst Raum lässt für bessere Preis‑Leistung.

Preis‑Leistung als Rankingkriterium – individualisiert am Referenzprodukt

Im nächsten Schritt kommt die Bewertungslogik: Innerhalb der Kugel bewertet die AI die Kandidaten hinsichtlich Preis‑Leistung. Dabei ist „Leistung“ nicht starr definiert, sondern ergibt sich kontextuell aus dem Referenzprodukt und den erkennbaren Eigenschaften der Kategorie.

In der Demo zeigt Wissgott, wie die AI Eigenschaften gewichtet und diese Gewichtungen offenlegt. Links werden Prozentsätze angezeigt, die verdeutlichen, welche Produkteigenschaften für die Bewertung gerade wichtig sind. Ein Beispiel: Beim Samsung Galaxy M51 erkennt die AI, dass die Konversationszeit („64 Stunden“ – ein sehr hoher Wert) stark ins Gewicht fällt.

• Transparente Wichtigkeiten: Die Prozentwerte geben Einblick in die „Gedankenwelt“ des Modells.
• Kontextsensitives Scoring: Ein Merkmal kann je nach Referenzprodukt an Relevanz gewinnen oder verlieren.
• Fokus auf „besser oder ähnlich“: Upselling heißt hier, bessere Gesamtangebote im Kontext zu finden – nicht nur teurer.

Interaktive Individualisierung: „Boosts“ auf Eigenschaften statt 20 Filter-Hebel

Ein praktisches Highlight ist die Möglichkeit, ausgewählte Eigenschaften zu „boosten“. Das ist keine klassische Filterung, sondern ein gezieltes Gewichten: „Mach mir dieses Kriterium wichtiger.“

• Beispiel 1: Aktualität. In der Demo ist „Aktualität“ zunächst mit 13 % gewichtet. Durch einen Klick wird diese Eigenschaft auf 47 % geboostet – sofort ändern sich die vorgeschlagenen Produkte.
• Beispiel 2: Kamera hinten (Megapixel). Ein Boost auf die Kameraqualität verschiebt die Vorschläge erneut.

Dieser Mechanismus ist mächtig, weil er mit minimalem Interaktionsaufwand viel Aussage über Präferenzen transportiert. Er ersetzt nicht das Scoring, sondern moduliert es. Das Explorieren fühlt sich dadurch nicht wie „Filtern“, sondern wie „Führen“ an: Man lotst die AI durch den Produktraum.

Die Demo im Detail: Vom Samsung Galaxy M51 zu OnePlus Nord und Realme X3

Wissgott führt den Fluss an konkreten Geräten vor und macht so die Wirkung greifbar:

• Referenzprodukt: Samsung Galaxy M51
• AI‑Vorschläge: Fünf ähnliche Produkte mit besserem oder ähnlichem Preis‑Leistungs‑Verhältnis; sichtbar u. a. das Samsung Galaxy A71
• Erklärbarkeit: Anzeige, in welchen Eigenschaften ein Kandidat besser oder schlechter ist
• Gewichtung sichtbar: Links Prozentwerte, u. a. hohe Wichtigkeit für die Konversationszeit beim M51
• Boost „Aktualität“: Erhöhung der Relevanz von 13 % auf 47 % führt zu veränderten Empfehlungen; OnePlus Nord erscheint
• Weiterklicken: Vom OnePlus Nord zu dessen ähnlichen Produkten
• Neues Top‑Ergebnis: Realme X3
• Weitere Präzisierung: Boost auf „Kamera hinten Megapixel“ führt erneut zu einer anderen Auswahl

Die Quintessenz: „Mit sehr wenigen manuellen Eingriffsmöglichkeiten kann ich eigentlich sehr viel darüber aussagen, was mir wichtig ist.“ Genau das ist der Unterschied zu starren Filterleisten.

Architektur & Werkzeuge: JavaScript/Node.js, Docker, Worker‑Framework, SDK

Technologisch setzte danube.ai auf ihre bestehende Basis auf:

• SDK‑Fundament: Die unternehmenseigene Technologie lag bereits als SDK vor – ein Vorteil für schnelle Integration.
• Hauptstack: JavaScript und Node.js.
• Containerisierung: „Alles natürlich Dockerized.“
• Verarbeitung & Skalierung: Ein Worker‑Framework mit „sinnvolles Load‑Balancing“ sorgt dafür, dass sehr viele gleichzeitige API‑Anfragen abgewickelt werden können.

Aus Engineering‑Perspektive ist das bemerkenswert pragmatisch: Die AI‑Logik wird nicht als monolithischer Spezialdienst beschrieben, sondern als API, die auf einem bewährten Web‑ und Worker‑Stack fußt. Das macht die Lösung deployment‑freundlich und skalierbar.

Team-Setup und Projektmodus: Klare Verantwortungen, breite Beteiligung

Das Team bei danube.ai umfasst rund zehn Personen. Für dieses Projekt haben „eigentlich fast alle Teammitglieder“ mitgearbeitet:

• T‑Shaped mit Schwerpunkten: Einige stärker im Frontend, andere im Backend – „obwohl eigentlich alle alles können“.
• Ownership nach Neigung: Frontend‑Spezialist:innen „pickten sich ihre Frontend‑Juwele raus“, Backend‑Spezialist:innen entnahmen die Backend‑Teile – ein schönes Bild für motivierte Ownership.
• Technische Projektleitung: Verantwortlich für Issue‑Management und Abnahme gegenüber dem Entwicklerteam.
• Product‑Owner‑ähnliche Rolle: Wissgott selbst übernahm die featureseitige Steuerung und die Kommunikation mit Geizhals, um früh zu validieren, „ob wir auf dem richtigen Weg sind“.

Diese Aufstellung erklärt, warum die API in nur zwei Monaten fertig wurde: Breite Beteiligung, klare Rollen, schnelle Validierungsschleifen.

Von „funktioniert“ zu „rasend schnell“: Performance-Optimierung als zweiter Akt

Ein ehrlicher Punkt im Talk: „Die erste Lösung, die die Features erfüllt, hat meistens nicht die beste Performance.“ Nach der funktionalen Fertigstellung wurde die API auf Tempo getrimmt. Das Ergebnis beschreibt Wissgott so: „so dermaßen schnell“, dass der Unterschied zur ersten Version kaum vorstellbar sei.

Als Engineering‑Takeaway lesen wir daraus:

• Erst Wert, dann Wucht: Zuerst das korrekte Verhalten und den Product‑Fit herstellen, dann Hot‑Paths optimieren.
• Messbarkeit und Fokus: Ohne Zahlen lässt sich Performance nicht verbessern – auch wenn der Talk keine Metriken nennt, signalisiert die Aussage klare Verbesserungsarbeit an den Bottlenecks.
• Infrastruktur zahlt sich aus: Worker‑Framework + Load‑Balancing + Containerisierung erleichtern horizontale Skalierung.

Geizhals war „sehr begeistert“ – ein starkes Signal, dass sowohl die Nutzererfahrung als auch die technischen Eigenschaften überzeugt haben.

UX als Systemeigenschaft: Erklärbarkeit und Kontrolle ohne Komplexität

Besonders aus UX‑Sicht sticht heraus, dass die AI ihre Gewichte offenlegt. Die Prozentwerte links in der Demo schaffen Vertrauen – man sieht, „was die AI gerade wichtig findet“. Zusammen mit dem Boost‑Mechanismus entsteht eine Interaktion, die weit weniger komplex ist als 20 Filter, aber viel aussagekräftiger über Präferenzen.

• Explainability light: Keine Blackbox‑Magie, sondern nachvollziehbare Signale.
• Direktes Feedback: Änderungen an Gewichten wirken sofort in den Vorschlägen – das stärkt Gefühl und Kontrolle.
• Kontext bleibt erhalten: Durch das Referenzprodukt bleiben Vorschläge „nah dran“ und wirken plausibel.

Praktische Schritte zum Nachbauen (auf Konzeptniveau)

Die Session enthält keine konkreten Code‑Snippets – dennoch lässt sich der Weg konzeptionell nachzeichnen:

1. Referenzprodukt bestimmen

• Eingangspunkt der Nutzer:innen identifizieren (z. B. Produktdetailseite nach Google‑Suche).
• Dieses Produkt als „Mitte“ des Ähnlichkeitsraums setzen.

1. Ähnlichkeitsraum definieren

• Produkteigenschaften (Features) in ein konsistentes Merkmalsmodell überführen.
• Distanz/Ähnlichkeit so definieren, dass „nahe“ Produkte sinnvoll benachbart sind (z. B. Preisklasse, Kernfeatures, Formfaktor).

1. Multidimensionale Kugel als Filter anwenden

• Einen Radius (oder Schwellenwert) wählen, der „ähnlich genug“ abgrenzt.
• Kandidaten innerhalb der Kugel für das Ranking bereitstellen.

1. Preis‑Leistungs‑Scoring implementieren

• Eine Bewertungsfunktion, die Preis und Leistungsmerkmale kombiniert.
• Kontextsensitiv: Bedeutung einzelner Merkmale kann vom Referenzprodukt abhängen.

1. Explainability-Signale freilegen

• Gewichte wichtiger Eigenschaften berechnen und sichtbar machen.
• Unterschiede gegenüber dem Referenzprodukt klar hervorheben („wo besser/schlechter“).

1. Boost-Mechanik ergänzen

• Nutzerseitige Gewichtungsimpulse erlauben (z. B. Aktualität, Kamera, Akkulaufzeit).
• Boosts unmittelbar ins Ranking rückkoppeln.

1. Architektur produktionsreif machen

• API‑Schicht in JavaScript/Node.js (wie bei danube.ai in der Session beschrieben) oder äquivalent.
• Containerisierung (Docker) für reproduzierbare Deployments.
• Worker‑Framework und Load‑Balancing, um hohe Parallelität zu bedienen.

1. Iterativ auf Performance trimmen

• Nach Funktionsnachweis Bottlenecks identifizieren.
• Caching, Parallelisierung, schlanke Datenpfade – je nach Profil.

Diese Abfolge spiegelt die in der Session geschilderten Prinzipien wider, ohne über die gegebenen Informationen hinauszugehen.

Risiken, Grenzen, Trade-offs – und wie der Ansatz sie adressiert

Ohne neue Fakten zu erfinden, lassen sich aus dem Gesagten einige generelle Trade‑offs ableiten:

• Ohne Nutzerhistorie fehlt Langzeitkontext. Der Referenzprodukt‑Ansatz kontert das mit einem starken Startsignal und interaktiven Boosts, verzichtet aber bewusst auf Tracking.
• Eine „Kugel“ im Ähnlichkeitsraum benötigt gutes Feature‑Engineering. Die Session zeigt, dass die interne Technologie von danube.ai dieses Fundament bereits als SDK bereitstellte.
• Erklärbarkeit vs. Komplexität: Das Anzeigen von Gewichten ist ein einfacher, aber wirkungsvoller Schritt, der Vertrauen schafft, ohne die Nutzer:innen zu überfrachten.

Zwei Monate bis zur API: Warum das funktioniert hat

Wissgott betont die kurze Time‑to‑Market: „innerhalb von zwei Monaten fertig“. Wesentliche Gründe laut Vortrag:

• Bestehende Technologie im SDK
• Klarer Scope (Upselling innerhalb eines Ähnlichkeitsraums, Fokus Preis‑Leistung)
• Breite Teambeteiligung und klare Rollen (technische Projektleitung, Product‑Owner‑Funktion in Kundennähe)

Das ist ein lehrreiches Muster für Tech‑Teams: Mit einem klaren Produktkern, vorhandener Plattform und eng getakteter Validierung lassen sich auch neuartige Ansätze zügig in eine produktionsreife API bringen.

Zitat-Splitter, die hängen bleiben

• „Unser Filter sind nicht irgendwelche manuellen Preisranges, sondern eine Kugel im Ähnlichkeitsraum der Produkte.“
• „Die erste Lösung, die die Features erfüllt, hat meistens nicht die beste Performance.“
• „Es ist schon irgendwie ein gutes Gefühl, wenn man weiß, dass man so ein Problem das erste Mal löst.“

Diese Sätze rahmen Anspruch, Ehrlichkeit und Pioniergeist des Projekts.

Engineering‑Takeaways für die Praxis

Für Entwickler:innen und Architekt:innen, die ähnliche Ideen umsetzen wollen, lassen sich aus der Session „How danube.ai built: "Eine Upselling-AI als API für Geizhals"“ von Philipp Wissgott (danube.ai) folgende Kernerkenntnisse mitnehmen:

• Startsignal statt Nutzerprofil: Das Referenzprodukt liefert genug Kontext, um sinnvolle, personalisierte Upselling‑Vorschläge zu machen – ganz ohne Cookies.
• Ähnlichkeitsraum als Filter: Eine geometrische Denkweise („Kugel“) kann UI‑Filter ersetzen und führt zu kohärenteren Kandidatenmengen.
• Preis‑Leistung als Leitstern: Statt am nackten Preis zu kleben, bewertet die AI die relationale Güte eines Angebots.
• Transparenz baut Vertrauen: Gewichtsprozent und Eigenschaftsvergleiche machen die AI greifbar.
• Wenige, starke Interaktionen: Boosts sind ergonomischer als 20 Filterregler und leistungsfähiger in der Aussage.
• Produkt zuerst, dann Performance: Features validieren, dann systematisch optimieren – so entsteht Tempo dort, wo es zählt.
• Produktionsreife Architektur: SDK‑Reuse, JavaScript/Node.js, Docker, Worker‑Framework, Load‑Balancing – pragmatische Bausteine für schnelle Lieferung.
• Teamdynamik als Hebel: Breite Beteiligung, klare Verantwortlichkeiten und enge Kundensynchronisierung beschleunigen die Umsetzung.

Fazit

Die Session „How danube.ai built: "Eine Upselling-AI als API für Geizhals"“ mit Philipp Wissgott zeigt einen konsequent anderen Blick auf E‑Commerce‑Suche: raus aus Filterlisten, hinein in einen Ähnlichkeitsraum, in dem eine AI Preis‑Leistung kontextsensitiv bewertet und sich mit wenigen Boosts präzise steuern lässt. Mit einem schlanken, containerisierten JS/Node‑Stack, einem Worker‑Framework und klaren Rollen im Team brachte danube.ai die API in nur zwei Monaten zur Reife und trimmt sie seitdem auf Geschwindigkeit.

Für uns als Tech‑Publikum ist die Botschaft erfrischend klar: Gute Empfehlungen entstehen nicht aus mehr Schaltern, sondern aus besseren Signalen. Indem das Referenzprodukt zum Startsignal wird und die AI ihre Gewichtungen offenlegt, wird Upselling nicht nur intelligenter, sondern auch verständlicher – genau die Art von Produktintelligenz, die im E‑Commerce wirkt.

• 

  

  Reinventing AI

  Philipp Wissgott von danube.ai beschäftigt sich in seinem devjobs.at TechTalk mit dem Gedanken, was man sich eigentlich von Suchmaschinen erwartet und zeigt einen Weg, wie entsprechende Ergebnisse ermittelt werden könnten.

  Jetzt ansehen