// stack · schnittstelle
Ein PIM ist das System, in dem Produktinformationen zentral liegen — Texte, Attribute, Kategorien, Medien, Übersetzungen. Diese Seite beschreibt bewusst keine einzelne Software, sondern den Weg: wie Produktdaten aus einem PIM auf eine Website kommen und dort zu Katalog, Detailseite und Datenblatt werden. Denn die Muster sind systemunabhängig — siteway baut diese Anbindung immer nach derselben Logik: spiegeln, nicht durchreichen.
// definition
eine quelle statt vier
PIM steht für Product Information Management. Gemeint ist ein System, in dem alles gepflegt wird, was ein Produkt beschreibt: Bezeichnung und Beschreibungstext, technische Attribute mit Einheiten, die Einordnung in Kategorien, Bilder und Videos, Datenblätter und Montageanleitungen, dazu die Übersetzungen. Aus dieser einen Quelle werden anschließend alle Kanäle beliefert — die Website, der Shop, der gedruckte Katalog, die Datenlieferung an Handelspartner.
Der Grund, warum es solche Systeme überhaupt gibt, ist bei jedem Projekt derselbe. Ohne zentrale Pflege liegen Produkttexte in einer Tabelle beim Produktmanagement, in einer zweiten Fassung im Shop, in einer dritten in der Katalog-Datei der Grafik und in einer vierten auf der Website. Alle vier waren einmal gleich. Nach zwei Sortimentswechseln ist keine mehr wie die andere. Das PIM ist die Antwort darauf: eine Quelle, ein Redaktionsprozess, viele Ausgabekanäle.
Der wichtigste Punkt für die Abgrenzung ist das Verhältnis zum ERP. Ein ERP führt die kaufmännischen Daten — Artikelnummer, Preise, Bestände, Aufträge, Lieferanten, Buchhaltung. Ein PIM führt die beschreibenden, marketingrelevanten Daten. Beide kennen dasselbe Produkt, aber über unterschiedliche Ausschnitte, und beide sind über die Artikelnummer verbunden. Für eine Website heißt das ganz praktisch: Der Text kommt aus dem PIM, Preis und Verfügbarkeit kommen aus dem Warenwirtschaftssystem — etwa aus SAP oder weclapp. Wer beides braucht, baut zwei Anbindungen mit einem gemeinsamen Schlüssel.
Welches PIM-Produkt im Haus steht, ändert an dieser Rolle wenig. Die Systeme unterscheiden sich in Oberfläche, Rechteverwaltung und Umfang — für die Website zählt vor allem, dass sie nach draußen sprechen können: über eine Schnittstelle, über einen Export oder über beides. Ab da ist es eine Integrationsaufgabe wie jede andere.
// praxis
spiegeln · nicht durchreichen
Am Anfang steht kein Code, sondern eine Bestandsaufnahme. Wie viele Produkte umfasst das Sortiment, gibt es Varianten, wie tief ist der Kategoriebaum, wie viele Attribute hängen an einem Produkt, in wie vielen Sprachen liegt es vor? Und vor allem: Was kann das System herausgeben? Eine Schnittstelle, einen Export, Ereignismeldungen — oder eine Kombination davon. Aus diesen Antworten ergibt sich der Weg, nicht aus einer Vorliebe.
Dann kommt der Teil, der die meiste Zeit kostet und in Angeboten trotzdem gern in einer Zeile verschwindet: das Feld-Mapping. Die Struktur im PIM ist selten identisch mit dem, was die Website braucht. Dort stehen häufig mehrere hundert Attribute je Produkt, gruppiert nach Warengruppe, mit eigenen Einheiten und eigenen Wertelisten. Auf der Website braucht es davon einen bewussten Ausschnitt: die Felder für die Detailseite, die Felder für den Filter, die Felder für die Suche und die Felder für die strukturierten Daten. Wir legen fest, welches Quellfeld auf welches Zielfeld geht, welche Einheit und welches Format gelten, was Pflicht ist und was leer bleiben darf. Das Ergebnis ist ein Dokument, und es steht, bevor gebaut wird.
Der wichtigste Grundsatz danach: Produktdaten werden in das CMS gespiegelt, nicht bei jedem Seitenaufruf abgefragt. Der Abgleich läuft im Hintergrund und schreibt die Produkte als eigene Inhaltsart mit eigenen Feldern, eigener URL und eigener Sortierung. Ausgeliefert wird aus dem eigenen Bestand. Das hält die Seite schnell, macht sie unabhängig von der Erreichbarkeit des PIM und sorgt dafür, dass eine Wartung am führenden System keinen leeren Katalog produziert. Nach dem Import nehmen wir gezielt die betroffene Detailseite und die betroffenen Listen aus dem Cache, statt die ganze Website zu leeren.
Bilder und Dokumente ziehen wir beim Abgleich auf den eigenen Server, statt sie live aus dem PIM zu verlinken. Danach laufen sie durch dieselbe Bildpipeline wie der Rest der Website: skaliert, als AVIF und WebP ausgespielt, mit Maßen im Markup. Ein Datenblatt liegt danach auf der eigenen Domain — auffindbar, verlinkbar, unabhängig von einem fremden System. Über eine Prüfsumme oder ein Änderungsdatum erkennt der nächste Lauf, welche Datei tatsächlich neu ist, damit nicht bei jedem Durchgang das gesamte Medienarchiv erneut über die Leitung geht.
Und schließlich der Fall, den niemand plant: der Fehlerfall. Antwortet die Schnittstelle nicht, ist die Exportdatei halb geschrieben oder fehlt ein Pflichtfeld, dann bleibt der letzte gute Stand stehen. Der Lauf wird protokolliert, mit Abstand erneut versucht und meldet sich, wenn er zweimal hintereinander scheitert. Ein abgebrochener Abgleich darf nie den Katalog leeren — das ist die Regel, an der sich jede Anbindung messen lassen muss.
// technik · 6 details
muster statt produkt
Was hier steht, gilt systemunabhängig. Die Oberflächen und Begriffe unterscheiden sich von Haus zu Haus, die Muster dahinter kaum: eine Datenstruktur aus Produkten und Attributen, ein Übergabeweg nach draußen, ein Takt für die Aktualisierung und eine Regel für alles, was verschwindet.
// d-01datenmodell
Im Zentrum steht das Produkt, darunter oft Varianten — dieselbe Baureihe in mehreren Größen, Farben oder Anschlüssen. Für die Website entscheidet sich hier, ob eine Variante eine eigene Seite bekommt oder als Auswahl auf der Seite des Elternprodukts erscheint. Das ist keine technische Frage, sondern eine der Auffindbarkeit: Wonach suchen die Kunden — nach der Baureihe oder nach der konkreten Ausführung?
zweck: struktur
// d-02attribute
Attribute sind die Eigenschaften eines Produkts, meist in Gruppen gebündelt und je nach Warengruppe unterschiedlich belegt. Wichtig ist die Sauberkeit der Werte: Ein Attribut mit fester Werteliste taugt als Filter, ein Freitextfeld mit fünf Schreibweisen desselben Materials nicht. Wo die Wertelisten im PIM noch uneinheitlich sind, ist das ein Datenthema — kein Frontend-Problem, das sich wegprogrammieren lässt.
zweck: filter · vergleich
// d-03übergabe
Drei Muster sind üblich. Eine REST-Schnittstelle liefert JSON, abgesichert über Schlüssel oder Token, und erlaubt gezielte Abrufe nach Kategorie oder Änderungsdatum. Ein Dateiexport legt CSV oder XML in einem definierten Verzeichnis ab, das die Website im Takt einliest — robust und gut prüfbar. Ereignismeldungen wie Webhooks melden nur, dass sich etwas geändert hat; die Daten holen wir danach gezielt nach.
zweck: transportweg
// d-04takt
Die Ersteinrichtung ist ein Vollabgleich: Das gesamte Sortiment wandert einmal in das CMS, inklusive Medien. Im Betrieb laufen danach Teilabgleiche, die nur Geänderte holen — über ein Änderungsdatum, einen Zeitstempel oder eine Ereignismeldung. Ein regelmäßiger Voll-Lauf bleibt als Grundsicherung daneben bestehen, damit ein verpasster Datensatz nicht dauerhaft im alten Stand hängen bleibt.
zweck: aktualität
// d-05löschlogik
Der unterschätzte Teil jeder Anbindung. Ein Produkt, das im PIM auf inaktiv gesetzt wird oder aus dem Export fällt, verschwindet auf der Website nicht einfach: Es wird als entfallen gekennzeichnet, seine URL bleibt bestehen und verweist auf den Nachfolger oder wird sauber umgeleitet. Ohne diese Regel produziert jeder Sortimentswechsel eine neue Ladung Fehlerseiten — und alte Links ins Leere.
zweck: saubere urls
// d-06sprachen · kanäle
Ein PIM hält Übersetzungen als Sprachvarianten am Produkt und unterscheidet oft zusätzlich nach Kanal — der Text für den Katalog ist nicht derselbe wie der für die Website. Beim Abgleich zählt die eindeutige Zuordnung: Welche Sprachkennung im PIM entspricht welcher Sprache der Website, und welcher Kanal ist der maßgebliche? Für nicht übersetzte Felder gilt eine feste Regel statt einer Zufallsentscheidung.
zweck: mehrsprachigkeit
Aus den gespiegelten Daten wird kein Datenbank-Dump, sondern eine Website. Der Produktkatalog filtert über genau die Attribute, die im Mapping als Filter markiert sind — Warengruppe, Maße, Material, Anschlussart — und arbeitet dabei auf dem eigenen Bestand, also ohne Wartezeit auf ein fremdes System. Die Detailseite bekommt eine sprechende, dauerhafte URL, die Bildergalerie, die technischen Daten als Tabelle und die Downloads: Datenblatt, Montageanleitung, Zeichnung. Wo aus der Auswahl eine Bestellung werden soll, kommt der Shop dazu — dieselben Daten, ein zusätzlicher Weg.
Die Suche profitiert am deutlichsten von sauberen Attributen: Wer nach einer Maßangabe oder einer Norm sucht, findet das Produkt nur, wenn dieser Wert als Feld existiert und indexiert wird — nicht, wenn er irgendwo im Fließtext steht. Denselben Feldern verdanken wir die strukturierten Daten: Bezeichnung, Beschreibung, Bild, Artikelnummer und Kennzeichnungen wie GTIN oder Herstellernummer wandern aus dem Mapping direkt in das Product-Schema. Einmal gepflegt, dreifach genutzt — im Text, im Filter und in der Auszeichnung für Suchmaschinen.
Mehrsprachigkeit ist dabei der Regelfall, nicht die Ausnahme — wer ein PIM einführt, tut das oft genau deswegen. Jede Sprache bekommt ihre eigene URL und ihre eigene Sprachfassung im CMS, verknüpft über die Sprachverwaltung des Systems; wie das im Detail aussieht, steht bei Mehrsprachigkeit. Und weil Produktdaten selten personenbezogen, aber oft geschäftskritisch sind, gehören Zugangsdaten serverseitig abgelegt und Zugriffe begrenzt — mehr dazu unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er ist bewusst systemunabhängig gedacht: Die Produktdaten werden im festen Takt in das CMS gespiegelt, und das Frontend liest anschließend aus dem eigenen Bestand. Was dafür im CMS liegen muss, ist schnell benannt — eine eigene Inhaltsart „Produkt“ mit genau den Feldern aus dem Mapping, die Bilder und Datenblätter in der Medienverwaltung des Systems, und die Artikelnummer aus dem PIM als Schlüssel. Über diesen Schlüssel erkennt der zweite Lauf ein Produkt wieder und aktualisiert es, statt eine Dublette anzulegen. Erst dadurch werden Produkte zu echten Seiten mit dauerhafter URL statt zu einem eingebetteten Fremdinhalt.
Aktualität ist danach eine Frage von Takt, Auslöser und Cache. Ausgeliefert wird aus dem eigenen Bestand, also aus Cache oder statisch erzeugten Seiten — schnell und unabhängig davon, ob das PIM gerade erreichbar ist. Läuft der Import durch, nehmen wir gezielt die betroffenen Detailseiten und Listen aus dem Cache, statt die ganze Website zu leeren. Meldet das führende System eine Änderung als Ereignis, holen wir genau dieses eine Produkt nach; der geplante Lauf bleibt daneben als Grundsicherung bestehen. Live abgefragt wird nur, was live sein muss — und das ist bei Produktdaten selten mehr als ein Bestand oder ein persönlicher Preis, der ohnehin aus dem ERP kommt. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts — nur daran, wo die Produkte am Ende liegen und was die Redaktion damit tun kann.
// cms-01typo3
TYPO3 bringt mit Extbase, TCA, dem Scheduler und Fluid alles mit, was eine PIM-Anbindung braucht. Wir bauen sie als eigene Extension: Das TCA beschreibt das Datenmodell, also die Inhaltsart „Produkt“ mit genau den Feldern und Relationen aus dem Mapping. Der Import läuft als Scheduler-Task, die Produkte liegen als Records in einem Systemordner, Bilder und Datenblätter in FAL. Zugangsdaten stehen in der Extension-Konfiguration und nie im Repository. Sprechende URLs kommen aus dem Site Handling, gerendert wird über Fluid. Mehrsprachigkeit läuft über die Sprachverwaltung von TYPO3 — jede Sprachvariante aus dem PIM landet in der zugehörigen Sprachfassung. Die Redaktion sieht die Produkte im Backend und pflegt eigene Texte in Feldern daneben, die der Import nicht anfasst.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie beim Theme-Wechsel bestehen. Die Produkte werden ein Custom Post Type mit eigenen Meta-Feldern für die Attribute, dazu Taxonomien für Kategorien und für die Attribute, die später als Filter dienen sollen. Ein geplanter Lauf hält den Bestand nach, eine eigene Route nimmt Ereignismeldungen entgegen und stößt den Abgleich für genau ein Produkt an. Alle Aufrufe des PIM laufen serverseitig; der Schlüssel steht als Konstante in der wp-config.php und nie im Frontend. Fürs Frontend kommen Template-Dateien und Blocks für den Editor dazu, damit die Redaktion Liste, Filter und Teaser dort platziert, wo sie hingehören.
// cms-03statamic
Statamic läuft auf Laravel — Inhalte sind Entries in Collections, Bilder Assets in Containern. Für einen Produktimport ist dieser Unterbau angenehm direkt: Ein Blueprint beschreibt das Datenmodell mit allen Feldern aus dem Mapping, ein Artisan-Command holt die Produkte und schreibt sie als Entries in eine eigene Collection, der Laravel-Scheduler bestimmt den Takt. Route und Controller nehmen Ereignismeldungen entgegen und aktualisieren genau ein Produkt. Der Schlüssel liegt in der .env, Bilder und Datenblätter landen als Assets im eigenen Container. Antlers oder Blade rendern Liste, Filter und Detailseite, Static Caching liefert sie aus. Im Control Panel pflegt die Redaktion Texte und Reihenfolge in Feldern, die der Import nicht überschreibt.
// entscheidung
zuordnung statt rangliste
Fast jede Diskussion über eine PIM-Anbindung endet bei dieser Frage. Sie hat keine grundsätzliche Antwort, sondern eine pro Feld: Was darf ein paar Minuten alt sein, und was muss im Moment der Anzeige stimmen? An drei Mustern lässt sich das zuordnen.
// e-01spiegeln
Bezeichnung, Beschreibung, Attribute, Kategorien, Bilder, Datenblätter: Das sind Inhalte, keine Momentaufnahmen. Sie gehören ins CMS. Die Seite wird dadurch schnell, bleibt bei einer Störung des PIM vollständig lesbar, ist für Suchmaschinen erfassbar und lässt sich redaktionell ergänzen.
inhalt · fester takt
// e-02live
Bestand, Lieferzeit, ein kundenspezifischer Preis hinter dem Login: Diese Werte altern in Minuten — und kommen meist ohnehin nicht aus dem PIM, sondern aus dem ERP. Sie werden im Moment der Anzeige serverseitig geholt, mit kurzer Zwischenspeicherung, mit Zeitlimit und mit einer klar definierten Anzeige, falls keine Antwort kommt.
abruf · serverseitig
// e-03kombination
Der Regelfall bei Produktdaten: Die Seite wird aus dem gespiegelten PIM-Bestand gebaut und im Frontend um genau einen Live-Wert aus dem ERP ergänzt. Zwei Quellen, ein gemeinsamer Schlüssel, zwei unterschiedliche Takte. Ein Weg für die Substanz, ein Weg für den Moment.
substanz + moment
Die zweite Frage betrifft den Transportweg — und hier entscheidet meist das führende System mit. Eine Schnittstelle ist der feinere Weg: gezielte Abrufe nach Kategorie oder Änderungsdatum, kleine Datenmengen, enger Takt, sofort nach dem Ereignis. Sie setzt voraus, dass das PIM erreichbar ist und der Zugang sauber verwaltet wird. Ein Dateiexport ist der robustere Weg: Was im Verzeichnis liegt, lässt sich prüfen, versionieren und im Zweifel noch einmal einlesen. Er ist grobkörniger, dafür unbeeindruckt von Ausfällen und Zugriffslimits — und oft der einzige Weg, wenn im Haus nur ein Export vorgesehen ist.
Vier Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Wie viele Produkte umfasst das Sortiment, und wie oft ändern sich Texte und Attribute? Welche Felder müssen wirklich auf die Website — und welche Attribute sollen filterbar sein? Wie viele Sprachen sind im Spiel? Und woher kommen Preis und Verfügbarkeit, wenn sie überhaupt gezeigt werden sollen? Danach steht das Mapping als Dokument, bevor gebaut wird. Welche Anbindung ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
Ein PIM — Product Information Management — ist das System, in dem Produktinformationen zentral gepflegt werden: Bezeichnungen, Beschreibungstexte, technische Attribute, Kategorien, Bilder, Datenblätter und Übersetzungen. Aus dieser einen Quelle werden anschließend alle Kanäle beliefert: die Website, der Shop, der gedruckte Katalog, Datenblätter für den Vertrieb und die Datenlieferungen an Handelspartner. Der Zweck ist immer derselbe: Ein Produkttext wird an einer Stelle geschrieben und überall gleich ausgespielt, statt in Tabellen, Präsentationen und Website-Feldern nebeneinander zu altern.
Das ERP führt die kaufmännischen Daten, das PIM die beschreibenden. Im ERP liegen Artikelnummer, Preise, Bestände, Aufträge, Lieferanten und Buchhaltung — alles, was gerechnet und gebucht wird. Im PIM liegt, was das Produkt erklärt und verkauft: Marketingtexte, technische Attribute, Kategorien, Bilder, Videos, Datenblätter, Übersetzungen. Beide Systeme kennen dasselbe Produkt, aber über unterschiedliche Ausschnitte, und beide sind über die Artikelnummer verbunden. Für die Website heißt das in der Praxis: Der Text kommt aus dem PIM, Preis und Verfügbarkeit kommen aus dem ERP. Wer beides braucht, baut zwei Anbindungen mit einem gemeinsamen Schlüssel.
Über einen von drei Wegen, oft über zwei davon gleichzeitig. Erstens eine REST-Schnittstelle, die JSON liefert und über einen Schlüssel oder ein Token abgesichert ist — der bequemste Weg, weil sich gezielt einzelne Produkte, Kategorien oder Änderungen seit einem Zeitpunkt abrufen lassen. Zweitens ein Dateiexport: Das PIM legt CSV- oder XML-Dateien mit dem Sortiment in einem definierten Verzeichnis ab, die Website liest sie im festen Takt ein — robust, gut prüfbar und oft der einzige Weg, wenn das führende System nur exportieren kann. Drittens Webhooks oder Ereignismeldungen, die melden, dass sich ein Produkt geändert hat, und den gezielten Nachlauf auslösen. Welche Wege möglich sind, entscheidet das System; welcher genutzt wird, entscheiden wir im Konzept.
Gespiegelt, als Grundregel. Die Website fragt das PIM nicht bei jedem Seitenaufruf, sondern holt die Produktdaten im festen Takt ab und legt sie im Datenmodell des CMS ab. Ausgeliefert wird danach aus dem eigenen Bestand. Das hält die Seiten schnell, macht sie unabhängig von der Erreichbarkeit des PIM und sorgt dafür, dass eine Wartung am führenden System keinen leeren Produktkatalog produziert. Live geholt wird nur, was live sein muss — typischerweise ein Bestand oder ein kundenspezifischer Preis, und der stammt meist ohnehin aus dem ERP. Diese Abfragen laufen serverseitig, mit kurzer Zwischenspeicherung und mit einer definierten Anzeige für den Fall, dass keine Antwort kommt.
Weil die Struktur im PIM fast nie identisch ist mit dem, was die Website braucht. Im PIM stehen häufig mehrere hundert Attribute je Produkt, gruppiert nach Warengruppe; auf der Website braucht es davon einen bewussten Ausschnitt — die Felder für die Detailseite, die Felder für die Filter, die Felder für die Suche und die Felder für die strukturierten Daten. Im Mapping legen wir fest, welches Quellfeld auf welches Zielfeld geht, welche Einheit und welches Format gelten, was Pflicht ist, was leer bleiben darf und welche Attribute als Filter taugen. Dazu gehört ein stabiler Schlüssel, meist die Artikelnummer: Über ihn erkennt der zweite Lauf ein Produkt wieder und aktualisiert es, statt eine Dublette anzulegen. Das Mapping steht als Dokument, bevor gebaut wird.
Zweigleisig. Zur Ersteinrichtung läuft ein Vollabgleich, der das gesamte Sortiment in das CMS schreibt. Im Betrieb laufen danach Teilabgleiche, die nur Produkte holen, die sich seit dem letzten Lauf geändert haben — das hält die Übertragung klein und den Takt eng. Ein regelmäßiger Vollabgleich bleibt als Grundsicherung daneben bestehen, damit verpasste Änderungen nicht dauerhaft hängen bleiben. Für entfallene Produkte gilt eine eigene Regel: Was im PIM verschwindet oder auf inaktiv gesetzt wird, wird auf der Website nicht still gelöscht, sondern als entfallen gekennzeichnet. Die URL bleibt bestehen, verweist auf den Nachfolger oder wird sauber umgeleitet — sonst entstehen mit jedem Abgleich neue Fehlerseiten.
Ja, in allen dreien. Die Anbindung bauen wir in jedem System selbst, mit dessen eigenen Bordmitteln. In TYPO3 entsteht eine eigene Extension: Das TCA beschreibt das Datenmodell, der Import läuft als Scheduler-Task, die Produkte liegen als Records in einem Systemordner, die sprechenden URLs kommen aus dem Site Handling, gerendert wird über Fluid. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type mit Meta-Feldern für die Produktdaten, Taxonomien für Kategorien und Attribute, ein geplanter Lauf für den Abgleich, dazu Template-Dateien und Blöcke für das Frontend. In Statamic liegt Laravel darunter: ein Blueprint als Datenmodell, ein Artisan-Command im Scheduler, die Produkte als Entries in einer Collection, Bilder und Datenblätter im Assets-Container, gerendert mit Antlers oder Blade. Die Mechanik bleibt dieselbe — nur der Ort, an dem die Produkte liegen, ist ein anderer.
In der Regel ja — bei PIM-Anbindungen ist Mehrsprachigkeit der Regelfall und nicht die Ausnahme. Genau dafür wird ein PIM häufig eingeführt: Übersetzungen liegen dort als Sprachvarianten am Produkt, gepflegt von Übersetzern oder Landesgesellschaften. Der Abgleich holt je Sprache die passende Variante und schreibt sie in die entsprechende Sprachfassung des CMS, sodass jede Sprache ihre eigene URL bekommt und über die Sprachverwaltung des Systems mit den anderen verknüpft ist. Wichtig ist die Zuordnung der Sprachkennungen: Was im PIM als Sprache oder Kanal geführt wird, muss eindeutig auf eine Sprache der Website zeigen. Für nicht übersetzte Felder braucht es eine festgelegte Regel — Ausgangssprache anzeigen oder Feld weglassen.
// womit das zusammenhängt
systeme, frontend & leistung
// stack · schnittstelle
Die kaufmännische Seite: Cloud-ERP mit CRM, aus dem Preise, Bestände und Aufträge kommen — der Gegenpol zum PIM.
zur technik →
// stack · schnittstelle
Das ERP in der großen Ausbaustufe: andere Größenordnung, dieselbe Frage — welche Daten gehören auf die Website und in welchem Takt?
zur technik →
// stack · schnittstelle
Der Nachbar für technische Daten: CAD-Modelle und Konfiguration zum Download, ergänzend zu den beschreibenden Daten aus dem PIM.
zur technik →
// leistung · komponente
Was aus den Produktdaten im Frontend wird: Liste mit Filter, Detailseite, Datenblatt — buchbar als Komponente.
zur leistung →
// leistung · komponente
Wenn aus der Auswahl eine Bestellung wird: Warenkorb, Checkout und der Auftrag, der zurück ins ERP läuft.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Produktdaten aus dem PIM auf deiner Website?
Projekt anfragen