Blog | foobar Agency

Gartner Magic Quadrant 2026: Was er für Ihre Plattformentscheidung bedeutet

Matthias Dietrich — Mon, 26 Oct 2026 00:00:00 GMT

Gartner hat den Magic Quadrant für Digital Commerce neu aufgelegt, und viele CIOs und CDOs stellen sich gerade dieselbe Frage. Ändert der neue Quadrant etwas an unserer Plattformentscheidung? Unsere Einschätzung ist, dass er bestehende Entscheidungen selten in Frage stellt. Er verschiebt aber deutlich die Kriterien, an denen Sie Ihre Plattform in den nächsten zwei bis drei Jahren messen sollten.

Gartner hat 2026 vor allem die Spielregeln geändert. Neu ist, welche Anbieter überhaupt aufgenommen werden und welchen Funktionsumfang eine Plattform mitbringen muss. Wer die neuen Positionen richtig lesen will, braucht deshalb zuerst den Blick auf diese Regeln.

Was sich gegenüber 2025 geändert hat

2025 waren fast alle Bewertungskriterien hoch gewichtet. 2026 konzentriert Gartner das Gewicht auf Produkt, Wirtschaftlichkeit, Preisgestaltung, Marktverständnis und Innovation, während Kundenerlebnis, Marketing- und Vertriebsstrategie nur noch mittel zählen. Die größten Veränderungen liegen aber in der Marktdefinition, im Pflichtumfang und in den Aufnahmekriterien.

Aspekt	2025	2026
Titel des Reports	Digital Commerce	Digital Commerce Platforms
Käufer laut Definition	Kunden	Kunden und KI-Agenten
Pflichtfunktionen	Storefront bis Checkout, Preisberechnung, Business-Tooling, API-Interoperabilität	zusätzlich Digital Experience Composition, Personalisierung, Low-/No-Code-Integration, B2B-Grundfunktionen (Berechtigungen, Einkaufsorganisationen, Angebote, Bestellnummern) und Post-Purchase (Bestellstatus, Sendungsverfolgung, Retouren)
Neu als optional		KI-Agenten und Copilots, Anbindung externer Agenten über MCP, Digital Sales Rooms
Entfallen		Live Commerce, Einbindung von Verkaufsmitarbeitern, Basis-PIM
Aufnahmekriterium	Softwareumsatz zwischen 28 und 65 Mio. US-Dollar mit Wachstumsanforderungen	mehr als 70 Kunden im Produktivbetrieb, mindestens 10 Neukunden im Jahr 2025, Relevanz für Gartner-Kunden nach Einschätzung der Analysten
Regionale Verteilung gemessen an	Umsatz	Kundenzahl
Bewertete Anbieter	19	14
Honorable Mentions	Baozun, Liferay, Ultra Commerce	Centra, Commerce Layer, DJUST, Emporix, PrestaShop

Als zentrale Kriterien für Käufer nennt Gartner 2026 drei Punkte. Das sind die Bereitschaft für agentische KI, eine flexible Architektur und nachgewiesene Skalierbarkeit für B2B und B2C auf einer gemeinsamen Plattform.

Neue Positionen spiegeln vor allem neue Regeln

Wenn ein Anbieter 2026 an anderer Stelle steht als 2025, liegt das oft am veränderten Feld. Mit fünf Anbietern weniger verschieben sich die relativen Positionen, auch wenn sich an den Produkten selbst wenig geändert hat.

Dazu kommt der Wechsel vom Umsatz zur Kundenzahl. Ab 2026 zählt die Zahl der Abschlüsse mehr als ihre Größe. Das dürfte erklären, warum WooCommerce neu im Quadranten ist, während Sana, Infosys Equinox, Virto, Elastic Path und HCL nicht mehr enthalten sind. Außerdem steht die Einschätzung der Analysten jetzt an erster Stelle der Aufnahmekriterien und hat damit offiziell mehr Gewicht.

Für Sie als Betreiber heißt das Folgendes. Eine Plattform, die vor einem Jahr gut zu Ihren Prozessen gepasst hat, passt heute genauso gut. Ein Abstieg im Quadranten ist ein Anlass, genauer hinzusehen. Ein Grund für einen Plattformwechsel ist er allein selten.

Agentic-Readiness an dem messen, was heute läuft

Gartner nimmt KI-Agenten erstmals als Käufer in die Marktdefinition auf. Eine Plattform soll Kunden und Agenten gleichermaßen ermöglichen, einzukaufen. Damit gewinnen Roadmap und agentische Fähigkeiten an Gewicht, während Kundenerlebnis und Marktumsetzung relativ an Bedeutung verlieren.

Wie stark sich der Blick verschoben hat, zeigt die Gewichtung. Das Kundenerlebnis, in das die Zufriedenheit von Referenzkunden einfließt, zählt 2026 nur noch mittel statt hoch. Gleichzeitig ist ein Teil der agentischen Funktionen, die Gartner positiv wertet, nach Angaben der Anbieter selbst noch in der Beta-Phase oder auf der Roadmap.

Deutlich wird auch, welche Art von KI zählt. Ein Anbieter wurde abgestuft, weil seine KI-Investitionen überwiegend Werkzeuge für Entwickler sind. Als Readiness wertet Gartner Agenten und Schnittstellen, die beim Kunden ankommen.

Die Richtung halten wir für richtig. Im Handelsalltag sehen wir aber ein anderes Tempo. Agenten, die selbstständig im Namen von Endkunden einkaufen, sind heute noch die Ausnahme. Messbaren Nutzen stiften Agenten bereits intern, etwa in der Auftragsbearbeitung, im Kundenservice und in der Datenpflege, sowie in B2B-Prozessen wie Nachbestellung und Angebotserstellung. Wie es nach einem Jahr um den Checkout im Chatbot steht, besprechen wir im Podcast in der Folge Ein Jahr Agentic Commerce: Gibt es was zu feiern?.

Deshalb empfehlen wir, Agentic-Readiness an konkreten Punkten zu prüfen. Entscheidend sind offene Schnittstellen, ein sauberer Datenzugriff auf Produkte, Preise und Bestände sowie die Möglichkeit, eigene Agenten über Standards wie MCP anzubinden. Eine Plattform, die das heute kann, ist für die agentische Zukunft gut aufgestellt, unabhängig davon, was auf der Roadmap-Folie steht.

KI-Kosten und B2B-Automatisierung werden zum Maßstab

Die Kritikpunkte, die Gartner bei den einzelnen Anbietern nennt, zeigen deutlicher als die Gewichtungstabellen, woran Plattformen 2026 gemessen werden. Drei Themen stehen im Vordergrund.

Das erste sind die Kosten für KI-Funktionen. Bei mehreren großen Anbietern bewertet Gartner token- oder nutzungsbasierte KI-Zusatzmodule ausdrücklich als Kostenrisiko. Was in der Demo überzeugt, kann im Vollbetrieb die Gesamtkostenrechnung spürbar verändern.

Das zweite ist die Automatisierung im B2B-Vertrieb. Als Maßstab gelten jetzt KI-Funktionen, die Bestellungen aus unstrukturierten Dokumenten wie PDFs und E-Mails übernehmen und bei Angeboten mitverhandeln. Für Industrie und Großhandel ist das der greifbarste Punkt im ganzen Report. Die manuelle Auftragserfassung bindet in vielen Innendiensten viel Kapazität, und genau dort senkt KI heute schon Kosten und verkürzt Durchlaufzeiten.

Das dritte sind offene Protokolle. Unterstützung für Standards wie MCP, ACP und UCP, über die Agenten mit einer Plattform kommunizieren, wertet Gartner als Stärke.

Der breitere Pflichtumfang stärkt Composable-Architekturen

Mit Digital Experience Composition, Personalisierung, B2B-Grundfunktionen und Post-Purchase als Pflicht liegt die Messlatte für eine Plattform deutlich höher. Ein reiner Commerce-Kern erfüllt die Definition kaum noch.

Unternehmen haben damit zwei Wege. Sie setzen auf eine große Suite, die alles aus einer Hand liefert. Oder sie verbinden spezialisierte Komponenten zu einer Plattform, die genau zu ihren Prozessen passt. Die neuen Honorable Mentions zeigen, dass Gartner den zweiten Weg ernst nimmt. Mit Commerce Layer, Emporix und DJUST sind dort mehrere API-first-Anbieter vertreten, die stark auf MCP setzen. Die Gruppe ist zudem deutlich europäischer als im Vorjahr.

Für Unternehmen im DACH-Raum mit gewachsenen Systemlandschaften ist das eine gute Nachricht. ERP, PIM und Datenplattform bleiben, wo sie sind, und die Commerce-Plattform wächst um die Funktionen, die Gartner jetzt voraussetzt. Der Aufwand verschiebt sich dabei von der Lizenz zur Integration. Genau dort entscheidet sich, ob eine Composable-Plattform ihre Vorteile ausspielt.

Gartner legt dabei einen strengen Maßstab an. Funktionen, die nur über Drittlösungen verfügbar sind, rechnet der Report Composable-Anbietern weiterhin als Schwäche an. 2025 betraf das CMS und Personalisierung, 2026 vor allem KI-Assistenten in der Storefront.

Zugleich beschreibt der Report zwei Entwicklungen nebeneinander, den anhaltenden Trend zu Composable und eine Konsolidierung hin zu Komplettsuiten. Die Architekturentscheidung nimmt Ihnen der Quadrant damit nicht ab. Sie hängt an Ihren Prozessen, Ihrer Systemlandschaft und daran, wie gut die Komponenten miteinander verzahnt sind.

Sechs Fragen für Ihre nächste Plattformprüfung

Der Quadrant liefert eine gute Marktorientierung. Die Entscheidung für Ihr Unternehmen beantworten diese sechs Fragen genauer.

Welche der neuen Pflichtfunktionen deckt Ihre Plattform heute ab, und welche brauchen Sie tatsächlich für Ihr Geschäft?
Wie sind KI-Funktionen in Ihrem Vertrag bepreist, und was kosten sie bei voller Nutzung über die gesamte Laufzeit?
Können eigene oder externe Agenten heute auf Produkte, Preise, Bestände und Bestellungen zugreifen, zum Beispiel über MCP?
Bilden Sie B2B und B2C auf einer gemeinsamen Plattform ab, oder betreiben Sie dieselben Funktionen doppelt?
Wo bindet Ihre Plattform heute den größten Teil von Budget und Teamkapazität, und würde ein Wechsel daran etwas ändern?
Wie schnell können Sie eine neue Funktion wie die automatische Erfassung von Bestellungen oder einen Service-Agenten live bringen?

Unser Fazit

Der Magic Quadrant 2026 beschreibt eine Commerce-Plattform, die mehr kann als verkaufen. Sie gestaltet Erlebnisse, bedient B2B und B2C gemeinsam und öffnet sich für Agenten. Diese Richtung deckt sich mit dem, was wir in Projekten mit Handels- und Industrieunternehmen sehen.

Wer die Positionen im Quadranten als Rangliste liest, zieht schnell falsche Schlüsse. Wer die neuen Kriterien als Prüfliste für die eigene Plattform nutzt, gewinnt einen klaren Plan für die nächsten Ausbaustufen. Gern sprechen wir mit Ihnen darüber, wo Ihre Plattform heute steht und welche Schritte sich für Ihr Geschäft lohnen.

Grundlage dieses Beitrags sind die Gartner-Reports „Magic Quadrant for Digital Commerce“ (2025) und „Magic Quadrant for Digital Commerce Platforms“ (2026). Die Einordnung gibt die Einschätzung von foobar Agency wieder.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/gartner-magic-quadrant-2026-digital-commerce-plattformentscheidung

Gartner Magic Quadrant 2026: Agentic Commerce mischt die Plattformen neu

What Works Tomorrow — Fri, 23 Oct 2026 16:53:16 GMT

Der neue Gartner Magic Quadrant für Digital Commerce ist da, und er sieht deutlich anders aus als im Vorjahr. Statt 19 Anbietern sind nur noch 14 drin, einige große Namen sind ganz rausgefallen, und agentische Fähigkeiten zählen plötzlich zu den wichtigsten Bewertungskriterien.

Matthias Dietrich und Philipp Krueger ordnen ein, was sich verändert hat. Philipp hat den Prozess selbst als Hersteller durchlaufen und erzählt, wie man überhaupt in den Quadranten kommt, was das kostet und warum ein Platz dort nicht zu kaufen ist. Dazu kommt die Frage, warum Gartner in diesem Jahr kein Umsatzziel mehr ansetzt und was das für das Teilnehmerfeld bedeutet.

Danach geht es um die Bewegungen im Quadranten: SAP, Spryker, Shopify, Shopware, WooCommerce und die deutschen Anbieter. Als commercetools-Partner schauen die beiden genauer hin, was von den Agentic-Initiativen schon nutzbar ist und was erst auf der Roadmap steht. Das führt zu einem Punkt, der nachdenklich macht. Bewertet Gartner in diesem Jahr stärker Roadmaps als das, was heute live ist?

Zum Schluss wird es praktisch. Was sollte ein CIO oder CDO mit dem Magic Quadrant anfangen, und welches neue Kostenrisiko hat Gartner bei KI-Funktionen identifiziert?

What Works Tomorrow. Der Podcast für Entscheider in Handel und Industrie. Von Matthias Dietrich und Philipp Krueger, Co-CEOs der foobar Agency.

#GartnerMagicQuadrant #AgenticCommerce #commercetools #eCommerce #WhatWorksTomorrow

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/gartner-magic-quadrant-2026-agentic-commerce-mischt-die-plattformen-neu

Warum KI-Projekte an der Datenarchitektur scheitern

What Works Tomorrow — Mon, 19 Oct 2026 19:01:11 GMT

Viele KI-Piloten starten vielversprechend und landen nach ein paar Monaten in der Schublade. Gartner erwartet, dass Unternehmen bis Ende 2026 rund 60 Prozent der KI-Projekte aufgeben, die nicht auf KI-tauglichen Daten beruhen. Matthias Dietrich und Philipp Krueger sprechen darüber, was eine Datenarchitektur leisten muss, damit KI im Betrieb funktioniert, und welche Rolle das Data Lakehouse dabei spielt.

Der Weg führt vom Data Warehouse, das einmal im Monat einen Report liefert, über den Data Lake zum Data Lakehouse, das Daten im laufenden Betrieb nutzbar macht. An Beispielen aus Handel und Industrie zeigen die beiden, wie Kundenwert und Margen in Suche, CMS und Warenkorb einfließen. Talk to your Data ersetzt dabei den Report, der wochenlang im Sprint wartet. Philipp erzählt von einem Projekt, in dem dasselbe Produkt je nach Abteilung einen anderen Deckungsbeitrag hatte. Für ein KI-Modell bleibt das ein Problem, solange sich Finanzen, Einkauf und Vertrieb nicht auf eine Definition geeinigt haben.

Zum Schluss wird es praktisch. Wie startet ein Unternehmen, bei dem ERP, PIM, CRM, Shop und Kasse jeweils eigene Daten halten? Welche Quellen gehören an den Anfang, und wie werden Produkt, Kunde und Auftrag einheitlich definiert? Und warum lohnt es sich, mit einer konkreten Fachfrage und einem ersten Fachbereich zu beginnen?

Passend zur Folge ist bei Springer Professional der Artikel „KI-Projekte scheitern häufig an der Datenarchitektur“ von Matthias Dietrich erschienen. Am Beispiel eines Omnichannel-Händlers zeigt er, wie ein einfacher Vergleichswert eine festgefahrene Retourenprognose in den Betrieb gebracht hat.
Zum Artikel bei Springer Professional

What Works Tomorrow. Der Podcast für Entscheider in Handel und Industrie. Von Matthias Dietrich und Philipp Krueger, Co-CEOs der foobar Agency.

#KI #Datenarchitektur #DataLakehouse #eCommerce #WhatWorksTomorrow

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/warum-ki-projekte-an-der-datenarchitektur-scheitern

Ein Jahr Agentic Commerce: Gibt es was zu feiern?

What Works Tomorrow — Mon, 28 Sep 2026 13:08:51 GMT

Vor einem Jahr hat OpenAI das Agentic Commerce Protocol vorgestellt. Google, Stripe, Mastercard und Visa zogen mit eigenen Protokollen nach, und die Erwartung war klar: Kunden kaufen künftig direkt im Chatbot. Matthias Dietrich und Philipp Krueger ziehen Bilanz. Was wurde versprochen, was ist tatsächlich live, und wohin hat sich der Markt seitdem bewegt?

In dieser Folge:
- Warum der Checkout im Chatbot bisher nicht funktioniert: Verfügbarkeit, Preiszusagen, Rabattcodes, fehlendes Up- und Cross-Selling und die Frage nach Vertrauen
- Cart-Handover: Wie OpenAI und Google den Kauf zurück zum Händler geben
- Product Discovery über LLMs wächst weiter und bringt Traffic mit hoher Kaufabsicht
- Was Händler und Hersteller jetzt tun sollten: saubere Daten, kuratierte Sortimente, Accessibility und eine Architektur, die nicht von einem einzigen Protokoll abhängt
- Warum Warenkorb, Checkout und Kundenbindung neu gedacht werden müssen, wenn die Customer Journey erst dort beginnt

Und am Ende die Antwort auf die Eingangsfrage: Gibt es nach einem Jahr etwas zu feiern?

What Works Tomorrow. Der Podcast für Entscheider in Handel und Industrie. Von Matthias Dietrich und Philipp Krueger, Co-CEOs der foobar Agency.

#AgenticCommerce #KI #eCommerce #WhatWorksTomorrow

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/ein-jahr-agentic-commerce-gibt-es-was-zu-feiern

Agentic Commerce: Warum der KI-Checkout am Handwerk scheitert

What Works Tomorrow — Tue, 25 Aug 2026 15:47:16 GMT

Vor einem Jahr sollte der Einkauf in ChatGPT stattfinden. Inzwischen hat OpenAI den Checkout zurückgestellt — und der Grund dafür ist keine fehlende Technologie.

Philipp Krueger und Matthias Dietrich, Co-CEOs der foobar Agency, gehen die agentische Welle des letzten Jahres durch: die Protokolle von Google, OpenAI und Stripe, den Schalter bei Shopify, der Millionen Shops über Nacht an ChatGPT gehängt hätte, und die Frage, woran der agentische Checkout tatsächlich gescheitert ist. Nämlich am Handwerk: Verfügbarkeitsberechnung, Liefermethoden, Altgeräterücknahme, Verpackungsverordnung. „150 auf Lager" heißt nicht, dass 150 Stück im Lager liegen — vielleicht sind es 120, zwanzig sind unterwegs, zehn stehen auf einem Container.

Es geht außerdem um die Prognose vom einbrechenden Suchtraffic, die nicht eingetreten ist, und warum diese Zahlen inzwischen kaum messbar sind. Um Search und Discovery als den Bereich, in dem agentische Interfaces heute wirklich Wert schaffen. Und um die Lektion, die vom Experiment bleibt: Wer Produktdaten, Zahlungs- und Liefermethoden sauber und maschinenlesbar bereitstellen kann, testet einen neuen Kanal in einem Monat, ohne ein Projekt daraus zu machen. Diese Fähigkeit ist der Vorsprung, unabhängig davon, welches Protokoll am Ende gewinnt.

Für CEOs, CIOs, CDOs und CMOs in Handel und Industrie, die eine durchdachte Antwort auf die agentische Frage brauchen. Auch wenn diese Antwort lautet: wir machen das nicht.

#AgenticCommerce #ECommerce #KI #Handel #Digitalisierung

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/agentic-commerce-warum-der-ki-checkout-am-handwerk-scheitert

B2B eCommerce — mehr als ein Shop mit Umsatzsteuer-ID?

What Works Tomorrow — Thu, 06 Aug 2026 05:45:00 GMT

67 Prozent der B2B-Einkäufer wollen laut Gartner gar nicht mehr mit einem Verkäufer sprechen. Gleichzeitig laufen Bestellungen im Maschinenbau noch per E-Mail an Günther, der erst mal suchen muss, was der Kunde vor drei Jahren bestellt hat. Matthias Dietrich und Philipp Krüger über das Paradox der deutschen Industrie: vorne Digital Twin und Predictive Maintenance, hinten ein Vertrieb, der auf Zuruf arbeitet.

Die Folge räumt mit einer Fehlannahme auf: B2B eCommerce ist kein B2C mit Umsatzsteuer-ID. Wholesale, Auftragsfertigung, Ersatzteilgeschäft, Angebotsprozesse mit endlosen Schleifen — jedes Projekt ist anders, und die eigentliche Herausforderung ist selten technisch. Sie steckt in Excel-Makros, die seit 20 Jahren niemand mehr versteht, und in Wissen, das nur in den Köpfen einzelner Mitarbeiter existiert.

Außerdem: Warum das Geld in der Industrie nicht beim Verkauf verdient wird, sondern im Service. Welche digitalen Geschäftsmodelle in Telemetriedaten stecken. Und warum 73 Prozent der Einkäufer bereit sind, 50.000 US-Dollar und mehr online auszugeben — das Argument "hohe Tickets kauft online keiner" zieht nicht mehr.

What Works Tomorrow — der Podcast für Entscheider in Handel und Industrie. Von Matthias Dietrich und Philipp Krüger, Co-CEOs der foobar Agency.

#B2B #eCommerce #Manufacturing #WhatWorksTomorrow

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/b2b-ecommerce-mehr-als-ein-shop-mit-umsatzsteuer-id

Agentic vs. Autonomous Commerce — Buzzword-Bingo oder echter Hebel?

What Works Tomorrow — Thu, 30 Jul 2026 15:18:57 GMT

Agentic Commerce, Autonomous Commerce — auf der K5 war alles beides, und hinterher wusste keiner mehr, was was ist. Matthias Dietrich und Philipp Krüger sortieren die Begriffe: Was steckt hinter dem Vendor-Marketing, was ist real, und wo liegt der echte Hebel?

Die These der Folge: Nicht der Bot, der Ihre Sportschuhe kauft, verändert den Handel — sondern die Orchestrierung im Backoffice. Promotions, Merchandising, Suche, Loyalty: Systeme, die heute nebeneinander laufen, lassen sich erstmals übergreifend steuern. Warum das für Teams relevant ist, die ihre Commerce-Plattform nicht ausreizen, und wo trotzdem Vorsicht gilt — etwa bei Editorial, Marke und finanziellen Entscheidungen mit Tragweite.

Außerdem: Warum vieles, was als innovativ gilt, regelbasierte Modelle sind, die wir seit Jahren kennen. Und die provokante Frage: Braucht es überhaupt noch ein CMS?

What Works Tomorrow — der Podcast für Entscheider in Handel und Industrie. Von Matthias Dietrich und Philipp Krüger, Co-CEOs der foobar Agency.

#eCommerce #KI #AgenticCommerce #WhatWorksTomorrow

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/agentic-vs-autonomous-commerce-buzzword-bingo-oder-echter-hebel

KI funktioniert morgen. Die Frage ist, wie.

What Works Tomorrow — Mon, 20 Jul 2026 15:34:02 GMT

Auftakt für What Works Tomorrow: Matthias Dietrich und Philipp Krueger, Co-CEOs der foobar Agency, nehmen den KI-Hype auseinander.

Frisch von der K5 sprechen sie darüber, warum so viele KI-Prototypen im Demo-Stadium hängen bleiben – und warum gerade die schönsten am seltensten in Produktion gehen. Warum die Industrie dem Handel beim KI-Einsatz voraus ist. Und warum Daten der zweithäufigste Blocker auf dem Weg zur echten Nutzung sind.

Dazu: das Gartner-Reifegradmodell zur eigenen Standortbestimmung, ein IBM-Zitat von 1979, das aktueller ist denn je, ein KI-Projekt in der Kinderkrebsforschung, bei dem nichts halluziniert sein darf – und die These, dass die nächste Disruption aus der Individualisierung kommt, wenn alles algorithmisch immer gleicher wird.

Die erste von vielen Folgen. What Works Tomorrow erscheint regelmäßig – mit Klartext für Führungskräfte in Handel und Industrie.

Eine Produktion der foobar Agency.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/podcast/what-works-tomorrow/ki-funktioniert-morgen-die-frage-ist-wie

Von Snowflake zu KI: Predictions und LLMs am Commerce-Datenmodell

Dominik Thalmeier — Thu, 25 Jun 2026 00:00:00 GMT

Wenn der CDO im Quartalsmeeting fragt, "wo steht unsere KI?", dann ist die ehrliche Antwort selten ein einzelner Use Case — sondern eine Landkarte. Auf dieser Landkarte liegen drei Reifegrade nebeneinander: deterministische Berechnungen (Umsatz nach Region, Lagerreichweite, Marge pro SKU), probabilistische Predictions (CLV, Churn-Wahrscheinlichkeit, Next-Best-Action) und LLM-gestützte Entscheidungen (Service-Co-Pilot mit Order-Historie, generierte Produkttexte, semantische Suche im Katalog). In Snowflake-Projekten bei foobar Agency sehen wir, dass Kunden alle drei brauchen — aber selten gleichzeitig in der gleichen Liga spielen. Dieser Beitrag schließt die Daten-Serie ab und zeigt, was Snowflake Cortex und Snowpark ML heute liefern, wo LLMs auf strukturierten Commerce-Daten tragen und welche Voraussetzungen erfüllt sein müssen, bevor das Datenmodell zum Vertrag zwischen klassischen Modellen und Sprachmodellen wird.

Drei Reifegrade, eine Architektur

Die drei Reifegrade unterscheiden sich nicht im Datenstand, sondern in der Frage, die sie beantworten. Deterministische Berechnung beantwortet "Wie viel?" und "Wann?" — präzise, reproduzierbar, in jedem Dashboard nachvollziehbar. Probabilistische Prediction beantwortet "Wie wahrscheinlich?" — sie liefert Erwartungswerte mit Konfidenzintervallen, getragen von Feature-Engineering und einem trainierten Modell. LLM-gestützte Entscheidung beantwortet "Was passt hier?" — sie verarbeitet unstrukturierte Texte, kombiniert sie mit strukturiertem Kontext und gibt eine Antwort, die in der Form variiert.

In Snowflake liegt das Fundament für alle drei in der gleichen Lakehouse-Architektur. dbt-modellierte marts-Tabellen versorgen die deterministischen Berichte, Snowpark ML trainiert und versioniert die Prediction-Modelle, und Snowflake Cortex stellt LLM-Funktionen direkt als SQL bereit — `COMPLETE` für Antworten, `EMBED_TEXT_768` und `EMBED_TEXT_1024` für Vektor-Repräsentationen, `EXTRACT_ANSWER` für Question-Answering auf unstrukturierten Texten, `SUMMARIZE` für Zusammenfassungen. Die Modelle laufen verwaltet in der Snowflake-Region; eigene Modelle lassen sich über Snowpark Container Services betreiben.

Architektonisch heißt das: Das Datenmodell wird zum Vertrag. Die gleichen marts-Tabellen, die das CLV-Modell trainieren, liefern den Kontext für den Service-Co-Piloten. Die gleichen Produkt- und Kategorie-Embeddings, die die semantische Suche tragen (siehe Semantic Search und Agentic Search im B2B), liefern Kandidaten für die LLM-gestützte Antwort. Wer diese Trennung nicht sauber zieht, baut für jeden Use Case eine eigene Pipeline — und verliert die Skalierung.

Was Snowflake Cortex heute praxisreif liefert

Snowflake Cortex stellt vortrainierte Modelle als verwaltete SQL-Funktionen bereit. Die Modelle laufen innerhalb der Snowflake-Security-Perimeter; die Daten verlassen die Snowflake-Region nicht, wenn die gewählte Funktion in der Region verfügbar ist. Für Commerce-Projekte sind aus unserer Sicht vier Funktionsklassen relevant.

Erstens: `COMPLETE` ruft ein Sprachmodell mit Prompt und optionalem Konversations-Kontext auf. Verfügbare Modelle reichen von Snowflakes eigenem Arctic über Mistral und Meta Llama bis zu Anthropic-Modellen — die Auswahl hängt an Region und Pricing. Praktisch nutzbar für Produktbeschreibungs-Entwürfe aus PIM-Attributen, Kategorisierung freier Service-Anfragen, Auswertung von Review-Texten.

Zweitens: `EMBED_TEXT_768` und `EMBED_TEXT_1024` erzeugen Vektor-Embeddings aus Texten. In Kombination mit Snowflakes Vector-Datentyp und der `VECTOR_COSINE_SIMILARITY`-Funktion lassen sich Embedding-basierte Such- und Empfehlungsstrecken vollständig in SQL formulieren — ohne separate Vektor-Datenbank. Für mittlere Katalog-Größen (bis in den niedrigen Millionenbereich an SKUs) ist das ein pragmatischer Pfad. Für sehr große Kataloge oder Sub-100-ms-Anforderungen bleibt eine spezialisierte Vector-Engine relevant.

Drittens: `EXTRACT_ANSWER` beantwortet Fragen aus einem mitgelieferten Textkontext. Für Service-Co-Piloten und FAQ-Strecken ist das die ehrlichste Variante — die Antwort kommt zwingend aus dem übergebenen Kontext, nicht aus dem Modellgedächtnis. Halluzinations-Risiko sinkt, weil das Modell keine Quelle hat, in der es frei wandern könnte.

Viertens: `SUMMARIZE` und Hilfsfunktionen wie `TRANSLATE` oder `SENTIMENT`. Diese liegen in der zweiten Reihe — nicht weil sie unwichtig sind, sondern weil sie als Bausteine in größeren Pipelines auftauchen, nicht als Use-Case-Treiber.

Wer mehr Kontrolle braucht — eigene Modelle, eigene Tokenizer, eigene Inference-Logik — geht über Snowpark Container Services. Das ist die Variante für Industrie-Kunden mit bestehenden ML-Investitionen, die nicht auf verwaltete Modelle migrieren wollen, sondern Snowflake als Daten- und Compute-Plattform nutzen.

LLMs auf strukturierten Commerce-Daten

LLMs liefern den größten Hebel dort, wo strukturierte Commerce-Daten auf unstrukturierte Anfragen oder unstrukturierte Texte treffen. Drei Use Cases sehen wir in DACH-Projekten besonders häufig.

Embedding-basierte Suche und Empfehlung. Produkt- und Kategorie-Texte werden mit `EMBED_TEXT_768` in Vektoren überführt, in einer marts-Layer-Tabelle abgelegt und zur Suchzeit gegen das Embedding der Anfrage abgeglichen. Das ergänzt — nicht ersetzt — die klassische SKU- und Facetten-Suche, wie wir sie in Warum B2B-Suche eigene Spielregeln hat beschreiben. Im B2C trägt das Muster bei Discovery-lastigen Sortimenten (Möbel, Mode, Drogerie). Im B2B-Industrie-Kontext (siehe Daten-Foundation für B2B-Industrie) liefert es Treffer für Suchanfragen, die in der klassischen Volltextsuche scheitern — etwa "Ersatzteil für Sicherung, die nach Regen ausgefallen ist".

Generative Produktbeschreibungen aus PIM-Daten. Aus strukturierten Attributen (Materialien, Maße, Normen, Anwendungsfeldern) erzeugt ein Prompt mit `COMPLETE` einen ersten Beschreibungs-Entwurf. Der Wert liegt nicht in der finalen Qualität — die übernimmt die Redaktion — sondern in der Skalierung über Kataloge mit zehntausenden SKUs und mehreren Sprachen. Voraussetzung: ein PIM-Datenstand, der die relevanten Attribute sauber führt. Ohne saubere Eingangsdaten halluziniert das Modell, weil ihm Spezifika fehlen.

Service-Co-Pilot mit Order- und Service-Historie als Kontext. Eine Service-Anfrage trifft ein — der Co-Pilot zieht in einer Snowflake-Abfrage die Order-Historie des Kunden, die letzten Service-Tickets, die zugehörigen Produktstammdaten und gibt sie mit der eingehenden Anfrage als Kontext an `COMPLETE` oder `EXTRACT_ANSWER`. Das Modell formuliert keinen freien Vorschlag, sondern eine Antwort, die im Kontext verankert ist. Halluzinations-Risiko sinkt, Servicequalität steigt, ohne dass jeder Bearbeiter selbst alle Datenquellen abklappert.

Was diese drei Use Cases verbindet: Sie greifen auf das gleiche Datenmodell zu. Die gleichen Customer-, Order- und Product-Tabellen, die die deterministischen Reports speisen, sind die Quelle für den LLM-Kontext. Wenn das gemeinsame Datenmodell trägt, das wir in Snowflake im Commerce beschreiben, tragen die LLM-Use-Cases.

Vier Voraussetzungen, bevor LLMs auf Ihre Commerce-Daten dürfen

Bevor ein LLM produktiv auf Commerce-Daten zugreift, sollten vier Voraussetzungen sitzen. Wer sie überspringt, baut Demos — keine tragenden Use Cases.

#	Voraussetzung	Warum sie tragen muss
1	marts-Layer-Daten mit klarer Modellierung	LLMs sind genauso gut wie ihr Kontext. Wenn Customer, Order, Product nicht sauber modelliert sind, halluziniert das Modell auf Lücken in den Daten.
2	Embeddings-Strategie mit Update-Pfad	Ein einmal erzeugter Embedding-Index wird stale, sobald sich Kataloge oder Texte ändern. Wer Embeddings einsetzt, braucht einen Mechanismus für inkrementelle Aktualisierung — sonst sinkt die Relevanz schleichend.
3	Eval-Setup vor Go-Live	"Das sieht gut aus" reicht nicht. Use-Case-spezifische Eval-Sets — gold-standardisierte Frage-Antwort-Paare, gemessene Treffer-Quoten, Halluzinations-Checks — gehören vor den ersten Produktiv-Roll-out. Ohne Eval misst niemand Regressionen, wenn das Modell wechselt.
4	Governance: Wer darf was sehen?	LLM-Antworten dürfen keine Daten exfiltrieren, die der Anfragende nicht sehen darf. Row-Access-Policies und Masking-Policies in Snowflake müssen vor der LLM-Schicht greifen — nicht erst im Antwort-Filter.

DSGVO, Region und Souveränität

"Ist das DSGVO-konform?" ist die häufigste Frage im KI-Workshop und die unpräziseste. DSGVO-Konformität ist kein Schalter, sondern ein Bündel aus Datenresidenz, Verarbeitungs-Vereinbarungen, Zugriffskontrollen und der Frage, wer im Zweifel rechtlich worauf zugreifen kann. Drei Mechanismen sollten in jedem Cortex-Projekt benannt sein.

Region-Pinning. Snowflake Cortex-LLM-Funktionen sind regional verfügbar — nicht jede Funktion in jeder Region. Wer auf eine AWS- oder Azure-EU-Region pinnt, hält die Inferenz dort. Vor dem Roll-out gehört geprüft, welche Funktion in der Zielregion verfügbar ist und welches Modell hinter `COMPLETE` läuft; Cross-Region-Inference kann sonst unbemerkt aktiv sein und Daten in andere Regionen replizieren.

Schrems II und CLOUD Act. Eine EU-Region beim US-Hyperscaler löst die Schrems-II-Frage nicht restlos. US-Anbieter unterliegen US-Recht — auch für Daten, die physisch in Frankfurt liegen. Wer hier strikt souverän braucht (öffentlicher Sektor, kritische Infrastruktur, einzelne regulierte Industrien), muss die Architektur mit Rechtsabteilung und ggf. Sovereign-Cloud-Anbietern bewerten. Für die meisten Commerce-Projekte ist die Kombination aus EU-Region, Auftragsverarbeitungs-Vereinbarung und konsequenter Pseudonymisierung im marts-Layer tragfähig — aber sie ist es nicht "automatisch".

Halluzinations-Kontrolle als DSGVO-Anliegen. Eine LLM-Antwort, die personenbezogene Daten erfindet ("Frau Schmidt hat letzte Woche bestellt"), ist keine Fehlfunktion — sie ist im Zweifel ein DSGVO-Vorfall. Wer LLMs auf Kundendaten loslässt, braucht Retrieval-Augmented Generation mit eindeutigen Quellen, Eval-Sets für Halluzinations-Detection und Logging, das die Quelle jeder Antwort nachvollziehbar macht.

Was nicht trägt: das Versprechen "ist DSGVO-konform" als Marketing-Aussage ohne konkrete Mechanismen. Was trägt: Region-Pinning, Datenresidenz, Pseudonymisierung im Datenmodell, definierte Modelle, dokumentierte Verarbeitungs-Vereinbarungen.

Wann LLM, wann klassisches Modell

Nicht jeder Use Case verdient ein LLM. Eine CLV-Prediction auf RFM-Features ist ein Gradient-Boosting-Modell — kein LLM-Job. Eine Lagerreichweiten-Berechnung ist eine SQL-Abfrage — kein LLM-Job. Ein LLM rechtfertigt sich, wenn drei Bedingungen zusammenkommen: Die Eingabe ist unstrukturiert oder die Ausgabe ist sprachlich variabel, das Problem hat hohe Heterogenität (jede Anfrage ist anders), und der Kontext aus strukturierten Daten ist verfügbar.

Wer LLMs auf Use Cases setzt, bei denen ein deterministisches oder probabilistisches Modell stärker, billiger und besser auditierbar ist, baut sich ein Risiko ein, das im ersten Audit auffällt. Wer umgekehrt klassische Modelle auf Use Cases zwingt, die echte Sprachverarbeitung brauchen, baut Workarounds, die mit jedem neuen Sortiment oder jeder neuen Sprache wieder zerfallen. Die Reifegrad-Logik aus dem ersten Abschnitt ist keine Hierarchie — sie ist eine Zuordnung.

LLMs auf Commerce-Daten tragen genau dann, wenn die strukturierte Welt vorher steht. Wir sehen regelmäßig Projekte, in denen ein Gradient-Boosting-Modell die CLV-Prediction besser, billiger und auditierbarer löst als jeder LLM-Ansatz — und gleichzeitig Service-Anfragen, bei denen erst ein RAG-Setup mit sauberem Order-Kontext die Wartezeiten in den Griff bekommt. Die Kunst ist nicht, überall LLMs einzubauen, sondern den richtigen Reifegrad für den jeweiligen Use Case zu wählen.
— Dominik Thalmeier, Team Lead Data Science foobar Agency

Häufig gestellte Fragen

Was ist Snowflake Cortex?

Snowflake Cortex ist die KI-Schicht innerhalb von Snowflake. Sie stellt vortrainierte Sprach- und Embedding-Modelle als SQL-Funktionen bereit — `COMPLETE` für Antworten, `EMBED_TEXT_768` und `EMBED_TEXT_1024` für Vektor-Embeddings, `EXTRACT_ANSWER` für Question-Answering, `SUMMARIZE` für Zusammenfassungen. Die Modelle laufen verwaltet innerhalb der Snowflake-Region, die Daten verlassen den Snowflake-Perimeter nicht, wenn die Funktion regional verfügbar ist.

Brauche ich eigene GPUs für LLMs auf Commerce-Daten?

Für die in Cortex verfügbaren Modelle nein — Snowflake stellt Compute und Modell bereit, abgerechnet wird über Credit-basiertes Pricing pro Token. Eigene GPUs werden erst relevant, wenn Sie eigene Modelle in Snowpark Container Services betreiben oder Modelle einsetzen, die Cortex nicht abdeckt. Für die meisten Commerce-Use-Cases — Produktbeschreibungen, Embeddings, Service-Co-Pilot — reicht der verwaltete Pfad.

Wie geht das mit DSGVO?

DSGVO-Tragfähigkeit hängt an konkreten Mechanismen, nicht an einem Label. Drei Punkte gehören in jedes Projekt: Region-Pinning auf eine EU-Region inklusive Prüfung der Funktions-Verfügbarkeit; Pseudonymisierung im marts-Layer, sodass nur die für den Use Case nötigen personenbezogenen Daten in den LLM-Kontext gelangen; und Auftragsverarbeitungs-Vereinbarungen, die die Schrems-II-Frage adressieren. Für strikte Souveränitätsanforderungen kommt zusätzlich die Bewertung mit Rechtsabteilung dazu — eine EU-Region beim US-Hyperscaler löst CLOUD-Act-Themen nicht restlos.

KI-Workshop am Commerce-Datenmodell

In zwei Stunden klären wir bei foobar Agency mit Ihnen, welche Reifegrad-Stufe zu welchem Use Case passt, was Ihr Snowflake-Datenmodell heute schon trägt und wo Cortex, Snowpark ML oder klassische Pipelines die bessere Wahl sind.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/snowflake-ki-llm-commerce-datenmodell-predictions

Semantic Search und Agentic Search im B2B: Wann Vektor-Embeddings, wann LLM-Agenten?

Matthias Dietrich — Mon, 22 Jun 2026 00:00:00 GMT

Semantic Search ist im eCommerce kein Forschungsthema mehr. Vektor-Embeddings hängen produktiv in Algolia NeuralSearch, Constructor, Coveo und Bloomreach Discovery; native Pipelines lassen sich auf Snowflake mit Cortex bauen. Parallel hat sich mit "Agentic Search" eine neue Stufe etabliert — der LLM-Agent als Berater, der mehrere Quellen abfragt, Rückfragen stellt und in Mehr-Schritt-Dialogen führt. Im B2B-Kontext heißt das nicht: alles muss KI werden. Es heißt: Sie haben jetzt drei Reifegrade — Keyword plus Synonyme, Semantic mit Embeddings, Agentic mit LLM — und müssen entscheiden, welcher zu welchem Such-Anlass passt. Dieser Beitrag schließt unsere Serie zur B2B-Suche mit der Frage, die in Architektur-Workshops am häufigsten kommt: Was bringt KI in der Suche wirklich — und was kostet sie?

Semantic Search: Wann Embeddings messbar besser sind

Vektor-Embeddings verwandeln Suchbegriffe und Produkte in mathematische Vektoren, deren Nähe semantische Ähnlichkeit abbildet. Eine Suche nach "rutschfeste Schutzhandschuhe für Ölumgebung" findet damit auch Produkte, die im Titel "Nitril-Handschuhe, Grip-Beschichtung, Oil-Grip" heißen — ohne dass jemand die Synonyme manuell pflegt.

In B2C-Studien finden sich für Semantic Search regelmäßig Konversions-Effekte im zweistelligen Prozentbereich. Solche Zahlen lassen sich nicht ungeprüft auf B2B übertragen — die Suche-Anlässe sind anders, das Sortiment kleiner, das Klickverhalten ein anderes. Wo Embeddings im B2B aber messbar tragen, sind drei Konstellationen: lange Natural-Language-Anfragen wie "Schmiermittel für Hochtemperatur-Lager bis 250 Grad", Anfragen mit beschreibendem Vokabular statt SKU, und Sortimente mit ausgeprägter Synonym-Vielfalt aus DIN/ISO-Bezeichnungen, Markennamen und Branchenjargon.

Wo Embeddings nicht tragen, ist genauso klar: bei reiner SKU- und Bestellnummern-Suche. Pure dense Vector-Suche degradiert auf exakten Produkt-IDs, SKUs, Maßbezeichnungen — also genau dem Verhalten, das den größeren Teil der B2B-Suche ausmacht. Die produktive Konsequenz ist Hybrid Search: Keyword (BM25) und Vector laufen parallel, die Treffermengen werden fusioniert und gemeinsam geranked. Algolia NeuralSearch macht das in einer API; Elastic, OpenSearch und die nativen Cortex-Search-Services in Snowflake auch. Wer in einem B2B-Setup über Semantic nachdenkt, denkt in der Praxis über Hybrid Search nach.

Agentic Search: Der Agent als Berater, nicht als Trefferliste

Agentic Search ist nicht die nächste Version von Semantic. Sie ist ein anderes Interaktionsmodell. Ein klassisches Suchsystem antwortet auf eine Anfrage mit einer Trefferliste. Ein agentischer Suchassistent bricht eine Anfrage in mehrere Teilaufgaben, ruft Tools auf — Produktkatalog, Verfügbarkeit, Konfigurator, ERP — und führt einen Dialog, bis die Anfrage entschieden ist. Amazon hat dieses Muster mit Rufus seit Februar 2024 im B2C produktiv.

Im B2B verschiebt das die Suche in Richtung Konfigurator-Logik. Eine Anfrage wie "Wir bauen eine Förderanlage für Schüttgut bis 80 Tonnen pro Stunde, Außenbereich, FDA-konform — welche Lager passen?" bekommt von einem klassischen Index keine sinnvolle Trefferliste. Ein Agent, der die Anwendungsparameter klärt, dann den Katalog filtert, Datenblätter prüft, Cross-Sell-Komponenten ergänzt und am Ende drei Kandidaten mit Begründung präsentiert, ist näher an dem, was Einkäufer aus dem persönlichen Verkauf kennen. Genau hier liegt das Cross-Sell-Potenzial: nicht im "Andere kauften auch", sondern in der kontextgetriebenen Kombination — passende Schmierstoffe zur Lager-Empfehlung, passende Befestigungselemente zur Konstruktion.

Die Architektur dahinter ist nicht trivial. Ein produktiver Agent braucht Tool-Use (API-Calls zu Katalog, Pricing, Bestand), Multi-Turn-State (das System merkt sich, was bereits geklärt wurde), und eine Abbruch-Logik, wenn der Agent in eine Halluzinations-Zone läuft. Im B2B kommt eine Anforderung dazu, die der B2C-Discovery-Kontext nicht hat: Der Agent darf eine empfohlene Komponente nicht erfinden. Sie muss im Sortiment sein, der Kunde muss sie bestellen dürfen, der Preis muss der Vertragspreis sein.

Tech-Stack: Native Plattform-Features oder eigene Pipeline?

Für die Umsetzung von Semantic und Agentic im B2B gibt es zwei realistische Pfade — selten ein Entweder-Oder, oft eine bewusste Aufteilung.

Pfad A: Native Such-Plattform. Algolia NeuralSearch liefert Hybrid Search aus einer API; Constructor und Coveo bringen ähnliche Capabilities mit. Vorteil: Time-to-Market in Wochen statt Monaten, Latenz unter 50 ms, kein eigener Embedding-Service, kein eigener Vector-Store. Grenze: Die Embedding-Modelle sind herstellereigen, Re-Ranking-Logik teilweise Blackbox, Anpassung an branchenspezifisches Vokabular läuft über Tuning, nicht über Modell-Wechsel. Für klassische eCommerce-Suche im B2B ist das in den allermeisten Fällen der pragmatische Weg.

Pfad B: Eigene Embedding-Pipeline auf Snowflake/Cortex. Wer ohnehin auf Snowflake aufsitzt — und das ist bei foobar-Kunden zunehmend der Fall — kann Embeddings nativ über Cortex erzeugen (EMBED_TEXT_768, EMBED_TEXT_1024) und mit Cortex Search als managed Vector-Service betreiben. Das eröffnet Use Cases jenseits der Storefront: semantische Suche über Datenblätter, Service-Manuals, Vertragsdokumente, interne Wissensdatenbanken. Wirtschaftlich relevant: Cortex Search rechnet Embedding-Indexing pro Token ab, das Hosting des Indexes pro GB-Monat — also auch ohne Abfragen. Das ist ein Modell, das man in der Kalkulation ehrlich abbilden muss.

Für Agentic Search liegt der Schwerpunkt heute klar auf dem zweiten Pfad: LLM-Agent (z. B. über OpenAI, Anthropic oder Snowflake Cortex AI SQL) plus Tool-Calls in die Commerce-Plattform. Wir vertiefen die Daten- und KI-Pipeline dazu in unserer parallelen Serie zu Snowflake — siehe den Beitrag Von Snowflake zu KI: Predictions und LLMs am Commerce-Datenmodell. Weiterführend zu Agenten im Commerce: Agenten für Ihre Kunden.

Ehrliche Grenzen: Halluzination, Compliance, Erklärbarkeit

Die drei Grenzen, die in B2B-Implementierungen am häufigsten unterschätzt werden, kommen nicht aus der Technik, sondern aus dem Einkaufs-Kontext.

Halluzination. Ein LLM-Agent, der einer Einkäuferin ein Produkt empfiehlt, das es im Sortiment nicht gibt, produziert keinen "kreativen Vorschlag" — er produziert eine Reklamation und im schlimmsten Fall eine Compliance-Verletzung. Agentische Suche im B2B braucht harte Tool-Constraints: Der Agent darf ausschließlich aus dem freigegebenen Sortiment empfehlen, jede Empfehlung muss gegen einen autoritativen Katalog validiert sein, der Preis kommt aus der Pricing-Engine, nicht aus dem Modell.

Compliance. Im Industrie-B2B sind Sortimente regulatorisch geprägt — REACH, RoHS, Exportkontrolle, branchenspezifische Normen. Ein Agent, der einem Kunden in Land X einen Artikel empfiehlt, der dort nicht versendet werden darf, ist nicht "fast richtig". Compliance-Filter müssen vor der LLM-Antwort greifen, nicht danach.

Erklärbarkeit. Einkäufer wollen wissen, warum ein bestimmtes Produkt empfohlen wird — gegenüber dem Vorgesetzten, dem Auditor, der QM-Abteilung. "Das Modell hat es ausgegeben" trägt nicht. Ein produktiver B2B-Agent muss Quellen, Datenblatt-Referenzen und die genutzten Filter ausweisen können. Wo das nicht möglich ist, bleibt die klassische Trefferliste mit Facetten der saubere Ansatz.

Vier Entscheidungsfragen vor dem KI-Such-Pilot

Bevor ein Pilot startet, sollten diese vier Fragen beantwortet sein. Sie entscheiden, ob ein KI-Such-Projekt eine Investition oder ein Showcase wird.

#	Frage	Was die Antwort entscheidet
1	Welche Suchanfragen treffen heute schlecht — SKU oder Natural-Language?	SKU-Schwäche löst man mit Indexing-Logik, nicht mit Embeddings. Natural-Language-Schwäche ist der Embedding-Case.
2	Gibt es einen klaren Use Case für Multi-Turn-Dialog (Konfigurator, technische Beratung)?	Ohne Multi-Turn-Use-Case ist Agentic Search Overengineering. Hybrid Search reicht.
3	Sind Sortiment, Preis und Compliance pro Kunde sauber gemodelt?	Ohne diese Basis halluziniert jeder Agent — und produziert Reklamationen statt Aufträgen.
4	Wer trägt die laufenden Kosten — Hosting des Indexes, Token-Verbrauch, Modell-Updates?	Embedding-Indexing und LLM-Calls sind verbrauchsbasiert. Die TCO-Linie muss vor dem Pilot stehen.

Embeddings sind kein Allheilmittel. Wir sehen in B2B-Projekten regelmäßig, dass eine ehrliche Hybrid-Search auf Algolia oder Elastic die Suche schon um Stufen besser macht — und für Agentic-Use-Cases legen wir den LLM-Layer dann gezielt nur dort drüber, wo der Multi-Turn-Dialog wirklich Geld verdient. Die Modell-Logik bringt nichts, wenn das Sortiment und die Vertragsdaten dahinter nicht sauber sind.
— Dominik Thalmeier, Team Lead Data Science, foobar Agency

Häufig gestellte Fragen

Lohnt sich Semantic Search bei einem kleinen Sortiment?

Bei wenigen tausend SKUs und überschaubarer Synonym-Komplexität bringt ein gut gepflegter Keyword-Index mit Synonym-Listen oft 80 Prozent des Effekts — bei einem Bruchteil der laufenden Kosten. Semantic lohnt sich, sobald lange Natural-Language-Anfragen, viel Branchenjargon oder mehrsprachige technische Begriffe in den Logs auftauchen.

Wie lassen sich LLMs in eine bestehende Suche integrieren, ohne alles umzubauen?

Der pragmatische Weg ist ein vorgeschalteter Query-Understanding-Layer: Der LLM klassifiziert die Anfrage, schreibt sie um (z. B. extrahiert Filter-Parameter aus Natural Language) und reicht sie an die bestehende Such-API weiter. So bleiben Index, Ranking und Berechtigungslogik unangetastet — der LLM-Layer ist ein Übersetzer, kein Ersatz.

Was kostet das Hosting von Embeddings und Vector-Suche?

Bei nativen Plattformen wie Algolia ist es Teil der NeuralSearch-Lizenz. Bei eigenen Pipelines auf Snowflake fallen zwei Kostenblöcke an: Embedding-Erzeugung pro Token (laut Snowflake-Dokumentation im Bereich von 0,03 bis 0,07 Credits pro Million Token, abhängig vom Modell) und Index-Hosting pro GB-Monat — letzteres auch ohne aktive Abfragen. Genaue Zahlen kommen nur aus der Pilot-Kalkulation mit echtem Sortiment.

KI-Such-Pilot oder Hybrid-Search-Audit

In einem zweistündigen Architektur-Workshop klären wir mit Ihnen, ob Ihre B2B-Suche durch Hybrid Search, Embeddings oder einen agentischen Layer wirklich besser wird — auf Basis Ihrer Such-Logs, Ihres Sortiments und Ihres Tech-Stacks. Keine Folien, sondern Architektur-Entscheidungen mit Aufwand und Kostenbild.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/semantic-search-agentic-search-b2b-vektor-embeddings-llm-agenten

Daten-Foundation für B2B-Industrie: Forecasting, After-Sales, Service-Datenflüsse

Dominik Thalmeier — Thu, 18 Jun 2026 00:00:00 GMT

In B2B-Industrie-Setups ist die Daten-Foundation selten ein Snowflake-Projekt mit Commerce-Use-Case obendrauf. Sie ist ein Projekt zwischen S/4HANA oder ECC, einem CRM (oft Salesforce), einem Service-Tool (ServiceNow, SAP Service Cloud oder eigenentwickelt), einem MES und — neuerdings — IoT-Plattformen mit Sensordaten aus dem Feld. Wer hier die Commerce-Logik aus dem B2C eins-zu-eins übernimmt, baut eine Foundation, die nach Launch Reporting-Dashboards trägt, aber bei der ersten echten Industrie-Frage zerbricht: "Welche Ersatzteile werden wir in Q3 in Region Süd brauchen, abhängig davon, welche Anlagen 2022 ausgeliefert wurden?"

Dieser Beitrag zeigt drei Use Cases, die sich auf einer sauber gebauten Snowflake-Foundation für B2B-Industrie schnell zünden lassen — Forecasting, After-Sales-Prediction und Service-Datenfluss zurück in den Commerce —, und beschreibt, was an der ERP-/CRM-/Service-Anbindung Standard ist, was Maßarbeit braucht und wo die Lessons aus Industrie-Projekten zwischen Sicherheits-, Verbindungs- und Power-Tool-Herstellern liegen.

Warum Commerce-Daten allein zu kurz greifen

Im B2C-Commerce ist die Datenwelt überschaubar: Sessions, Bestellungen, Kunden, Produkte, Marketingkanäle, ein bisschen Loyalty. In der B2B-Industrie kommt eine zweite Welt dazu, die nicht im Shop entsteht — und die in vielen Foundation-Projekten entweder zu spät oder gar nicht angebunden wird.

Service-Tickets sind die kleinste, oft unterschätzte Einheit. Ein Techniker dokumentiert, dass an Anlage X die Komponente Y getauscht wurde, dass die Schraubverbindung Z Verschleißspuren zeigte und dass der Kunde bei der Gelegenheit nach Z-Ersatzteilen gefragt hat. Diese Information ist im Service-Tool. Sie ist nicht im Shop, nicht im CRM und meist nicht im ERP. Ohne sie ist jede Re-Order-Empfehlung im B2B-Portal ein Rateschüss.

Wartungszyklen und Lifecycle-Daten sind die zweite Schicht. B2B-Industrie-Produkte haben Lebenszyklen von fünf bis fünfzehn Jahren — bei einigen Hersteller-Setups deutlich länger. Wer eine Foundation auf einem 24-Monats-Fenster baut (typisch im Retail), verliert die Hälfte der Information, die für After-Sales-Vorhersagen relevant ist.

Sensor- und IoT-Daten sind die dritte Schicht. Vibration, Temperatur, Druck, Zykluszahlen — moderne Anlagen liefern diese Daten kontinuierlich. Snowflake hat mit dem Manufacturing-Data-Cloud-Angebot und Partnern wie HighByte, Crosser oder Cirrus Link eine Architektur etabliert, in der OT- und IT-Daten in derselben Plattform landen. Was vor fünf Jahren noch ein eigenständiges Industrial-IoT-Projekt war, ist 2026 ein Layer in der Foundation — wenn die Foundation entsprechend geplant ist.

Stammdaten-Hierarchien und Vertretungsregeln sind das vierte, leiseste Thema. In der B2B-Industrie bestellt selten ein einzelner Kunde. Es bestellt eine Einkaufsorganisation für mehrere Werke, mit unterschiedlichen Lieferadressen, mit Vertretungsregeln im Urlaubsfall, mit Genehmigungsschwellen je nach Position. Diese Logik liegt im ERP, im CRM und teils im Shop verteilt. Wer sie in der Snowflake-Foundation nicht sauber modelliert, baut Forecasts auf Kunden-IDs, die in der Realität gar nicht die Bestellung auslösen.

Die Konsequenz ist nicht akademisch. Sie zeigt sich an dem Tag, an dem die erste Forecast-Auswertung dem Vertriebsleiter vorgelegt wird — und der sagt: "Das kann nicht stimmen, das sind drei verschiedene Werke desselben Konzerns."

Drei B2B-Use-Cases auf Snowflake

Eine Snowflake-Foundation, die ERP, CRM, Service und IoT zusammenführt, ist kein Selbstzweck. Sie ist die Voraussetzung für drei Use Cases, die in B2B-Industrie-Projekten regelmäßig den ersten Business Case liefern.

1. Forecasting — Mengen, Saisonalität, Kapazitätsplanung. Klassisches Demand-Planning bekommt durch Machine Learning eine andere Qualität. Gradient-Boosting-Verfahren (XGBoost, LightGBM) und LSTM-Modelle reduzieren Forecast-Fehler in Industrie-Studien um 20 bis 50 Prozent gegenüber statistischen Standardverfahren. Voraussetzung ist eine Foundation, die Bestellhistorie, Saisonalitäts-Signale, Marketing-Aktivitäten und externe Treiber (Wetter, Branchenindizes, Projekt-Pipeline aus dem CRM) in einer modellierten Schicht zusammenführt — typischerweise in dbt-Modellen mit klar getrennten Staging-, Intermediate- und Mart-Layern. Was Snowflake hier liefert, ist die Rechenleistung für tausende SKU-Forecasts parallel, nicht die ML-Magie selbst.

2. After-Sales — Re-Order-Wahrscheinlichkeit, Wear-out-Signale, Verschleißteile-Vorhersage. Dies ist der Use Case, der Industrie-CIOs am schnellsten überzeugt — weil er einen Margenhebel im Ersatzteilgeschäft hebt, das in vielen Hersteller-Bilanzen die profitabelste Sparte ist. Drei Signale gehen zusammen: Bestellhistorie (wer hat wann was gekauft), Service-Tickets (wo wurde wann getauscht) und — wenn vorhanden — Sensordaten (wo zeigen Anlagen Anomalien). Das Ergebnis ist eine Re-Order-Wahrscheinlichkeit pro Kunde × Artikel × Zeitfenster, die als Empfehlung im B2B-Portal, als Lead-Liste im CRM oder als Trigger für Outbound-Service-Calls landet. Wichtig: Diese After-Sales-Prediction ist nicht dasselbe wie Predictive Maintenance. Predictive Maintenance prognostiziert den Ausfall einer konkreten Anlage anhand von Sensordaten — eine Engineering-Disziplin, die tief in OT-Daten und Modellen wie Remaining-Useful-Life-Schätzungen sitzt. After-Sales-Prediction prognostiziert das Kauf- und Service-Verhalten ganzer Kundensegmente — eine Commerce- und CRM-Disziplin. Beide profitieren von derselben Foundation, beantworten aber unterschiedliche Fragen.

3. Service-Datenfluss — Field-Service ↔ Commerce. Der dritte Use Case ist der, der am häufigsten unterschätzt wird. Ein Techniker, der vor Ort eine Komponente tauscht, erzeugt eine Information, die in Echtzeit eine Re-Order-Empfehlung im Kundenportal auslösen sollte. Heute liegt diese Information meist auf einem mobilen Service-Gerät, wandert in ServiceNow oder SAP Service Cloud und endet dort. Wer den Datenfluss schließt — Service-Ticket → Snowflake → Event in Commerce-Plattform → Re-Order-Empfehlung — schließt nicht nur eine Datenlücke. Er macht aus jedem Wartungseinsatz einen halbautomatischen Vertriebskontakt.

ERP, CRM, Service: Was Standard ist, was Maßarbeit

Die Anbindung der Quellsysteme an Snowflake ist 2026 keine Erfindungsleistung mehr — die Mehrheit der Pfade ist beschrieben. Worauf es ankommt, ist die Trennung zwischen technischer Anbindung (gibt es als Standard) und semantischer Modellierung (bleibt Maßarbeit).

Standard sind die Connectoren. Für SAP S/4HANA und ECC sind im Markt vier Hauptpfade etabliert: SAP-native ODP-/CDS-View-Extraktion über SAP Datasphere, Drittanbieter-CDC auf Datenbank-Ebene (BryteFlow, Fivetran HVR, SNP Glue, Theobald), klassisches Batch-ETL über das SAP-Application-Layer (eher Auslaufmodell) und — neu für 2026 — SAP Business Data Cloud Connect for Snowflake mit Zero-Copy- und bidirektionalem Zugriff (Verfügbarkeit nach SAP-Roadmap H1 2026). Welcher Pfad trägt, hängt an drei Fragen: Wie sensitiv ist die SAP-Systemlast? Wie viel Business-Logik soll im Source-System bleiben? Wie nah an Echtzeit muss die Replikation sein? Für Salesforce, ServiceNow, HubSpot oder Microsoft Dynamics ist die Standard-Antwort meist ein ELT-Tool (Fivetran, Airbyte, Matillion) mit nativem Connector — schnell aufgesetzt, oft in Tagen statt Wochen.

Maßarbeit ist die Modellierung. Was die Connectoren liefern, sind Tabellen — keine Datenmodelle. Eine Forecast-fähige Foundation braucht eine semantische Schicht, in der Materialnummern, Kunden-Hierarchien, Vertretungsregeln und Zeitvaliditäten so verknüpft sind, dass die ML-Modelle nicht an Inkonsistenzen scheitern. In dbt heißt das: konsequente Trennung zwischen Staging (1:1 zur Quelle), Intermediate (saubere Business-Konzepte) und Marts (Use-Case-spezifische Tabellen für Forecasting, After-Sales-Prediction, Service-Reporting). Wer hier abkürzt, baut ein Reporting-Lager, keine analytische Plattform.

Maßarbeit bleibt auch die Behandlung der Stammdaten-Hierarchien. In B2B-Industrie-Setups ist die Frage "Wer ist der Kunde?" selten trivial. Ein Konzern bestellt für 14 Werke; jedes Werk hat einen technischen Einkäufer, der bestellt, und einen Werksleiter, der genehmigt; im Urlaubsfall springt ein anderes Werk ein. Im ERP sind diese Beziehungen oft mehrstufig modelliert, im CRM teils anders, im Shop nochmal anders. Diese Diskrepanzen früh zu mappen — bevor das erste ML-Modell trainiert wird — entscheidet, ob die Foundation hält oder ob in sechs Monaten eine zweite Welle Modellierungsaufwand nötig wird.

In Industrie-Projekten zwischen Sicherheits-, Verbindungs- und Power-Tool-Herstellern sehen wir das gleiche Muster: Die Technik ist in Wochen aufgesetzt. Die Stammdaten-Diskussion dauert Monate. Wer das umdreht und mit der Stammdaten-Arbeit beginnt, spart sich die Schleifen.

Vier B2B-Use-Cases, die schnell zünden

Wenn die Foundation steht — ERP-Replikation läuft, dbt-Modelle sind sauber geschnitten, Stammdaten-Hierarchien sind gemappt — gibt es vier Use Cases, die sich in B2B-Industrie-Setups regelmäßig in den ersten sechs bis neun Monaten realisieren lassen. Nicht weil sie trivial wären, sondern weil die Daten dafür ohnehin gehoben werden.

#	Use Case	Datenquellen	Erster Output	Typischer Hebel
1	Demand-Forecast je SKU × Region	ERP-Auftragshistorie, CRM-Pipeline, Saisonalität, Werks-Hierarchien	Rollierender 12-Monats-Forecast mit Konfidenz-Intervallen	Reduzierter Sicherheitsbestand, weniger Engpässe in Hochsaison
2	After-Sales-Score (Re-Order-Wahrscheinlichkeit)	Bestellhistorie, Service-Tickets, Sensor-Anomalien (wenn vorhanden)	Kunden × Artikel × Zeitfenster mit Wahrscheinlichkeit	Höhere Ersatzteil-Marge, gezielte Outbound-Service-Calls
3	Service-Ticket → Re-Order-Empfehlung	Field-Service-Tool, Anlagen-Stammdaten, Commerce-Katalog	Event-getriebene Empfehlung im Kundenportal	Verkürzte Re-Order-Zyklen, weniger Telefon-Bestellungen
4	Kapazitäts- und Engpass-Frühwarnung	MES, ERP-Auftragsbestand, Lieferanten-Vorlaufzeiten	Wochenweise Engpass-Liste mit Top-Risiken	Frühere Eskalation, weniger Lieferverzögerungen

Was diese vier Use Cases verbindet: Sie alle ziehen aus denselben Quellen — ERP, CRM, Service, optional IoT — und alle profitieren davon, wenn die Snowflake-Foundation die semantische Schicht von Anfang an mit B2B-Industrie-Logik baut, nicht mit Retail-Defaults.

Wer die Foundation selbst gerade plant, findet die Argumentationslinie zur Plattform-Entscheidung in Snowflake im Commerce: Vom Datensilo zur gemeinsamen Architektur. Wer die Commerce-Seite vorhat, also kundenspezifische Suche und Sortimente, findet die Logik in Customer-specific Search: Wenn jeder Einkäufer ein anderes Sortiment sieht.

In einem Industrie-Projekt haben wir die Service-Tickets aus dem Field-Service-Tool in Snowflake gespiegelt und mit der Auftragshistorie aus S/4HANA verknüpft. Nach acht Wochen lief der erste After-Sales-Score, nach vier Monaten landeten die Empfehlungen im Kundenportal. Der schwierigste Teil war nicht die Pipeline — es waren die Stammdaten-Hierarchien zwischen Konzernmutter, Werk und technischem Einkäufer. Wir wissen das, weil wir es tun.
— Matthias Dietrich, CEO foobar Agency

Häufig gestellte Fragen

Brauche ich für B2B andere Modelle als für B2C?

Die ML-Algorithmen sind weitgehend dieselben — Gradient Boosting, LSTM, klassische Zeitreihen-Verfahren. Was sich unterscheidet, sind Datenstrukturen und Features: B2B-Kundenhierarchien (Konzern → Werk → Einkäufer), Vertragslaufzeiten, Lifecycle-Daten von Anlagen, Service-Ticket-Historien, technische Stammdaten mit Norm-Bezeichnungen. Wer ein B2C-Forecasting-Modell auf B2B-Daten anwendet, ohne diese Features sauber zu modellieren, bekommt rechnerisch valide, aber operativ unbrauchbare Vorhersagen.

Wie binde ich SAP an Snowflake an?

Es gibt vier etablierte Pfade: SAP-native ODP-/CDS-View-Extraktion über SAP Datasphere, Drittanbieter-CDC auf Datenbank-Ebene (BryteFlow, Fivetran HVR, SNP Glue, Theobald Xtract Universal), klassisches Batch-ETL (rückläufig) und ab H1 2026 SAP Business Data Cloud Connect for Snowflake mit Zero-Copy-Zugriff. Die Entscheidung hängt an Systemlast, Echtzeit-Anforderung und Frage, ob Business-Logik im SAP bleiben soll oder in dbt nachgebaut wird.

Wie lange dauert es bis zum ersten Forecast?

In Industrie-Projekten mit einer halbwegs sauberen SAP-Quelle erreichen wir typischerweise nach acht bis zwölf Wochen einen ersten produktiven Forecast — vorausgesetzt, die Stammdaten-Hierarchien sind in den ersten Wochen geklärt. Wer sie nicht klärt, sieht den ersten Forecast nach sechs Monaten, weil das Modell zwischendurch zwei Mal neu trainiert werden muss.

Foundation-Audit für B2B-Industrie

In einem halbtägigen Workshop bewerten wir bei foobar Agency Ihre bestehende Datenlandschaft — SAP, CRM, Service, IoT — gegen die Anforderungen von Forecasting, After-Sales-Prediction und Service-Datenfluss. Sie bekommen einen konkreten Architektur-Pfad und eine Aufwandsschätzung, keine Folien.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/daten-foundation-b2b-industrie-forecasting-after-sales

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

Matthias Dietrich — Mon, 15 Jun 2026 00:00:00 GMT

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 im Beitrag Daten-Foundation für B2B-Industrie.

Drei Muster für kundenspezifische Suchindizes

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.

Kontraktpreise sichtbar machen — Pre-Compute oder Live-Call

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.

ERP- und PIM-Anbindung: Wie aktuell ist aktuell genug?

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.

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 im Beitrag Daten-Foundation für B2B-Industrie.

Fünf Fallen bei kundenspezifischen Suchindizes

Diese fünf Fehler tauchen in Architektur-Audits regelmäßig auf — und kosten in der Regel deutlich mehr als ein sauberer Entwurf vorab.

#	Falle	Was passiert	Was es kostet
1	Sichtbarkeits-Filter erst im Frontend	Der Index liefert das Gesamtsortiment, das UI versteckt unsichtbare Treffer	Falsche Trefferzahlen, falsche Sortierungen, latente Datenleaks
2	Listenpreis im Index, Kontraktpreis im PDP	Sortierung "Preis aufsteigend" produziert kunden-individuell falsche Reihenfolgen	Reklamationen, manuelle Korrekturen im Vertrieb
3	Multi-Tenant-Index ohne Index-Lifecycle	Hunderte Indizes wachsen unkontrolliert, Cluster-Metadata kippt	Performance-Einbruch, ungeplante Reindex-Migrationen
4	ERP-Sync ohne Idempotenz	Doppelt verarbeitete Events lassen Indizes auseinanderdriften	Schleichende Inkonsistenzen, schwer reproduzierbare Bugs
5	Vertretungsregeln / Stellvertreter ignoriert	Wer für einen Kollegen einkauft, sieht das eigene statt das vertretene Sortiment	Falsche Bestellungen, Schatten-Workflows per Telefon

Customer-specific Search ist der Punkt, an dem B2B-eCommerce vom Katalog-Frontend zur echten Vertragsschnittstelle wird. Unsere Kunden sortieren diese Frage genau dann, wenn der erste Großkunde eine personalisierte Sicht erwartet — und merken im selben Moment, dass die Antwort an drei Stellen gleichzeitig hängt: Index, Pricing, Sync. Wer das jetzt sauber baut, macht die nächsten Vertrags-Eskalationen in der IT lösbar, nicht im Vertrieb.
— Philipp Krueger, Co-CEO foobar Agency

Häufig gestellte Fragen

Wie aktuell müssen Preise in der Suche sein?

Die Antwort hängt am Vertragstyp. Stammkunden mit jährlich verhandelten Konditionen brauchen keine Sekunden-Aktualität — ein nächtlicher Sync reicht. Projektgeschäft mit täglich verhandelten Preisen, Spot-Konditionen oder dynamischen Mengenrabatten dagegen verlangt sub-Minute. In Mischsortimenten lohnt eine Differenzierung pro Produktkategorie: stabile Stammdaten batchweise, volatile Preise event-driven. Wichtiger als die absolute Frequenz ist, dass der Preis in der Trefferliste exakt dem entspricht, der im Warenkorb gilt.

Wie skaliert das bei vielen Kunden?

Die Skalierungsgrenze liegt selten im Index selbst, sondern im Sync-Pfad und in der Entitlement-Logik. Multi-Tenant-Indizes skalieren bis in den niedrigen vierstelligen Bereich an Tenants gut; darüber hinaus überwiegen die Vorteile eines Filtered-Index. Bei Kontraktpreisen ist die kritische Größe das Produkt aus Anzahl Kunden mal Anzahl Artikel mit individueller Preisbildung — sobald das in den zweistelligen Millionenbereich wächst, lohnt sich eine Segmentierung in Preisgruppen statt vollständig individueller Konditionen.

Was passiert bei Vertretungsregeln und Stellvertretern?

Im B2B-Alltag arbeiten Einkäufer regelmäßig "im Auftrag von" — etwa wenn ein zentraler Einkauf für mehrere Standorte bestellt oder ein Vertreter eine Krankheits-Vertretung übernimmt. Die Suche muss in diesem Fall den effektiven Kontext (für welches Account, welche Business Unit, welche Vertragsnummer wird gerade gesucht?) auswerten, nicht nur die User-ID des eingeloggten Mitarbeiters. Plattformen wie commercetools und Spryker modellieren das über Business Units und Account-Wechsler im UI; die Suche muss diesen Kontext über jeden Request mittragen und im Index respektieren.

Architektur-Workshop kundenspezifische Suche

In einem zweistündigen Workshop klären wir mit Ihnen, welches Index-Muster zu Ihrer Kundenstruktur passt, wie Kontraktpreise sichtbar werden und welche Sync-Strategie zwischen ERP, PIM und Suche trägt — entlang Ihrer Plattform und Ihrer Vertragslandschaft.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/customer-specific-search-kundenindividuelle-sortimente-preise

RFM und CLV: Wer Ihre wertvollsten Kunden sind — und welche Sie gerade verlieren

Dominik Thalmeier — Thu, 11 Jun 2026 00:00:00 GMT

Die meisten eCommerce-Organisationen wissen ziemlich genau, wer im letzten Quartal viel gekauft hat. Sie wissen seltener, wer im nächsten Quartal viel kaufen wird — und noch seltener, welche Stammkunden gerade leise verschwinden. Genau diese Lücke füllt eine Customer Lifetime Value Prediction: Sie verwandelt Bestelldaten in eine belastbare Erwartung, wie viel Umsatz ein einzelner Kunde in den kommenden zwölf oder vierundzwanzig Monaten beitragen wird. In der Praxis sehen wir bei foobar Agency, dass dieser Schritt selten an der Methode scheitert — sondern daran, dass RFM-Auswertungen und CLV-Berechnungen nebeneinander leben, statt aufeinander aufzubauen. Dieser Beitrag zeigt, wie die Brücke von RFM zu probabilistischer CLV aussieht, was BG/NBD und Gamma-Gamma im Tagesgeschäft leisten — und welche Geschäftsentscheidungen sich damit anders treffen lassen.

Wir bauen damit auf dem ersten Beitrag dieser Reihe auf, in dem es um die Snowflake-Foundation als gemeinsames Datenfundament ging — und ordnen den Use Case in den Maturity-Pfad ein, den wir bei Retail- und B2C-Kunden in DACH wiederkehrend sehen.

RFM: Drei Zahlen, die mehr sagen als ein Dashboard

RFM steht für Recency, Frequency und Monetary — drei Kennzahlen pro Kunde, abgeleitet aus der Bestellhistorie: Wann hat dieser Kunde zuletzt gekauft? Wie oft hat er in einem Zeitfenster gekauft? Welchen Wert haben seine Bestellungen im Durchschnitt? In der klassischen Variante wird jede der drei Dimensionen in fünf Quintile geteilt, und jeder Kunde erhält ein dreistelliges Profil — von 1-1-1 (lange nicht da, selten gekauft, kleine Beträge) bis 5-5-5 (zuletzt aktiv, häufig gekauft, hochwertig).

Was nüchtern klingt, ist in der Praxis oft der erste Punkt, an dem Marketing-Verantwortliche zum ersten Mal sehen, wer ihre wertvollsten Kunden tatsächlich sind. Die typischen Aha-Effekte: Top-Frequenz-Kunden sind nicht automatisch Top-Monetary-Kunden. Reaktivierungs-Kandidaten lassen sich präzise eingrenzen — nicht "alle Kunden, die in 90 Tagen nicht gekauft haben", sondern "Kunden mit historisch hoher Frequenz, deren Recency-Score jetzt ins zweite Quintil rutscht". Und Marketing-Spending, das vorher gleichmäßig über die Datenbank verteilt war, bekommt eine erste Hierarchie.

RFM hat zwei Grenzen, die man kennen muss. Erstens beschreibt es Vergangenheit, nicht Zukunft — ein 5-5-5-Kunde von heute kann morgen ein Wechsler sein, ohne dass es im Score sichtbar wird. Zweitens behandelt es alle Kunden mit demselben Recency-Score gleich, obwohl ein Kunde mit 180 Tagen Recency und einer historischen Bestellfrequenz von einem Monat ein anderer Fall ist als ein Kunde mit 180 Tagen Recency und einer Frequenz von sechs Monaten. Genau hier setzen probabilistische Modelle an.

Probabilistische CLV: Was BG/NBD und Gamma-Gamma wirklich tun

Probabilistische CLV-Modelle behandeln jeden Kunden als individuelle Wahrscheinlichkeits-Verteilung — nicht als Punkt in einem Quintil-Raster. Das Standard-Setup im non-contractual eCommerce, also überall dort, wo Kunden ohne Abo oder Vertragsbindung kaufen, besteht aus zwei Modellen, die aufeinander aufbauen: BG/NBD für die Frage "wie oft kauft dieser Kunde wieder?" und Gamma-Gamma für die Frage "wie viel gibt er pro Bestellung aus?".

BG/NBD — Beta-Geometric / Negative Binomial Distribution — wurde 2005 von Fader, Hardie und Lee als pragmatische Weiterentwicklung des älteren Pareto/NBD-Modells (Schmittlein/Morrison/Colombo, 1987) eingeführt. Beide Modelle beantworten dieselben Fragen, BG/NBD ist nur deutlich einfacher zu schätzen und numerisch stabiler. Der Kern in zwei Sätzen: Die Kauffrequenz eines aktiven Kunden folgt einem Poisson-Prozess mit individueller Rate; die Wahrscheinlichkeit, dass ein Kunde nach einer Bestellung "inaktiv wird" (in der Sprache des Modells: drop out), folgt einer Beta-Verteilung. Beobachtet werden nur die Bestellungen — das Modell errechnet daraus die Wahrscheinlichkeit, dass ein Kunde überhaupt noch aktiv ist, und die erwartete Zahl seiner Bestellungen in einem zukünftigen Zeitfenster.

Gamma-Gamma modelliert den durchschnittlichen Bestellwert. Die Annahme ist, dass der erwartete Bestellwert eines Kunden um einen individuellen Mittelwert streut und dass diese Mittelwerte über die Kundenbasis gammaverteilt sind. Wichtig: Gamma-Gamma setzt formal voraus, dass Frequenz und Bestellwert unkorreliert sind — eine Annahme, die in der Praxis vor dem Modelltraining geprüft wird, weil sie nicht in jedem Sortiment hält.

Das Produkt aus erwarteter zukünftiger Bestellzahl (aus BG/NBD) und erwartetem Bestellwert (aus Gamma-Gamma) ergibt die individuelle CLV-Prognose über einen festgelegten Zeithorizont. Die Standard-Implementierung in Python ist die Bibliothek `lifetimes` von Cam Davidson-Pilon — sie macht aus einer transaktionalen Bestelltabelle innerhalb weniger Schritte einen kundenindividuellen CLV-Wert.

Was im Tagesgeschäft zählt: Die Ausgabe pro Kunde ist nicht ein Punktwert, sondern ein Wert mit Aussagekraft über Unsicherheit. Marketing-Verantwortliche, die das verinnerlichen, fangen an, anders zu fragen — nicht "wie hoch ist die CLV?", sondern "wie sicher sind wir, dass dieser Kunde noch aktiv ist?".

Praxisfall: Ein DACH-Multi-Channel-Händler auf Snowflake

Bei einem DACH-Multi-Channel-Händler aus dem Retail-Umfeld haben wir genau diese Brücke gebaut: RFM-Auswertung und probabilistische CLV in einem Datenmodell auf Snowflake, transformiert über dbt, mit klaren Schnittstellen ins Marketing- und Service-Tooling.

Verankert. Den Ausgangspunkt bildete eine konkrete Geschäftsfrage des Marketing-Bereichs: Welcher Anteil des kommenden Akquisebudgets ist Akquise wert, und welcher Anteil müsste eigentlich in Retention fließen? Diese Frage lässt sich ohne CLV nicht beantworten — und die bestehenden RFM-Reports gaben sie nur in ihrer Vergangenheits-Perspektive her. Das Projekt setzte deshalb nicht beim Modell an, sondern bei den Geschäftsentscheidungen, die das Modell anschließend stützen sollte: Spending-Allokation zwischen Akquise und Retention, CRM-Trigger für Reaktivierung, Priorisierung von Service-Cases nach Kundenwert.

Vernetzt. Die Datenbasis lag in Snowflake — Bestelldaten aus dem Commerce-System, Retouren, Kundenattribute aus dem CRM. Über dbt wurde ein Layer von RFM-Modellen aufgebaut: pro Kunde Recency, Frequency und Monetary, plus die Quintil-Scores, plus eine stabile Segment-Zuordnung. Auf demselben Layer setzt die probabilistische CLV-Berechnung auf: Trainings- und Holdout-Zeitfenster werden in dbt definiert, das eigentliche Modelltraining läuft in einer Python-Umgebung gegen Snowflake (Cam Davidson-Pilons `lifetimes`-Bibliothek), und die Vorhersagen — erwartete Käufe in den nächsten zwölf Monaten, erwarteter Bestellwert, daraus abgeleiteter CLV — fließen als neue Spalten zurück in das dbt-Modell. Deterministische Berechnungen (RFM-Quintile, historische Werte) und probabilistische Predictions (BG/NBD, Gamma-Gamma) liegen damit in derselben Datentabelle, nebeneinander, mit denselben Schlüsseln — und werden im Service- und Marketing-Tooling über dieselbe Customer-ID konsumiert.

Vorausgedacht. Die Architektur ist bewusst so geschnitten, dass sich weitere Predictions ergänzen lassen, ohne dass neue Datenpipelines entstehen — Next-Best-Action, Churn-Klassifikation, kategorie-spezifische CLV-Sichten. Snowflake ist dabei nicht die "Daten-Insel für Predictions", sondern dasselbe Datenfundament, von dem aus auch Reporting und operative Steuerung leben. Marketing-Automation, Service-Tooling und CRM-Kampagnen bekommen die Scores über regelmäßige Reverse-ETL-Strecken oder direkt über Live-APIs — je nach Anwendungsfall.

Der Nutzen ist messbar dort, wo vorher mit Bauchgefühl gearbeitet wurde: Reaktivierungs-Kampagnen werden auf Kunden mit hoher prognostizierter Restwertigkeit gerichtet — nicht auf "alle inaktiven Kunden". Service-Mitarbeitende sehen bei einer Eskalation den Kundenwert und entscheiden anders. Und Akquisebudgets bekommen eine Soll-Wertigkeit: Wir wissen, was ein Neukunde im Durchschnitt wert ist — und können sagen, ob ein neuer Kanal überhaupt ökonomisch tragen kann.

Vom Score in den Stack: Was Marketing und Service damit anfangen

Eine CLV-Prediction, die nur im Data-Warehouse liegt, ist kein Use Case — sie ist eine Tabelle. Der Wert entsteht erst, wenn die Werte in den Systemen ankommen, in denen Entscheidungen fallen.

Spending-Allokation. Mit kundenindividueller CLV lässt sich der Erwartungswert eines Neukunden errechnen — segmentiert nach Akquisekanal, Kampagne oder Sortimentskategorie. Wenn der durchschnittliche CLV eines Neukunden aus Kanal A bei einem bestimmten Wert liegt und der CAC dort darüber liegt, ist das nicht eine Bauchentscheidung, sondern eine Zahl. Dasselbe gilt für Retention: Was darf eine Reaktivierungs-Kampagne pro reaktiviertem Kunden kosten? Antwort wieder: die erwartete CLV der reaktivierten Kohorte, gewichtet mit Reaktivierungs-Wahrscheinlichkeit.

CRM-Triggering. BG/NBD liefert pro Kunde eine Wahrscheinlichkeit, noch aktiv zu sein. Sobald diese Wahrscheinlichkeit unter eine Schwelle fällt — und gleichzeitig die prognostizierte Restwertigkeit hoch ist — entsteht ein präzises Reaktivierungs-Signal. Statt eines breiten "90 Tage keine Bestellung"-Triggers bekommt das CRM einen wertgewichteten Frühwarn-Trigger.

Service-Priorisierung. In Service-Eskalationen ist Kundenwert eine relevante Größe — kontroverser, aber relevant. Wenn ein Service-Team weiß, dass ein eingehender Fall einen hochwertigen Bestandskunden mit niedrig werdender Aktiv-Wahrscheinlichkeit betrifft, wird er anders behandelt als ein Erst-Käufer mit kleinem Warenkorb. Das ist kein Auto-Pilot — das ist eine Information, die Service-Verantwortliche bei Bedarf nutzen.

Personalisierte Kommunikation. Frequenz und erwarteter Bestellwert sind starke Inputs für Mailing-Frequenz, Empfehlungs-Logik und Sortimentskuration. Ein Kunde mit hoher prognostizierter Frequenz braucht keine wöchentlichen Newsletter-Pushes — er kauft ohnehin. Ein Kunde mit hoher CLV und niedriger Frequenz reagiert oft auf gezielte Anlässe (Sortimentsstart, Limited Edition), nicht auf Mengen-Kommunikation.

CLV im Vergleich: heuristisch, RFM-basiert, probabilistisch

Wenn Sie einen schnellen Vergleich brauchen, wo Sie heute stehen und wohin der nächste Schritt führen kann — diese drei Reifegrade sind die Stationen, die wir in Projekten regelmäßig sehen.

Reifegrad	Methode	Aufwand	Aussagekraft	Anwendungsfall
Heuristisch	Durchschnittlicher Bestellwert × Bestellfrequenz × Marge × angenommene Laufzeit	Tage	Vergangenheitsbezogen, kein Kunden-Differenzierung über Segment hinaus	Grobe Wirtschaftlichkeitsrechnung, frühe Strategie-Phase
RFM-basiert	Recency-, Frequency-, Monetary-Quintile, daraus abgeleitete CLV-Schätzung pro Segment	Wochen	Beschreibt die Vergangenheit gut, ist als Zukunftssignal robust, aber gröber	Reaktivierungs-Kampagnen, Basis-Segmentierung im CRM
Probabilistisch	BG/NBD + Gamma-Gamma (oder vergleichbare Modelle), pro Kunde individuell	Wochen bis Monate für Aufbau, dann laufender Betrieb	Individuelle Vorhersagen mit Unsicherheits-Maß; trennt aktive von wahrscheinlich inaktiven Kunden	Spending-Allokation, CRM-Triggering, Service-Priorisierung

Die wichtige Lesart: Es ist kein Wettbewerb. RFM bleibt auch in fortgeschrittenen Setups als deskriptiver Layer erhalten — er ist die einfachste Sprache, in der Marketing- und Service-Teams über Kunden reden. Die probabilistische Schicht setzt sich darauf, sie ersetzt sie nicht.

CLV ändert weniger das Reporting als das Entscheidungs-Muster. Sobald Marketing-Spending und Service-Priorisierung an einer individuellen Wert-Erwartung hängen, fällt eine ganze Klasse von Bauchentscheidungen weg — und das Gespräch zwischen Marketing, Vertrieb und Finance wird ein anderes. Das ist der eigentliche Wert hinter der Methodik.
— Philipp Krueger, Co-CEO, foobar Agency

Häufig gestellte Fragen

Was unterscheidet Customer Lifetime Value von Customer Equity?

CLV ist ein kundenindividueller Wert — die erwartete zukünftige Wertschöpfung aus genau einem Kunden. Customer Equity ist die Summe der CLVs über alle Kunden eines Unternehmens; die Kennzahl bewertet also die gesamte Kundenbasis als Vermögenswert. In der Praxis arbeitet das Marketing operativ mit CLV; Customer Equity ist eine Steuerungs-Größe für die Geschäftsleitung und für Investitions-Diskussionen über Akquise und Retention im Aggregat.

Wie viele historische Daten brauche ich für eine probabilistische CLV-Prediction?

Eine Faustregel aus der Praxis: mindestens zwei vollständige Kaufzyklen Ihres typischen Kunden — bei Verbrauchsgütern können das zwölf Monate sein, bei Anschaffungsgütern eher 24 bis 36. Wichtig ist nicht nur die Länge, sondern die Sauberkeit: anonymisierte Bestellungen, Retouren, Gutscheine, Mitarbeiter-Accounts müssen sauber von normalen Käufen getrennt sein, sonst verzerren sie die Modell-Schätzungen.

Funktioniert das auch im B2B?

Im Grundsatz ja, aber mit Einschränkungen. BG/NBD und Gamma-Gamma sind für nicht-vertragliche Käufer-Mengen mit vielen, kleinen Transaktionen optimiert — also klassisches B2C-eCommerce. Im B2B liegen oft wenige große Bestellungen pro Kunde, längere Vertriebszyklen und Account-Strukturen mit mehreren Bestellern hinter einer Kundennummer. Das macht reine BG/NBD-Setups oft instabil. Wie sich die Logik auf B2B-Strukturen mit Account-Hierarchien und längeren Zeithorizonten überträgt, zeigt der Beitrag Daten-Foundation für B2B-Industrie.

CLV-Use-Case-Workshop

In zwei Stunden klären wir bei foobar Agency mit Ihnen, welche RFM- und CLV-Ausbaustufe zu Ihrer Datenlage, Ihrem Commerce-Stack und Ihren Marketing-Prozessen passt — mit konkretem Maturity-Check, nicht mit Folien.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/rfm-clv-prediction-wertvollste-kunden-erkennen

B2B-Suche im Plattform-Vergleich: Algolia, Constructor, Bloomreach, FactFinder, Coveo, Elastic

Matthias Dietrich — Mon, 08 Jun 2026 00:00:00 GMT

Im ersten Teil dieser Serie haben wir gezeigt, warum B2B-Suche eigene Spielregeln hat: SKU-Treffer vor Marketing-Logik, Sortimente am Vertrag, Kontraktpreise in der Trefferliste, Punchout in fremden UIs. Wer diese Anforderungen kennt, steht in der Plattform-Auswahl vor einem Markt, der sich auf den ersten Blick gleicht — und sich beim zweiten als sehr unterschiedlich erweist. Algolia, Constructor, Bloomreach Discovery, FactFinder, Coveo und Elastic sind die sechs Anbieter, die uns in B2B-Projekten bei foobar Agency am häufigsten begegnen. Sie unterscheiden sich nicht in der Frage, ob sie Suche können — sondern darin, welcher B2B-Use-Case darin nativ trägt, welcher über Konfiguration läuft und welcher Stack-Fit sich aus dem Lizenzmodell ergibt. Dieser Beitrag ordnet die sechs entlang der sieben Kriterien aus dem ersten Teil — und sagt, wann welche Plattform sinnvoll ist und wann nicht.

Algolia: schnelle Site-Search, starkes Merchandising

Algolia ist die wahrscheinlich am breitesten eingesetzte Such-Plattform im DACH-Mittelstand. API-first, exzellente Developer-Experience, gut dokumentierte InstantSearch-Bibliotheken und Trefferlisten in einer Latenz, die das Frontend-Team selten zum Thema machen muss. Was in Plattform-Vergleichen oft unterschätzt wird: Algolia hat 2024/2025 sein Merchandising-Backend deutlich ausgebaut. Die Merchandising Studio mit Visual Editor erlaubt drag-and-drop-Steuerung von Trefferlisten und Kategorie-Seiten, Smart Groups bündeln Kuratierungs-Logik über Search, Categories und Collections hinweg, und AI-Re-Ranking sowie Generative Shopping Guides sind 2025 produktiv. Für Merchandiser-Teams, die ohne Engineering-Ticket arbeiten wollen, ist das ein realer Hebel.

Im B2B adressiert Algolia die Kernanforderungen über Personalisierung auf Account-Ebene, gefilterte Indizes nach Berechtigungen und kundenspezifische Preis-Konfigurationen — die Dokumentation zur B2B-Katalogverwaltung beschreibt diese Muster ausdrücklich. Entitlement-Logik, Kontraktpreis-Indizes und kundenspezifische Sortimente werden am Backend zugespielt und im Index gepflegt. Algolia liefert dafür belastbare Mechanik, der konkrete Workflow für komplexe B2B-Szenarien wandert in die Architektur.

Lizenzlogik: Algolia rechnet pro Search-Request und pro indizierten Records ab, mit transparentem Listenpreis ab Grow-Tier. Bei B2B-Setups mit kundenspezifischen Indizes wächst die Record-Zahl multiplikativ — das gehört in jede TCO-Rechnung. Stack-Fit ist hoch, wenn Sie ein Composable-Setup mit commercetools, Spryker oder einer Custom-Storefront fahren und die Such- und Merchandising-Logik im eigenen Frontend orchestrieren wollen. Anti-Empfehlung: Wenn Sie einen out-of-the-box-B2B-Workflow für komplexe Kontraktpreis-Indizes und Punchout-Konnektoren erwarten, ohne dafür eigene Backend-Logik bauen zu wollen, sind die spezialisierten B2B-Plattformen der schnellere Weg.

Constructor: B2B-spezifisch, KPI-getrieben

Constructor positioniert sich explizit als enterprise-eCommerce-Plattform für Suche und Product Discovery — und hat in den letzten zwei Jahren systematisch B2B-Funktionen ausgebaut. Account-segmentierte Preise und Verfügbarkeiten, Part-Number-Suchen, dynamische Facetten und optionale Suche in ausgelisteten Artikeln sind dokumentierte Features der B2B-Lösung. Forrester hat Constructor im Wave Commerce Search and Product Discovery Solutions Q3 2025 als Leader gelistet; Gartner ebenfalls als Leader im Magic Quadrant 2025. Beides ist Marketing-Material — aber zwei unabhängige Häuser, die Constructor in B2B als ernstzunehmenden Spieler einsortieren.

Der Unterschied zu Algolia liegt im Ansatz: Constructor optimiert nicht auf Relevanz-Scores, sondern explizit auf Conversion-, Revenue- oder Margenziele. Für einen B2B-Shop mit Wiederkäufer-Verhalten und kundenspezifischen Sortimenten kann das ein deutlicher Hebel sein — die Frage ist immer, ob das KPI-Optimierungs-Modell auf B2B-typische Such-Muster (SKU-Lookups, Re-Order, Punchout) ausreichend trainiert ist. In foobar-Projekten sehen wir die besten Constructor-Ergebnisse bei Distributoren mit großen Sortimenten und klar messbarem Bestell-Conversion-Funnel.

Lizenzlogik: Usage-basiert, gestaffelt nach Such-Volumen und Feature-Set, im Enterprise-Bereich individuell. Stack-Fit: hoch bei B2B-Distributoren und Industrie-Shops mit großen Sortimenten, Wiederkäufer-Anteil und einer composable Storefront. Anti-Empfehlung: Wenn Ihr Hauptbedarf ein einfacher Site-Search-Ersatz für ein überschaubares Sortiment ist, ist Constructor preislich und konzeptionell überdimensioniert.

Bloomreach Discovery: stark in Merchandising und SKU-Logik

Bloomreach Discovery ist eine Plattform, die historisch aus dem retail-getriebenen Merchandising kommt — Bloomreach steht im Gartner Magic Quadrant 2025 als Leader und im Forrester Wave Q3 2025 ebenfalls in der Leader-Gruppe. Für B2B hat Bloomreach in den letzten Releases spezifische Features nachgezogen: SKU Select für SKU-genaues Ranking, Enhanced Lookups für Bestell- und Part-Numbers mit Sonderzeichen, NLP-Verständnis für quantitative Maße ("3/4 inch wire" als Beispiel aus der Dokumentation). 2025 ist Variant Slicing als Beta dazugekommen — also feinere Steuerung von Varianten als eigenständige Treffer.

In B2B-Projekten ist Bloomreach besonders dann stark, wenn Merchandiser-Teams die Trefferlisten aktiv pflegen — kuratierte Listen, Boost-Regeln, Saisonalitäten. Für reine SKU-Lookups ist es überdimensioniert; für ein Sortiment, in dem technische Suche und Merchandising-Steuerung zusammenkommen, ist es ein sehr ernstzunehmender Kandidat. Die kundenspezifischen Sortimente und Kontraktpreise sind über Bloomreach-Profiles und Index-Filter abbildbar, brauchen aber — wie überall — saubere Datenanbindung an ERP, PIM und Pricing-Engine.

Lizenzlogik: Enterprise-SaaS mit Jahresvertrag, kein öffentliches Preisschild. Stack-Fit: hoch bei B2B-Retailern und Hybriden mit gemischtem Sortiment, in denen Merchandising aktiv betrieben wird. Anti-Empfehlung: Wenn Sie eine schlanke Headless-Such-API für einen klar definierten technischen Use-Case suchen, ist Bloomreach mit seinem Funktionsumfang zu schwer.

FactFinder: B2B aus Pforzheim, DACH-Markt-spezifisch

FactFinder ist der DACH-native Anbieter im Vergleich. Die OMIKRON Data Quality GmbH aus Pforzheim betreibt die Plattform seit über zwei Jahrzehnten in Commerce-Projekten; nach eigenen Angaben sind über 2.000 Shops produktiv darauf — Referenzen wie OBI, STIHL, Intersport oder Bauhaus zeigen die DACH-Verankerung. Die technische Stärke liegt da, wo andere Anbieter mit englischsprachigem Default zu kämpfen haben: deutsche Compound Words, Norm-Bezeichnungen, technische Synonyme und domainspezifische Industrie-Begriffe. Wer Produktdaten in deutscher Industriesprache pflegt, merkt den Unterschied zwischen "elf-mm-schraube" und "M11 verzinkt" in der Trefferrelevanz.

B2B ist bei FactFinder kein Erweiterungs-Modul, sondern Teil des Produkt-Kerns. Account-spezifische Sortimente und Sichtbarkeiten, kundenspezifische Preise mit Vertragsbezug, standortbasierte Verfügbarkeit und KI-gestützte Re-Order-Vorschläge auf Basis der Bestellhistorie sind dokumentierte Features. Hybride Suche kombiniert Exact-, Fuzzy- und Vector-Search — die SKU-Treffer-Stärke bleibt, die semantische Erweiterung kommt obendrauf. Hosting in der EU mit DSGVO-Vertrag ist Standard, was bei datensensiblen Industrie-Setups Argumente liefert, die andere Anbieter erst über Konfiguration nachweisen.

Lizenzlogik: Enterprise-SaaS, individuelle Verträge nach Such-Volumen und Feature-Set, keine öffentliche Preisliste. Stack-Fit: hoch bei DACH-B2B-Distributoren, Industrie-Herstellern mit deutschsprachigen Sortimenten und Retailern mit gemischtem B2C-/B2B-Geschäft. Anti-Empfehlung: Wenn Ihr Geschäft primär englischsprachig und international ist, spielen FactFinders DACH-Stärken weniger aus — dann sind die globalen Plattformen meist im Vorteil.

Coveo: Enterprise Search, B2B als Stärke

Coveo kommt aus der Enterprise-Search-Welt — und das prägt das Produkt. Coveo wurde von Gartner 2025 zum zweiten Jahr in Folge als Leader im Magic Quadrant for Search and Product Discovery eingestuft. Die Plattform unterstützt sowohl Commerce-Suche als auch Wissens- und Support-Suche, was im B2B-Kontext mit Konfiguratoren, technischen Datenblättern und Service-Portalen ein realer Vorteil sein kann — eine Suche, ein Index, mehrere Touchpoints. Coveo hat 2024/25 die GenAI-Antwortfunktion "Coveo Relevance Generative Answering" auf RAG-Basis ergänzt; für B2B mit Produktdokumentation und Konfigurations-Beratung ist das eine substanzielle Erweiterung über klassische Trefferlisten hinaus.

Für kundenspezifische Sortimente, Berechtigungen und kontraktgebundene Sichtbarkeit bringt Coveo das Engineering-DNA mit, das man bei einer Enterprise-Search-Plattform erwartet: feingranulare Security-Trimming-Modelle, Source-Connectors, individuelle Re-Ranking-Pipelines. Die Kehrseite ist Komplexität: Coveo-Implementierungen sind aufwendiger als Algolia- oder FactFinder-Setups, und der Wertbeitrag entsteht erst, wenn man die Stärken auch wirklich nutzt.

Lizenzlogik: Enterprise-SaaS, individuelle Verträge, Pricing nicht öffentlich. Stack-Fit: hoch bei B2B-Unternehmen mit Service- und Wissens-Komponente neben dem Commerce-Shop, hoher Sortiments-Komplexität, dokumentenlastiger Beratung. Anti-Empfehlung: Wenn der Use-Case ein klassischer B2B-Shop ohne Service-Portal und ohne Wissens-Suche ist, kauft man bei Coveo Funktionalität, die teuer ist und brachliegt.

Elastic: Engine, kein Produkt

Elastic ist der Sonderfall in dieser Gruppe — und einer, der oft missverstanden wird. Elasticsearch ist die Engine, auf der ein erheblicher Teil moderner Suche läuft (auch im Backend mancher hier genannter Anbieter). Mit "Elastic Enterprise Search" hat Elastic in den letzten Jahren ein Produkt-Bundle dazugepackt; mit den 2024 eingeführten Vector-Search- und Semantic-Search-Funktionen bringt Elastic eine semantische Such-Schicht mit, die für technische Sortimente attraktiv ist.

Aus B2B-Sicht heißt das: Elastic ist die maximale Flexibilität — und der höchste Eigenbau-Aufwand. Kundenspezifische Sortimente, Kontraktpreis-Indexierung, Punchout-Integration sind technisch alle möglich, aber sie sind nicht das Produkt. Sie sind das, was Sie auf Elastic bauen. Für Unternehmen mit einer starken Engineering-Mannschaft, sehr individuellen Such-Anforderungen oder einer Architektur, in der Suche tief in eigene Backend-Services eingewoben ist, ist Elastic ein berechtigter Kandidat — gerade auch, weil sich der Stack on-premises oder in der eigenen Cloud betreiben lässt, was für Datenschutz-sensible Industrie-Setups ein Argument sein kann.

Lizenzlogik: Open-Source-Kern, kommerzielle Subscriptions (Standard/Gold/Platinum/Enterprise), Elastic Cloud nach Ressourcen. Stack-Fit: hoch bei Unternehmen mit eigener Engineering-Mannschaft und Anforderungen an Datenhoheit oder Stack-Tiefe. Anti-Empfehlung: Wenn Sie keine Engineering-Kapazität für eine Such-Plattform vorhalten wollen, ist Elastic der falsche Hebel — dann sind die spezialisierten SaaS-Plattformen der schnellere Weg.

Vergleichsmatrix: sechs Plattformen, sieben Kriterien

Die folgende Matrix bewertet die sechs Plattformen entlang der Kriterien aus Post 1. Die Skala ist bewusst grob — drei Stufen reichen, um eine Shortlist sauber zu schneiden. Zwei der Kriterien werden in Plattform-Briefings regelmäßig nachgefragt — deshalb hier kurz, was wir damit meinen:

Kontraktpreise in der Trefferliste heißt: Der individuell vereinbarte Preis des angemeldeten Einkäufers — abhängig von Vertrag, Account oder Kundengruppe — wird bereits in der Such-Trefferliste angezeigt, nicht erst beim Klick auf die Produktdetailseite. Das ist im B2B kein Komfort-Feature, sondern Voraussetzung dafür, dass Filter, Sortierung und Vergleiche im Treffer-Set überhaupt sinnvoll funktionieren. Im Hintergrund läuft das entweder über vorgerechnete Kontraktpreise im Suchindex oder über einen synchronen Call an die Pricing-Engine zur Suchzeit — beide Varianten haben ihren Platz und entscheiden sich an Datenvolumen, Aktualisierungs-Frequenz und Latenz-Anforderung.

Punchout-Kompatibilität heißt: Die Such-API der Lieferanten-Plattform liefert Treffer auch dann sauber aus, wenn der Einkäufer nicht im Lieferanten-Shop ist, sondern in seinem Beschaffungssystem (SAP Ariba, Coupa, Microsoft Dynamics 365 Supply Chain). Bei der häufigsten Variante — cXML Level 2 — wird die Lieferantensuche im Procurement-UI gerendert. Für die Suchplattform bedeutet das: stabile API, korrekte Kontraktpreise auch im fremden Kontext, korrekte kundenspezifische Sortimente. Native Punchout-Konnektoren liefert keine der hier genannten Such-Plattformen mit — die Integration ist in jedem Projekt eine eigene Aufgabe und sollte in der Plattform-Wahl ehrlich budgetiert werden.

Zur Bewertungsskala: "Stark" heißt, das Kriterium ist nativ erfüllt oder über einen dokumentierten Standard-Workflow abgedeckt. "Über Konfiguration" heißt, das Kriterium ist erfüllbar — über Standard-Erweiterungen, Plattform-Konfiguration oder gepflegte Index-Strukturen, mit einem bewussten Implementierungs-Schritt. "Über Eigenentwicklung" heißt, das Kriterium ist technisch machbar, aber als Engineering-Projekt im Stack zu planen. Keine der drei Stufen ist negativ — sie sind drei legitime Implementierungs-Pfade mit unterschiedlichem Investitions-Profil.

Kriterium	Algolia	Constructor	Bloomreach	FactFinder	Coveo	Elastic
SKU- / Part-Number-Suche	stark	stark	stark	stark	stark	über Konfiguration
Kundenspezifische Sortimente	über Konfiguration	stark	stark	stark	stark	über Eigenentwicklung
Kontraktpreise in Trefferliste	über Konfiguration	stark	über Konfiguration	stark	stark	über Eigenentwicklung
Punchout-Kompatibilität	über Eigenentwicklung	über Konfiguration	über Konfiguration	über Konfiguration	über Konfiguration	über Eigenentwicklung
Semantische / NLP-Suche	stark	stark	stark	stark	stark	über Konfiguration
Merchandising / Kuratierung	stark	stark	stark	stark	stark	über Eigenentwicklung
Lizenz / TCO im B2B	mittel	hoch	hoch	mittel–hoch	hoch	variabel

Die Bewertungen sind im foobar-Implementierungs-Kontext zu lesen: Sie spiegeln nicht das, was technisch theoretisch geht, sondern das, was im Projekt mit vertretbarem Aufwand und stabilem Betrieb ankommt.

Die Plattform-Wahl entscheidet sich in B2B-Projekten selten am Feature-Datenblatt. Sie entscheidet sich an drei Fragen: Wie tief sitzen Kontraktpreise und Sortimente in Ihrem ERP, wie viel Engineering wollen Sie für die Suche selbst vorhalten, und wo soll die Suche in fünf Jahren stehen? Wer diese drei Fragen vor dem RFP beantwortet, kommt mit zwei Plattformen in die Shortlist statt mit sechs — und spart sich ein halbes Jahr Vergleichs-Workshops.
— Matthias Dietrich, CEO foobar Agency

Häufig gestellte Fragen

Welche Suchplattform ist am günstigsten?

"Am günstigsten" ist im B2B die falsche Frage — die Such-Lizenz ist selten der dominierende Kostenblock. Algolia hat ein transparentes Listenpreismodell, alle anderen sind im Enterprise-Bereich verhandelt. Entscheidender für den TCO sind Implementierungs-Aufwand, ERP-Anbindung, Index-Pflege und Re-Ranking-Logik. Eine Plattform, die billig in der Lizenz und teuer in der Eigenentwicklung ist, kostet am Ende mehr als eine spezialisierte B2B-Lösung.

Können wir die Suche aus unserem Shopsystem behalten?

Für überschaubare Sortimente und einfache Kundengruppen-Strukturen oft ja — das hängt am Shopsystem. commercetools, Spryker und OroCommerce haben eingebaute Such-Endpunkte, die für viele Standardfälle reichen. Sobald kundenspezifische Sortimente in der Trefferliste, Kontraktpreise als Sortierkriterium oder Punchout-Szenarien dazukommen, stoßen Shop-Suchen meist an Grenzen. Die ehrlichere Frage ist: Welcher Such-Use-Case ist heute schmerzhaft, und wo wollen Sie in 24 Monaten stehen?

Was kostet eine Migration zu einer dedizierten Such-Plattform?

Verlässlich nur im Discovery-Projekt zu schätzen. Treiber sind: Sortimentsgröße und Anzahl der Sprach-/Länder-Indizes, Komplexität der Berechtigungslogik, ERP- und PIM-Anbindung, Pricing-Engine-Integration, Frontend-Anpassung. In foobar-Projekten sehen wir B2B-Such-Migrationen typischerweise als drei- bis sechsmonatige Implementierungen mit klarer Roll-out-Reihenfolge — selten als Big Bang, fast immer mit einem Pilot-Sortiment oder einem Pilot-Markt.

Plattform-Auswahl B2B-Suche

In einem zweistündigen Discovery-Workshop bei foobar Agency schneiden wir die Plattform-Shortlist für Ihren B2B-Stack zu — entlang Ihrer Sortiments-Struktur, Ihrer Vertrags-Logik und Ihrer ERP-Anbindung. Verankert in Ihren Prozessen, vernetzt mit Ihren Daten, vorausgedacht für die nächsten Architektur-Schritte. Im nächsten Teil der Serie zeigen wir, wie kundenspezifische Sortimente technisch sauber in die Suche kommen — Vorschau auf Post 3: Customer-specific Search. Wenn die Datenseite Sie ebenso beschäftigt wie die Such-Auswahl, lohnt der Blick in die parallele Serie: Snowflake-Foundation für Commerce-Daten.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/b2b-suche-plattform-vergleich-algolia-constructor-bloomreach-factfinder-coveo-elastic

Snowflake im Commerce: Vom Datensilo zur gemeinsamen Architektur

Dominik Thalmeier — Thu, 04 Jun 2026 00:00:00 GMT

Commerce-Daten leben in Silos. Der Shop kennt die Bestellung, das ERP kennt die Lieferung, das CRM kennt den Ansprechpartner, der Marketing-Stack kennt die Kampagne, das Service-Tool kennt den Fall — und jede dieser Welten hat eine eigene Definition davon, was "Kunde" und "Umsatz" eigentlich bedeuten. Aus Sicht von CDOs und CIOs wird das spürbar, sobald CLV-Reports, Margenanalysen und Kampagnen-ROI nebeneinanderliegen und sich gegenseitig widersprechen. Eine Data Foundation auf Snowflake mit dbt-Modellierung ist die Antwort, die wir in den letzten Jahren in DACH-Commerce-Projekten am häufigsten gebaut haben — weil sie genau diesen Widerspruch auflöst, ohne dass das Operating Model umgebaut werden muss. Dieser Beitrag zeigt, warum Commerce-Daten fragmentiert sind, was sich mit einer gemeinsamen Architektur ändert und wie Snowflake sich von BigQuery, Databricks und Redshift abgrenzt. Dieselbe Frage besprechen wir auch im Podcast What Works Tomorrow in der Folge Warum KI-Projekte an der Datenarchitektur scheitern.

Warum Commerce-Daten fragmentiert sind

Die Datenlandschaft im Commerce ist über Jahre gewachsen, nicht entworfen. Typisch sehen wir bei Retailern und Industrie-Herstellern fünf bis sieben operative Systeme, von denen jedes für sich gut funktioniert, aber kein gemeinsames Datenmodell teilt: Shop-Plattform (Shopware, commercetools, Spryker), ERP (SAP S/4HANA, Microsoft Dynamics, Infor), CRM (Salesforce, HubSpot, Dynamics 365), Marketing-Stack (Klaviyo, Emarsys, Adobe Campaign), Service-Tool (Zendesk, Salesforce Service Cloud), PIM und in vielen Fällen ein Subscription- oder Loyalty-System.

Jedes dieser Systeme schreibt seine eigene Wahrheit. Der Shop schließt eine Bestellung mit Brutto-Umsatz ab; das ERP verbucht sie netto, mit Rabatten, Storno- und Retourpositionen; das CRM kennt nur das Kontaktereignis. Die Folge ist nicht nur ein Reporting-Problem — sie ist ein Definitions-Problem. Marketing optimiert auf Brutto-Umsatz, Controlling rechnet mit Netto-Marge, Vertrieb misst Pipeline. Drei Säulen, drei Wahrheiten.

Dazu kommt das Identitäts-Problem. Im B2C heißt ein Kunde in fünf Systemen oft fünfmal anders — Gast-Bestellung im Shop, eMail-Hash im Marketing-Stack, Kundennummer im ERP, Account im CRM, Ticket-ID im Service. Im B2B wird es komplexer: Buying Center, Mehr-Niederlassungs-Strukturen und kontraktbasierte Sortimente bedeuten, dass ein "Kunde" auch eine Hierarchie sein kann. Wer CLV ohne saubere Identity-Resolution rechnet, summiert systematisch falsch.

Solange diese Systeme nur untereinander Daten austauschen — Punkt-zu-Punkt-Integrationen, nächtliche Exporte, BI-Tools mit eigenen Connectoren — wächst die Komplexität quadratisch. Jede neue Quelle bedeutet n neue Verbindungen. Eine gemeinsame Datenebene reduziert diese Komplexität auf 1:n.

Snowflake und dbt als gemeinsame Datenebene

Snowflake ist eine Cloud-Datenplattform mit getrennter Compute- und Storage-Architektur: Daten liegen einmal, Workloads laufen in unabhängigen Virtual Warehouses. Das ist die technische Voraussetzung dafür, dass Marketing, Controlling, Data Science und BI gleichzeitig auf demselben Datenbestand arbeiten können, ohne sich gegenseitig zu blockieren. dbt (data build tool) ergänzt diese Plattform um eine deklarative Modellierungsschicht in SQL — versionierbar in Git, mit Tests, Lineage und Dokumentation.

In foobar-Projekten arbeiten wir mit vier Schichten, die sich in der dbt-Community als Standard etabliert haben:

- raw — die unveränderten Ingestion-Tabellen aus den Quellsystemen, beladen über Connectoren wie Fivetran, Airbyte oder Snowpipe. - staging — typisierte, umbenannte, eindeutig referenzierte Versionen der Quelltabellen. Eine staging-Schicht pro Quellsystem. - intermediate — Joins, Identity-Resolution, Business-Logik, die noch nicht reportingfähig ist, aber als Baustein wiederverwendet wird. - marts — fachliche Modelle nach Domäne: `marts.commerce`, `marts.marketing`, `marts.finance`. Hier liegen die Tabellen, auf denen Dashboards und KI-Modelle aufsetzen.

Diese Schichtung ist konzeptionell nah an der "Bronze/Silver/Gold"-Logik aus dem Databricks-Lakehouse-Vokabular, in der dbt-Welt sind die Begriffe raw/staging/intermediate/marts üblicher. Inhaltlich gleich, terminologisch sauberer für ein Snowflake-Setup.

Was sich konkret ändert, sobald diese Foundation steht: CLV, Umsatz und Marge haben genau eine Definition. Die `dim_customer`-Tabelle in `marts.commerce` ist die Single Source of Truth — Marketing-Automation, Service-Routing, Forecasting und Vorstand-Reporting ziehen aus derselben Quelle. Metriken werden in dbt einmal definiert und überall identisch konsumiert. Diskussionen darüber, wessen Zahl stimmt, hören nicht auf, weil Menschen anders rechnen — sie hören auf, weil das Modell verbindlich ist.

Architektur-Skizze: Quellen, Schichten, Anwendungen

Eine Commerce-Data-Foundation auf Snowflake lässt sich in drei Spalten denken — Quellen links, Snowflake-Schichten in der Mitte, Anwendungen rechts. Auf der Quellen-Seite stehen Shop, ERP, CRM, Marketing-Stack, Service und PIM. Über Connectoren landen ihre Tabellen in `raw` — als rohe, schemastabile Spiegelung der Quelle, idealerweise mit Change-Data-Capture, damit Veränderungen und nicht nur Endstände ankommen.

In der Mitte modelliert dbt die staging-Schicht (Typisierung, Umbenennung), die intermediate-Schicht (Joins, Identity-Resolution, Sessionizing) und die marts-Schicht (Dimensionen und Fakten je Domäne). Hier entstehen die zentralen Tabellen: `dim_customer`, `dim_product`, `fct_orders`, `fct_marketing_touchpoints`, `fct_service_cases`. dbt-Tests überwachen Eindeutigkeit, Vollständigkeit, Wertebereiche; die generierte Dokumentation zeigt, woher jede Spalte stammt.

Auf der Anwendungs-Seite konsumieren vier typische Zielgruppen das gleiche Datenmodell: BI-Tools (Looker, Tableau, Power BI) für Reporting; Marketing-Automation für Segmente und Kampagnen; Operations und Service für Echtzeit-Lookups; Data Science für Modelle wie CLV, Churn und Next-Best-Action. Snowflake Cortex ergänzt diese Schicht um native ML- und LLM-Funktionen, die direkt auf den modellierten Tabellen arbeiten — ohne Daten in eine separate ML-Plattform exportieren zu müssen.

Diese Architektur ist nicht spektakulär. Sie ist verankert in den Geschäftsprozessen, vernetzt zwischen Commerce und Intelligence-Layer und vorausgedacht, weil neue Quellen oder Anwendungen sich an die Foundation anhängen, statt einen weiteren Punkt-zu-Punkt-Connector zu erzeugen.

Snowflake, BigQuery, Databricks, Redshift: drei Entscheidungskriterien

Die Frage, welche Plattform die richtige ist, lässt sich nicht aus dem Stand beantworten. Sie hängt an drei Kriterien, die wir in Architektur-Workshops konsequent durchgehen.

Erstens: Multi-Cloud. BigQuery ist eng an Google Cloud gebunden, Redshift an AWS, Azure Synapse an Microsoft. Snowflake läuft nativ auf AWS, Azure und GCP — derselbe Account kann Workloads auf verschiedenen Cloud-Providern haben. Für DACH-Konzerne mit hybriden Cloud-Strategien (z. B. SAP-Welt auf Azure, Analytics auf AWS) ist das ein realer Unterschied. Databricks ist ebenfalls Multi-Cloud, aber funktional ein Lakehouse, kein klassisches Warehouse — die Stärken liegen bei Streaming, Spark-Workloads und ML-Plattformen.

Zweitens: Workload-Trennung. Snowflakes getrennte Virtual Warehouses bedeuten, dass ein BI-Dashboard, ein nightly dbt-Run und ein ad-hoc Data-Science-Notebook unabhängig voneinander skalieren. Bei BigQuery teilen sich Slots; bei Redshift skaliert man Cluster oder nutzt Serverless. Wer viele konkurrierende Workloads hat — Reporting, Marketing-Automation, Forecasting, ML-Training — bekommt mit Snowflake die einfachste Isolation.

Drittens: Data Sharing. Snowflake teilt Daten Account-übergreifend, ohne sie zu kopieren. Im Commerce-Kontext heißt das: Lieferanten-Daten, POS-Daten von Filialpartnern oder Marktforschungs-Quellen können live eingebunden werden. Für Retailer mit Marktplatz-Strategien oder Industrie-Hersteller mit Händlernetz ist das eine Funktion, die in BigQuery (Analytics Hub) und Databricks (Delta Sharing) zwar Pendants hat, in Snowflake aber am längsten ausgereift ist.

Keines dieser Argumente macht Snowflake universell zur richtigen Wahl. Aber sie sind die drei Fragen, an denen sich Entscheidungen meistens belastbar festmachen lassen.

Fünf Anzeichen, dass Ihre Commerce-Daten eine Foundation brauchen

Wenn Sie in einer Architektur-Bewertung einen schnellen Check brauchen — diese fünf Anzeichen sehen wir in Workshops am häufigsten als Auslöser für ein Foundation-Projekt.

#	Anzeichen	Was es bedeutet
1	Marketing, Vertrieb und Controlling haben drei verschiedene Umsatzzahlen	Definitionen sind nicht abgestimmt; jede Quelle rechnet anders
2	Eine neue Kampagne braucht zwei Wochen Datenvorlauf	Identity-Resolution und Segmentierung passieren manuell, nicht im Modell
3	CLV existiert als Konzept, aber als Zahl nur in PowerPoint	Es gibt keine produktive Tabelle, die mehrere Teams konsumieren
4	Jede neue Datenquelle braucht einen neuen Connector zu jedem Ziel	Punkt-zu-Punkt-Integration statt zentraler Datenebene
5	BI-Reports und Marketing-Segmente weichen voneinander ab	Keine gemeinsame dim_customer; jedes Tool zieht aus eigener Quelle

Branchenfall: RFM-basierte CLV bei einem DACH-Multi-Channel-Händler

Ein Multi-Channel-Händler aus dem DACH-Raum mit eigener TV-, Online- und App-Präsenz hat mit foobar Agency eine Customer-Lifetime-Value-Prediction auf Snowflake mit dbt umgesetzt. Die Ausgangslage war typisch: Bestelldaten im ERP, Kontaktereignisse in mehreren Marketing-Tools, Stammdaten im CRM, Kundenservice-Daten in einem dritten System. Eine konsistente Aussage über Kundenwert war über Reports hinweg nicht herstellbar.

Die Foundation entstand in drei Schritten. Erstens: Identity-Resolution. Bestellungen, Kontaktpunkte und Service-Fälle wurden über deterministische Schlüssel (Kundennummer, Hash-eMail, Telefonnummer) und probabilistische Fallbacks zu einer eindeutigen `dim_customer`-Identität zusammengeführt. Zweitens: RFM-Berechnung. Auf der Fakten-Tabelle `fct_orders` werden in dbt Recency, Frequency und Monetary Value pro Kunde berechnet — deterministisch, nachvollziehbar, mit dbt-Tests gegen Definitions-Drift abgesichert. Drittens: Probabilistische CLV-Prediction. Auf Basis der RFM-Features läuft ein Modell der BG/NBD- und Gamma-Gamma-Familie, das die erwartete Anzahl und den erwarteten Wert zukünftiger Käufe pro Kunde schätzt.

Das Ergebnis ist nicht ein Dashboard, sondern eine Tabelle: `marts.commerce.customer_clv` enthält für jeden Kunden einen Recency-Wert, ein RFM-Segment, einen historischen Wert und eine probabilistische Vorhersage. Marketing nutzt sie für Segmente und Aussteuerung, Service nutzt sie für Eskalations-Routing, Controlling nutzt sie für Kohorten-Reporting. Dieselbe Tabelle, dieselbe Definition — kein Datenbank-Tourismus mehr zwischen den Teams. Wie die RFM-basierte CLV-Logik im Detail funktioniert und warum sie probabilistischen Modellen den Vorzug vor reinen ML-Black-Boxes gibt, behandelt der Beitrag RFM und CLV: Wer Ihre wertvollsten Kunden sind.

Eine Datenarchitektur ist erst dann eine Foundation, wenn drei Teams aus drei Welten dieselbe Zahl ziehen und keiner mehr nachfragt, wessen Definition jetzt gilt. Snowflake und dbt sind keine Magie — sie zwingen uns, Definitionen einmal sauber zu schreiben und dann produktiv zu machen. Der Effekt zeigt sich in jedem Projekt zuerst dort, wo CLV, Marge und Kampagnen-ROI vorher dauernd auseinanderliefen.
— Dominik Thalmeier, Team Lead Data Science foobar Agency

Häufig gestellte Fragen

Brauche ich Snowflake, wenn ich bereits BigQuery habe?

Nicht zwingend. Wenn Ihre Welt vollständig in Google Cloud liegt und Workload-Trennung kein Problem darstellt, ist BigQuery eine valide Wahl. Snowflake wird relevant, wenn Sie Workloads über AWS, Azure und GCP verteilen, wenn konkurrierende Workloads sich gegenseitig ausbremsen oder wenn Sie Daten cross-account teilen wollen. Die Modellierungs-Logik in dbt funktioniert auf beiden Plattformen — eine Migration zwischen den Warehouses ist machbar, aber kein triviales Wochenende-Projekt.

Wie lange dauert ein Snowflake-Setup im Commerce-Kontext?

Ein produktives Minimum-Setup mit drei bis vier angebundenen Quellen, raw/staging/intermediate/marts-Schichten und einer ersten domänenspezifischen Marts-Schicht (z. B. Commerce) sehen wir in der Regel bei zwölf bis sechzehn Wochen. Voraussetzung ist, dass die Quellsysteme klar definiert sind und ein Daten-Owner pro Quelle benannt ist. Identity-Resolution und KI-Use-Cases wie CLV-Prediction folgen anschließend in iterativen Schritten — sie sind keine Voraussetzung für Schritt eins.

Was kostet Snowflake im Commerce-Kontext?

Snowflake ist consumption-based: Sie zahlen Compute-Credits nach genutzter Warehouse-Laufzeit und Storage nach Datenvolumen. Im Commerce-Kontext mit gut modellierter dbt-Pipeline und sauber konfigurierten Virtual Warehouses (Auto-Suspend, Größen-Tuning) liegen die laufenden Plattformkosten meist deutlich unter den Tool-Kosten, die durch redundante BI-, CDP- und Analytics-Stacks entstehen. Belastbare Zahlen entstehen erst nach einem Workload-Assessment — pauschale Monatswerte ohne Workload-Profil sind selten aussagekräftig.

Daten-Foundation-Workshop

In zwei Stunden klären wir bei foobar Agency mit Ihnen, welche Quellen Ihre Foundation tragen muss, welche Metriken sich zuerst auflösen lassen und ob Snowflake, BigQuery oder Databricks zu Ihrer Cloud-Landschaft passt — mit Hand am Architektur-Bild, nicht mit Folien.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/snowflake-im-commerce-vom-datensilo-zur-gemeinsamen-architektur

Warum B2B-Suche eigene Spielregeln hat

Matthias Dietrich — Mon, 01 Jun 2026 00:00:00 GMT

Wenn der Einkäufer „M8x40 verzinkt“ tippt und nichts findet, verlieren Sie keinen Klick — Sie verlieren einen Auftrag.

B2B-Suche wird in vielen Projekten wie B2C-Suche mit anderen Produkten behandelt. Das geht oft eine Weile gut — bis die ersten Großkunden in Live-Demos zeigen, dass ihre Bestellnummern keine Treffer liefern, ihre Kontraktpreise nicht in der Trefferliste auftauchen oder ihr individuell freigeschaltetes Sortiment plötzlich Artikel zeigt, die sie gar nicht bestellen dürfen.

In B2B-Implementierungen sehen wir das Muster seit Jahren wiederkehren: Die Suche wird zuletzt geplant, oft als Feature des Shopsystems mitgeliefert — und ist dann der erste Punkt, an dem Einkäufer das System wieder verlassen. Dieser Beitrag zeigt sieben Eigenheiten, die B2B-Suche von B2C unterscheiden, und was sie für Architektur, Plattform-Wahl und ERP-Anbindung bedeuten.

Der Profi sucht anders

B2B-Einkäufer wissen meist, was sie wollen. In B2B-Implementierungen bei foobar Agency sehen wir regelmäßig, dass ein erheblicher Teil der Suchanfragen nicht aus generischen Produktbegriffen besteht, sondern aus SKUs, Bestellnummern, Norm-Bezeichnungen oder technischen Maßen. Eine Suche nach „M8x40 verzinkt“ ist kein Browser-Verhalten — das ist der direkte Zugriff auf einen bekannten Artikel im Sortiment.

Das hat Konsequenzen für das Ranking: Im B2C ist Exact-Match nur eine Komponente neben Personalisierung, Verkaufsdaten und Trends. Im B2B muss eine eindeutige SKU- oder Bestellnummer-Suche praktisch immer den exakten Artikel ganz oben liefern — bevor Synonyme, Empfehlungen oder Personalisierungsmodelle eingreifen. Suchplattformen, die ihr Ranking primär auf Click-Through-Verhalten optimieren, treffen hier auf ein Verhalten, das sie selten gut bedienen: Profis klicken, weil sie müssen — nicht, weil das Ranking sie überzeugt hat.

Dazu kommt das Re-Order-Verhalten. Ein erheblicher Teil der B2B-Aufträge sind Wiederholungskäufe. Suche im B2B ist deshalb oft kein Discovery-Tool, sondern ein schneller Zugriffspfad auf bekannte Artikel — und sollte sich entsprechend verhalten. Was Ihre Such-Logs zeigen — welche Bestellnummern nicht treffen, welche Synonyme fehlen, welche Wiederholungs-Suchen scheitern — ist eines der präzisesten Datenfundamente, die ein B2B-Shop hat. Wer es nicht auswertet, lässt Umsatzpotenzial im Index liegen.

Sortiment ist persönlich

Im B2C bedeutet Personalisierung: Vorlieben, Empfehlungen, kuratierte Auswahl. Im B2B bedeutet sie etwas grundlegend anderes — sie ist eine Frage von Berechtigungen, nicht von Geschmack. Welche Artikel ein Einkäufer überhaupt sehen darf, ergibt sich aus dem Kundenvertrag, der Account-Konfiguration, regionalen Freigaben und manchmal sogar der Rolle des Mitarbeiters innerhalb des Kundenunternehmens.

Plattformen wie commercetools, OroCommerce und Spryker bilden diese Logik über Customer-Groups, Business Units beziehungsweise Company-Hierarchien und kontraktgebundene Preis- und Kataloglisten ab. Für die Suche heißt das: Sie muss das individuelle Sortiment des angemeldeten Einkäufers indizieren — nicht das Gesamtsortiment des Shops. Ein Artikel, den ein bestimmter Kunde nicht bestellen darf, hat in seiner Trefferliste nichts verloren. Auch nicht als ausgegrauter, „auf Anfrage verfügbarer“ Treffer — das produziert Reklamationen, keine Aufträge.

Architektonisch gibt es dafür drei gängige Muster: Multi-Tenant-Indizes (ein Index pro Kunden-Gruppe), gefilterte Indizes (ein gemeinsamer Index mit Sichtbarkeits-Filter zur Suchzeit) und serverseitiges Re-Ranking nach der Suche. Welches Muster trägt, hängt davon ab, wie groß Ihr Sortiment, wie viele Kunden-Sortimente und wie häufig Vertragsänderungen sind. Die Frage entscheidet sich an Skalierung und Performance — und sollte vor der Plattform-Wahl beantwortet sein.

Preis ist Vertragssache

Im B2B sehen verschiedene Kunden für denselben Artikel verschiedene Preise — und sie sehen sie nicht erst auf der Produktdetailseite, sondern in der Trefferliste. Sortier-Funktionen, Filter und Vergleiche der Kunden hängen an diesem Preis. Wer in der Trefferliste den Listenpreis zeigt und erst beim Klick den Kontraktpreis nachlädt, sortiert seine Trefferliste über alle Suchanfragen hinweg falsch.

Es gibt zwei Architektur-Optionen. Erstens: Der Kontraktpreis wird zur Suchzeit aus dem ERP, der Pricing-Engine oder einem Caching-Layer gezogen und in die Trefferliste eingespielt — was Latenz und Last bedeutet. Zweitens: Kontraktpreise werden vorberechnet in den Suchindex geschrieben, kunden- oder kunden-gruppen-spezifisch — was Index-Größe und Update-Frequenz bedeutet. Beide Wege haben Berechtigung. Welcher trägt, hängt an der Anzahl der Kunden, der Volatilität der Preise und der Anforderung an Echtzeit-Konsistenz.

Was nicht trägt, ist die dritte Option: nur Listenpreise zeigen und den Kunden bitten, „den finalen Preis im Warenkorb“ zu prüfen. Das ist in Live-Demos der Punkt, an dem CIOs aufhören mitzulesen.

Der Kontext zählt: Punchout, Konfiguratoren, ERP

B2B-Suche endet nicht an der Shop-Domain. Über cXML — 1999 von Ariba eingeführt, seit der SAP-Übernahme 2012 SAP-eigen — und OCI, einen SAP-Standard, der sich als De-facto-Norm im E-Procurement etabliert hat, landen Einkäufer aus ihrem ERP-Beschaffungstool im Lieferanten-Katalog. SAP Ariba unterstützt beide Protokolle; Coupa und Microsoft Dynamics 365 Supply Chain setzen primär auf cXML. Bei der Level-2-Variante von cXML laufen Suche und Trefferdarstellung direkt im Ariba-UI — Treffer aus dem Lieferantenkatalog werden in der Beschaffungsoberfläche gerendert, ohne dass der Einkäufer die Ariba-Session verlässt. Eine B2B-Suche muss dafür API-fähig sein und in fremden UI-Kontexten brauchbare Ergebnisse liefern — inklusive der korrekten Kontraktpreise.

Konfigurator-getriebene Produkte sind die zweite Sonderform. Ein Sortiment, in dem Varianten erst durch Auswahl entstehen — Längen, Materialien, Beschichtungen, Toleranzen — kann nicht mit klassischem SKU-Indexing arbeiten. Suche muss hier Konfiguratoren entweder umgehen (Basis-SKU als Treffer, Konfiguration im PDP) oder die häufigsten Konfigurations-Varianten als virtuelle SKUs in den Index aufnehmen.

Drittens: Lagerstand und Lieferzeit. Der Sana-Commerce-B2B-Buyer-Report 2025 nennt fehlende Transparenz zu Bestand und Lieferzeiten als wichtigste Frustration der Einkäufer — 40 Prozent der Befragten geben das als Top-Problem an. Suche-Ergebnisse ohne aktuelle Bestandsdaten erzeugen Aufträge, die in der Auftragsbestätigung kippen — und beschädigen das Vertrauen, das im B2B länger braucht als ein Klick.

Sieben Anforderungen, die B2C-Suche nicht erfüllt

Wenn Sie in einer Plattform-Bewertung einen schnellen Check brauchen — diese sieben Anforderungen scheiden im B2B regelmäßig die Suche, die trägt, von der Suche, die nur funktioniert.

Anforderung	Begründung
SKU- und Bestellnummern-Suche mit Exact-Match-Priorität	Profis tippen Artikelnummern — nicht Beschreibungen.
Technische Facetten: Norm, Werkstoff, Maße, Mengeneinheiten	Filter im B2B sind technische Spezifikationen, keine Style-Optionen.
Kundenspezifische Sortimente (Entitlement-Logik)	Was ein Kunde sieht, ist eine Frage des Vertrags, nicht der Vorliebe.
Kontraktpreise in der Trefferliste	Filter und Sortierung hängen am individuellen Preis.
Re-Order-Hinweise und Bestellhistorie	Wiederholungskäufe machen einen großen Teil des B2B-Volumens aus.
Punchout-Kompatibilität (cXML Level 2, OCI)	Suche muss im Kontext fremder Beschaffungssysteme funktionieren.
Mehrsprachige technische Begriffe	DIN/ISO-Bezeichnungen und Branchenjargon sind nicht übersetzbar wie Marketingtexte.

B2B-Suche ist der unterschätzte Hebel. Sie sitzt am Punkt, an dem Vertragspreise, Sortimente und Einkäuferverhalten zusammenkommen — und sie ist gleichzeitig der erste Schritt, an dem viele B2B-Plattformen ihr Versprechen brechen. Wer hier sauber baut, baut die nächsten drei Jahre Wachstum ein.
— Philipp Krueger, Co-CEO, foobar Agency

Häufig gestellte Fragen

Reicht die Suche aus meinem Shopsystem aus?

Für kleine bis mittelgroße Sortimente und einfache Kundengruppen-Strukturen oft ja. Sobald Sie mit kundenspezifischen Sortimenten, Kontraktpreisen in Trefferlisten oder Punchout-Anbindungen arbeiten, stoßen Shopsystem-Suchen in der Regel an Grenzen — entweder bei der Performance oder bei der Differenzierbarkeit des Indexings.

Was ist der Unterschied zwischen Site Search und Enterprise Search?

Site Search ist auf einen Storefront-Kontext optimiert: ein Sortiment, ein Index, ein Mandant. Enterprise Search ist auf Mandanten-, Berechtigungs- und Quellen-Komplexität ausgelegt — verschiedene Sortimente, verschiedene Sichtbarkeitsregeln, Anbindung an mehrere Datenquellen. Für die meisten B2B-Setups ist eine Site-Search-Plattform mit B2B-Erweiterung der pragmatischere Weg als reine Enterprise-Search.

Welche Suchplattformen sind im B2B üblich?

Im DACH-Markt am häufigsten begegnen uns Algolia, FactFinder, Constructor, Bloomreach Discovery, Coveo und Elastic — jeweils mit unterschiedlichen Stärken bei B2B-Anforderungen. Im nächsten Teil der Serie, dem Plattform-Vergleich zur B2B-Suche, vergleichen wir die sechs entlang der sieben Kriterien aus diesem Beitrag.

Architektur-Workshop B2B-Suche

In zwei Stunden klären wir bei foobar Agency mit Ihnen, welche Such-Architektur zu Ihrem Sortiment, Ihren Verträgen und Ihrem ERP passt — mit Hand an den Plattform-Optionen, nicht mit Folien.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/warum-b2b-suche-eigene-spielregeln-hat

Aus Praxis wird Partnerschaft: foobar Agency und Snowflake besiegeln Zusammenarbeit

Matthias Dietrich — Wed, 27 May 2026 00:00:00 GMT

Aus jahrelanger Zusammenarbeit wird offizielle Partnerschaft: foobar Agency ist ab heute Mitglied im Snowflake-Partnernetzwerk. Die Münchner Agentur baut seit Jahren Snowflake-basierte Datenarchitekturen für Commerce- und Industrieunternehmen — der Status formalisiert nun, was im Tagesgeschäft längst gelebte Realität ist.

foobar Agency setzt Snowflake seit mehreren Jahren als zentrale Datenplattform in Kundenprojekten ein — von der initialen Datenmodellierung mit dbt über deterministische Berechnungen bis zu probabilistischen KI-Predictions wie Customer Lifetime Value, Churn-Indikatoren und Next-Best-Action-Empfehlungen. Ein Referenzprojekt ist die RFM-basierte CLV-Prediction für Home Shopping Europe (HSE), bei der deterministische Berechnung und KI-Vorhersage in einer gemeinsamen Snowflake-Architektur vereint wurden.

Daten-Projekte führt foobar Agency dabei nicht ausschließlich in Verbindung mit Commerce-Architekturen aus. Eigenständige Snowflake-Initiativen für B2B-Vertrieb, Service-Analytik, Forecasting und After-Sales bei Industriekunden gehören ebenso zum Portfolio — auch dort, wo der Commerce-Stack unverändert bleibt oder gar nicht im Projektfokus liegt. Die Verzahnung von Commerce und Daten bleibt die Spezialität der Agentur, ist aber kein Eintrittsticket: Snowflake-Projekte werden auch als reine Daten-Mandate aufgesetzt.

Mit der offiziellen Partnerschaft erhält foobar Agency direkten Zugang zu den technischen Programmen, Zertifizierungen und Roadmap-Informationen von Snowflake. Für Kunden bedeutet das einen kürzeren Weg zu neuen Datenfunktionen sowie eine engere Abstimmung bei plattformnahen Architekturentscheidungen.

In das integrierte Angebot der Agentur fügt sich die Partnerschaft als Vertiefung des Data Layers ein. Im Zusammenspiel mit Commerce-Mandaten bildet Snowflake gemeinsam mit commercetools die Architekturbasis — eingebettet in eine Composable Architektur mit ergänzenden Partnerlösungen für Content, Search und Discovery. In reinen Daten-Mandaten steht Snowflake eigenständig im Zentrum.

»Snowflake ist für uns kein nachgelagertes Reporting-Tool, sondern Bestandteil der Plattform, auf der unsere Kunden Commerce und Daten gemeinsam betreiben«, sagt Philipp Krueger, Co-CEO der foobar Agency. »Die offizielle Partnerschaft gibt unseren Projekten den direkten Draht in die Snowflake-Roadmap — davon profitieren vor allem Kunden, die ihre Datenstrategie skalieren wollen.«

"Datenarbeit zahlt sich für Unternehmen in zwei Richtungen aus — bei den Kosten und beim Umsatz", sagt Dominik Thalmeier, Team Lead Data Science bei foobar Agency. "Konkret heißt das zum Beispiel: passgenauere Rückstellungen, präzisere Forecasts und effizienteres Marketing-Spending auf der Kostenseite — CLV-basierte Kundenansprache und treffsichere Personalisierung auf der Umsatzseite. Mit der offiziellen Snowflake-Partnerschaft bringen wir solche Hebel schneller in Kundenprojekten zur Wirkung."

Über foobar Agency

foobar Agency ist eine inhabergeführte Digitalagentur mit Sitz in München. Seit der Gründung 2015 implementiert sie komplexen B2C-, B2B- und D2C-Commerce sowie digitale Experiences für Hersteller, Retailer und Marken im DACH-Raum – auf Basis von commercetools und Snowflake in einer Composable Architektur.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/aus-praxis-wird-partnerschaft-foobar-agency-und-snowflake-besiegeln-zusammenarbeit

Wie wähle ich die richtige eCommerce-Agentur für B2B? 7 Fragen, die Sie stellen sollten – bevor Sie beauftragen

Matthias Dietrich — Mon, 25 May 2026 00:00:00 GMT

Ein B2B-Commerce-Projekt ist keine Website-Erneuerung. Es ist eine strategische Investition in Ihre Vertriebsinfrastruktur. Die Wahl der falschen Agentur kostet nicht nur Geld, sondern Jahre. Fünf Jahre eines schlechten Systems bedeuten verlorene Marktanteile, Frustration im Vertrieb, und Kundenabwanderung.

Die richtige Agentur zu finden ist schwerer, als es aussieht. Der Markt ist fragmented. Es gibt Website-Agenturen, die sich als Commerce-Experten ausgeben. Es gibt reine Technologie-Partner, die kein Business-Verständnis mitbringen. Und es gibt Agentur-Netzwerke, die einen Hersteller präferieren und keine echten Alternativen anbieten.

Diese 7 Fragen helfen Ihnen, die Spreu vom Weizen zu trennen.

Frage 1: Welche B2B-Referenzen haben Sie in meiner Branche oder ähnlichen Branchen?

Die erste Frage ist eine Screening-Frage. B2B und B2C sind fundamental verschieden. Eine Agentur, die 50 erfolgreiche D2C-Stores gebaut hat, kann Ihre Anforderungen nicht verstehen.

Was Sie hören wollen:

Projekte in der Fertigungsindustrie, im Großhandel oder in Distributionen
Unternehmen mit einer Größenordnung ähnlich der Ihren (ein 500-Mann-Unternehmen hat andere Probleme als ein 5.000-Mann-Konzern)
Namen, die Sie überprüfen können (nicht: "mehrere DAX-Unternehmen" – sondern echte Referenzen)

Red Flag: "Wir machen alles – D2C, B2B, B2C, Marktplätze für Startups, Mittelstand und Konzern." Ein Unternehmen, das alles gleich gut macht, macht nichts richtig.

Frage 2: Wie gehen Sie ERP-Integrationen an – und welche Systeme kennen Sie?

Dies ist die technische Knockout-Frage. Eine B2B-eCommerce-Plattform ohne starke ERP-Integration ist ein teures Spielzeug.

Was Sie hören wollen:

Konkrete Integrationserfahrung mit SAP, NetSuite, Microsoft Dynamics, Sage oder den Systemen, die in Ihrer Branche standard sind
Ein klares Verständnis davon, wie Bestände, Preise, Kundenstamm und Aufträge aus dem ERP in den Shop fließen
Erfahrung mit typischen Fallstricken: Synchronisationsverzögerungen, Preisverwaltung auf Ebene von Kundengruppen, kundenspezifische Konditionen

Red Flag: "Ja, ERP-Integration geht. Das ist nur eine API-Anbindung." Jemand, der so spricht, hat nie ein großes ERP integriert. Es ist immer komplexer.

Frage 3: Setzt die Agentur Systeme ein, die sie aus echten Projekten kennt – oder empfiehlt sie Technologien, die sie noch nicht produktiv eingesetzt hat?

Es gibt einen erheblichen Unterschied zwischen einer Demo-Umgebung und einem Produktivsystem mit ERP-Anbindung, 50.000 SKUs und fünf Preislisten. Verlangen Sie Projektreferenzen für genau die Systemkonstellation, die für Sie relevant ist.

Was Sie hören wollen:

Konkrete Produktivprojekte mit den empfohlenen Plattformen – nicht Trainingsumgebungen oder Zertifizierungsnachweise
Eine klare Aussage, welche Systeme die Agentur besonders tief kennt und warum
Ehrlichkeit, wenn ein System außerhalb des eigenen Kompetenzbereichs liegt – und einen entsprechenden Plan dafür

Red Flag: "Wir können alle Plattformen." Breite ohne Tiefe ist im B2B-Commerce das gefährlichste Versprechen. Wer alles kann, kennt in der Regel keines der Systeme wirklich – und lernt auf Ihrem Projekt, auf Ihre Kosten.

Frage 4: Wie sieht Ihr MVP-Prozess aus – und wie schnell können wir live gehen?

Das MVP-Denken ist der Kern moderner B2B-Commerce-Projekte. Eine gute Agentur sollte einen klaren Rahmen für schnelle, iterative Launches haben.

Was Sie hören wollen:

Ein strukturierter Prozess für MVP-Definition (Scope, Datenzuschnitt, Features für Day 1)
Realistische Timelines (wenige Monate für ein echtes MVP, nicht ein halbes bis ganzes Jahr für einen "schnellen Start")
Ein Plan für Phase 2, Phase 3 – nicht nur der erste Launch

Red Flag: "Das MVP wird 12 Monate dauern." Das ist kein MVP. Das ist ein vollständiges System mit einem neuen Namen.

Frage 5: Wie unterstützen Sie uns nach dem Go-Live – und was kostet das?

Der Launch ist Tag 1, nicht das Ende. Sie brauchen eine Agentur, die Sie danach nicht alleine lässt.

Was Sie hören wollen:

Ein klares Support-Modell (Spannbreite: von Bug-Fixes über strategische Weiterentwicklung bis zur Erweiterung des internen Teams)
Transparente Preisgestaltung für Post-Launch-Services (Modul-Basiert: Bugfixes, Feature-Development, Performance-Optimierung)
Eine Perspektive auf langfristige Partnerschaft, nicht nur ein Projekt

Red Flag: "Nach dem Launch sind Sie auf unsere Support-Linie angewiesen – das kostet extra." Das ist normal. Problematisch ist nur, wenn die Support-Preise nicht vorab klar definiert sind.

Frage 6: Können Sie Strategie UND Implementierung leisten – oder nur eines von beidem?

Manche Agenturen sind Strategie-Only (sie beraten, implementieren aber nicht). Andere sind Implementierungs-Only (sie bauen, können aber nicht strategisch beraten).

Was Sie hören wollen:

Ein integriertes Team: Business-Strategist, Solution Architect, Tech Lead in einem Boot
Konkrete Fälle, in denen die Strategie den Erfolg des Projekts bestimmt hat
Ein klares Verständnis davon, dass Technology nur das Werkzeug ist – Strategy ist das entscheidende

Red Flag: "Wir sind Strategie-Partner – Implementierung macht ein anderes Team." Das schafft Verantwortungs-Diffusion. Sie wollen ein Team, das für Erfolg verantwortlich ist.

Frage 7: Wie integrieren Sie Daten und KI in Commerce-Projekte?

Dies ist die zukunftsfähige Frage. B2B-Commerce 2026+ wird datenbetrieben sein. AI-Personalisierung, Vorhersagen von Kundenabwanderung, Dynamische Preisoptimierung – das wird Standard.

Was Sie hören wollen:

Erfahrung mit Daten-Pipelines (ERP → Data Lake → Commerce)
AI-Einsätze in produktiven Systemen (nicht nur Proof-of-Concept)
Ein klares Roadmap-Verständnis: "Das ist für Tag 1 nicht relevant, aber für Phase 2 und Phase 3 aufschlussreich."

Red Flag: "KI ist zu früh für Sie." Das kann stimmen – aber ein zukunftsfähiger Partner sollte zumindest wissen, wie man es später einbaut.

Was schlechte Agenturen oft sagen

"Wir machen alles gleich gut."
"Das ist Ihr Anforderungsproblem, nicht unser."
"Diese Plattform ist beste für alles."
"Nach Launch sind Sie auf sich allein gestellt."
"ERP-Integration ist Standard – das dauert zwei Wochen."

Wie ein gutes Briefing für ein B2B-Commerce-Projekt aussieht

Bevor Sie Angebote einholen, bereiten Sie ein klares Briefing vor:

Business-Ziel (eine Seite): Warum jetzt? Was ändert sich durch den neuen Shop?
Systemlandschaft (eine Seite): Welche Systeme müssen integriert werden? Welche Daten fließen wohin?
MVP-Scope (eine Seite): Was muss Day 1 können? Was kommt später?
Team und Roadmap (eine Seite): Wer entscheidet? Welche Fristen sind realistisch?

Ein gutes Briefing ist die beste Versicherung gegen Missverständnisse später.

Bereit für den nächsten Schritt?

Die richtige Agentur zu finden ist entscheidend für den Erfolg Ihres B2B-Commerce-Projekts. Mit klaren Fragen und realistischen Erwartungen treffen Sie die richtige Wahl. Wir helfen Ihnen gerne bei Ihrer Entscheidung.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/wie-waehle-ich-die-richtige-ecommerce-agentur-fuer-b2b-7-fragen-die-sie-stellen-sollten-bevor-sie-beauftragen

Premiere im iBusiness-Ranking: foobar Agency erstmals gelistet

Matthias Dietrich — Tue, 19 May 2026 00:00:00 GMT

foobar Agency ist erstmals im jährlichen Internetagentur-Ranking von iBusiness vertreten. Die Münchner Agentur belegt Platz 82 im Hauptranking und ist zugleich im eCommerce-Subranking gelistet — Platz 20 der Top 20. Für die Agentur ist es die erste Aufnahme in das Branchenverzeichnis seit ihrer Gründung 2015.

Das iBusiness-Internetagentur-Ranking gilt seit Jahren als die Standard-Übersicht der digitalen Agenturlandschaft im DACH-Raum. Es wird jährlich auf Basis öffentlich zugänglicher Kennzahlen, Selbstauskünften und einer redaktionellen Einordnung erstellt. Mit der Aufnahme tritt foobar Agency erstmals offiziell in dieses Verzeichnis ein.

Beide Platzierungen sind für die Agentur ein erster Eintrag in eine etablierte Branchenliste. Die eCommerce-Top-20 bilden den Spezialisierungs-Schwerpunkt der Agentur ab; im Hauptranking ist foobar Agency unter den ersten 100 DACH-Internetagenturen sichtbar. Ziel ist es, beide Platzierungen in den kommenden Ausgaben gezielt zu verbessern.

Die Listung fällt in eine Phase, in der die Agentur ihren Wachstumskurs sichtbar fortsetzt. Das Jahr 2026 ist deutlich stärker angelaufen als das Vorjahr; die Auftragsentwicklung liegt auf dem in der Jahresplanung definierten Wachstumspfad. Beteiligungsstruktur, Personalentscheidungen wie die jüngste Bestellung von Philipp Krueger zum Co-CEO sowie der Ausbau von Technologie-Partnerschaften flankieren diesen Kurs.

»Wir sind zum ersten Mal in der iBusiness-Liste vertreten — das ist für uns ein Etappenziel, das wir uns bewusst gesetzt haben«, sagt Matthias Dietrich, Gründer und CEO der foobar Agency. »Die aktuelle Platzierung ist ein Anfang, kein Ergebnis. Wir wissen, wo wir stehen, und wir wissen, wo wir hinwollen. Mit starken Gesellschaftern, einem klaren Wachstumsziel und Partnern, die unsere Spezialisierung mittragen, schauen wir positiv in die nächsten Quartale.«

Über foobar Agency

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/premiere-im-ibusiness-ranking-foobar-agency-erstmals-gelistet

Warum B2B-Commerce-Projekte scheitern – und was die erfolgreichen wirklich anders machen

Matthias Dietrich — Mon, 18 May 2026 00:00:00 GMT

Die Zahlen sind beeindruckend – und beängstigend. Laut commercetools-Daten scheitern oder stecken 64 Prozent der B2B-eCommerce-Projekte im deutschsprachigen Raum fest, bevor sie ihre Ziele erreichen. Der Grund: nicht die Technologie. Die Schuld tragen unklare Anforderungen, fehlende digitale Führung und ein Planungsansatz, der die Komplexität von ERP-Integration und Stakeholder-Management systematisch unterschätzt. Die gute Nachricht: Die Projekte, die wirklich funktionieren, machen von Anfang an eines anders.

Vier Fehler, die zum Scheitern führen

1. Scope-Creep – Die Anforderungsliste wird zur Unmöglichkeit

Es beginnt harmlos. Der CFO hat eine Frage. Der Supply Chain Manager braucht noch ein Feature. Die Marketing-Chefin möchte eine Integrationserweiterung. Jede einzelne Anfrage ist rational. Zusammen erzeugen sie ein Projekt, das gar nicht mehr zu bewältigen ist.

In einem großen B2B-Unternehmen, das wir beraten haben, startete ein Commerce-Projekt mit einer Anforderungsliste von 120 Features. Nach drei Monaten waren es 280. Nach sechs Monaten wurde das Projekt gestoppt, weil die Komplexität nicht mehr zu managen war. Das Budget war halbiert, der Scope hatte sich verdreifacht, und niemand konnte mehr sagen, wann das Projekt fertig sein würde.

Das Problem: Ohne klare Priorisierung und ohne jemanden, der Nein sagen darf, wird jedes Feature zur „Must-have". Und eine Hundertschaft Must-haves ist nicht mehr umsetzbar.

2. Fehlende digitale Führung – Entscheidungen dauern Monate statt Tage

Die meisten B2B-Unternehmen haben ein großes Stakeholder-Problem. Marketing will das eine, Vertrieb das andere, Operations das dritte. Und die Entscheidung fällt nicht beim Projektmanager – sie fällt in einem Komitee, das sich einmal im Monat trifft.

Ein Relaunch-Projekt bei einem Maschinenbauer zeigte das klassische Muster: Ein Architekt schlug eine Lösung vor. Diese ging zur Genehmigung an den CIO. Der CIO koordinierte mit dem CFO. Der CFO wollte eine weitere Analyse. Diese Analyse dauerte acht Wochen. Die vorgeschlagene Lösung war bis dahin überholt. Ein anderes Thema forderte Aufmerksamkeit. Das Projekt rutschte weiter nach hinten.

Erfolgreiche Projekte haben einen klaren Owner – nicht (nur) eine Governance-Struktur. Eine Person mit echtem Entscheidungsmandat. Diese Person kann in drei Stunden Nein sagen zu einem Feature; nicht in drei Monaten.

3. ERP-Integration wird systematisch unterschätzt

Die größte Herausforderung in B2B-eCommerce ist nicht das Frontend. Es ist nicht das Design. Es ist die ERP-Integration – und sie wird in fast jedem Projekt zu optimistisch geplant.

Ein Distributor, mit dem wir zusammenarbeiteten, sagte: „Unsere SAP ist 25 Jahre alt. Niemand dokumentiert, welche Daten wohin fließen. Und die ERP-Integration muss perfekt sein, weil der Betrieb sonst zusammenbricht." Die geplante Integration war in der Anforderungsliste mit zwei Zeilen erwähnt. Erst in der Analyse wurde klar: Das Projekt brauchte zwei zusätzliche Monate nur für Integrations-Engineering.

Laut commercetools-Whitepaper ist ERP/CRM-Integration die Nummer-1-Hürde bei B2B-eCommerce-Implementierungen. Und sie wird fast immer zu optimistisch budgetiert.

4. Big-Bang-Denken – Der Versuch, alles gleichzeitig zu ändern

Der klassische Fehler: „Wir werden alles auf einmal umstellen. Neue Technologie, neue Prozesse, neue Datenstruktur, neues Team – all das parallel." Das ist nicht ambitioniert sondern fahrlässig.

Ein großer Retailer versuchte genau das: neues eCommerce-System, neue Fulfillment-Struktur, neu organisiertes IT-Team, neue Leistungskennziffern. Der Launch war ein Desaster. Weil die Prozesse nicht funktionierten, weil das Team nicht ausgebildet war, weil niemand wusste, wer für Probleme verantwortlich ist.

Erfolgreiche Projekte ändern eine Sache auf einmal. Sie launchen früh mit reduziertem Scope, messen, lernen und bauen dann weiter.

Was erfolgreiche Projekte von Anfang an anders machen

Discovery vor Delivery – 4 bis 8 Wochen intensive Analyse

Die erfolgreichsten B2B-Commerce-Projekte beginnen nicht mit Entwicklung. Sie beginnen mit Discovery. Vier bis acht Wochen, in denen folgende Fragen beantwortet werden:

Was sind die geschäftskritischen Use Cases für die erste Phase?
Wie sieht die Systemlandschaft aus? (ERP, CRM, PIM, Lager – wer ist mit wem verbunden?)
Wer sind die internen Stakeholder und was brauchen sie wirklich?
Wie realistisch ist die geplante ERP-Integration? (Nicht: Was hofft der CFO? Sondern: Was sagt der ERP-Administrator?)

Diese intensive Discovery-Phase kostet Zeit und Budget. Sie spart aber Millionen, weil sie Überraschungen vermeidet.

MVP-Disziplin – Die härteste Frage: Was kommt NICHT in V1?

Erfolgreiche Projekte folgen einer radikalen Disziplin: Sie definieren nicht, was rein soll. Sie definieren, was rausbleibt.

Ein Chemiehandel, der sein Portal neu baute, startete mit 200 Anforderungen. Nach der Discovery-Phase: 45 Anforderungen für V1. Das war der schwierigste Part – nicht die Umsetzung, sondern die Entscheidung, welche 155 Features in Phase 2 landen.

Das Ergebnis: Das MVP launcht schneller, hat weniger Fehler und gibt schneller echtes Feedback.

Digitaler Owner mit echtem Mandat – Entscheidungen statt Komitees

Erfolgreiche Projekte haben eine Person, die die Verantwortung trägt. Sie kann sagen „Ja, das kommt rein" oder „Nein, das nicht" – und das ist verbindlich. Diese Person sitzt nicht in einem Komitee. Sie sitzt im Projekt.

Iterative Releases – Früh live, früh lernen

Statt 18 Monate in Entwicklung und dann Bang beim Launch: MVP nach 3–4 Monaten live. Messen. Phase 2 nach weiteren 2–3 Monaten. Phase 3 später. Das senkt Risiko und erhöht Lernen.

Was das für Ihre Projektplanung bedeutet

1. Realistischer Zeitrahmen

Discovery: 4–8 Wochen je nach Systemkomplexität
MVP: 3–6 Monate je nach ERP-Landschaft und Scope
Phase 2 & 3: Iterativ, basierend auf echtem Feedback

Wer weniger als 4 Wochen Discovery plant, plant mehr Probleme ein.

2. Budget als Investment, nicht als Einmalprojekt

V1: Basis-Investment
V2 + V3: Iterationsbudget
Wer nur V1 finanziert, finanziert eine halbe Transformation

3. Interne Ressourcen, die wirklich nötig sind

Ein Product Owner (intern, nicht extern)
IT-Schnittstelle zum ERP-Team
Fachbereichs-Repräsentanten für Anforderungen
Ein Entscheider für Eskalationen

Das ist kein großes Team. Aber es ist ein fokussiertes Team.

Die richtige Agentur auswählen

Eine gute B2B-eCommerce-Agentur:

Kennt die Realität von ERP-Integrationen (SAP, Dynamics, NetSuite – nicht nur die Theorie, sondern die Komplexität)
Kann klare Scope-Gespräche führen und Nein sagen, wenn nötig
Hat scheiternde Projekte gesehen und nutzt dieses Wissen, um zukünftige zu retten
Verspricht nicht 90 Tage für alles – sondern 4 Wochen Discovery, dann ein ehrliches Zeitbild

Checkliste: Ist Ihr Unternehmen bereit?

Vor dem Start überprüfen Sie diese Punkte:

Haben Sie klare Business-Ziele für Phase 1? (Nicht: „Alles neu machen", sondern: „Bestellzeit um 40 Prozent senken".)
Gibt es einen erkannten Business Owner? (CEO, Vertriebsleiter oder CDO – mit Entscheidungsmandat.)
Sind Ihre Systemlandschaften dokumentiert? (ERP, CRM, Lager, Accounting – eine grobe Übersicht.)
Können Sie Phase 1 in 4–6 Monaten launchen – und dann live gehen? (Oder werden Sie später ungeduldig?)
Können Sie 3–5 Personen intern abstellen? (Projekte ohne internes Engagement scheitern.)

Wenn Sie vier dieser Punkte mit Ja beantworten: Sie sind bereit.

Bereit für den nächsten Schritt?

Sie planen ein B2B-Commerce-Projekt und wollen von Anfang an die richtigen Weichen stellen? Schicken Sie uns einen kurzen Projektsteckbrief – wir melden uns innerhalb von 24 Stunden für ein kostenloses Erstgespräch.

Dieser Beitrag erschien zuerst auf foobar.agency. https://foobar.agency/de/blog/warum-b2b-commerce-projekte-scheitern-und-was-die-erfolgreichen-wirklich-anders-machen