UPDATE: V1.2 vorgestellt mit Delisting von Artikeln via Datei.
Gastkommentar von Nina Obermeyer, Projektmanagerin Performance Marketing bei OTTO:
Viele PSMs sind in der Zwischenzeit mit Einzellösungen oder zumindest –ideen auf mich zugekommen. Ich glaube weiterhin daran, dass nur eine öffentliche Diskussion den PSM-Markt befördern kann und möchte hiermit noch einmal mit kurzen Worten beschreiben, welche Probleme OTTO vor sich sieht und wie wir uns eine Lösung vorstellen würden. Ich denke, OTTOs Sicht der Sicht unterscheidet sich da im Großen und Ganzen nicht von der Sicht anderer Shopbetreiber.
Probleme bei der Nutzung des Feedprozesse:
- als Basis wird der Shop genutzt (Abzüge von Daten, die (noch) nicht live sind, nicht so einfach möglich / bei uns definitiv eine Umstellung, die mehrere Wochen bis Monate dauern würde)
- die anschließende Generierung aller Feeds dauert eine gewisse Zeit (bei uns ca. 2 Stunden)
- die Aktualisierung auf PSM-Seiten dauert Zeit, egal wie wenig
Ergo: Die Datenkorrektur oder Löschung im Standard-Feed dauert zu lang
Mein Wunschprozess wäre:
- ich fange alle Artikelnummern, die demnächst im Preis angehoben werden sollen, vorher ab
- ich melde* diese Artikelnummern den PSMs, die die Artikel dann möglichst sofort löschen
- über den ganz normalen Feedgenerierungsprozess kommt der Artikel zum höheren Preis dann wieder in die PSMs
* Und diese „Meldung“ von Artikelnummern müsste für alle PSMs standardisiert werden. Ich kann nicht für jede PSM einen anderen Prozess bedienen. Der eine will eine Liste überliefert bekommen, der nächste per xml und der dritte per Einzellinkaufruf für jede Artikelnummer.
Einige PSM-Betreiber denken in ihren Konzepten schon deutlich weiter und erarbeiten auch Lösungen für jegliche andere Art von Datenänderung. Das begrüße ich aus Performancegründen sehr wohl – das Gerüst, welches uns juristisch sichern soll, ist mir im Moment aber deutlich wichtiger und sollte bei allen dieselbe Basis sein.
Ich bin gespannt auf Feedback!
Nina Obermeyer, Projektmanagerin Performance Marketing
Kommentar von Carsten Ussat, IPSM dazu:
Ich stelle die Idee, mehrere Artikel in einer separaten Datei im Shop bereitzustellen und der PSM die Order zu erteilen, diese Datei zu laden und die enthaltenen Artikel zu löschen in der neuen Version V1.2 des Standards vor (siehe neue Posititon 2.3):
STAND 01.04.2010 – Neue Version V1.2:
www.cyberline.de/download/20100401_ipsm_v1.2_01.pdf
Ich bitte um Feedback und Diskussion – vor allem von größeren PSM, die sehr umfangreiche Datenvolumina vorhalten. Welche Probleme sehen Sie? Sind die Vorschläge für Sie praktikabel? Bitte als Kommentar zu diesem Artikel.
Einsortiert unter:Technik | 3 Kommentare
3 Antworten auf „UPDATE: V1.2 vorgestellt mit Delisting von Artikeln via Datei.“
Kommentar verfassen
-
Letzte Kommentare
Alex Beer on Die Idee Martin Hepp on Die Idee M.Köhler on UPDATE: V1.2 vorgestellt mit D… Nina Obermeyer on UPDATE: V1.2 vorgestellt mit D… IWEG UG » Init… on UPDATE: V1.2 vorgestellt mit D…
..und um mich selbst noch zu kommentieren:
Die PSMs müssten dann noch damit zurecht kommen, dass
- wir auch Artikelnummern zum Löschen schicken, die gar nicht in deren Bestand waren (bei PSMs, die nicht das Voll-Sortiment als Feed erhalten)
- Artikelnummern nicht eindeutig sind. Also zumindest bei den Systemen, in denen wir zu einer Artikelnummer fünf Datensätze (z.B. fünf Größen) im Feed überliefern.
Es ist aus logischer Sicht eine Katastrophe, wenn 5 Datensätze mit der selben Aritkelnummer (quasi als eindeutige Kennzeichnung des Datensatzes) übermittelt werden. Selbst wenn sich diese nur in der Größe unterscheiden.
Wo zieht man denn da die harte Grenze? Bei Kleidungsstücken ist es noch “okay”, weil sich die Größe nicht auf den Preis auswirkt (wer garantiert das?)? Wie geht man damit bei technischen Produkten um? Wer garantiert der PSM, dass man nicht versehentlich die Daten falsch eingepflegt hat und eine Waschmaschine, wie auch einen Nike-Turnschuh mit der selben Artikelnummer überträgt?
Was ich damit sagen will, ist: Artikelnummern haben eindeutig zu sein.
Wie könnte man das Problem mit den verschiedenen Größen lösen?
Ich habe mich im Detail noch nicht mit der technischen Umsetzung befasst, allerdings wäre es mir aus logischer Sicht lieber, wenn man z.B. die Größe als ein Attribut des Datensatzes mit der Artikelnummer x betrachtet. Dieses Attribut kann verschiedene Werte enthalten. Über Schlüssel-Werte-Paare ließen sich auch komplexere Strukturen denormalisieren. Es ist dann die Aufgabe der PSM diese Daten in die interne Struktur einzupflegen.
Zu den hier vorgestellten Vorschlägen muss ich folgendes sagen: Es ist eine Illusion anzunehmen, dass ein Preis-Update wirklich in Echtzeit erfolgen kann. Wie soll das technisch zu lösen sein, wenn ein Shop bei 10 PSMs gelistet ist? Soll der etwa warten, bis die alle ihre Updates gemacht haben, um dann allen PSMs mitzuteilen, dass bei allen anderen PSMs die Preise identisch sind?
Die Presseerklärung des BGH spricht von einer “höchstmöglichen” Preisaktuallität. Genau darauf würde ich auch aufsetzen wollen.
Meiner Ansicht nach reicht es aus, wenn ein Shop der PSM mitteilt, dass die Preise für einige Produkte sich verändert haben. Je nach Anzahl der betroffenen Produkte, könnte man die neue Situation direkt im Link mitteilen (z.B. ?update=12345-4,39+6789-999,99).
In diesem Link wende ich das Schema “Artikelnummer – neuer Preis” an, wobei das Schlüssel-Werte-Paar durch einen Bindestrich getrennt worden ist und die Paare durch ein Plus-Zeichen voneinander zu unterscheiden sind.
Falls die Anzahl der zu updatenden Produkte zu groß ist, um diese per Link mitzuteilen, sollte der Shop eine CSV-Datei zur Verfügung stellen, die sich ausschließlich auf die zu updatenden Produkte und ihre Preise beschränkt. Gängige Datenbanken sind in der Lage binnen weniger Sekunden ein konkurrierendes Update auf tausende Datensätze durchzuführen.*
Mit allem Respekt gegenüber dem BGH-Urteil: Das muss aktuell genug sein. Ansonsten könnte ich jede Tankstelle verklagen, die ihre Preise erhöht/gesenkt hat, während ich an die Zapfsäule fuhr.
Dabei muss der Shop folgende Garantie geben:
Die Datei die man ggf. abholen muss, muss bereits generiert sein, bevor der Link an die PSM geschickt wird.
Die PSM muss die Garantie geben, dass der Preis aus technischer Sicht so schnell wie möglich geupdatet wird.
Was an diesem Ansatz zu diskutieren wäre, ist, ob man in den hier zu erarbeitendem Standard noch so etwas wie ein Standard-CSV-Format einbringt. Ich könnte mir zum Beispiel vorstellen, dass man eine Spalte “aktueller Preis” und zwei Spalten “Datum update”, “neuer Preis” zur Verfügung stellt. Welcher Preis letzten Endes angezeigt wird, kann (innerhalb des DB-Querys!) dynamisch anhand eines Timestamps festgelegt werden.
*Im Falle von MySQL hat man beispielsweise das MyISAM-Engine, welches konkurrierende Updates zulässt, wie auch das Falcon-Engine (transaktionssicher).
Für Anregungen, Kritik und andere Meinungen bin ich jederzeit offen!
Beste Grüße