Wir berechnen Relevanz statt sie zu definieren — und stellen damit den Kern von pxmize.ai vom Kopf auf die Füße.
Strategische Neuausrichtung der technischen Umsetzung. Context Handler als Herzstück, zweistufige Validierung, pragmatischer Daten-Pfad, archetyp-neutrale Architektur.
Erst das Herzstück validieren. Dann der erste Touchpoint. Dann jeder weitere. Am Ende: Enterprise.
Worum es geht
Die PXMIZE-Vision (Tailor-made Product Content über alle Touchpoints) ist tragfähig. Die heutige technische Umsetzung von pxmize.ai aber baut auf einer falschen Prämisse: sie rät Personas, definiert Criteria manuell und mappt deterministisch Kontext → Variante.
Dieses Konzept dreht die Logik um: ein Context Handler wird zum Herzstück der Architektur. Er nutzt brand-spezifische Repräsentationen, die aus realen Daten der Brand abgeleitet werden, und entscheidet je Request, welcher Content für die konkrete Situation am relevantesten ist.
Sequencing-Prinzip: Der Context Handler muss zuerst validiert werden — alles andere baut darauf auf. Funktioniert das Herzstück, expandiert pxmize.ai sukzessive entlang der Vision: erst PDP (Live A/B), dann weitere Touchpoints (Email, Ads, POS, Print), am Ende ein vollständiges Enterprise-Produkt. Kleiner Kern, ehrlich validiert, dann skaliert.
Validierung zweistufig: Phase A kombiniert quantitativen Holdout-Test mit qualitativem Brand-Team-Review. Phase B liefert den Live-A/B-Wertbeweis. Daten-Pfad zweistufig: pseudonymisierte Auszüge in pxmize-Cloud zum Start, Brand-Cloud-Deployment ab Phase B. Architektur archetyp-neutral entlang eines klaren Kerns und dünner Adapter.
Was am bisherigen Ansatz nicht passt
Der aktuelle pxmize.ai-MVP baut Funktionen entlang unstrukturierter, unvalidierter Annahmen:
- Generische Personas ("Jack Business", "Lisa Nature Lover") werden vordefiniert, ohne dass die Brand sie als ihre echten Kunden wiedererkennen muss.
- Criteria werden manuell konfiguriert und sind kombinatorisch starr.
- RACE / Redis-RTIM materialisiert ein deterministisches Mapping — skaliert nur, solange Variantenzahl klein bleibt.
- Variant Generation läuft batch-orientiert ohne Lernsignal aus realem Nutzungsverhalten.
- Validierung ist output-getrieben, nicht outcome-getrieben.
Konsequenz: man baut Features, von denen man glaubt, sie seien wichtig. Es gibt keinen Lernkanal, der diese Annahmen früh widerlegen oder bestätigen würde.
Drei Ziele dieses Konzepts
- PMF-Validierung — strukturiert lernen, für wen TMPC ein echtes Problem löst und welche Funktionen den Wert tragen.
- Demo-Fähigkeit — Format, das die Idee glaubwürdig transportiert.
- PoC mit 1–2 Brands — echte Daten, ehrliches Lernsignal.
Der Context Handler
Analogie als Leitbild, nicht als Implementierung
Die Attention-Mechanik aus Transformer-Modellen ist eine nützliche konzeptuelle Analogie: Kunden-Kontext (Query) und Produkt-Kontext (Key/Value) als Repräsentationen, Relevanz wird berechnet statt vordefiniert.
Wichtig: das ist ein Leitbild, kein Implementierungs-Versprechen. Die tatsächliche Realisierung im PoC ist pragmatischer:
- PoC-Substrat: Vector-Retrieval (Embeddings für Kunden- und Produkt-Repräsentationen in gemeinsamem Raum) + LLM-Rerank/Reasoning für die finale Auswahl.
- Mittelfristig (Phase B+): Learned Ranking auf Basis realer Konversions-/Klick-Signale.
- Echte Attention-/Two-Tower-Modelle: Erweiterungsoption, kein Tag-1-Bestandteil.
Was der Context Handler ist (und was nicht)
Ist: Eigenständige Komponente, die je Request entscheidet, welche Variante (vorgeneriert oder on-the-fly) für die konkrete Kunden-Situation am relevantesten ist. Brand-spezifisch in der Repräsentation. Architektur-Kern, von dem alles andere abhängt.
Ist nicht (bewusst): Kein vollständig "self-learning"-Modell im engeren Sinn. PoC ist Bootstrap-Learning aus historischen Daten (einmalige Repräsentations-Ableitung). Online-Learning kommt erst in Phase B+.
Erklärbarkeit als Pflichtteil
Brand-Akzeptanz erfordert, dass das System erklären kann, warum eine Variante gewählt wurde. Konkret zwei Mechanismen:
- Retrieval-Citations: pro Variant-Entscheidung werden die zugrunde liegenden Repräsentations-Treffer mitgeliefert (z. B. "Kunde gehört zu Segment X mit Affinität Y zu Produkt-Eigenschaft Z").
- Signal-Attribution: welche Kontext-Signale den Ausschlag gegeben haben, wird als kompakte Liste mitgeliefert.
RAG ist natürlich erklärbar — retrieved Documents sind sichtbar. Diese Erklärungs-Daten fließen in Approval-Workflow, Insights UI und optional in den Endkunden-Touchpoint.
Erst das Herzstück. Dann die Touchpoints. Dann Enterprise.
Der Context Handler ist nicht eine Komponente unter vielen — er ist die Komponente, deren Funktionieren über die Lebensfähigkeit des gesamten Produkts entscheidet. Daraus folgt eine investitionsrationale Build-Order.
- Wenn Phase A nicht trägt, ist alles Weitere Geldverbrennung — daher zuerst dort validieren.
- Wenn Phase B trägt, haben wir gleichzeitig den Wertbeweis und den ersten produktreifen Touchpoint — die Basis, von der wir uns finanzieren und weiterentwickeln.
- Jedes weitere Touchpoint-Tier ist eine Erweiterung des gleichen Kerns, kein Neubau.
- Kein Wasserfall — innerhalb jeder Phase wird iterativ gearbeitet.
- Keine starre Roadmap — Phasen-Reihenfolge ist Logik, nicht Vertrag.
- Keine Touchpoint-Stapelung um ihrer selbst willen — jeder weitere TP muss seinen Business-Value zeigen, sonst priorisieren wir um.
Architektur, Datenstrategie, Validierung und Roadmap in diesem Konzept folgen dieser Build-Order. Wenn an irgendeiner Stelle eine Entscheidung getroffen werden muss, ist die Default-Frage: „Trägt das den Context Handler zuerst?" Alles andere kommt danach.
Lernschleifen & Data Residency
Zwei Lernschleifen sauber getrennt. Ein zweistufiger Daten-Pfad, der den Setup-Widerspruch auflöst.
Zwei Schleifen
Offline, einmalig pro Brand, mit periodischem Re-Run
- Input: Orders, Customer-Master, Web-Analytics (90+ Tage), Produktkatalog, optional Reviews/Newsletter
- Output: brand-spezifische Embeddings, Segmente, Affinitäten, Persona-Hypothesen
- Zweck: Kaltstart vermeiden — Tag 1 hat das System brand-spezifische Struktur
- Wiederholung: alle paar Wochen, nicht kontinuierlich
Kontinuierlich, erst in Phase B+ scharf
- Input: Clicks, Konversionen, Dwell, A/B, Approval/Rejection
- Output: Re-Ranking-Updates, Counterfactual-Learning für Variant-Auswahl
- Zweck: Modell wird über Zeit besser ohne erneute Bootstrap-Runs
- Status PoC: Infrastruktur vorhanden, Loop deaktiviert
Realitätscheck Datenquellen
Für den ICP (Tier 1 × Mid-Market) gilt: Order-Daten allein sind ein schwaches Signal. Niedrige Wiederkaufsfrequenz (Miele alle 10 Jahre, Bogner saisonal, Specialized alle 5 Jahre) erzeugt viele "Customer = 1 Order"-Cases ohne lernbare Struktur. Das eigentliche Relevanzsignal sitzt prä-Konversion.
Orders + Customer-Master + 90 Tage Web-Behavior (GA4-Export oder gleichwertig). Reine Order-CSV reicht nicht.
Data Residency — zweistufiger Pfad
Hier wird der Setup-Widerspruch ("schneller PoC vs. Brand-Cloud") bewusst aufgelöst:
Brand exportiert pseudonymisierte Daten-Auszüge (PII durch Hash ersetzt). Verarbeitung in pxmize-Cloud unter DPA.
- Setup-Zeit: Tage
- Geringe Friction
- Ausreichend für PMF-Validierung
- Sales-Material: "so schnell kommen wir ins Lernen"
Bootstrap-Trainer und Inferenz-Stack in Brand-Account deployed. Daten verlassen die Brand-Zone nicht mehr.
- Setup-Zeit: Wochen bis Monate
- Erforderlich bei strikter Residency-Policy
- Identische Komponenten wie Stufe 0
- Enterprise-Material: "läuft auch in eurer Cloud"
Methoden-Wahl (PoC-Substrat)
- Customer- und Produkt-Embeddings (Off-the-shelf: Sentence-BERT, OpenAI, Voyage) auf Produkttexten und aggregierten Verhaltens-Repräsentationen.
- Vector-Store für Retrieval (pgvector, Qdrant, Pinecone — je nach Stufe).
- LLM-Rerank / Generation mit Retrieval-Citations als Erklärungs-Output.
- Klassische Segmentation (RFM, k-means auf Embedding-Clusters) als ergänzendes, leicht erklärbares Layer.
Echtes Fine-Tuning, eigene Embedding-Modelle, Two-Tower-Architekturen — explizit nicht PoC-Bestandteil.
Zwei Stufen, beide methodologisch sauber
Frage: Erkennt unser System echte, vorhersagestarke Struktur in den Brand-Daten?
Zwei parallele Validierungs-Pfade — nicht nur qualitatives Bauchgefühl:
- Quantitativ — Holdout-Test gegen historische Daten. Zeitlicher Split (75/25). System lernt auf Trainings-Daten, macht falsifizierbare Vorhersagen auf Holdout. Gegen Random-Baseline und Heuristik-Baseline gemessen. Lift muss messbar sein.
- Qualitativ — Brand-Team-Review. Rated Segmente, Persona-Hypothesen, PDP-Beispiele. Nicht "ja/nein/teilweise", sondern welche Aspekte anschlagen — mildert Confirmation Bias.
Kein Live-Deployment auf PDP nötig.
Frage: Führt erkannte Relevanz zu echtem Business-Value?
- Input: validierte Phase-A-Repräsentationen + Live-Traffic
- Processing: Context Handler entscheidet per Request
- Output: A/B-Test gegen Status-quo-Content auf ausgewählten PDPs
- Validierung: Conversion-Uplift, AOV, Engagement — quantitativ
- Aufwand inkl. Brand-Cloud-Deployment, Touchpoint-Integration, Approval-Workflow, statistische Signifikanz-Wartezeit
Architektur muss so gebaut sein, dass die Bootstrap-Pipeline aus A die gleichen Repräsentationen erzeugt, die in B online serviert werden. Kein Re-Build, nur Aktivierung des Online-Inferenz-Pfads + Touchpoint-Integration.
ICP & Archetypen
Primärer ICP nach Y1-Matrix: Tier 1 × Mid/Upper Mid Market. Innerhalb dessen zwei radikal verschiedene Archetypen — die gleiche Engine bedienen kann.
Sweet Spot: Tier 1 × M bis L, Online-Umsatz ~10–100 Mio EUR. Komplexes Produktdatenmodell, hoher Conversion- und PX-Fokus, emotionale UX. Schnellere Entscheidungswege als Enterprise.
Zwei Archetypen innerhalb Tier 1
Bogner, Specialized, Miele, Villeroy & Boch, Everdrop, MYCS
- Kontext-Signale: Lebenswelt, Stimmung, Use-Occasion, Saison, Lookbook
- Match-Logik: emotional/aspirational, semantisch reich, viel Unstructured
- Datenstärke: Browse-Pfade, Wishlist, Newsletter-Engagement
Festo, Maxon, Liebherr, Bosch Industrial, Baumer, Fischer
- Kontext-Signale: Anwendungsfall, technische Spec, Industrie, Account-Firmographics
- Match-Logik: funktional/spec-getrieben, hoch strukturiert
- Datenstärke: Konfigurator-Sessions, RFQ, Datenblatt-Downloads
Archetyp-Neutralität — was das konkret heißt
Eine Engine für beide Archetypen funktioniert nur, wenn klar getrennt wird zwischen Kernel und Adapter:
- Kernel (gemeinsam): Embedding-Store, Retrieval-Engine, LLM-Rerank/Generation, Approval-Workflow, Insights UI, Online-Loop-Infrastruktur. Identisch über beide Archetypen.
- Repräsentations-Adapter (archetyp-spezifisch): bestimmt, wie Kunden- und Produkt-Repräsentationen aufgebaut werden.
- α-Adapter: textreich, lifestyle-orientiert, gewichtet Verhaltens-Pfade hoch.
- β-Adapter: spec-orientiert, gewichtet strukturierte Attribute und Firmographics hoch.
Adapter sind dünn (Input-Formatierung, Source-Selection, Prompt-Templates), nicht ganze Pipelines. Großteil der Engine bleibt wirklich gemeinsam.
Ziel-Architektur & Reuse-Entscheidungen
Zwei Deployment-Zonen, identische Komponenten. LLM-Hosting und Online-Loop explizit gemacht.
Komponenten-Übersicht
LLM-Hosting — pro Brand entschieden
- API-Provider (Anthropic, OpenAI): schnell, mit DPA. Stufe-0-Default.
- Self-hosted in Brand-Cloud (z. B. Llama-3, Qwen auf Brand-GPU): für strikte Residency.
- pxmize-gehosteter Pool: für Stufe 0, falls Brand keine API-Provider akzeptiert.
Entscheidung pro Brand im Onboarding. Vom Architektur-Kern entkoppelt — Inference Endpoint abstrahiert das LLM-Backend.
Online-Feedback-Loop
STRIVE-Events (Clicks, Konversionen, Dwell, Approvals) landen im Feedback Store. In Phase B periodisch verarbeitet: Re-Ranking-Update + Re-Embedding-Trigger bei ausreichendem Datenvolumen. Loop ist in Phase A vorhanden, aber inaktiv.
Reuse vs. Rebuild
| Komponente | Heute | Entscheidung |
|---|---|---|
| Variant Generation | LLM-PCV aus Personas + Criteria | Reuse Context-Handler-getrieben |
| Target Manager | Publiziert zu RACE | Retire Rolle → Asset-Publisher |
| RACE / Redis RTIM | Deterministisches Mapping | Retire optional Cache-Layer |
| pxmize.js | Touchpoint-Injection | Reuse Endpoint wechselt |
| STRIVE | Event-Tracking | Reuse Feedback Store für Phase B |
| Cloudinary | DAM / CDN | Reuse agnostisch |
| Onedot | Produktdaten-Transform | Reuse Katalog-Ingest |
| aiuno | Conversational Commerce | Defer Phase 3+ |
| Personalisation Manager UI | Persona/Criteria-Verwaltung | Retire → Insights-Explorer |
Approval-Workflow ist Pflichtteil, nicht Bonus. Generierte Varianten gehen niemals ungeprüft live. Brand-Voice-Guardrails sind Teil der Repräsentation, nicht nur ein Prompt-Suffix. Override-Möglichkeit pro PCV ab Tag 1.
Demo — separat vom PoC, mit Wow-Moment
Eine Demo pro Archetyp. Interaktiv. Mit Erklärungs-Panel. Plus „Bring your own catalog"-Modus für Sales-Calls.
Zweck
Die Demo macht in 5–10 Minuten zwei Dinge greifbar:
- Kontext-Wirkung: ändere ich Kunden-Kontext, ändert sich die Product Experience nachvollziehbar.
- Erklärbarkeit: ich sehe, warum sich was geändert hat — nicht als Magic-Box.
Demo α — B2C Premium-Lifestyle
Beispiel: fiktive E-Bike-Brand „RIDGEFORM". 4–6 Produkte aus öffentlichem Katalog.
Demo β — B2B High-Tech
Beispiel: fiktiver Sensor-Hersteller „NORDLINE Industrial". 4–6 Produkte aus Industrie-Katalog.
Bonus-Modus: "Bring your own catalog"
Für PXM-Days und Sales-Calls mit hohem Wow-Bedarf:
- Sales-Person gibt eine Produkt-URL ein (z. B. von der Brand-Webseite des Prospects).
- Demo scrapet 3–5 Produkte (über Onedot-light oder simple Headless-Browser-Funktion).
- Bootstrap-Run-Light (vereinfacht: nur Produkt-Embeddings, generische Personas) — innerhalb von 30–60 Sekunden.
- Anschließend interaktive α-style Personalization auf deren Katalog.
"Wir haben eure Produkte gerade gelesen und können jetzt zeigen, wie wir Kontext darüber legen würden."
Tech-Architektur Demo
Single-Page-App · Vanilla JS oder Solid/React · schlank, kein Build-Schwergewicht
Cloudflare Worker oder Hono/FastAPI · LLM-Calls via Anthropic / OpenAI
Statische JSON-Kataloge · In-Memory Vector-Store · kein Persistenz-Layer
Was die Demo nicht ist
- Kein Persistenz, keine User-Accounts, keine echten Brand-Daten.
- Kein Beleg für Phase-A-Validität — sie ist Storytelling, nicht Evidenz.
- Kein Vorgriff auf das PoC-UI — Demo darf vereinfachen, wo PoC-UI Vollständigkeit braucht.
Phasen-Skizze, realistische Zeiten
Zeitliche Übersetzung des Sequencing-Prinzips aus §02bis: erst Herzstück validieren, dann Touchpoint-für-Touchpoint expandieren.
- Konzept finalisieren, Stakeholder-Alignment
- Demo-Konzept ausdetaillieren (dieses Doc)
- Ziel-Brand-Liste mit Y1 priorisieren
- Demo (eine pro Archetyp) lauffähig
- "Bring your own catalog"-Modus implementiert
- Bootstrap-Trainer-Skelett (Stufe 0, pxmize-Cloud)
- Erste Discovery-Calls mit Pilot-Brand-Kandidaten
- 1–3 Pilot-Brands ausgewählt
- Daten-Ingest via pseudonymisiertem Auszug
- Bootstrap-Run, Holdout-Test, Insights-Report
- Brand-Team-Validierung, Iteration
- Brand-Cloud-Deployment vorbereiten und ausrollen
- pxmize.js Touchpoint-Integration, STRIVE-Event-Loop, Approval-Workflow
- A/B-Test auf ausgewählten PDPs
- Business-Value-Messung
- Online-Learning-Loop scharf
- Weitere Touchpoints (Email, POS, Ad)
- Commercial Model finalisieren
Nicht in diesem Konzept entschieden
- ML-Methoden-Detail pro PoC — konkrete Embedding-Modelle, Vector-Store-Auswahl, Cluster-Verfahren — pro Brand entschieden.
- Brand-Cloud-Deployment-Format (Stufe 1) — Container vs. Clean Room vs. Helm — beim ersten Stufe-1-Pilot entschieden.
- Online-Learning-Mechanik im Detail — Bandit vs. Re-Ranking-Update, Re-Embedding-Frequenz — vertagt bis Phase B konkret.
- Pricing-Modell — orthogonal zur Architektur, parallel von Sales/PM.
Direkt anschließend
- Review dieses Konzepts (v1, korrigierte Fassung).
- Brand-Kandidaten-Shortlist mit Y1 erstellen (Tier 1 × M/M-L, je 3–5 für α und β).
- Implementation Plan für Phase 1 (Demo + Bootstrap-Trainer-Skelett) schreiben.
- Cloudflare Pages Deployment dieses Doc-Sites für Stakeholder-Sharing.