Customer-specific Search: Wenn jeder Einkäufer ein anderes Sortiment sieht

In B2B-Implementierungen sehen wir immer dieselbe Schlüsselszene: Zwei Einkäufer öffnen denselben Shop, tippen denselben Suchbegriff — und sehen unterschiedliche Trefferlisten, unterschiedliche Preise, manchmal sogar unterschiedliche Produkte. Das ist kein Fehler im System, das ist die Anforderung. Im B2B definiert der Vertrag, welches Sortiment sichtbar ist; die Pricing-Engine, welcher Preis gilt; das ERP, welcher Bestand greift. Die Suche ist das Frontend, an dem diese drei Welten zusammenkommen müssen — synchron, performant und nachvollziehbar. In diesem Beitrag zeigen wir drei Implementierungs-Muster für kundenspezifische Suchindizes, wie Kontraktpreise sichtbar in Trefferlisten landen, und welche Sync-Strategien zwischen ERP, PIM und Suchindex tragen. Wer einen Schritt weiter zurück will — wie die Daten-Foundation in der B2B-Industrie aussieht, die solche Setups speist — findet das in der Serie Daten & Snowflake unter "Snowflake als Daten-Foundation für B2B-Industrie".

Wer kundenindividuelle Sortimente abbilden will, hat im Kern drei architektonische Optionen — und keine davon ist universell richtig. Die Wahl entscheidet sich an Sortimentsgröße, Anzahl der Kundengruppen, Vertragsdynamik und Performance-Budget.

Muster 1: Multi-Tenant-Indizes — ein Index pro Kundengruppe. Jede Kundengruppe (oder im Extremfall jeder Großkunde) erhält einen eigenen Index, der ausschließlich das für sie sichtbare Sortiment enthält. Der Vorteil: Eine Suchanfrage trifft nur den relevanten Index, ohne nachgelagerte Sichtbarkeits-Filter. Das skaliert in Performance — bis zur Index-Explosion. Wer mehrere tausend Kunden mit jeweils eigenem Sortiment hat, stößt schnell an die Grenzen der Cluster-Metadata, wie Elastic in seinem Leitfaden zu Multi-Tenancy mit Elasticsearch und OpenSearch ausführlich beschreibt.

Muster 2: Filtered Index — gemeinsamer Index mit Sichtbarkeits-Filter. Ein einziger Index enthält das Gesamtsortiment; jedes Produktdokument trägt eine Liste der berechtigten Kundengruppen, Business Units oder Vertragsnummern. Zur Suchzeit wird ein Filter-Prädikat ("visibility_groups contains $customerGroup") an die Query angehängt. Das skaliert in der Anzahl der Kunden problemlos, erkauft sich die Skalierung aber mit zwei Lasten: Jedes Produkt-Update muss alle berechtigten Kunden-Gruppen pflegen, und die Trefferlisten-Sortierung muss damit umgehen, dass für unterschiedliche Kunden unterschiedliche Subsets relevant sind.

Muster 3: Server-Side Re-Ranking. Die Suche liefert ein Roh-Result-Set; eine Re-Ranking-Schicht hinter dem Index entscheidet, welche Treffer für den angemeldeten Einkäufer sichtbar sind, in welcher Reihenfolge sie ausgespielt werden und welcher Preis daneben steht. Das Muster ist die flexibelste Option — es entkoppelt Entitlement-Logik vom Index — und gleichzeitig die kritischste in Latenz und Last. Wer hier baut, kauft sich Architektur-Freiheit zum Preis von Antwortzeiten, die unter Beobachtung gehören.

In B2B-Projekten bei foobar Agency sehen wir am häufigsten Mischformen: ein gemeinsamer Index für das Standard-Sortiment plus dedizierte Indizes für die zehn bis fünfzig größten Kunden mit stark individuellen Sortimenten. Das ist die Variante, die in den seltensten Fällen "elegant" ist — aber in den meisten Fällen trägt.

Sobald kundenspezifische Sortimente stehen, kommt die zweite, häufig schwierigere Frage: Welcher Preis steht neben dem Treffer? Im B2B sind Listenpreise eine fiktive Größe — was gilt, ist der Vertrag. Filter ("Preis aufsteigend"), Sortierung und das Vertrauen in die Trefferliste hängen direkt daran. Es gibt zwei tragfähige Architektur-Pfade.

Pfad A: Pre-Compute — Preise wandern in den Index. Kontraktpreise werden vorberechnet und kunden- oder kundengruppen-spezifisch in den Suchindex geschrieben. Die Trefferliste rendert in derselben Anfrage, in der sie auch die Produkte holt. Performance ist hervorragend; die Belastung verschiebt sich auf den Sync-Pfad. Bei tausenden Kunden mit individuellen Konditionen wächst der Index entsprechend, und jede Preisänderung im ERP erzeugt eine Welle von Re-Indexings. Algolia dokumentiert diesen Ansatz für B2B-Szenarien explizit über segment- oder buyer-spezifische Preisfelder; vergleichbare Patterns sind in Elastic-Setups gängig.

Pfad B: Live-Call zur Suchzeit — Preise aus der Pricing-Engine. Die Suche liefert nur die Produktinformationen; ein Pricing-Service oder das ERP wird zur Suchzeit angefragt und liefert die finalen Preise. Vorteil: kein Index-Bloat, immer aktuelle Preise. Nachteil: jeder Sucht-Request erzeugt einen synchronen Call gegen die Pricing-Engine — bei großen Trefferlisten mit Pagination ist das die Stelle, an der Latenzen kippen. In der Praxis wird dieser Pfad fast immer durch einen Caching-Layer entlastet, etwa Redis mit kurzer TTL pro Kunde-Produkt-Kombination.

Welcher Pfad trägt, hängt an drei Hebeln: Volatilität der Preise (ändern sich Kontrakte täglich oder quartalsweise?), Anzahl der Kunden mit individuellen Preisen, und die Anforderung an Echtzeit-Konsistenz (sieht der Einkäufer den Preis, der im Warenkorb fällig wird?). Eine valide dritte Option gibt es nicht: Listenpreise in der Suche zeigen und im Warenkorb korrigieren ist der schnellste Weg, das Vertrauen in den Shop zu verspielen.

Die Suche ist nur so gut wie der Sync, der sie speist. Drei Sync-Strategien stehen in B2B-Setups regelmäßig zur Wahl — sie unterscheiden sich in Latenz, Implementierungs-Aufwand und der Konsistenz, die sie garantieren können.

Event-driven Sync. ERP und PIM publishen Änderungen über einen Message-Broker (Kafka, RabbitMQ, AWS SNS/SQS); ein Consumer schreibt in den Suchindex. Latenz: typischerweise Sekunden bis sub-Minute. Voraussetzung: Die Quellsysteme können Events erzeugen — was bei modernen ERPs gegeben, bei älteren SAP-ECC-Setups oft nur über Middleware machbar ist.

Change Data Capture (CDC). Die Änderungen werden direkt aus den Transaktions-Logs der Datenbank gelesen — log-basiertes CDC mit Werkzeugen wie Debezium ist der Industriestandard. Latenz liegt im Sekunden- bis Minutenbereich, bei minimaler Belastung des Quellsystems. CDC ist die pragmatische Wahl, wenn die Quelle keine sauberen Domain-Events liefert, aber Sie nicht stundenweise nachhinken wollen. Die dbt-Labs-Übersicht zu Data-Movement-Patterns positioniert CDC explizit zwischen Batch und Streaming als das Muster, das in der Praxis am häufigsten trägt.

Batch / Scheduled Sync. Klassischer nächtlicher Full- oder Delta-Import. Latenz: Stunden bis Tage. Für stabile Stammdaten (Maße, Norm-Bezeichnungen, Konstruktions-Attribute) völlig ausreichend; für Preise und Bestände selten. Wer Bestände nur einmal pro Nacht synct, produziert Aufträge auf nicht mehr verfügbare Ware — das ist der Punkt, an dem die Suche das Vertrauen verliert, nicht das ERP.

In den meisten B2B-Implementierungen sehen wir eine Mischarchitektur: Batch für die Produkt-Stammdaten aus dem PIM (täglich, manchmal mehrfach), CDC oder Event-driven für Preise und Bestände aus dem ERP (sub-Minute). Welche Frequenz für welches Feld trägt, ist eine Entscheidung pro Feld — nicht pro System. Das gehört in die Architektur-Skizze, nicht in die Sprint-Backlog.

Cross-Link: Wenn diese Sync-Architektur über Snowflake als zentrale Daten-Plattform laufen soll — was wir bei B2B-Industrie-Kunden regelmäßig empfehlen — finden Sie die Vertiefung in der Serie Daten & Snowflake, Post 3 ("Snowflake als Daten-Foundation für B2B-Industrie").