Ein Onlineshop verkauft technische Produkte mehrerer Hersteller. Die Fakten, die seine Käufer brauchen, steckten in Handbüchern, Datenblättern und Broschüren. Wir haben eine Pipeline gebaut, die aus diesen Dokumenten Produktseiten mit einer einheitlichen Struktur und einer Vergleichstabelle macht.
Die Pipeline baut inzwischen mehr als 100 Seiten des Shops mit Vergleichstabelle. Jedes Listing im Shop zählen wir als eine Seite, inklusive Bundles, Varianten und B-Ware. Beim Launch, den wir unten beschreiben, gingen neue Modelle innerhalb einer Arbeitssitzung vom frisch angelegten Datensatz in der Warenwirtschaft als geprüfte Seite live. Dieselben Tabellen liefern außerdem die Importdaten für eBay als zweiten Kanal.
Was die Pipeline an jeder Produktseite ändert.
-
Woher die Fakten kommenEin Wert ohne Quelle wird entferntJeder Tabellenwert führt zu einem Quelldokument
- Vorher
- Seite für Seite geschrieben oder eingefügt
- Nachher
- Herstellerdokumente von offiziellen Websites, nur freigegebene Produkte
-
Die Seite eines neuen ModellsNeue Datensätze werden zuerst auf geerbte Titel geprüftDer Launch wartet nicht auf einen Texter
- Vorher
- Wartet auf einen Texter
- Nachher
- Aus den Dokumenten gebaut, geprüft, freigegeben und importiert
-
Ein zweiter KanalErster Importsatz als Dateien geliefertDie Tabelle wird einmal geschrieben
- Vorher
- Keine gemeinsamen Produktdaten
- Nachher
- eBay-Artikelmerkmale und -Titel lesen aus derselben Tabelle
Die geschäftliche Frage
Was eine Produktseite einbringt, hängt von Treibern ab, die Sie selbst bewegen können. Mehr Besucher gewinnen Sie, wenn strukturierte Daten zu eBay und weiteren Kanälen gelangen. Die Conversion steigt, wenn ein Käufer Modelle vergleichen und das richtige wählen kann. Retouren und Support-Anfragen sinken, wenn Spezifikationen und Lieferumfang stimmen. Und Sie gewinnen Verkaufstage, wenn die Seite eines neuen Modells live ist, sobald das Modell eintrifft.
Entscheidend war, wie jede Seite die Fakten des Herstellers abbilden kann und wie schnell ein neues Modell in den Verkauf kommt. Seit dem 13. Dezember 2024 legt die EU-Produktsicherheitsverordnung zudem fest, was ein Online-Angebot zeigen muss. Dazu gehören der Hersteller mit Post- und E-Mail-Adresse und, wenn der Hersteller außerhalb der EU sitzt, eine verantwortliche Person in der EU. Dazu gehören auch die Angaben zur Identifizierung des Produkts mit einem Bild sowie Warnhinweise oder Sicherheitsinformationen. Unsere Qualitätsprüfung stellt sicher, dass jede Seite den Kontaktblock des Herstellers und eine verantwortliche Person in der EU enthält. Warnhinweise und Sicherheitstexte prüft sie nicht, deshalb ersetzt sie keine Compliance-Prüfung.
Warum eine Pipeline
Die Möglichkeiten, die Seiten zu füllen, haben wir danach abgewogen, was eine Seite kostet und wie schnell sie live geht.
Einzeln geschriebene Seiten können gut zu lesen sein, doch jede kostet gleich viel. Launches warten auf einen Texter, und ob die Fakten stimmen, hängt davon ab, wer sie geprüft hat. Den Herstellertext einfach zu übernehmen, geht schnell und kostet wenig. Die Seiten bleiben für Käufer so allerdings dünn, oft in der falschen Sprache und ohne Vergleich zwischen den Modellen.
Eine gesteuerte Pipeline aus Herstellerdokumenten braucht zunächst Aufbauarbeit und ein Regelwerk. Danach kostet jede weitere Seite wenig, die Seite eines neuen Modells wartet nicht auf einen Texter, und dieselbe Tabelle speist auch eBay.
Den Ausschlag gab, dass die Pipeline mit dem Sortiment mitwächst. Die Routine läuft automatisch, und an jeder wichtigen Prüfstufe entscheidet ein Mensch.
So haben wir gearbeitet
Wir haben in der Warenwirtschaft des Kunden, JTL-Wawi, und in seinem Shop gearbeitet. Die Warenwirtschaft bleibt das führende System für Produktdaten, und wir lesen sie über schreibgeschützte Snapshots. Änderungen erreichen den Shop nur über das eigene Importwerkzeug der Warenwirtschaft, und zwar erst nach der Freigabe. Anschließend veröffentlicht der Konnektor der Warenwirtschaft sie im Shop.
Wir haben die Hersteller um Erlaubnis gebeten, ihre Inhalte zu nutzen, und bauen daraus nur Seiten für die Produkte, die sie freigegeben haben. Die Dokumente kamen von den offiziellen Websites der Hersteller und von nirgendwo sonst. Gesammelt haben wir Handbücher, Datenblätter, Broschüren, Bilder und Videos. Wo es eine Website in mehreren Sprachen gibt, haben wir die Produkte über alle Sprachversionen hinweg zugeordnet.
Bestehende Seiten schützt schon der Aufbau: Seiten im neuen Format sind an mehreren getrennten Stellen gesperrt, und bestehende Attribute werden standardmäßig nie überschrieben. Eine bewusste Korrektur braucht eine eigene Datei und eine eigene Freigabe.
Im Zentrum des Datenmodells steht der Artikel in der Warenwirtschaft. Auf der einen Seite liegen Produkte und ihre Quelldokumente. Am Artikel hängen Attribute, die Beschreibung mit ihrer Tabelle und die Kanal-Listings.
Ein Wert ohne Quelle geht nicht live
Eine Vergleichstabelle weckt Vertrauen, weil jede Zelle wie eine Tatsache aussieht. Deshalb muss sich jede Zelle auf ein Herstellerdokument zurückführen lassen.
Als wir die Tabellen für mehrere Produktfamilien anhand der Herstellerhandbücher neu aufgebaut haben, änderte die Prüfung echte Werte. Mehrere Werte in einer Tabelle stimmten nicht mit dem Handbuch überein, und eine zusammengefasste Einstellung musste aufgeteilt werden. Eine Angabe hatte in den Dokumenten dieses Produkts keine Quelle, also haben wir die Zeile entfernt.
Die Arten von Korrekturen in dieser Grafik sind echt. Seitdem gilt eine einfache Regel: Ein Tabellenwert muss sich in den kuratierten Herstellerdokumenten finden. Wo die Dokumente keinen Wert nennen, entfernen wir die Zeile, statt sie mit einer plausiblen Vermutung zu füllen. Die Rückverfolgung halten wir auf Ebene des Dokuments fest und nicht für jede einzelne Zelle. Wer prüft, findet also das Dokument hinter einem Wert, aber nicht die Seite darin.
Der Kreislauf
Jedes Produkt durchläuft dieselben acht Schritte, vom PDF bis zur Live-Seite.
- Sammeln. Dokumente und Medien von der offiziellen Website des Herstellers holen.
- Auslesen. Den PDF-Text lesen, bei Scans per OCR, und je Produkt in einen Datensatz überführen.
- Zusammensetzen. Ein KI-System entwirft Seitentext und Tabelle aus dem Datensatz des Produkts, in der festen Struktur. Seiten für B-Ware entstehen ohne KI aus der Hauptseite.
- Prüfen. Eine Qualitätsprüfung testet die Struktur, und ein Duplikatschutz bereinigt wiederholte Blöcke. Fakten prüft sie nicht. Seiten, die durchfallen, werden zurückgehalten.
- Freigeben. Ein Mensch prüft jede Seite auf einem Freigabeblatt und zeichnet anschließend die Charge ab. Ob die Fakten stimmen, hängt an dieser Prüfung.
- Importieren. Das Importwerkzeug der Warenwirtschaft lädt Stammdaten, Attribute und Funktionsattribute in drei Läufen.
- Verifizieren. Wir lesen den Live-Produktfeed und bestätigen, dass jede Seite ihre Tabelle zeigt.
- Wiederverwenden. Dieselben Tabellen speisen danach auch den eBay-Import.
Ein Beispiel
Neue Modelle werden in der Warenwirtschaft oft als Kopie des vorherigen Datensatzes angelegt, weil das am schnellsten geht. Die Kopie bringt jedoch alte Titel mit, und der Überschreibschutz bewahrt dann ausgerechnet die falschen Werte.
arbeitsnotizen · Thread
-
Team
Die neuen Datensätze sind in der Warenwirtschaft. Können wir den Import zusammenstellen?
-
Capcelerate-SystemSystem
Noch nicht. Die Meta-Titel tragen noch die Modellnummern der Vorgängergeneration. Der Überschreibschutz würde sie behalten.
-
Team
Nur diese beiden Felder überschreiben. Alles andere bleibt geschützt.
-
Capcelerate-SystemSystem
Eine separate Attributdatei, zwei Felder je Seite. Sie steht zur Freigabe auf dem Freigabeblatt.
Die Tabelle für die neue Linie stammte aus der Serienbroschüre des Herstellers und umfasste vier Modelle. Nach der Freigabe liefen die Importe, und wir haben den Live-Produktfeed gelesen. Innerhalb einer Arbeitssitzung waren alle vier Seiten mit ihren vollständigen Vergleichstabellen live.
Aus der Korrektur wurde ein fester Schritt. Vor jedem Launch prüfen wir neue Datensätze jetzt auf geerbte Titel und eine geerbte Webadresse.
Was ein langsamer Launch kostet
Ein neues Modell verkauft sich erst, wenn seine Seite live ist. Jeder Tag ohne Seite ist ein Tag, an dem die Nachfrage woandershin geht.
Im Beispiel geht eine Seite an Tag 22 statt an Tag 1 live. Unter dieser Annahme verliert die späte Seite etwa ein Drittel der Stückzahlen der ersten zwei Monate. Außerdem unterstellt das Beispiel, dass kein Käufer auf das späte Modell wartet. Wer ein bestimmtes Modell will, wartet aber oft. Der tatsächliche Verlust kann also kleiner ausfallen. Die Pipeline soll diese Lücke kurz halten, und beim Launch oben waren die Seiten innerhalb einer Arbeitssitzung live.
Skalierung auf einen zweiten Kanal
Wir schreiben die Tabelle einmal, und jeder Kanal liest aus ihr.
Für eBay werden dieselben Beschreibungen ohne die Abschnitte zu Video und Hersteller wiederverwendet. Die Artikelmerkmale kommen direkt aus der Tabelle, mit einer Zeile je Merkmal und dem Wert für dieses Produkt. Wo der Kunde keinen Titel freigegeben hat, erzeugen wir einen nur aus Merkmalen der Tabelle. Er hat höchstens 80 Zeichen und kommt nie doppelt vor. Der erste eBay-Importsatz ging als Dateien an den Kunden.
Der Ausbau brachte eigene Erkenntnisse:
- Ein korrigierter Kanalfilter. Ein früher eBay-Export las die Einstellung eines anderen Kanals und ließ Produkte aus, die in den Satz gehörten. Mit der richtigen Einstellung waren sie im nächsten Satz enthalten.
- Bilder wiederverwendet statt doppelt hochgeladen. Bilder und Videos, die schon auf den früheren Seiten des Shops standen, haben wir in die neuen Seiten übernommen, statt sie erneut hochzuladen.
- Handbücher per Fingerabdruck geprüft. Handbuch-Links prüfen wir über den Datei-Fingerabdruck, und ein Handbuch in der falschen Sprache wird zur Korrektur markiert.
- Neuläufe, die nichts verändern dürfen. In frühen Läufen zeigten manche Bundle-Seiten einen Block mehrfach. Heute ersetzt jeder Schritt seinen Block, und ein Schutz entfernt wiederholte Blöcke, bevor eine Importdatei geschrieben wird.
Leitplanken
| Leitplanke | Was sie bewirkt |
|---|---|
| Nur offizielle Quellen | Neue Dokumente, Bilder und Videos kommen von den offiziellen Websites der Hersteller, und nur für Produkte, die der Hersteller freigegeben hat. Nie von Distributoren oder Drittseiten. Höhere Auflösung muss vom Hersteller kommen. |
| Feste Struktur | Ein Normalisierer baut jede Seite in derselben Abschnittsreihenfolge. |
| Qualitätsprüfung | Prüft jede Seite auf die Pflichtabschnitte, die Tabelle und den Herstellerblock mit Kontaktdaten. Fakten prüft sie nicht. Seiten, die durchfallen, werden zurückgehalten. |
| Duplikatschutz | Entfernt wiederholte Blöcke, bevor eine Importdatei geschrieben wird. |
| Freigabe durch einen Menschen | Jeder Lauf erzeugt ein Freigabeblatt. Ohne Haken und Unterschrift kommt nichts in die Importdatei. |
| Gesperrte Seiten | Fertige Seiten sind an mehreren Stellen geschützt. Attribute werden nur dort befüllt, wo sie leer sind. |
| Datensatzprüfung vor dem Launch | Neue Datensätze werden auf geerbte Titel und Webadressen geprüft, bevor der Import zusammengestellt wird. |
| Getrennte Importe | Attribute und Funktionsattribute kommen in getrennte Dateien. In unseren Läufen kam eine gemischte Datei nur zur Hälfte durch. |
| Live-Prüfung | Nach jedem Import wird der Live-Produktfeed gelesen. |
Ein Vorfall zeigt, wie die Prüfung auch bei unserer eigenen Arbeit greift. Für einen Launch entstand der erste Entwurf außerhalb der Pipeline, mit eigenem Text und eigener Tabelle. Wir haben ihn verworfen und die Seiten über die Pipeline neu gebaut. Seitdem ist die Regel schriftlich festgehalten, dass keine neue Seite ohne die Pipeline entsteht.
Wenn ein Hersteller nur Bilder in niedriger Auflösung anbietet, setzen wir sie auf eine größere weiße Fläche. Kopien von anderen Händlern übernehmen wir dagegen nicht.
Steuerung
Der Standard kam von uns. Unsere Projektleitung bei Capcelerate hat ihn in einem einzigen Satz festgelegt.
„Alles muss exakt gleich aufgebaut sein.“
Auch die Abwägungen dahinter lagen bei uns. Wo ein Wert keine Quelle hatte, haben wir die Zeile entfernt, statt „nicht verfügbar“ zu drucken, denn für Käufer liest sich das sauberer. War eine bestehende, von Hand bearbeitete Live-Seite reicher als die Fassung der Pipeline, haben wir die Live-Seite behalten.
Was es möglich macht
Sind die Daten einmal aufgebaut, nutzt jeder spätere Kanal und jeder Launch sie weiter, statt wieder bei den Dokumenten anzufangen.
Zubehör braucht eine eigene Vorlage, während weitere Produktfamilien derselben Pipeline folgen. Seiten mit und ohne Tabelle lassen sich über Conversion, Retouren und Support-Anfragen vergleichen. Der nächste Euro kann dann dorthin fließen, wo Seiten am meisten verdienen.
Was wir einem anderen Unternehmen raten würden
- Eine Produktseite als Release behandeln. Sie braucht eine Struktur, eine Quelle, eine Prüfstufe, eine Freigabe und eine Live-Prüfung.
- Jede Tatsache beim Hersteller belegen. Entfernen Sie, was Sie nicht belegen können, statt zu raten.
- Die Tabelle einmal schreiben und in jedem Kanal veröffentlichen. Alle Kanäle lesen dann aus einem einzigen Datensatz.
- Die Routine automatisieren und die Ausnahmen prüfen. Ihre Leute geben frei, statt abzutippen.
- Schützen, was schon gut ist. Überschreiben Sie eine fertige Seite standardmäßig nie.
Wenn Ihre Produktseiten weniger sagen als die Dokumente Ihrer Hersteller, können wir mit einer Produktfamilie beginnen.
Danksagung
Aufgebaut vom Capcelerate-Team. Danke an das Team des Kunden, das die neuen Datensätze angelegt und die Launch-Importe ausgeführt hat.