Wie berichtet, geht derzeit eine neue Abmahngefahr für Online-Shops um sofern diese ihre Produkte auch in Preissuchmaschinen listen. War es früher die Anzeige der Versandkosten und die korrekte Anzeige des Grundpreises (bei Artikeln, für die die Angabe vorgeschrieben ist) die den Preissuchmaschinen bzw. angeschlossenen Händlern zu schaffen machte, geht es aktuell um die Aktualisierung bei Preisänderungen.
Auswirkungen des neuen BGH-Urteil
So entschied der BGH vor knapp zwei Wochen, dass man die Preise für ein Produkt im Shop erst erhöhen darf, wenn die entsprechende Änderung auch in der Preissuchmaschine angezeigt wird. Dies sei dem Händler zuzumuten, denn der Verbraucher erwarte eine “höchstmögliche Aktualität”.
Als Konsequenz auf dieses Urteil, müssen Onlinehändler vor Preiserhöhungen also darauf achten, diese im eigenen Onlineshop erst dann vorzunehmen, wenn der Preis in allen seinen genutzten Preissuchmaschinen bereits aktualisiert wurde. Die Krux ist, dass der Händler in der Regel keinen Einfluss darauf hat, wann die Daten in den Preisvergleichslisten aktualisiert werden.
Probleme bei der technischen Umsetzung
Die Frage ist also, wie er dies technisch bewerkstelligen kann. Denn üblicherweise ist der Weg ja umgekehrt. Der Onlinehändler aktualisiert seine Preise im Onlineshop und informiert anschließend die Preissuchmaschinen über sog. Produktdatenfeeds. Dies genügt nun nicht mehr.
Noch wurden die Urteilsgründe zum BGH-Urteil nicht veröffentlicht. Die rechtlichen Rahmenbedingungen sind also noch unbekannt. Klar scheint zumindest, dass eine Lösung zur rechtlich wasserdichten Einhaltung der Vorschriften zum einen nur technischer Natur sein kann und wohl auch nur seitens der Preissuchmaschinen-Betreiber stattfinden kann.
Wie Preissuchmaschinen reagieren
Wir wollten daher von einigen Preissuchmaschinen-Betreibern wissen, wie sie auf das BHG-Urteil reagieren und welche Lösungsansätze sie den beunruhigten Shop-Betreibern anbieten werden.
Auch wenn bereits vereinzelt Zwischenlösungen angeboten werden, scheint sich abzuzeichnen, dass es bei den Produktsuchmaschinen letztlich auf eine gemeinsame Lösung hinauslaufen könnte.
Oder wie Björn Schäfers, Geschäftsführer bei smatch.com, schildert: „Wie der gesamte Markt verfolgen auch wir das Thema sehr aufmerksam und sind auch mit anderen Produktsuchmaschinen und Preisvergleichsdiensten, genauso wie mit Händlern im engen Austausch. Wir sind hier an einer gemeinsamen Lösung mit allen Beteiligten interessiert.“
Königsweg Echtzeitabfrage
Als Sofortmaßnahme haben quasi alle Preissuchmaschinen die Suchergebnisse nun deutlich mit dem jeweilig letzten Zeitpunkt der Aktualisierung gekennzeichnet und oftmals einen zusätzlichen Hinweis auf die alleinige Gültigkeit des Preises im Shop aufgenommen.
PreisRoboter hat zusätzlich neue Scan-Roboter in Betrieb genommen, um die angeforderten Scans schnellstmöglich zu bearbeiten. Weiter bot PreisRoboter ihren kostenpflichtigen Service „Sofortscan“ seinen Händlern in der ersten Woche nach Bekanntgabe des Urteils kostenlos an.
Dieser Service veranlasst, dass zum Zeitpunkt der Anforderung die Produktlistung gestoppt und erst nach erfolgreicher Abarbeitung des Scans wieder reaktiviert wird. Somit können die Änderungen schnellstmöglich bei PreisRoboter eingepflegt werden.
Derlei Sofort-Maßnahmen dürfen jedoch nicht darüber hinwegtäuschen, dass zumindest dem aktuellen Stand nach künftig an Echtzeitabfragen kein Weg vorbeiführen wird.
So arbeitet auch PreisRoboter bereits an einer Änderung der technischen Infrastruktur. Noch im Laufe dieses Jahres soll es möglich sein, Liveupdates anzubieten und damit die Scanintervalle deutlich zu verkürzen.
Andreas Wellensiek, Gründer von Wir lieben Preise, sieht die Zukunft ebenfalls in der Live-Abfrage: „Vielleicht müssten die Preise einfach live aus dem Shop ausgelesen werden, so wie es bei den Produktbildern schon lange üblich ist. Das scheint mir im Augenblick die beste Lösung für alle Beteiligten zu sein.“
PubSubHubbub
Der Name klingt erst einmal seltsam, könnte aber dennoch der von Björn Schäfers skizzierte gemeinsame Lösungsweg sein.
Erstmals wurde PubSubHubbub (PuSh) bei unseren Gesprächen von Dennis Klüsekamp, Geschäftsführer von preistipp.de, in den Ring geworfen: „Wir denken gerade aktiv über mehrere Möglichkeiten nach, aktuell kann allerdings nur die logische Schlussfolgerung eine Liveabfrage, z.B. über PubSubHubbub, sein.“
Das Online-Magazin drweb.de erklärt PuSH so:
Wie PuSH funktioniert
Schreibt nun unser Blogger einen neuen Beitrag, wird im Moment der Veröffentlichung der Hub angepingt. Daraufhin holt dieser unverzüglich den aktualisierten Inhalt ab und informiert aktiv die Abonnenten mittels Push. Weil der Ping hin zu den Abonnenten nicht nur die Information enthält, dass neuer Content vorliegt, sondern diesen Content gleich komplett mit übermittelt, spricht man vom „Fat Ping“.
Was bei Bloggern und Feedreadern funktioniert, sollte aber auch bei Online-Shops und Preissuchmaschinen funktionieren.
RTPC-Concept
Der Preisvergleich apnoti.com ist hier offensichtlich schon einen Schritt weiter. So hat apnoti.com mit seinem RTPC-Concept (Real-Time Product Communication) ein Echtzeit-System für Online-Händler entwickelt. Dies ermöglicht bereits jetzt den vollautomatischen Abgleich von Angebotsdaten in Echtzeit.
Auf Händlerseite muss der RTPC-Standard einmalig aktiviert werden, indem eine Art Snippet in die Produktdetailseiten eingebunden werden. Neue Preisänderungen werden dann in Echtzeit von apnoti.com automatisch festgestellt. Die Serverlast liegt laut apnoti.com dabei hauptsächlich auf deren Seite.
apnoti.com möchte die RTPC-Technologie in absehbarer Zeit übrigens auch anderen Produktsuchmaschinen als Dienstleistung zur Verfügung stellen.
Egal, ob nun PubSubHubbub, RTCP-Concept oder etwas anderes. Zumindest derzeit scheint eine Echtzeitabfrage bzw. Push-Technologie die einzige langfristige Lösung zur Problematik. Dabei könnte es wichtig sein, dass alle Preissuchmaschinen-Betreiber an einem Strang ziehen und sich auf einen gemeinsamen Weg bzw. Technologie einigen.
Lädt...
Diese Änderungen im Verpackungsgesetz kommen 2022
Bundestagswahl ‘21: Online-Händler fordern Fairness und Erleichterungen
Rücknahme & Recycling im nationalen und internationalen E-Commerce
Abmahnungen wegen Verstößen gegen die Textilkennzeichnungsverordnung mehren sich
FWP Systems meint
Danke für den interessanten Artikel und die Aufstellung der Möglichkeiten.
Einige der Ideen sind zwar nett, lassen sich aus meiner Sicht jedoch in der Praxis nicht umsetzen.
Probleme bei apnoti.com sehe ich in erster Linie darin, dass die Aktualisierung von Produkten durch den Aufruf der Detailseite erfolgt.
Fraglich ist, ob die Artikelseite häufig genug aufgerufen wird, um die Daten zu übermitteln.
Mit Livedaten hat der Ansatz leider wenig zu tun.
Ebenso sind aus meiner Sicht Liveanfragen wie Andreas vorschlägt, nicht praktikabel, da Preisvergleiche ansonsten eine recht hohe Datenbanklast auf den Shops erzeugen können.
Aus meiner Sicht ist der einzig praktikable Weg ein Push-Dienst.
H.P. meint
Sehe ich genauso.
Vielleicht klappt es ja diesmal so ein Protokoll auf den Weg zu bringen, der letzte Versuch von Robert und meiner Wenigkeit 2008 ein solches Protokoll an die entsprechenden Leute zu bringen scheiterte ja geradezu grandios.
Robert Fischer, sandoba.de meint
Hoffen wir, dass durch dieses Urteil ein wenig Schwung in die Standardisierung der Formate und Übermittlungswege für die Produktdaten von Online-Shops kommt. Ansätze wie shopinfo.xml konnten sich bislang leider noch nicht in ausreichender Form durchsetzen, zu unterschiedlich sind teilweise die Anforderungen der einzelnen Preisvergleichsdienste und gerade die großen setzen einfach gerne auf eigene Formate, auch um sich einen Vorteil gegenüber kleineren Diensten zu verschaffen (Stichwort zusätzlicher Aufwand für die Erstellung weiterer Schnittstellen).
Ohne Frage muss es aber bei einer Umstellung der Datenübermittlung auf Echtzeit-basierte Verfahren wie PubSubHubbub im Zuge des Urteils zu einer weiteren Standardisierung kommen. 20 oder mehr unterschiedliche Lösungen zu integrieren ist kaum praktikabel, weder für kleinere Preisvergleichsdienste, die Entwickler von Shop-Software bzw. entsprechende Dienstleister oder die Shop-Betreiber, die letztendlich die Kosten für den erhöhten Entwicklungsaufwand + die laufende Überprüfung/Pflege inhouse oder durch Dritte werden tragen müssen.
Nur ein einheitlicher Standard auf XML-Basis wird hier die Lösung bringen. Bspw. 1 XML-Datei mit Informationen zum Shop, Format und URL der Produktdaten sowie 2 XML-Dateien mit kompletten Produktdaten bzw. nur Kennung und aktuellem Preis (jeweils dynamisch generiert bzw. nach der letzten Änderungen vom Shop erzeugt).
Nach einer Änderung erfolgt vom Shop ein Ping eines Hubs, welcher dann die angeschlossenen Dienste informiert (+ die URL der zentralen XML-Datei übermittelt), damit die Daten abgeholt werden können. Es bleibt eigentlich nur die Frage, wer letztendlich diesen Hub betreibt. Möglichst ein unabhängiger Anbieter, d.h. keiner der Preisvergleichsdienste. Vllt. wäre daher eine Weiterentwicklung von shopinfo.xml am besten, die Grundlagen sind dort schließlich bereits gelegt.
H.P. meint
Ich enttäusche Dich nur ungern aber shopinfo.xml ist keineswegs unabhängig.
Dr. Stefan Kuhlins (derjenige der mit seinen Studenten das Format erfunden hat) ist Mitgründer von gimmahot und durchaus in der Szene verankert da das Format von den Diensten ja teilweise genutzt wurde.
Ich sehe shopinfo.xml allerdings nicht als praktikable Lösung, es ist ungenügend was Datensicherheit und Echtzeitfähigkeit anbelangt, zudem in den Umsetzungen nicht wirklich den heutigen Bedürfnissen bzgl. der Produktauswahl entsprechend.
Ich glaub auch kam das es ein einheitliches Format geben wird, dazu werden die Preissuchmaschinen nicht bereit sein, niemand gönnt in diesem Bereich dem anderen Produktdaten. Das es Probleme geben dürfte ein solches Format in möglichst vielen Shopsystemen durchzusetzen liegt nahe.
Daher denke ich das eine out of the box Lösung gut wäre, und das wäre per RTPC oder Pubsubhubbub durchaus denkbar. Allerdings ist das Problem das dies nur die Formatfrage lösen würde, den Hub kann man schlecht auslagern da man dann ja wieder die Datensichereit gefährden würde. Wir reden hier immerhin von maschinell lesbaren Produkt- und Preisdaten, etwas das sicherlich auch die werte Konkurrenz interessieren würde und das Shopbetreiber eigentlich ungern in die freie Welt entlassen würden. Ich bin schon immer erstaunt bei wie vielen Shopbetreibern diese Daten ohne jeglichen Schutz frei abrufbar sind.
Bis es zu einem einheitlichen Format kommen wird sehe ich noch ein paar Urteile ins Land gehen.
Peter meint
Das erfreuliche an diesem Artikel ist, dass im Nachgang ein paar Betreiber zumindest etwas aus der Deckung gegangen sind.
Mein Fazit: Echtzeitaktualisierung wird kommen, ob dies aber auf einen gemeinsamen Standard/Technik aufsetzt darf zumindest momentan bezweifelt werden.
H.P. meint
Glaube ich nicht mal, ich denke man wird wohl eher gar nichts tun.
PubSubHubbub ist nett (haben wir gerade in unser Shopsystem zur Aktualisierung der RSS Feeds integriert) aber eben, es würde nur den Benachrichtigungsweg berühren.
Die Shops müssten nach wie vor alle Daten exportieren, die Preissuchmaschinen immer noch die komplette Datei saufen und verarbeiten die Last reduziert sich nur insofern als das eben nur auf Anforderung gearbeitet werden würde. Das problem dabei ist das damit auch die technische Verantwortlichkeit für die Aktualisierung die bislang ja teilweise noch bei den Preissuchmaschinen gelegen hat auf den Shop verlagert werden würde.
Ferner müssten die Preissuchmaschinen geeignete Hubs aufsetzen, mit der Hubstruktur sieht es aber bei PubSubHubbub zumindest noch recht düster aus.
Für Shops die auf mehreren Preissuchmaschinen vertreten sind würde sich das Problem sogar verschärfen, die Pings gehen an die jeweiligen Dienste heraus und die greifen alle (im Idealfall zumindest) sofort zu. Bei größeren Datenbeständen die live exportiert werden müssten kann das schonmal recht ordentlich Last ergeben wenn der Export nicht vernünftig programmiert wurde.
Eigentlich sollte man weg von der Dateiebene, hin zur Produktebene, damit würde man einen Komplettexport mit anschließender Verarbeitung vermeiden. Allerdings gibt es dafür noch weniger Lösungsansätze die von allen getragen werden könnten, zudem wird die ganze Sache damit noch komplexer da man hier wohl eher auf eine XML API aufsetzen müsste.
Robert Zajonz meint
Solange sich alle PSM streiten und nicht wissen was Sie machen sollen, realisieren wir hier eine eigene „Lösung“. Habe jetzt keinen Namen dafür, aber es geht wie folgt. Bitte korrigiert mich, wenn ich da einen Denkfehler habe.
Normalerweise meldet man ja an die Preissuchmaschine einen Link wie
htt../..meinshop.de/x.php?artikel=123&trackid=55
Wir erweitern diesen Deeplink so:
htt../..meinshop.de/x.php?artikel=123&trackid=55&preis=U4bfui3frsf4HDi33fs43334fds..
Was soll der gehaschte Wert? Nun, dahinter verbirgt sich (kryptisch natürlich so intelligent verschlüsselt, dass den Preis keiner manipulieren kann) der seinerzeit an die PSM übergebene VK!
Klickt ein Besucher bei einer PSM drauf und kommt in den Shop zurück, blende ich ihm den zu dem Zeitpunkt der Überspielung an die PSM gültigen Preis ein. Dieser ja dann logischerweise 100% der gleiche ist! Wenn der Kunde „in den Warenkorb“ klickt, wird auch dieser Preis in den Warenkorb übernommen.
In den seltensten Fällen ändert sich der Preis so gravierend, dass der Händler auf Marge verzichten muss, also gehen wir bei POWERGAP den umgekehrten Weg und warten nicht x Jahre auf die PSM bis sich die Herrschaften mal an einen Tisch gesetzt haben (wovon wohl nicht auszugehen ist, ich und PeterH. haben das ja schon mal versucht). Zwar bedeutet das einmalig Aufwand beim Shopsystementwickler, aber dann können alle schon morgen ruhig schlafen.
Es rennen sowieso wieder alle PSM allein los! Noch gestern hat eine PSM hier Ihren Datensatz um die Spalte „Preis gültig bis“ erweitert, was wir dann für die umgesetzt haben. Oh je, was für ein Quatsch! Egal, braucht man nicht zu kommentieren..
Würde mich freuen, wenn Ihr Feedback gebt, ob ich da total falsch liege, oder ob das Zurücksenden des Preises doch eigentlich eine pragmatisch einfache Lösung ist?
Robert Fischer, sandoba.de meint
@Robert Zajonz:
Die Nutzung eines Hashes in den URLs ist durchaus machbar. Dies bedeutet dann aber, dass man bei jeder Erzeugung eines Exports durch den Shop-Betreiber (Push) und bei jedem Abruf der Daten durch einen Preisvergleichsdienst (Pull) alle zu diesem Zeitpunkt gültigen Preise der Artikel und Artikel-IDs samt der Hashes zusätzlich hinterlegen muss, was je nach Shop durchaus recht umfangreich sein kann.
Mögliche Lösung: Datum ebenfalls hinterlegen und z.B. nach 1 Woche automatisch löschen lassen (langsamer dürfte keiner der Anbieter sein, dann Fallback auf den aktuellen Preis).
—
In dem Urteil ging es ja um eine Preiserhöhung. Wenn über einen solchen Hash ein vorher genutzter niedrigerer Preis im Shop wieder sichtbar wird, dann dürfte dies für die Marge kein Problem darstellen. Zumindest sofern sich zwischenzeitlich nicht der Einkaufspreis stark erhöht hat und letztlich der Auslöser für die Preiserhöhung war.
—
Ein weiteres Problem jedoch: Besucher die über einen Link mit einem solchen Hash in den Shop gelangen, müssten überall konsequent nur diesen Preis sehen. Egal ob im Warenkorb/Bestellprozess, Detailansicht, nach Preis sortierten Ansichten in den Kategorien, Filterung nach Preis etc. Dort alle Queries umzuschreiben um zusätzliche Datenbanktabellen einzubeziehen ist zwar machbar, aber es muss bessere Lösungen geben.
—
Auch hier tröpfeln gerade die ersten Mails der Preisvergleichsdienste herein mit neuen Aktualisierungsintervallen, neuen Feldern etc.
Robert Zajonz meint
Danke für die Antwort!
> ..müssten überall konsequent nur diesen Preis sehen.
> Egal ob im Warenkorb/Bestellprozess, Detailansicht,
nicht ganz. Also das hatte ich schon einfacher gedacht. Es geht den Richtern ja darum, dass wenn ein Verbraucher aus einer PSM kommt, der Preis nicht teurer wird. Der Besucher landet ja im Artikeldetail, wo dank des Hashwerts der richtige Preis abgebildet ist. Klickt der wieder im Shop herum und gelangt nach einigen Klicks wieder in den Artikel, den er in der PSM gesehen hat, wird er den aktuallen (also evtl. teureren Preis) angezeigt bekommen. Denn kommt er ja nicht mehr aus einer PSM! Also nicht unmittelbar.
Ok, eigentlich wollte ich das hier nicht rausposaunen, aber ich schreibe mal ganz offen hin, was ich noch mit dem Hashwert umsetzen möchte:
Kommt der Kunde aus der PSM in den Shop und bekommt 20 EUR angezeigt, und der Artikel kostet inzwischen 25 EUR, dann kann der Shopbetreiber in der Shopverwaltung einstellen, dass er dem Kunden das als Vorteil verkauft! In diesem Fall wird dick, groß und in Farbe dem Kunden sichtlich gemacht:
„Der Artikel kostet bei uns aktuell 25 €. Sie als Kunde von geizhals.de bekommen aber mit 20 € den günstigeren Preis angeboten und sparen x %!!!“
Was der Shopbetreiber auch einstellen kann ist wenn der aktuelle Preis niedriger als in der PSM ist:
„Der Artikel ist bei geizhals.de noch mit 20 €ausgezeichnet. Aufgrund noch besserer Einkaufskonditionen können wir Ihnen den Artikel derzeit sogar für 19 € anbieten! Sie sparen x %!“
Mit diesen Möglichkeiten eröffnet man dem Shopbetreiber diese Preisunterschiede (egal ob billiger oder teuerer) in jedem Fall als Marketingfunktion für sich zu nutzen.
Ich finde ein Mehrgewinn, der die eher überschaubere Aufwendung in der Entwicklung rechtfertigt.
H.P. meint
Ich kenne diese Vorgehensweise, ist in einigen Shopsystemen durchaus nicht unüblich.
Allerdings ist Sie genaugenommen kontraproduktiv, denn damit bindet man den Kunden an die Preissuchmaschine und nicht an den Shop. Wie alle wissen das PSMs eine durchaus unangenehme Kostenstruktur haben können (nicht müssen, aber die Konversionsrate macht die Musik).
Ich persönlich wäre eigentlich dafür die PSMs zu einer anständigen bzw. einvernehmlichen Lösung zu zwingen, immerhin ist es so das wir als Shopsystemhersteller damit ja großen Aufwand haben dabei aber kaum etwas von der Sache haben. Ob unsere Kunden immer ein gutes Geschäft bei der Sache haben ist auch noch so eine Frage, manchmal wäre es ja durchaus wünschenswert Kunden von der Listung in einer PSM zu bewahren.
Man sieht immer nur eine Seite, nämlich die der PSMs, das die aber Material aus den Shopsystemen bekommen müssen sieht kaum jemand. Das unsereiner einen Haufen Aufwand hat dafür aber letztendlich nichts bekommt haben wir eigentlich ein Interesse daran eine Lösung mit Bestand zu erstellen und nicht permanent irgendwelchen Wünschen nachkommen zu müssen.
Robert Fischer, sandoba.de meint
Fasst die aktuelle Situation gut zusammen. Nur: Wie bringen wir (die „Vereinigung aller Shop-Betreiber und Shop-Entwickler“) die Preisvergleichsdienste dazu (gerade die großen), miteinander an einer dauerhaften und für alle Seiten praktikablen Lösung zu arbeiten?
H.P. meint
Falscher Ansatz Robert, es gibt nämlich keine “Vereinigung aller Shop-Betreiber und Shop-Entwickler”. Wenn es die gäbe dann wäre das auch kein Problem.
Aber da wir jeder für uns selbst wursteln und es keine Firmenübergreifende Vereinigung gibt und wir auf der anderen Seite auf dieselben Strukturen stoßen gibt es auch keine Möglichkeit etwas zu verändern.
So ist es nunmal, ich habe natürlich nichts dagegen etwas daran zu ändern, aber allein, und das steht fest, können wir nunmal nichts aurichten.
Robert Fischer, sandoba.de meint
Daher ja auch in Anführungszeichen. 😉
Als Entwickler könnte ich mir so einige „Optimierungen“ in der Branche vorstellen, gerade auch wie die einzelnen Parteien miteinander agieren. Leider bewegen sich aber nicht alle mit derselben Geschwindigkeit. Und so werden wir wohl wieder selbst nach sinnvollen Lösungen für Probleme wie dieses suchen müssen.
Robert Zajonz meint
> Ich persönlich wäre eigentlich dafür die PSMs zu einer
> anständigen bzw. einvernehmlichen Lösung zu zwingen
wie schööön das wäre, brauchen wir nicht zu betonen 🙂
Aber wie RobertF. schon sagt gibt es kein Druckmittel und wie so oft sind dann einige Shopsystementwickler einfach schneller in der Reaktion hier eine Lösung für die Shopbetreiber zu schaffen. Denn wir sind ja daran interessiert unseren Kunden zu helfen. Und so sollten wir besser handeln, als sich auf andere zu verlassen oder gar auf die PSM zu warten, von denen wenn dann ohnehin nur jeweils einzelne Insellösungen kommen. Sprich wir für jede PSM wieder einzeln umfrickeln müssen. Da ist der einmalige Aufwand mit dem oben vorgeschlagenem Konzept schneller gelöst und auch noch mehr von Vorteil für den Shop.
Für mich steht jedenfalls fest, dass ich diesen Aufwand kurz zwischen schiebe. Danach haben wir damit jedenfalls Ruhe, findest Du nicht auch?
H.P. meint
Inwiefern das BGH Urteil praktische Auswirkungen haben wird bleibt immer noch abzuwarten, erstmal müsste es Kläger geben die die Zeitverzögerungen nachweisen können. Zudem steht jetzt das Datum der Angaben normalerweise beim Preis, damit sind die PSMs mehr oder weniger aus dem Spiel.
Eigentlich müsste man jeden Zugriff der PSM protokollieren, und zwar nicht in irgendwelchen Apache Logs sondern aufbereitet für den Shopbetreiber damit der mit entsprechenden Informationen in eine eventuelle Klage gehen kann. Immerhin gibt es ja schon noch Dienste die nur alle Tage aktualisieren.
Die Lösung mit dem Hash ist schon nicht übel, allerdings ist mir die Sache schlicht ein wenig zu heikel. Wenn jemand die Nummer knackt dann haben unsere Shopbetreiber, und damit auch wir, ein echtes Problem. Das müsste also eigentlich schwerstens abgesichert sein und zwar auch gegen eventulle Brute Force Attacken die so schwer nicht wären da man ja Hash und Ergebnis schonmal kennt. Genaugenommen würde ich mit 2 Hashes arbeiten, einmal den im URL der einen in der Datenbank abgelegten Hash bestätigt der einen festen Preis vorgibt der auch in der Datenbank liegt. Den Preis direkt zu übertragen halte ich für ziemlich risikobehaftet, selbst wenn man da ein paar Zeichen dazuzaubert.
Ich sehe in der Sache aber keine Endlösung. Uns geht es doch eigentlich primär erstmal um die Benachrichtigung, das ist ja eine out of the box lösbare Sache. Das damit der Aufwand bei uns steigt ist nicht von der Hand zu weisen, und das die Preissuchmaschinen mit entsprechenden Hubs reagieren müssten ebenfalls. Immerhin, wenn die PSMs alle 5 Minuten crawlen dann gewinnen wir durch die Lösung schon etwas, nämlich weniger Last auf unseren Systemen. Vielleicht solle man doch noch mal einen Versuch starten ein Protokoll zu entwickeln, die Sache hat nämlich einen Punkt den sonst noch niemand beachtet hat, der Shopbetreiber kommt so vielleicht aus dem juristischen Dilemma heraus.
Wenn der Shopbetreiber nachweisen kann das Er bzw. Sein System nach der Preisaktualisierung die Preissuchmaschinen in Kenntnis setzte dann hat Er alles getan was Ihm technisch möglich war. Die Frage ist ob man den Shop dann noch belangen kann.
Da es zur Zeit keinen Weg gibt die „Inkenntnissetzung“ auf elegante Art und Weise zu erledigen bleibt eigenlich nur ein Weg, nämlich die Sendung einer guten alten eMail an die PSM. Wäre doch mal witzig zu sehen was die mit den tausenden eMails / Tag so anfangen würden.
So etwas wie PubSubHubbub ist an sich schon relativ gebrauchbar. Problem ist natürlich das die Dinge nicht distributiert weitergegeben werden können und dürfen, es handel sich ja um durchaus heikles Datenmaterial, der Ping also nicht an einen Hub sondern tatsächlich an die PSM gehen müsste, zudem ein Merkmal enthalten müsste das es der PSM erlauben würde den Shop zu identifizieren. Womit wir übrigens wieder auf dem Stand von 2008 in der Xing Gruppe damals angekommen wären, die Sache hätte damals bereits gelöst werden können.
Theoretisch würde ein HTTP Request mit einer nicht öffentlichen von der PSM vergebenen ShopID, gern als Hash, reichen. Diese vermerkt den Ping, fügt die Daten aus der eigenen Datenbank in die Queue und crawlt den Datenbestand.
Der Aufwand ist für alle Seiten ziemlich gering, die PSMs stellen jeweils einen Hub hin und schaffen sich eine Menge Last vom Hals und wir machen die Pings und sparen ebenfalls Last. Der Shopbetreiber bekommt keine Abmahnung, ein paar Rechtsanwälte ziehen unter Brücken, die Welt wird insgesamt ein klitzekleines bisschen schöner…
Claudia Carolina Thielemann meint
Hallo zusammen,
ich gehe die ganze Umsetzung einer geeigneten Lösung mal etwas pragmatischer an.
Zum einen glaube ich nicht, das die diversen und im Wettbewerb stehenden PSMs sich auf eine gemeinsame Lösung einigen werden. Falls doch, wird so etwas frühestens nach einen sehr langen Diskussionsprozess gelingen.
Alle oben genannten Lösungen erfordern schon einen gewissen technischen Aufwand in Programmierarbeiten und einen zusätzlichen Pflegeaufmand. Das alles resultiert letztendlich in Kosten, die ein Unternehmen wieder erwirtschaften muss. Große Shopbetreiber haben da wahrscheinlich genügend Resourcen, aber vielen der kleineren, spezialiserten Shop’s wird es da wohl schwer fallen, genügend Fachkenntnisse und Pflegeaufwand bereitzustellen.
Ich denke, das es die primäre Aufgabe der PSMs ist, eine Lösung an zu bieten. Denn gerade die PSM, die schnell eine umsetzbare Idee aufzeigt, wird einen Wettbewerbsvorteil haben, denn die Shopbetreiber werden sich, um Rechtssicherheit (Stichwort: Abmahnfalle) zu erlangen bevorzug einer solchen PSM zuwenden.
Bis dahin werden wir z.B. unsere Preisaktualisierungen bzw. Einstellungen auf 1 oder 2 PSM’s reduzieren und genau aufpassen müssen, wann welche Preise im Shop aktiviert werden können.
P.S.: Grundsätzlich halte ich das BGH Urteil für die richtige Entscheidung. Es wird helfen, seriöse Angeboten im Web zu platzieren und viele Preisdumpingaktionen erschweren oder unterbinden (wer kennt das nicht: Ein sehr guter Preis über eine Preissuchmaschine, aber leider ist die Ware nicht lieferbar oder teurer geworden)
LG
C. C. Thielemann
apnoti.com meint
Hallo Zusammen,
gerne möchte ich an dieser Stelle nochmals auf die Echtzeit-Technologie von apnoti.com hinweisen, das erste praktikable und standardisierte Echtzeit-System für Online-Händler und Preissuchmaschinen. Ausführliche Informationen zum RTPC-Standard (Real-Time Product Communication) findet man unter http://merchant.apnoti.com/.
Merkmale der neuen Echtzeit-Technologie:
– Das RTPC-Concept (Real-Time Product Communication) ist ein standardisiertes Verfahren zum Austausch von Produktinformationen in Echtzeit.
– Die Händleranmeldung für den Service ist kostenlos, schnell und unkompliziert.
– Auf Händlerseite muss der RTPC-Standard einmalig aktiviert werden, indem eine Art Snippet in die Produktdetailseiten eingebunden werden.
– Anschließend erfolgt der automatische Abgleich von Produktinformationen. Manuelle Feedübermittlungen/ Datenexports etc. entfallen und minimieren somit den Administrationsaufwand auf Seiten der Händler.
– Neue Preisänderungen werden in Echtzeit von apnoti.com mittels der RTPC-Technologie festgestellt, wobei die „Serverlast“ hauptsächlich von apnoti.com getragen wird.
– Im ausschließlichen Falle einer Preisänderung greift das RTPC-System auf die Händlerseite zu, um den neuen Preis zu verifizieren.
– Alle Preissuchmaschinen können die Preis- und Angebotsdaten von Online-Händlern in Echtzeit, mittels des RTPC-Standards, beziehen und somit die Aktualität von Preisen sicherstellen.
LG,
Wolfram
H.P. meint
Ich nehme mal an Sie vermarkten dieses Paket, kostenlos für die Händler, kostenpflichtig für die PSMs?
Ihrer Broschüre ist nicht wirklich viel zu entnehmen bzg. Technologie etc., es finden sich keinerlei Angaben über die Datensicherheit und inwiefern sich die Daten kontrollieren lassen (die müssen ja offenbar den Weg über Ihre Plattform nehmen) bleibt auch noch offen.
Gibt es irgendwo genauere Informationen?
Ganz offen gesagt gefällt mir der Gedanke einen völlig unkontrollierbaren Hub zwischenzuschalten gar nicht, ich könnte es keinem Händler verdenken wenn er sich Sorgen um sein Datenmaterial machen würde.
H.P. meint
Habe doch noch was gefunden, Sie übernehmen die Daten also von der produktseite mittels Bild dem die Daten mitgegeben werden.
Wenn Ihr Dienst technische Probleme bekommt dann kriegen erstmal die angeschlossenen Seiten auch Probleme da das Bild nicht geladen werden kann.
Zudem sind die Daten in keinster Form geschützt, ein wenig Handarbeit und die Konkurrenz pflückt sich die Daten direkt von den Webseiten, HTML parsen entfällt völlig, man muss nur noch den Link auseinandernehmen.
Sorry, netter Versuch, aber so etwas würde ich unseren Händlern unter gar keinen Umständen anzubieten wagen!
HilmarG meint
Also wir haben dieses „Snippet“ bei uns eingebunden und unsere IT het hier keinerlei Sicherheitsrelevanten Bedenken. Jeder Händler hat ein anderes Snippet und zudem ist diese verschlüsselt.
Zudem könnte jeder zu jeder Zeit Daten auch aus deinem Shop entnehmen, wenn er die Seite parst, sie stehen dort ja so oder so, es sei denn du zeigts deinen Kunden keine Preise…
Wo ist den hier die Sicherheitslücke?
Seit wann bekommen denn Seiten Probleme, wenn ein Pixel nicht geladen werden kann, ist mir neu. Der Austasuch zwischen Bild und Server findet ja bekanntlich Clientseitig statt, also…
Wie gesagt, bei und funktioniert der Spaß und ich halts echt für sinnvoll.
FWP Systems meint
@Wolfram
Wie sollen die Daten dann in Echtzeit an den Service übermittelt werden?
Letztendlich übernimmt ein User, den ich zeitlich nicht steuern kann, die Übermittlung der Daten an die Preissuchmaschine.
Wie könnt Ihr für die Realtime-Übermittlung Verantwortung übernehmen?
Robert Zajonz meint
> Seit wann bekommen denn Seiten Probleme, wenn ein Pixel nicht geladen werden kann
..sehr einfach. Die Seite beim Besucher baut sich nicht zu Ende auf, wenn nicht alle Objekte geladen werden. Das erlebt man schon sogar mit Google-Analytics oder etracker. Wir hatten auch schon Erfahrungen damit. Da rufen uns dann die Shopbetreiber an und sagen deren Shop wäre derzeit sehr langsam. Ich schaue mach und unser Server gähnt vor Langeweile. Dann schalte ich bei denen kurzzeitig den etracker oder Analytics Code aus und siehe da, die Geschwindigkeit ist wieder optimal.
Ich kann nur bestätigen, dass solche Grafikpixel sehr wohl die Performance beeinträchtigen können.
Manche Shops sind vom Layout her so gestrickt, dass nochmals ein ganzes DIV oder eine TABLE um den gesamten Inhalt gehängt ist. Wenn der besagte Pixel nicht wirklich außerhalb dieses Bereichs liegt, dann kann es vorkommen, dass durch so einen Pixel (dessen Server gerade hängt) die ganze Seite nicht anzeigt.
> Letztendlich übernimmt ein User, den ich zeitlich nicht steuern
> kann, die Übermittlung der Daten an die Preissuchmaschine
> Wie könnt Ihr für die Realtime-Übermittlung Verantwortung übernehmen?
Das wird mir bei dieser Lösung auch nicht klar?
apnoti.com meint
@ FWP Systems und Robert Zajonz:
Es ist richtig, dass der User die Datenübermittlung an die RTPC-Schnittstelle zum überwiegenden Teil übernimmt. Dabei wird für jedes einzelne Händler-Produkt eine Signatur (beinhaltet Preis, Verfügbarkeit, etc.) in ein extra dafür entwickeltes XML-Format (RTXML) gespeichert, welches sich automatisch aktualisieren kann. Sollte bei einer Preisabfrage auf einer PSM festgestellt werden, dass sich die Produkt-Signatur geändert hat, so simuliert unser RTPC-Verfahren einen virtuellen User, der die Produktdetailseite beim Händler aufruft, verifiziert und die Angebotsdaten (RTXML) wieder aktualisiert. Der Händler profitiert somit von nur einem Zugriff auf die Händlerseite anstatt zahlreichen Einzelzugriffen diverser Preissuchmaschinen.
Weitere Informationen stehen unter http://merchant.apnoti.com/ zur Verfügung. Hier kann sich jeder kostenfrei von den Vorteilen der Echtzeit-Technologie überzeugen.
Viele Grüße,
Wolfram
FWP Systems meint
Sorry, aber ich verstehe immer noch nicht, wer die Produktdetailseite bei einer Preisänderung aktualisiert. Kannst Du es evtl. noch mal anders erklären?
H.P. meint
Dem Beispielcode für xt:C ist zu entnehmen das überhaupt nix verschlüsselt wird. Reiner Klartext, geht kaum einfacher zu parsen.
Wenn ich mich mit HTML rumschlagen müsste wäre das sicher nicht einfach, aber so serviert kann jedes Skriptkiddy die Shops komplett auslesen.
Siehe : http://merchant.apnoti.com/code.html
Die Art und Weise der Datenübertragung erzeugt fast schon mehr Last als Freude, wenn andauernd der Preis gegenreferenziert werden muss habe ich ja bei gut laufenden PSMs eine Menge Hits von diesem Dienst.
Ich sehe offen gesagt nicht wie das eine echte Push Lösung ersetzen könnte. Es mag ein Weg sein, aber sehr unelegant und was das Kostenverhältnis anbelangt sehr teuer.