Wettbewerber-Preistracking für Magento: Ein praktischer Leitfaden

Wettbewerber auf Magento verfolgen, nicht den Preis von Magento

Zuerst eine Abgrenzung: In diesem Leitfaden geht es darum, zu beobachten, was andere Shops verlangen, und nicht darum, was der Betrieb von Magento kostet. Wer nach „Magento Preise", „Adobe Commerce Preise" oder „was kostet Magento" sucht, findet fast nur Ergebnisse zu Lizenzgebühren: Open Source ist kostenlos, Adobe Commerce ist ein individuell kalkulierter Jahresvertrag. Das ist eine andere Frage. Wenn Sie hier sind, weil Sie auf Magento verkaufen und wissen wollen, was Ihre Konkurrenten für die Produkte verlangen, die Sie beide führen, sind Sie auf der richtigen Seite.

Zweitens ein Versionsanker. Alles Technische weiter unten gilt für Magento Open Source und Adobe Commerce 2.4.x auf einer Standard-Storefront auf Luma-Basis. Version 2.4.9 erschien im Mai 2026, und der Support für 2.4.6 endete im August 2026 (Adobe, abgerufen im August 2026). Ein Vorbehalt gilt durchgehend: Adobe Commerce as a Cloud Service, Headless- und Edge-Delivery-Storefronts sowie Drittanbieter-Themes wie Hyva, Porto oder BSS geben nicht zwangsläufig Luma-Markup aus. Ein Wettbewerber auf einer dieser Varianten zeigt möglicherweise nichts, was erkennbar nach Magento aussieht.

Das wirtschaftliche Bild ist nicht jenes, das die meisten Artikel zeichnen: Magento schrumpft nach Shop-Anzahl, während die verbleibenden Shops größer werden. StoreLeads zählt 104.546 aktive Magento-Shops, 14 % weniger als im Vorjahr und rund 35 % unter dem Höchststand von 161.970 aus dem vierten Quartal 2021 (StoreLeads, Juli 2026). Die abgewanderten Shops waren überwiegend klein. Verdrängt wurden sie zuerst dadurch, dass Adobe den Support für Magento 1 im Juni 2020 einstellte (Help Net Security, Juni 2020), danach durch die Kosten einer Adobe-Commerce-Lizenz. W3Techs, das die Plattformnutzung über die untersuchten Websites hinweg misst und nicht den Anteil am Online-Umsatz, beziffert Magento auf 1,5 % aller E-Commerce-Systeme (W3Techs, August 2026). Kleiner Anteil, große Shops: Ihre Magento-Wettbewerber sind weniger und größer als vor drei Jahren, jede ihrer Preisbewegungen wiegt also schwerer.

Der Rest dieses Leitfadens behandelt einen Gedanken und seine Folgen. Die Zahl auf einer Magento-Produktseite ist das Ergebnis einer Formel, kein Feld in einer Datenbank. Für dieselbe Aufgabe auf anderen Plattformen lesen Sie die Leitfäden zu Shopify und WooCommerce.

Adobes Formel für den Endpreis ist das ganze Problem

Beginnen Sie mit der Formel, denn jeder Fehlerfall weiter unten folgt aus ihr. Adobe formuliert sie direkt:

Final Price = Min(Regular(Base) Price, Group(Tier) Price, Special Price, Catalog Price Rule) + Sum(Min Price per each required custom option)

Sie stammt aus Adobes Dokumentation zu Sonderpreisen (Adobe, abgerufen im August 2026) und ist für jeden, der eine Preishistorie aufbaut, der nützlichste Absatz der gesamten Magento-Dokumentation.

Lesen Sie, was daraus folgt. Vier Mechanismen konkurrieren um die Zahl, die ein Käufer sieht, der niedrigste gewinnt, und nur der erste ist der Preis, den ein Händler als den Preis versteht. Die drei anderen hängen an Bedingungen, die ein anonymer Besucher nicht steuern und in einem Fall überhaupt nicht sehen kann.

Mechanismus	Wirkung auf den Preis der Produktseite	Sichtbar für anonyme Besucher	Geltungsbereich
Regulärer Preis (Basispreis)	Der Standardwert, und der Verlierer, sobald etwas anderes niedriger ist	Ja	Website
Tier-/Gruppenpreis	Eine Mengenstaffel erscheint als „Kaufen Sie 6 für je 5,95 $ und sparen Sie 15 %"; ein Gruppenpreis gilt, „wenn der Käufer in seinem Konto angemeldet ist"	Teilweise. Staffeln für die Gastgruppe werden angezeigt, gruppenbeschränkte Preise nicht	Website und Kundengruppe, bei Tier-Preisen zusätzlich die Menge
Sonderpreis	Ersetzt den regulären Preis für ein geplantes Zeitfenster	Ja	Website und ein Datumsfenster
Katalog-Preisregel	Rabatte „treten in Kraft, bevor das Produkt in den Warenkorb gelegt wird", der angezeigte Preis der Produktseite ändert sich also	Ja, sofern die Regel die Gastgruppe betrifft	Website, Kundengruppe und ein Datumsfenster

Zwei Details lohnt es sich festzuhalten. Ein Sonderpreis läuft „unmittelbar nach Mitternacht zu Beginn des Startdatums (00:01) und bis kurz vor Mitternacht (23:59) am Tag vor dem Enddatum". Das Enddatum ist also exklusiv, und eine Aktion, die Sie am letzten Tag erwarten, ist bereits vorbei. Und Adobes Auswahl der Kundengruppe bietet sowohl „ALL GROUPS" als auch „NOT LOGGED IN". Ihre Überwachung lebt dauerhaft in der zweiten.

Fehlerfall 1: Der angezeigte Preis ist ein abgeleitetes Minimum

Magento kennt vier Produkttypen, und nur einer verhält sich so, wie ein Preistracker es annimmt. Ein simple product (einfaches Produkt) hat einen Preis und eine SKU. Ein configurable product (Variantenprodukt) hat das nicht: Adobe schreibt ausdrücklich, dass sich „der Preis des configurable product von seinen vorrätigen Kindprodukten ableitet" (Adobe, abgerufen im August 2026). Grouped products erben dasselbe Verhalten, und bundle products mit dynamischer Preisgestaltung zeigen eine Spanne statt eines Preises.

Die Folge ruiniert Preishistorien. Wenn die günstigste vorrätige Variante ausverkauft ist, springt der angezeigte Preis auf die nächstgünstige. Niemand hat einen Preis geändert. Ihre Zeitreihe verzeichnet eine Erhöhung, Ihre Benachrichtigung löst aus, und Sie reagieren auf einen Lagerausfall, als wäre er eine Preisentscheidung. Wenn Sie schon einmal beobachtet haben, wie der Preis eines Wettbewerbers im Zwei-Tage-Takt ohne jede kaufmännische Logik schwankt, liegt es meist daran.

Verfolgen Sie also die Variante, nicht das Elternprodukt. Das heißt: Preise je Variante aus der Seite lesen statt den gerenderten Anzeigepreis. In der GraphQL-API gibt Adobe Ihnen ein sauberes Erkennungsmerkmal (Adobe, abgerufen im August 2026): „Fragen Sie ein Produkt ab, das kein zusammengesetztes Produkt ist, sind Mindest- und Höchstpreis identisch." Ein minimum_price, der von maximum_price abweicht, ist deshalb ein maschinenlesbares Signal: Das hier ist der Endpunkt einer Spanne, lösen Sie darauf keine Benachrichtigung aus.

Fehlerfall 2: Der echte Preis kann gesperrt sein

Sie können einen Wettbewerber monatelang zum Listenpreis verfolgen, während seine Kunden 20 % weniger zahlen, und nichts in Ihren Daten wird falsch aussehen.

Der Mechanismus dahinter ist die Gruppenpreisgestaltung: Der Rabatt greift, in Adobes Worten, „wenn der Käufer in seinem Konto angemeldet ist". Adobe Commerce vergrößert die Lücke, denn die lizenzierte Edition ergänzt Customer Segments und B2B Shared Catalogs zusätzlich zu den einfachen Kundengruppen, und die Preise eines shared catalog haben Vorrang vor den Standardsätzen der Kundengruppe. Magento Open Source hat weder das eine noch das andere. Bei einem B2B-Wettbewerber auf Adobe Commerce kann der tatsächlich abgerechnete Preis in einem shared catalog liegen, den keine anonyme Anfrage je zurückgibt. Der öffentliche Preis ist dann eine Obergrenze und kein Marktpreis.

Drei Anzeichen dafür, dass gesperrte Preise im Spiel sind: eine Aufforderung „zum Anzeigen des Preises anmelden" oder „für Händlerpreise anmelden", eine Staffeltabelle, die erst nach der Anmeldung erscheint, und eine Schaltfläche „Angebot anfordern" dort, wo „In den Warenkorb" stehen sollte. Erfassen Sie solche Messwerte als Listenpreis mit gesperrtem Echtpreis, nicht als saubere Datenpunkte.

Um die naheliegende Umgehung klar zu benennen: Fake-Konten anzulegen, um an gesperrte Preise zu kommen, ist ein Problem der Nutzungsbedingungen, kein technisches. Bauen Sie Ihre Überwachung nicht darauf auf.

Fehlerfall 3: Ein Preis, drei Darstellungen

Dieser Fall ist heikel, weil nie etwas kaputt aussieht. Jeder einzelne Messwert ist in sich stimmig.

Magento trennt websites, stores und store views, und der Preis hängt an einer anderen Ebene als die Währung. Adobes Dokumentation zum Geltungsbereich von Katalogpreisen stellt fest: „Commerce erlaubt es nicht, einen Produktpreis je store festzulegen. Sie können den Preis aber je website ändern" (Adobe, abgerufen im August 2026). Der Preis variiert je website, nie je store view. Die Basiswährung wird auf website-Ebene gesetzt, die Anzeigewährung je store view, und die Steueranzeige kann Preise ohne Steuer, mit Steuer oder beides gleichzeitig zeigen.

Kombinieren Sie diese drei Ebenen, und eine SKU zu einem einzigen website-Preis wird auf drei Arten dargestellt. Die folgenden Zahlen sind veranschaulichend, nicht gemessen.

Store view	Was die Seite zeigt
US, ohne Steuer, USD	99,00
DE, inkl. Steuer, EUR	120,79
UK Handel, beides sichtbar	99,00 (120,79 inkl. Steuer)

Die store view wird über den URL-Pfad oder über ein store-Cookie beziehungsweise einen Query-Parameter gewählt. Ein neuer Versuch, der auf einer anderen View landet, oder eine Geo-Weiterleitung, der Ihr Abrufer stillschweigend folgt, verschiebt Ihren erfassten Preis um genau den Mehrwertsteuersatz oder kippt die Währung. Ein Tracker, der die store view nicht festnagelt, misst eine store-view-Reihe, keine Preisreihe.

Die Gegenmaßnahmen sind unspektakulär. Behalten Sie die genaue store-view-URL, bemerken Sie Geo-Weiterleitungen, statt ihnen blind zu folgen, senden Sie bei GraphQL den Store-Header, und speichern Sie den Währungscode zu jedem Preispunkt. Behandeln Sie einen Währungswechsel als Datenintegritätsereignis, nicht als Preisänderung.

Fehlerfall 4: MAP versteckt den Preis hinter einer Geste

Richtlinien zum Mindestwerbepreis (MAP) sind eine eingebaute Magento-Funktion, und sie brechen naives Scraping in die teuerste Richtung.

Adobes MAP-Funktion kennt die Einstellung „Display Actual Price" mit drei Werten: In Cart, Before Order Confirmation und On Gesture. Der letzte versteckt den Preis hinter einem „Click for Price"-Popup. In allen drei Fällen ist die Zahl im Markup die UVP, konstruktionsbedingt der höchste plausible Wert. Ein Scraper erfasst sie, schließt daraus, dass Sie den Wettbewerber unterbieten, und Sie halten einen Preis, den Sie nie hätten halten müssen. Häufig ist das bei Unterhaltungselektronik, Musikinstrumenten, Optik, Elektrowerkzeugen und Haushaltsgeräten.

MAP gilt nicht einheitlich. Bei grouped products erscheinen die Preise der zugehörigen simple products nur gemäß der Einstellung Display Actual Price. Und MAP greift ausschließlich bei bundle products mit festem Preis: Es „ist für bundle products mit dynamischer Preisgestaltung nicht verfügbar" (Adobe, abgerufen im August 2026). Ein Händler, der ein bundle auf dynamische Preisgestaltung umstellt, schaltet die Unterdrückung also stillschweigend ab.

Erkennen Sie MAP, statt hindurchzuparsen. Erfassen Sie das Produkt als Preis auf Anfrage und schließen Sie es aus Berechnungen zur Preisposition aus, statt eine UVP in Ihre Historie zu schreiben. Wenn Sie selbst Preisuntergrenzen durchsetzen, ist MAP-Monitoring die verwandte Disziplin.

Fehlerfall 5: Dafür brauchen Sie keinen Headless-Browser

Fast jeder Artikel über das Scrapen von Magento rät Ihnen, die Seite in einem Headless-Browser zu rendern. Für die Preisextraktion ist dieser Rat meist falsch, und Adobes eigene Frontend-Dokumentation erklärt, warum.

Magento initialisiert JavaScript-Widgets über ein <script type="text/x-magento-init">-Tag, dessen Schlüssel auf oberster Ebene CSS-Selektoren sind, wobei "*" bedeutet: an kein Element gebunden. Adobe beschreibt, was der Mechanismus tut. Er „bereitet die gesamte Konfiguration im Backend auf und gibt sie mit Standardwerkzeugen in den Seitenquelltext aus" (Adobe, abgerufen im August 2026). Die Widget-Konfiguration, Preise eingeschlossen, wird serverseitig serialisiert und im HTML ausgeliefert. Es gibt keinen XHR, auf den zu warten wäre, und keine clientseitige Preisberechnung nachzubilden. Die Seite zu rendern kostet Zeit und Geld und liefert nichts Neues.

Bei einem configurable product ist die gesuchte Nutzlast jenes Konfigurationsobjekt, das Magentos Widget für configurable products, Magento_ConfigurableProduct/js/configurable, ausliest. Üblicherweise trägt es den Schlüssel spConfig. Adobe dokumentiert x-magento-init selbst, dokumentiert dieses Objekt aber nicht namentlich. Behandeln Sie die folgende Struktur daher als beobachtete Konvention und nicht als Zusicherung:

{
  "attributes": {
    "93": {
      "code": "color",
      "options": [{ "id": "50", "label": "Blue", "products": ["1234"] }]
    }
  },
  "optionPrices": {
    "1234": { "finalPrice": { "amount": 79 }, "oldPrice": { "amount": 99 } }
  },
  "salable": { "93": { "50": ["SKU-BLUE-M"] } },
  "currencyCode": "USD"
}

Drei Dinge darin verdienen ihren Platz. optionPrices.<childId>.finalPrice.amount ist der echte Preis je Variante, und oldPrice gegen finalPrice ergibt das Paar aus Streichpreis und Aktionspreis. salable ist die ehrliche Bestandskarte: Eine Option, die in ihrer Achse fehlt oder auf eine leere Liste zeigt, ist nicht kaufbar, auch wenn sie noch einen Eintrag in optionPrices besitzt. Und der Preis, der vor jeder Auswahl dargestellt wird, ist das abgeleitete Minimum des Elternprodukts und gehört zu keiner SKU.

Rechnen Sie mit drei Ausgabeformen. Vanilla Luma nutzt den selektorbasierten x-magento-init-Block. Viele Drittanbieter-Themes geben einen Inline-Aufruf initConfigurableOptions() aus, dessen optionales drittes Argument je Kindprodukt eine Bestandsmeldung trägt, die wörtlich „In Stock" oder „Out of Stock" lautet und maßgeblich ist, wenn sie vorhanden ist. Themes der BSS-Familie legen dieselbe Matrix unter einer anders benannten Komponente ab.

Vier Stellen, vier Antworten

Die Seite hält meist mehrere Preise bereit, die sich widersprechen, und der am leichtesten erreichbare ist der unzuverlässigste.

Ebene	Zuverlässigkeit
spConfig.optionPrices.<childId>.finalPrice.amount	Maßgeblich je Variante
priceBox-DOM, data-price-amount an der finalPrice-Box	Maßgeblich für die aktuelle Auswahl, und auch auf Seiten ohne Bestand vorhanden
JSON-LD Product.offers.price	Oft nicht vorhanden und oft im mainEntity eines WebPage-Knotens verschachtelt statt auf oberster Ebene
Meta-Angabe og:price:amount oder product:price:amount	Häufig veraltet

Lesen Sie sie in dieser Reihenfolge, und steigen Sie rekursiv in mainEntity hinab, bevor Sie schließen, das JSON-LD trage keine Angebote. Ein Extraktor, der zuerst nach OpenGraph greift, was am einfachsten zu schreiben ist, erfasst bereitwillig den Preis vom letzten Monat.

Ihre Wettbewerber sind nicht alle auf Magento

Ihre Käufer interessiert nicht, welche Plattform jemand betreibt. Sie vergleichen Ihr Produkt mit jedem, der es verkauft, und dazu gehören Shopify-Shops, WooCommerce-Websites, Marktplatzangebote und große Händler auf eigenen Stacks.

Gute Überwachung liest öffentliche Produktseiten unabhängig von der Plattform. Bauen Sie Ihre Beobachtungsliste deshalb um die Frage herum auf, wer um den Käufer konkurriert, und nicht darum, wer denselben Stack nutzt. Dieselbe Mechanik mit anderen Fehlerfällen gilt für einen Shopify-Shop und für eine WooCommerce-Website.

Prüffrequenz festlegen

Jede Prüfung kostet etwas, staffeln Sie die Liste also, statt alle Produkte gleich zu behandeln.

• Hero-Produkte: alle ein bis wenige Stunden, denn eine Bewegung des Wettbewerbers verändert hier Ihre Verkäufe dieser Woche.
• Mittlere Produkte: täglich, mit einem breiteren Toleranzband und einer wöchentlichen Reaktion, sofern nichts Drastisches passiert.
• Long-Tail-Produkte: wöchentlich, zum Schutz der Marge statt zur Preisangleichung.

Magento fügt eine Besonderheit hinzu. Weil sich configurable parents mit dem Lagerbestand bewegen und nicht mit Preisentscheidungen, erzeugt eine höhere Frequenz dort Scheinbewegung statt Signal, solange Sie keine Preise auf Variantenebene lesen. Bringen Sie zuerst die Extraktion in Ordnung. Zum größeren Rahmen lesen Sie, wie oft Sie Wettbewerberpreise prüfen sollten.

Was Respot auf einer Magento-Seite liest

Respot hat keine Magento-Integration und keine Erweiterung zum Installieren. Es liest öffentliche Produkt-URLs, und das ist hier die richtige Architektur, denn der Preis eines Wettbewerbers liegt nicht in Ihrem Shop.

Was Respot hat, ist eine Extraktion, die für die oben beschriebenen Fehlerfälle gebaut ist. Sie parst Magentos Variantenkonfigurationsobjekt, fällt auf das Attribut data-price-amount der priceBox zurück und durchläuft JSON-LD rekursiv, damit ein in mainEntity verschachteltes Angebot nicht übersehen wird, und das alles ohne Headless-Browser. Das Tracking erfolgt je Variante, sodass die ausverkaufte günstigste Farbe eines Wettbewerbers als Lagerausfall erfasst wird und nicht als Preiserhöhung.

Der kostenlose Tarif umfasst 5 Tracker ohne Kreditkarte und 7 Tage Preishistorie, genug, um zu prüfen, ob Ihre am stärksten umkämpften Seiten sauber geparst werden. Die kostenpflichtigen Tarife skalieren auf 100, 400 oder 2.000 Tracker mit 30, 90 oder unbegrenzt vielen Tagen Historie.

Womit Sie beginnen

Wählen Sie Ihre zehn am stärksten umkämpften Produkte aus, suchen Sie die URLs der Wettbewerber, und tun Sie dann eines, bevor Sie eine davon einem Monitor hinzufügen: Öffnen Sie jede Seite und entscheiden Sie, welcher Fehlerfall zutrifft. Ist der angezeigte Preis das Minimum eines configurable product? Gibt es eine Preissperre hinter der Anmeldung? Nagelt die URL eine store view fest, und ist die Währung die erwartete? Steht eine „Click for Price"-Geste anstelle einer Zahl?

Dieses Audit dauert einen Nachmittag und entscheidet, ob die nächsten sechs Monate Preishistorie überhaupt etwas bedeuten. Ein Tracker, der auf ein Magento-Elternprodukt mit MAP-unterdrücktem Preis und nicht festgelegter store view zeigt, produziert ein ordentliches Diagramm aus Zahlen, die nichts beschreiben.

Stimmt die Extraktion, wird Magento zu einer der leichter zu verfolgenden Plattformen, denn Adobe legt die Daten bewusst in den Seitenquelltext. Beginnen Sie mit dem Tracking Ihrer Wettbewerber, sobald Sie wissen, was Ihnen jede Seite sagt.