Der Weg einer gesponserten
Produktanzeige.
Das Bild dahinter: eine Gästeliste, vorab geschrieben — im Moment der Anzeige schaue ich nur schnell nach, statt live die große Datenbank zu fragen.
OBI Sponsored‑Ad Flow
Der Weg einer gesponserten Produktanzeige —
von der Kundengruppe bis zur fertigen Anzeige, als interaktives Modell.
- 1 · Der Datenfluss: von der Kundengruppe bis zur Anzeige
- 2 · Zielbild & Vorgehen — mit dem CDP‑ und Adserver‑Team
- 3 · Live: so sieht es beim Kunden aus
OBI verkauft Werbeplätze. Gute Daten machen sie wertvoll.
Ziel: die Retail-Media-Performance steigern — ein umsetzbarer Plan, der die CDP-Kundengruppen bis in die Anzeige nutzbar macht. Mehr Relevanz → bessere Klick-/Abschlussrate, höhere Fill-Rate, beweisbarer ROAS.
Worum es geht
OBI verkauft Werbeplätze im eigenen Shop & Marketplace an Marken und Drittanbieter (gesponserte Produktanzeigen, Display). Das bringt gutes Geld — aber nur, wenn die Anzeige zum Kunden passt.
Meine Rolle (TPO)
Ich entwickle die Schnittstelle CDP ↔ Adserver weiter — so, dass die in der CDP vorsegmentierten Kundengruppen dem Adserver rechtzeitig vorliegen. (Produkt-/Verfügbarkeitsdaten laufen schon täglich mehrfach — neu: die Kundengruppen.)
Ehrlich vorab: Wer „Fugenmörtel" sucht, will Fugenmörtel — das Suchwort ist das Wichtigste. Die Kundengruppe hilft zusätzlich, ist aber nicht das Entscheidende. Das baue ich auch so ins System ein.
Segmente vorberechnen und pushen — nie live im Auktionsmoment.
① Datenfluss
Gruppen vorab in den Adserver; im Aufruf nur ein schneller Lookup.
② Build vs. Buy
Adserver + ML kaufen (Topsort), die CDP-Anbindung bauen wir inhouse.
③ Erfolg
Über inkrementellen Lift (iROAS) messen, nicht nur ROAS.
Die Gruppe wirkt als Booster, nicht als harter Filter. Das eine Risiko, das ich zuerst kläre: bietet Topsorts API einen Audience-Upload?
Den Maschinenraum gibt es schon — meine Flanke ist die CDP-Anbindung.
Adserver
Topsort (KI) — Sponsored Products + Display, onsite.
Offsite
Ad Alliance/RTL + Decentriq Clean Room.
In-Store
Stratacache-Screens im Markt.
CDP / First-Party
Hier setze ich an — die Brücke zum Adserver.
Öffentliche Quellen (e-commerce-magazin, Agile Brand Guide). Topsort & Decentriq sind gesetzt — neu ist die saubere CDP → Adserver-Brücke.
Kundengruppen werden vorher ausgerechnet und bereitgelegt.
Beim Seitenaufruf wird nur schnell nachgeschaut —
die große Datenbank wird im Moment der Anzeige nie live gefragt.
Das Bild: eine Gästeliste, vorab geschrieben. Zielbild: der Adserver entscheidet die Anzeige — aber nur mit den Gruppen, die wir ihm vorab liefern. Der Schnellspeicher liefert die Gruppen und prüft die Einwilligung — entscheiden tut der Adserver. Ausgelegt auf Timings, Resilienz, Effizienz.
Schnell. Ausfallsicher. Mit Einwilligung. — Kurz noch, worauf der Plan steht: ↓
Worauf der Plan steht — und was ich mit euch prüfe.
Meine Annahmen
Adserver-API: Audience-Upload?Bezahlmodell — noch zu klären Auswahl trifft der AdserverGroßteil der Besucher anonymGesetzt (öffentlich): OBI nutzt Topsort (Adserver) & Decentriq (Datentresor). Meine Flanke ist die CDP-Anbindung dazwischen. Stimmt eine Annahme nicht, ändert sich der Weg — nicht die Idee.
Das würde ich mit euch klären
- Wie genau bekommt der Adserver die Kundengruppen?
- Wie stark zählt die Kundengruppe bei der Auswahl?
- Wie oft rechnet die CDP die Gruppen neu aus?
- Wie viele Besucher sind überhaupt eingeloggt?
Genug Annahmen — schauen wir es uns live an. ↓
Warum nicht einfach die große Datenbank jedes Mal live fragen?
Ein reiches Segment ist kein Standard-Feld im Adserver.
Der Adserver zielt von Haus aus auf Produkt, Kategorie, Suchwort, Region. „Renovierer, Garten-affin" muss ich aktiv reinbringen — dafür gibt es drei Wege:
A · Gruppe vorab syncen
Die Gruppe wird vorab als Zielgruppe im Adserver hinterlegt — im Aufruf zählt nur die ID, die OBI mitschickt. Schnell & skaliert — wenn die API einen Audience-Upload bietet.
B · Label pro Aufruf
Das Gruppen-Kürzel wird pro Anfrage als Zusatz-Schlüssel mitgegeben. Flexibel — wenn die Adserver-API es erlaubt.
C · Vorfilter in der Middleware
Die Middleware schränkt die Produkt-Kandidaten vor der Auktion ein. Mächtig, aber riskant für die Fill-Rate.
Meine Empfehlung — hängt an der Adserver-API: bietet sie einen Audience-Upload → Weg A; ist es eine reine Echtzeit-API ohne Speicher → Weg B als Default. In beiden Fällen wirkt die Gruppe als Booster, nicht als harter Filter — sonst bleibt der Platz leer. Genau das kläre ich früh mit dem Adserver-TPO.
Die ehrliche Kehrseite: drei Dinge gehen nicht vorher.
Einwilligung widerrufen
„Doch nicht" muss sofort wirken — Gruppe aktiv beim Adserver löschen.
Häufigkeit
Wie oft jemand die Anzeige sieht — sonst 20× dieselbe Werbung.
Budget
Wie viel schon verbraucht ist — sonst gibt eine Marke zu viel aus.
Diese drei zählt der Adserver live (der Adcontroller meldet zu; seltene Doppel-Anzeigen nehme ich bewusst in Kauf).
Und wenn etwas ausfällt? Eine Notfall‑Treppe:
Der Werbeplatz bleibt nie leer — kein Umsatz verschenkt.
Persönlich nur mit Erlaubnis — Daten bleiben bei OBI.
Erst fragen, dann zeigen
Vor jeder Nutzung wird die Einwilligung geprüft. Keine Einwilligung → keine persönliche Werbung, nur nach Suchwort. Onsite reicht die eigene Einwilligung; weitere Standards erst, wenn Werbung außerhalb von OBI dazukommt.
Keine echten Daten nach draußen
Name und Adresse verlassen OBI nie. Der Adserver bekommt nur eine anonyme Nummer + die Kundengruppe.
Der „Datentresor" (OBI nutzt: Decentriq)
Will OBI Daten mit einem Partner abgleichen, passiert das in einem abgeschotteten Raum: Keine Seite sieht die Rohdaten der anderen — es kommen nur anonyme Gesamt‑Ergebnisse raus.
Nicht alles auf einmal. Jede Stufe liefert messbaren Wert.
Stufe 1 · MVP (~6–8 Wochen)
Konkret: eine Gruppe (z. B. „Renovierer"), ein gesponserter Slot, Batch-Sync — end-to-end stabil. Einwilligung, Notfallplan, Messung ab Tag 1. Nutzt die bestehende Produkt-Feed-Pipeline wieder — Gruppen sind nur ein neuer Datentyp.
Ziel: stabiler Weg · kein leerer Werbeplatz · ~120 ms → erste SPA-UmsätzeStufe 2 · Echtzeit
Schnell wechselnde Gruppen in Echtzeit. Plus: wie oft gezeigt, Budget, Erfolg messen.
Ziel: Gruppen aktueller (Stunden → Minuten) → mehr Relevanz = bessere CTR/Conversion, ROAS messbarStufe 3 · Mehr
Datentresor für ähnliche Zielgruppen, Werbung auch außerhalb von OBI, und: online geklickt → im Laden gekauft.
Ziel: mehr Inventar/Reichweite (Display, Offsite) · Wirkung bis in den Laden · null DatenlecksWer treibt was: CDP-Team die Gruppen · Adserver-Team die Auktion · ich die Middleware, die Schnittstelle & die Tempo-/Stabilitäts-Ziele — die genaue Aufteilung auf der nächsten Folie.
Wer macht was — mit dem CDP‑ und dem Adserver‑Team.
Lesehilfe: verantwortlich = macht's / hat den Hut auf · gefragt = wird einbezogen, macht's nicht selbst · informiert = nur auf dem Laufenden
| Aufgabe | CDP‑Team | Adserver‑Team | Ich (dazwischen) |
|---|---|---|---|
| Kundengruppen festlegen & neu berechnen | verantwortlich | gefragt | gefragt |
| Middleware: übersetzen, Schnellspeicher, Ausfallschutz | gefragt | gefragt | verantwortlich |
| Adcontroller (Frontend‑Team): Einwilligung prüfen, Versteigerung anstoßen | informiert | gefragt | gefragt — Consent‑/Lookup‑Logik |
| Häufigkeit & Budget korrekt zählen | informiert | verantwortlich | gefragt |
| Tempo‑ & Stabilitäts‑Ziele | gefragt | gefragt | verantwortlich |
Wir einigen uns zuerst auf die Schnittstelle (wer liefert was, in welcher Form) — dann baut jedes Team parallel.
Schwere ML kaufen, die Datenschicht selbst besitzen.
Kaufen (Buy)
Adserver + Auktions-ML: Topsort (sub-50 ms). Integration in Wochen, nicht Jahren.
Selbst (Inhouse)
CDP, First-Party-Datenschicht, Consent/Governance, Middleware — genau die Schnittstelle, die ich owne.
Was andere messbar erreichen (Markt-Beleg, nicht meine Prognose für OBI): OTTO +49 % Retail-Media-Umsatz · Keyword-Targeting +120 % ROAS / +50 % CTR · Instacart/Schnucks 5,7× ROAS. Quellen: PPC Land, Supermarket Perimeter.
Ohne Messung weiß keiner, ob es funktioniert.
Läuft die Technik?
Wie schnell jeder Schritt ist
Wie oft etwas hängt / der Notfallplan greift
Wie oft der Schnellspeicher trifft
Match-Rate (Profil ↔ Adserver)
Bringt es Geld?
Fill-Rate (gefüllte Werbeplätze)
Inkrementeller Lift (iROAS), nicht nur ROAS
„hätte gepasst, kam aber nicht"
nur sichtbare Anzeigen zählen, Bots raus
So messe ich Erfolg — Beispiel: ROAS = Umsatz ÷ Werbekosten → 7.000 € ÷ 1.000 € = 7. Entscheidend ist aber der iROAS: nur der zusätzliche Umsatz (Test − Kontrolle) ÷ Kosten. Wären 2.000 € auch ohne Werbung gekommen, ist der echte Lift 5.000 € ÷ 1.000 € = iROAS 5 — gemessen über einen Holdout (Attributionsfenster 7–14 Tage, Signifikanz vorab geprüft). North-Star: inkrementeller €-Umsatz je Werbeplatz.
Effizienz: kein Over‑Engineering — eigener Schnellspeicher nur, wo Einwilligung/Notfallplan ihn rechtfertigen; eine Targeting‑Wahrheit (kein Doppel‑Speicher). Damit sind die drei geforderten Ziele abgedeckt: Timings · Resilienz · Effizienz.
Kurz: vorberechnen & pushen — der Adserver entscheidet, die Gruppe boostet.
Schnell · ehrlich messbar (iROAS) · ausfallsicher · mit Einwilligung. Offenes Risiko zuerst: Audience-Upload der Adserver-API. Ein erster Entwurf zum Ausprobieren.
Zum Ausprobieren scannen:
Einwilligung abschalten, Adserver ausschalten, zuschauen.
Mein erster Schritt im Job: einmal mit beiden Teams
zusammensetzen und die Schnittstelle gemeinsam festlegen.
Dominik Flieter · Fragen? Sehr gern →