Die versteckten Kosten einer schlechten Produktfeed-Integration

Zuletzt aktualisiert: 7. Juli 2026. Verfasst auf Basis unserer Arbeit an Lieferanten-Import- und Marktplatz-Sync-Integrationen für PrestaShop 1.7, 8 und 9. Die folgenden Diagnose-Abfragen laufen gegen PrestaShop-Core-Tabellen, die Sie in Ihrem eigenen Shop prüfen können.

Autor: Redaktionsteam von mypresta.rocks — wir entwickeln PrestaShop-Module und betreiben selbst PrestaShop-Shops.

Eine schlechte Produktfeed-Integration gehört zu jener seltenen Art von Fehler, die Geld kostet, während alles gut aussieht. Nichts läuft auf einen Fehler — kein rotes Banner, kein fehlgeschlagener Cronjob, kein Support-Ticket. Der Katalog fängt einfach still und leise an, den Kunden den falschen Preis, den falschen Bestand, die falsche Verfügbarkeit zu nennen, und jede kleine Unwahrheit ist eine stornierte Bestellung, eine Rückerstattung oder eine Rückbuchung, die nur darauf wartet, einzutreten.

Es geht hier um die Risikoklasse: was eine billige, undurchsichtige oder ungepflegte eingehende Import- bzw. Marktplatz-Sync-Integration mit einem Shop anrichtet — und was eine vertrauenswürdige anders macht. Wenn Sie bereits eine betreiben und nur wissen wollen, ob es Sie trifft, springen Sie direkt zu den beiden Abfragen — sie finden den Schaden in Ihrem eigenen Katalog in etwa einer Minute.

Schnellvergleich: billiger Feed vs. vertrauenswürdiger Feed

1. Phantom-Bestand: Ware verkaufen, die Sie nicht haben

Die häufigste Art, wie ein billiges Import-Modul einen Shop ausbluten lässt, ist der Phantom-Bestand — eine Bestandszahl im Shop, der nichts Reales in einem Lager entspricht. Er entsteht, wenn ein Sync eine Menge schreibt, die er nicht dem richtigen Produkt zuordnen kann: die falsche Spalte ist gemappt, ein „Verfügbar"-Flag wird als Stückzahl gelesen, oder die Menge des einen Produkts wird auf ein anderes geschrieben, weil der Abgleich falsch war. Zwei Ausprägungen: Phantom (eine Zahl, die nie der Realität entsprach) und veraltet (eine Zahl, die einmal stimmte, aber der Feed hörte auf, sie zu aktualisieren, und der Shop verkaufte weiter auf einem eingefrorenen Stand). So oder so wirkt die Zahl plausibel, also stellt sie niemand infrage — bis Sie Bestellungen stornieren, die Sie nicht erfüllen können, Rückerstattungen schlucken und auf Marktplätzen einen Defect-Rate-Treffer kassieren, der die Kontogesundheit beschädigt.

Die PrestaShop-spezifische Falle: Der echte Bestand liegt in ps_stock_available (pro Produkt, pro Kombination, abgegrenzt über id_shop oder id_shop_group) und sollte über StockAvailable::setQuantity() geschrieben werden, damit der Hook actionUpdateQuantity ausgelöst wird und der abhängige Zustand konsistent bleibt. Ein billiger Import, der die veraltete Spalte ps_product.quantity direkt beschreibt, läuft aus dem Takt mit dem, was der Shop tatsächlich ausliest. Kombinieren Sie das mit der Einstellung „Bestellung bei Nichtverfügbarkeit erlauben" (PS_ORDER_OUT_OF_STOCK, global oder pro Produkt), und eine Phantom- oder auf null gesetzte Menge wird direkt zu einem Live-Überverkauf. Eine vertrauenswürdige Integration schreibt nur eine Menge, die sie einer korrekt abgeglichenen Quellzeile zuordnen kann, prüft sie gegen den vorherigen Wert auf Plausibilität und hält alles zurück, für das sie nicht bürgen kann, statt darauf zu verkaufen.

2. Der teure Fall: ein beschädigtes Marktplatz-Angebot

Sobald Ihr Katalog einen Marktplatz beliefert — Allegro, Amazon, eBay — bearbeitet die Integration nicht mehr bloß Zeilen in Ihrer Datenbank. Sie manipuliert ein Live-Asset auf der Plattform eines anderen, nach dessen Regeln. Ein einziger fehlerhafter Push kann diese Regeln auslösen: ein Preis, den die Plattform als ungültig liest, ein auf null gesetzter Bestandswert, der das Angebot beendet, ein falsch gemappter Identifikator, der das Angebot wie ein anderes Produkt aussehen lässt.

Seien Sie präzise, was tatsächlich auf dem Spiel steht, denn die Plattformen unterscheiden sich. Was Sie verlieren können, ist Momentum auf Angebotsebene — Angebotsalter, Position, die Velocity-Signale, die das Ranking eines Kanals belohnt, Beobachter — und, auf angebotsbasierten Kanälen wie Allegro und eBay, die an dieses Angebot geknüpfte Verkaufshistorie. Produktbewertungen sind differenzierter: Bei Amazon hängen sie an der ASIN und überstehen einen Angebotswechsel in der Regel; eBay-Bewertungen sind verkäuferbezogen, nicht angebotsbezogen. „Ein fehlerhafter Push löscht Ihre Bewertungen" stimmt also nicht pauschal — aber das Momentum, das das Angebot wettbewerbsfähig gemacht hat, kann definitiv zurückgesetzt werden, und ein neu eingestelltes Angebot baut es aus dem Stand wieder auf. Der Fehlermodus, der das gefährlich macht, ist die Weitergabe: Eine billige Integration spiegelt den Katalog ohne jede Schranke an den Kanal, sodass eine fehlerhafte lokale Zeile ein Live-Angebot in Maschinengeschwindigkeit erreicht. Eine vertrauenswürdige validiert den Preis- und Bestandsschreibvorgang und blockiert massenhafte „Angebot beenden"-/Nullungs-Pushes zur Prüfung, bevor irgendetwas weitergegeben wird.

3. Angebote unter dem realen Preis: rechtliches und finanzielles Risiko

Ein Produkt, das weit unter seinem realen Preis gelistet ist, wird üblicherweise unter „verlorene Marge" verbucht. Das untertreibt. Sobald Sie eine Bestellung zu einem angezeigten Preis annehmen, erwarten manche Rechtsordnungen die Erfüllung (ein bloß angezeigter Preis ist in Common-Law-Systemen oft kein bindendes Angebot; offensichtliche Irrtümer können stornierbar sein — das hängt vom lokalen Recht und Ihren AGB ab), und in jedem Fall kostet eine Massenstornierung mehr an Rückbuchungen und Streitfällen, als die Marge wert war, die Sie schützen wollten. Falsch bepreiste Artikel werden zudem schnell gefunden: Wiederverkaufs-Skripte lauern genau darauf, sodass ein weit unter Marktwert bepreister Artikel binnen Minuten geräumt ist. Auf der Compliance-Seite ist der Verstoß gegen eine Lieferantenvereinbarung das realistische Risiko; eine reine kartellrechtliche Haftung ist eng gefasst (EU-Artikel 102 setzt Marktbeherrschung und Missbrauch voraus; das US-Recht behandelt Preise unter Einstandspreis grundsätzlich als legal, sofern sie nicht verdrängend sind). Und Google Merchant verlangt, dass Ihr Feed-Preis mit Ihrer Landingpage übereinstimmt, sodass eine Abweichung in Ablehnungen im bezahlten Kanal überschwappt.

Der Auslöser ist fast immer ein Abgleichsfehler vorgelagert, und es wird keine Exception geworfen — das Angebot geht einfach zu einem Bruchteil seines Werts live. Die Verteidigung ist eine Preisuntergrenze, die einen unplausiblen Schreibvorgang verweigert, bevor er den Shop oder einen Kanal erreicht. Die eine Feinheit, die man einbauen sollte: Vergleichen Sie Gleiches mit Gleichem — ein Grundpreis, der die Untergrenze passiert, kann trotzdem unter den Einstandspreis rutschen, sobald ein aktiver ps_specific_price-Rabatt oder eine Katalogregel greift. Die Untergrenze muss also den effektiven Preis berücksichtigen, nicht nur ps_product_shop.price.

Die Grundursache: Abgleich über instabile Lieferanten-IDs

Das ist die Erbsünde der Feed-Integration. Interne Lieferanten-IDs sind nicht stabil — Distributoren recyceln und vergeben sie neu, während ihre eigenen Systeme sich verändern. Gleichen Sie über diese ID ab, binden Sie Ihren Katalog an ein bewegliches Ziel: An dem Tag, an dem ein Lieferant eine ID für einen anderen Artikel wiederverwendet, übernimmt Ihr teures Produkt Preis und Bestand des billigen. Verankern Sie stattdessen an einem stabilen Identifikator des Zielprodukts. In PrestaShop ist das eine eindeutige GTIN (ean13 / upc), die Herstellerteilenummer mpn oder Ihre eigene reference, auf Kombinationsebene (ps_product_attribute). PrestaShop 8.1+ validiert ean13 auf Produktebene als GTIN. Die eigene Referenz des Lieferanten gehört in ps_product_supplier.product_supplier_reference, abgegrenzt über id_supplier, und sollte nur als deterministischer Fallback verwendet werden — niemals als Primärschlüssel, der Preis und Bestand überschreibt.

Wie Sie erkennen, dass es Sie bereits trifft

Wenn Sie heute ein billiges Import-Modul betreiben, müssen Sie nicht auf eine Beschwerde warten. Der Schaden hinterlässt Fingerabdrücke. Dies sind Smoke-Checks für den ersten Durchgang — schreibgeschützt, sicher auf einer Kopie — kein vollständiges Audit, aber sie legen die beiden Fehler offen, die am meisten kosten.

Doppelte Identität — die Voraussetzung für einen Falsch-Produkt-Abgleich. Jede GTIN, die von zwei Basisprodukten geteilt wird, ist ein Datendefekt und die Vorlage für eine Falsch-Produkt-Vertauschung:

SELECT ean13, COUNT(*) AS n
FROM ps_product
WHERE ean13 <> ''
GROUP BY ean13
HAVING n > 1;
-- für upc, mpn und die ps_product_attribute-Identifikatoren (Kombinationen) wiederholen

Angebote unter Einstandspreis — alles, was unter seinen eigenen Einkaufskosten bepreist ist, ist ein aktives Margen-Leck oder ein Abgleichsfehler, der bereits gefeuert hat. Beachten Sie id_shop: Im Multistore kann dasselbe Produkt in einem Shop unbedenklich und in einem anderen unter Einstandspreis sein. Dies prüft nur den Grundpreis — es verrechnet keine aktiven specific_price-Rabatte, Steuern, Gebühren oder Kombinationen; behandeln Sie ein sauberes Ergebnis daher als „kein offensichtliches Grundpreis-Leck", nicht als „alles in Ordnung":

SELECT p.id_product, p.reference, ps.id_shop, ps.price, ps.wholesale_price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE ps.wholesale_price > 0
  AND ps.price < ps.wholesale_price;

Zeilen unter Einstandspreis sind ein aktiver Fehler; doppelte Identifikatoren sind ein Datendefekt und eine Falsch-Produkt-Vertauschung, die nur darauf wartet, einzutreten. So oder so steckt es jetzt in Ihrem Katalog, nicht bloß in der Theorie.

PrestaShop-eigene Fußangeln, die man kennen sollte

• Die CSV-Import-Checkbox „Alle Produkte vor dem Import löschen" — zusammen mit „Alle ID-Nummern erzwingen" ist das die berüchtigtste katalogzerstörende Aktion in PrestaShop. Ein einziger unbeaufsichtigter Lauf kann den Katalog löschen und neu verschlüsseln.
• Das Beschreiben von ps_product.quantity statt der Nutzung von StockAvailable. Der echte Bestand liegt in ps_stock_available; die Umgehung der API überspringt den Hook actionUpdateQuantity, sodass Caches und alle davon abhängigen Listener nie erfahren, dass sich die Zahl geändert hat.
• Multistore-Abgrenzung. Preise sind über id_shop abgegrenzt; Bestand über id_shop oder eine gemeinsame id_shop_group. Ein Import, der die Abgrenzung ignoriert, aktualisiert den falschen Shop — oder alle auf einmal.

Katalog-Drift und abgeschnittene Feeds

Katalog-Drift ist das langsame Auseinanderdriften zwischen dem, was Ihr Lieferant heute anbietet, und dem, was Ihr Shop noch anzeigt — hinzugefügte, ausgelistete und neu bepreiste SKUs, die Ihr Feed nicht abgebildet hat. Der übelste Fall ist ein ausgelistetes Produkt, das noch Phantom-Bestand zeigt: Der Kunde kauft etwas, das Sie nicht beschaffen können. Der Umgang damit ist heikel. Erkennen Sie „aus dem Feed verschwunden", aber killen Sie das Produkt nicht blind — der Abverkauf von realem, eigenem Bestand (vorhanden nach Reservierungen, nicht die Zahl des Lieferanten) ist Geld, das Sie bereits bezahlt haben. In einem Katalog mit mehreren Lieferanten sollte „aus einem Feed verschwunden" diese Quelle streichen, nicht das Produkt, und Sie schalten erst dann auf „nicht mehr verfügbar", wenn der reale vorhandene Bestand null erreicht und kein anderer Lieferant ihn abdeckt.

Der Fehler, der aus einem kleinen Problem eine Katastrophe macht, ist der abgeschnittene Feed — ein Download, der auf halbem Weg abbricht und den ein naives Modul als vollständig behandelt. Plötzlich sieht ein großer Teil der SKUs „fehlend" aus und wird massenhaft auf null gesetzt oder ausgelistet. Die Lösung ist ein Import-Lauf-Audit: Handeln Sie nie auf Basis eines Feeds, den Sie nicht gegen den vorherigen Lauf validiert haben.

CREATE TABLE ps_feedrun (
  id_run         INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  supplier       VARCHAR(64),
  started_at     DATETIME,
  row_count      INT UNSIGNED,
  prev_row_count INT UNSIGNED,
  checksum       CHAR(64),
  state          ENUM('running','applied','rejected'),
  reject_reason  VARCHAR(255)
);
-- Den Lauf ablehnen (nie Entfernungen anwenden), wenn der Download unvollständig ist,
-- die Prüfsumme fehlschlägt, der Export-Zeitstempel veraltet ist oder row_count
-- gegenüber prev_row_count einbricht.

Wie ein einziger fehlerhafter Lauf kaskadiert

Illustrativ, aber jeder Schritt ist ein realer Mechanismus: Ein geplanter Import läuft über Nacht, wie seit Monaten. Diesmal bricht der Export auf halbem Weg ab, und das Modul nimmt ihn als Evangelium. Produkte hinter dem Abbruchpunkt sehen „verschwunden" aus, also wird ihr Bestand auf null gesetzt. Eine Handvoll IDs, die der Lieferant in dieser Woche recycelt hat, binden teure Artikel an billige Zeilen, und deren Preise werden überschrieben. Bis sich jemand einloggt, zeigt der Shop „nicht auf Lager" bei Live-Produkten, ein paar Artikel stehen weit unter Einstandspreis und verkaufen bereits an Bots, und — weil der Katalog alles ohne Schranke weitergereicht hat — sind Marktplatz-Angebote wegen ungültiger Daten zurückgesetzt worden. Keine einzige Zeile warf einen Fehler. Jede Schutzvorkehrung, die das abgefangen hätte — das Import-Lauf-Audit, die Preisuntergrenze, die Herkunftsprüfung, die Kanal-Schranke — fehlte schlicht.

Was eine vertrauenswürdige Feed-Integration leisten muss

• Abgleich über stabile Identität — eine GTIN (ean13/upc), mpn oder Ihre eigene reference, auf Kombinationsebene; Lieferantenreferenz nur als abgegrenzter Fallback.
• Preise vor der Veröffentlichung absichern — eine Untergrenze auf den effektiven Preis (nach specific_price und Katalogregeln), die verweigert und alarmiert, statt zu veröffentlichen.
• Bestand zuordenbar schreiben — über StockAvailable, nur aus einer korrekt abgeglichenen Quellzeile, mit einem Plausibilitätsband für große Sprünge.
• Jeden Import-Lauf auditieren — Prüfsumme, Zeilenzahl gegenüber der vorherigen, Aktualität des Exports; ein verdächtiger Feed treibt niemals Entfernungen an.
• Kanal-Weitergabe absichern und umkehrbar bleiben — vor jeder Übermittlung an einen Marktplatz validieren und vor jeder Änderung einen Snapshot ziehen, damit die Wiederherstellung ein Restore ist, kein Neuaufbau.

FAQ

Warum verkauft mein Shop nicht vorrätige Artikel?

Meist Phantom- oder veralteter Bestand, oft verstärkt durch „Bestellung bei Nichtverfügbarkeit erlauben", oder eine Bestellung, die in das Zeitfenster zwischen zwei Syncs fällt. Die Lösung ist eine Integration, die den Bestand zuordenbar über StockAvailable schreibt, eine bestätigte Null von einer fehlenden Aktualisierung unterscheidet und unplausible Sprünge absichert.

Wie höre ich auf, unter Einstandspreis zu verkaufen?

Setzen Sie vor jeden Preisschreibvorgang eine Untergrenze, verglichen auf dem effektiven Preis nach jedem aktiven specific_price oder jeder Katalogregel — nicht bloß ps_product_shop.price. Verweigern und alarmieren Sie, statt zu veröffentlichen, und halten Sie die Kostendaten aktuell, denn veraltete Kosten verbergen einen Verkauf unter Einstandspreis, bis der Margenbericht eintrifft. Die obige Abfrage für Verkäufe unter Einstandspreis findet die, die bereits live sind.

Was ist Katalog-Drift?

Die wachsende Lücke zwischen dem, was Ihr Lieferant jetzt anbietet, und dem, was Ihr Shop noch anzeigt. Messen Sie Ihre eigene, indem Sie den aktuellen Feed des Lieferanten gegen Ihren Live-Katalog abgleichen — jede SKU, die im einen und nicht im anderen steht, ist Drift: ein falscher Preis, Phantom-Bestand oder ein Artikel, den Sie nicht mehr beschaffen können.

Der Kern der Sache

Eine Feed-Integration verdient sich ihr Geld an ihrem schlimmsten Tag, nicht an ihrem durchschnittlichen. Wenn der Export abbricht, eine ID recycelt wird oder ein Distributor über Nacht neu bepreist, verweigert eine gut gebaute Integration die schlechten Daten — und eine billige wendet sie an. Keiner dieser Fehler ist exotisch — sie sind das vorhersehbare Ergebnis davon, eine Handvoll Schutzvorkehrungen zu überspringen, die nicht schwer zu bauen sind. Lassen Sie die beiden obigen Abfragen gegen Ihren eigenen Katalog laufen; wenn sie Zeilen zurückgeben, haben Sie die Antwort bereits.