Der Vergleichen-Button, den Shopify nicht hat: Produktvergleiche nach dem Systemwechsel
In Magento ist er Kernfunktion, in Shopware Standard oder Plugin, in Shopify gibt es ihn nicht — und niemand hat ihn je beauftragt, weil ihn niemand als Anforderung wahrgenommen hat. Warum der Nachbau die kleinere Hälfte der Arbeit ist, welche vier Bauformen es überhaupt gibt und weshalb die teuerste davon bei den meisten Sortimenten die falsche ist.
Sechs Wochen nach dem Umschalten kommt eine Mail aus dem Kundenservice. Kein Fehler, keine Störung, nur eine Frage, die inzwischen dreimal in einer Woche gestellt wurde: „Wo kann ich die Geräte jetzt nebeneinanderlegen?“ Im alten Shop gab es unter jeder Produktkachel ein kleines Kästchen mit „Vergleichen“. Im neuen ist es weg.
Im Projektplan taucht dieser Punkt nicht auf. Nicht, weil ihn jemand gestrichen hätte, sondern weil ihn nie jemand aufgeschrieben hat. Der Vergleichen-Knopf war keine Entscheidung, sondern eine Eigenschaft des alten Systems — so wie die Breadcrumb-Leiste oder die Merkliste. Anforderungen entstehen aus Wünschen. Diese Funktion war nie ein Wunsch, sie war einfach da.
Damit gehört sie in eine unangenehme Kategorie: Dinge, die beim Systemwechsel verschwinden, ohne dass jemand sie vermisst hat, bis sie fehlen. Die gute Nachricht ist, dass der Nachbau selten teuer ist. Die schlechte, dass der teure Teil woanders liegt — nämlich in den Daten, die eine Vergleichstabelle überhaupt erst füllbar machen. Und die eigentlich interessante Nachricht ist eine dritte: Die Form, die im Altsystem existierte, ist bei den meisten Sortimenten nicht die, die am besten wirkt.
Warum die Funktion fehlt — und woher sie eigentlich kam
Was der Wechsel mitnimmt
Der Vergleichen-Button zieht nie um — die Zeilen darunter entscheiden den Preis
In vier von fünf Ausgangssystemen gibt es einen Produktvergleich, ohne dass ihn jemals jemand beauftragt hätte. Shopify liefert ihn nicht mit. Der Nachbau der Oberfläche ist dabei die kleinere Hälfte: Was ein Vergleich kostet, hängt daran, wie gut die Attributdaten im Altsystem gepflegt sind — und das unterscheidet sich je System dramatisch.
-
Shopware 5
Im StandardIm Standard enthalten, meist ohne dass jemand die Funktion je aktiviert hat
Attributgüte für einen Vergleich Gemischt- Worauf der Vergleich aufsetzt
- Artikeleigenschaften und Freitextfelder
- Was das für die Daten bedeutet
- Eigenschaften sind sauber strukturiert, die Freitextfelder daneben sind es fast nie. Beim Export kommt beides gemischt an.
Nach dem Wechsel auf Shopify Die Eigenschaften werden zu Metafeldern, die Freitextfelder zu einer Aufräumaufgabe. Der Button selbst wird neu gebaut.
-
Shopware 6
Über PluginIn vielen Shops über ein Plugin nachgerüstet, nicht über den Kern
Attributgüte für einen Vergleich Durchgängig strukturiert- Worauf der Vergleich aufsetzt
- Properties und benutzerdefinierte Felder
- Was das für die Daten bedeutet
- Properties sind typisiert und mehrsprachig gepflegt — die beste Ausgangslage von allen fünf. Die Zuordnung nach Shopify ist überwiegend mechanisch.
Nach dem Wechsel auf Shopify Properties lassen sich fast eins zu eins auf Metafelddefinitionen abbilden. Der Aufwand liegt im Frontend, nicht in den Daten.
-
Magento 2
Im StandardKernfunktion mit eigener Vergleichsseite und Merkliste
Attributgüte für einen Vergleich Durchgängig strukturiert- Worauf der Vergleich aufsetzt
- Produktattribute mit Attributsets
- Was das für die Daten bedeutet
- Attributsets erzwingen Struktur je Produkttyp. Das ist der Grund, warum Magento-Kataloge sich am besten vergleichen lassen — und warum der Verlust am deutlichsten auffällt.
Nach dem Wechsel auf Shopify Attributsets haben in Shopify keine direkte Entsprechung. Die Trennung nach Produkttyp muss über Metafelder und Kollektionen neu abgebildet werden.
-
WooCommerce
Über PluginNie im Kern, immer über ein Plugin — häufig seit Jahren nicht aktualisiert
Attributgüte für einen Vergleich Überwiegend Freitext- Worauf der Vergleich aufsetzt
- Produktattribute und Custom Fields
- Was das für die Daten bedeutet
- Attribute und Custom Fields wachsen im Betrieb ohne Vorgabe. Dieselbe Angabe steht im selben Katalog in drei Schreibweisen und zwei Einheiten.
Nach dem Wechsel auf Shopify Vor der Abbildung steht die Normalisierung. Dieser Schritt ist der eigentliche Posten und gehört ins Angebot.
-
Eigenentwicklung
Nicht vorhandenMeist gar nicht vorhanden — oder als einmalig gebaute Sonderseite
Attributgüte für einen Vergleich Überwiegend Freitext- Worauf der Vergleich aufsetzt
- Was die Datenbank hergibt
- Was das für die Daten bedeutet
- Attribute liegen häufig in eigenen Tabellen ohne Typisierung. Was vergleichbar ist, weiß nur, wer die Struktur kennt.
Nach dem Wechsel auf Shopify Hier entsteht der Vergleich zum ersten Mal — als Chance, nicht als Ersatz. Das Zielmodell wird auf der grünen Wiese entworfen.
Shopify liefert keinen Produktvergleich mit. Das ist keine Lücke im Funktionsumfang, sondern eine Haltung: Die Plattform hält den Katalog, das Theme hält die Darstellung, und alles, was zwischen mehreren Produkten Zustand aufbaut, gilt als Aufgabe des Themes oder einer App. Wer aus Magento kommt, erlebt das als Verlust, weil dort die Vergleichsliste inklusive eigener Seite zum Kern gehört. Wer aus WooCommerce kommt, erlebt es kaum, weil die Funktion dort ohnehin über ein Plugin lief.
Der Unterschied, auf den es ankommt, steht in der Übersicht in der letzten Spalte. Der Knopf zieht in keinem der fünf Fälle um — er wird immer neu gebaut. Was umzieht, sind die Angaben darunter, und dort trennen sich die Projekte deutlich.
Ein Magento-Katalog mit gepflegten Attributsets bringt eine Struktur mit, die eine Vergleichstabelle praktisch von selbst füllt: Jeder Produkttyp hat einen definierten Satz Eigenschaften, jede Eigenschaft einen Typ, jeder Wert eine Herkunft. Die Arbeit besteht darin, diese Struktur in Shopify-Metafelder zu übersetzen — mechanisch, planbar, in Stunden schätzbar.
Ein gewachsener WooCommerce-Katalog bringt dieselben Angaben mit, aber in drei Schreibweisen und zwei Einheiten. Hier besteht die Arbeit nicht im Übersetzen, sondern im Vereinheitlichen, und dieser Posten wird regelmäßig unterschätzt, weil er im Angebot unter „Katalogmigration“ verschwindet. Wie sich solche stillen Positionen vorher sichtbar machen lassen, steht in Umsetzungspartner für den Shopify-Wechsel.
Der Test dafür dauert zehn Minuten und braucht keinen Dienstleister: Exportieren Sie zwanzig Artikel derselben Kategorie und sehen Sie sich eine einzige Spalte an — Gewicht, Leistung, Material, was auch immer bei Ihnen die Kaufentscheidung trägt. Wenn dort dreimal dasselbe in drei Formen steht, kennen Sie den größten Posten dieses Themas, bevor ihn jemand anbietet.
Vier Bauformen, und die teuerste ist selten die richtige
Vier Bauformen
Produktvergleich ist kein Feature, sondern eine Entscheidung zwischen vier Bauformen
Die teuerste Form ist die, die im Altsystem als Knopf existierte: der frei zusammenstellbare Vergleich. Die wirksamste ist bei den meisten Sortimenten eine andere. Vor dem Nachbau lohnt deshalb eine Frage, die im Projekt selten gestellt wird — nämlich ob die Funktion im alten Shop überhaupt benutzt wurde.
-
Feste Vergleichstabelle
Redaktionell gesetzt, für alle gleich
Kleiner Aufwand Theme-Abschnitt plus Metafelder. Kein Zustand, kein JavaScript, keine App.
- Passt bei
- Schmale Sortimente mit klarer Staffel: drei Modellstufen, zwei Tarife, vier Größen derselben Maschine. Die Auswahl steht ohnehin fest, und Sie wollen sie erklären statt filtern lassen.
- Wo sie scheitert
- Sobald das Sortiment wächst, veraltet die Tabelle schneller, als jemand sie pflegt. Ab etwa zwölf Artikeln ist sie eine Baustelle statt einer Hilfe.
-
Auswählbarer Vergleich
Die Kundschaft stellt sich die Spalten selbst zusammen
Großer Aufwand Zustand über mehrere Seiten hinweg, Auswahlgrenze, mobile Darstellung, leere Zellen. Das ist die Form, die man als Nachbau unterschätzt.
- Passt bei
- Große, homogene Kataloge mit vielen gleichartigen Artikeln — Werkzeug, Elektronik, Technikteile —, bei denen sich zwei Kandidaten erst am Ende der Recherche herauskristallisieren.
- Wo sie scheitert
- Bei heterogenen Sortimenten produziert die Funktion vor allem leere Zellen. Und sie wird deutlich seltener benutzt, als ihre Sichtbarkeit im alten Shop vermuten lässt.
-
Filtern statt vergleichen
Die Auswahl schrumpft, bevor verglichen wird
Mittlerer Aufwand Metafelder in filterfähigen Typen plus Konfiguration in Search & Discovery. Die Arbeit steckt in den Daten, nicht im Frontend.
- Passt bei
- Der Regelfall bei mittleren Katalogen. Wer nach drei Filtern noch vier Kandidaten übrig hat, braucht keinen Vergleich mehr, sondern nur noch gut lesbare Produktkacheln.
- Wo sie scheitert
- Ersetzt keinen echten Detailvergleich, wenn die Kaufentscheidung an fünfzehn Eigenschaften hängt. Dann bleibt die Tabelle nötig.
-
Visueller Vergleich
Bilder, Symbole und Skalen statt Zahlenspalten
Kleiner Aufwand Ein Theme-Abschnitt mit drei bis fünf Achsen. Die Arbeit liegt in der Redaktion, nicht in der Entwicklung.
- Passt bei
- Sortimente, deren Unterschiede sich nicht messen lassen: Härtegrad, Röstgrad, Passform, Pflegeaufwand, Intensität. Eine Skala erklärt hier mehr als jede Tabellenzeile.
- Wo sie scheitert
- Verliert an Glaubwürdigkeit, sobald die Skala nicht begründet ist. Wer „Intensität 4 von 5“ schreibt, muss sagen können, woran das gemessen wurde.
„Produktvergleich“ klingt nach einer Funktion und ist in Wirklichkeit eine Entscheidung zwischen vier Bauformen mit sehr unterschiedlichem Aufwand. Die Verwechslung ist folgenreich, weil im Altsystem meist genau die teuerste installiert war: der frei zusammenstellbare Vergleich, bei dem Besucher Artikel ankreuzen und anschließend eine Tabelle mit selbst gewählten Spalten sehen.
Diese Form ist aufwendig, und zwar nicht wegen der Tabelle. Aufwendig ist alles, was darum herum liegt: Die Auswahl muss über mehrere Seiten hinweg erhalten bleiben, es braucht eine Obergrenze, die Darstellung auf dem Telefon ist ein eigenes Problem — vier Spalten passen nicht auf 390 Pixel —, und für jede fehlende Angabe braucht es eine Regel. In Projekten, die diesen Nachbau eins zu eins beauftragen, ist er regelmäßig der Posten, der zuerst über die Schätzung läuft. Was mobile Darstellung sonst noch an Fallen bereithält, haben wir in Mobile Commerce: die stillen Conversion-Verluste beschrieben.
Vor dem Nachbau steht deshalb eine Frage, die im Systemwechsel fast nie gestellt wird: Wie oft wurde die Funktion im alten Shop tatsächlich benutzt? Die Zahl steht in Ihrem Analytics, sie ist in einer halben Stunde zu haben, und sie ist der einzige belastbare Grund, diesen Posten zu beauftragen oder zu streichen. In den Projekten, in denen wir sie gesehen haben, lag sie fast immer deutlich unter dem, was das Team erwartet hatte — sichtbar heißt nicht benutzt.
Das ist ausdrücklich kein Argument gegen die Funktion. Bei großen, gleichartigen Katalogen — Werkzeug, Messtechnik, Bauteile, Laborbedarf — trägt sie sehr wohl, weil dort am Ende einer Recherche wirklich zwei Kandidaten übrig bleiben, die sich in acht Zahlen unterscheiden. Es ist ein Argument dafür, diese Entscheidung mit einer Zahl zu treffen statt mit einer Gewohnheit.
Der Vergleich ist ein Datenproblem
Die Zeilen unter der Tabelle
Sieben Angabetypen — drei vergleichen sich von selbst, einer nie
Ob ein Produktvergleich funktioniert, entscheidet sich nicht im Theme, sondern im Typ der Angabe. Eine Zahl mit Einheit ist eine Vergleichszeile, sobald sie sauber im Feld steht. Ein Beschreibungsabsatz wird auch dann keine, wenn man ihn in eine Spalte zwingt. Die Zuordnung unten ist zugleich die Aufgabenliste für die Datenmigration.
-
Zahl mit Einheit
Gewicht 2,4 kg · Leistung 1.400 W · Länge 180 cm
Stolperstelle beim Übertragen Einheiten im Altsystem sind selten einheitlich. Gramm neben Kilogramm, Millimeter neben Zentimeter, und in jeder dritten Zeile steht die Einheit im selben Feld wie die Zahl. Genau das muss vor der Migration auseinandergezogen werden.
-
Ja oder Nein
Spülmaschinenfest · Akku enthalten · Für Außenbereich
Stolperstelle beim Übertragen Der undankbarste Wert ist der dritte: „unbekannt“. Ein leeres Wahrheitsfeld wird in der Tabelle zu einem Nein, das niemand geprüft hat — und das im Zweifel eine Retoure auslöst.
-
Auswahl aus fester Liste
Material Edelstahl · Energieklasse B · Passform schmal
Stolperstelle beim Übertragen Die Liste ist im Altsystem meistens keine Liste, sondern ein Textfeld. „Edelstahl“, „Edelstahl gebürstet“ und „V2A“ sind dort drei Werte und werden in Shopify zu drei Filtereinträgen, wenn niemand sie vorher zusammenführt.
-
Mehrfachauswahl
Anschlüsse USB-C, HDMI · Im Lieferumfang: Tasche, Ladegerät
Stolperstelle beim Übertragen In der Vergleichszeile wird daraus schnell eine Textwand. Besser ist ein Häkchenraster: eine Zeile je möglichem Wert, Häkchen oder Strich je Produkt. Das kostet mehr Zeilen und spart der Kundschaft das Lesen.
-
Bereich von–bis
Temperatur 20–80 °C · Körpergröße 165–180 cm
Stolperstelle beim Übertragen Als „20–80 °C“ in einem Textfeld ist der Bereich weder sortierbar noch filterbar noch vergleichbar. Zwei getrennte Felder kosten in der Migration eine Stunde und lösen alle drei Probleme dauerhaft.
-
Bild oder Symbol
Pflegesymbole · Energielabel · Zertifikatslogo
Stolperstelle beim Übertragen Trägt visuell hervorragend und ist der stärkste Teil eines visuellen Vergleichs — aber nur mit Alternativtext. Ohne ihn ist die Zeile für Screenreader und für die Websuche leer.
-
Freitext
Hinweis zur Montage · Beschreibungsabsatz
Stolperstelle beim Übertragen Der häufigste Fehler beim Nachbau: Freitextfelder aus dem Altsystem landen unverändert als Vergleichszeile. Drei Absätze nebeneinander sind kein Vergleich, sondern drei Beschreibungen. Diese Angaben gehören auf die Produktseite, nicht in die Tabelle.
Die Regel für leere Zellen: Eine Vergleichszeile, die bei einem der gezeigten Produkte leer bleibt, macht diesen Artikel schlechter, als er ist — auch dann, wenn die Angabe nur nicht gepflegt wurde. Nehmen Sie eine Zeile erst in den Vergleich auf, wenn sie bei allen vergleichbaren Artikeln gefüllt ist. Das ist der Grund, warum ein guter Vergleich meist mit acht Zeilen auskommt und nicht mit dreißig.
Hier liegt der Kern des Themas, und er hat mit dem Vergleich nur mittelbar zu tun. Eine Vergleichstabelle ist eine Anzeigeform für strukturierte Produktdaten. Wo diese Daten sauber sind, ist die Tabelle in Tagen gebaut. Wo sie es nicht sind, hilft keine App der Welt — sie zeigt dann nur die Unordnung in einem übersichtlicheren Layout.
Der entscheidende Unterschied ist der Typ der Angabe. „2,4 kg“ in einem Gewichtsfeld ist eine Vergleichszeile, sobald sie im Feld steht. Derselbe Wert im Satz „wiegt nur 2,4 Kilogramm und liegt damit gut in der Hand“ ist keine — er ist Marketingtext, in dem zufällig eine Zahl vorkommt. Kein Import der Welt trennt das zuverlässig, und genau deshalb ist die Aufteilung nach Typen die eigentliche Arbeit einer Katalogmigration.
Diese Arbeit zahlt weit über den Vergleich hinaus. Dieselben Metafelder tragen die Filter auf der Kategorieseite, die Angaben auf den Produktkacheln, die strukturierten Daten für Suchmaschinen und den Produktfeed, aus dem inzwischen auch KI-Assistenten ihre Antworten ziehen. Wer Attribute nur für eine Tabelle normalisiert, hat den Nutzen falsch verbucht; wie weit er reicht, steht in Produktdaten für KI-Suche.
Zwei Regeln aus der Praxis sind wichtiger als jede Werkzeugentscheidung.
Leere Zellen sind teurer als fehlende Zeilen. Eine Vergleichszeile, die bei einem der drei gezeigten Artikel leer bleibt, wirkt wie eine Aussage über diesen Artikel — auch wenn die Angabe nur nicht gepflegt wurde. Nehmen Sie eine Zeile erst auf, wenn sie bei allen vergleichbaren Produkten gefüllt ist. Acht vollständige Zeilen schlagen dreißig lückenhafte, und zwar deutlich.
Nur Vergleichbares nebeneinander. Ein Espressokocher und eine Siebträgermaschine haben kaum gemeinsame Zeilen; eine Tabelle über beide besteht überwiegend aus Strichen. Deshalb gehört zum Vergleich immer eine Regel, welche Artikel überhaupt gemeinsam gezeigt werden dürfen — in Shopify sinnvollerweise über eine Kollektion oder ein Produkttyp-Feld, nicht über die freie Wahl der Kundschaft.
Wo der Vergleich hingehört
Wo der Vergleich hingehört
Vier Orte, vier verschiedene Zweifel — und vier verschiedene Antworten an die Suchmaschine
Ein Vergleich hilft nur dort, wo der passende Zweifel entsteht. Wer die dynamische Vergleichsseite nachbaut, weil das Altsystem sie hatte, bedient den dritten Ort — und lässt die drei anderen leer. Der vierte ist dabei der einzige, der neue Besucher bringt, statt vorhandene zu begleiten.
-
Orientierung
Kategorieseite
„Welche kommen überhaupt infrage?“
Aus achtzig Artikeln vier machen. Das leisten Filter aus Metafeldern und Produktkacheln, auf denen die zwei entscheidenden Angaben schon sichtbar sind — nicht erst nach dem Klick.
Gehört in den Index Die Kollektion selbst gehört in den Index. Gefilterte Varianten mit Parametern gehören es nicht — sonst konkurrieren hunderte fast identische Seiten miteinander.
Was dafür gebaut wird Metafelder in filterfähigen Typen, Konfiguration in Search & Discovery, zwei Angaben pro Kachel
-
Auswahl
Produktseite
„Ist das die richtige Größe, Stufe, Ausführung?“
Den einen Artikel gegen seine nächsten Nachbarn stellen — eine Stufe größer, eine Stufe stärker. Das ist der am häufigsten unterschätzte Ort: Er beantwortet die Frage dort, wo sie entsteht, ohne dass jemand die Seite verlässt.
Teil der Produktseite Kein eigener Index-Fall, aber ein SEO-Beitrag: Der Abschnitt verlinkt intern auf verwandte Artikel und hält Besucher länger auf der Seite.
Was dafür gebaut wird Theme-Abschnitt mit Produkt-Referenz-Metafeld, drei bis sechs Vergleichszeilen
-
Entscheidung
Dynamische Vergleichsseite
„Diese zwei — welcher jetzt?“
Zwei bis vier selbst gewählte Artikel nebeneinander, alle Zeilen sichtbar. Der klassische „Vergleichen“-Knopf aus dem Altsystem. Er trägt nur bei großen, gleichartigen Katalogen — dort dafür deutlich.
Gehört auf noindex Aus jeder Auswahlkombination entsteht eine eigene URL. Diese Seiten gehören auf noindex; ohne diese Vorgabe wandern beliebig viele Dubletten in den Index.
Was dafür gebaut wird Auswahlzustand über Seiten hinweg, Auswahlgrenze, mobile Darstellung, Umgang mit leeren Zellen
-
Vor dem Shop
Redaktioneller Vergleichsbeitrag
„Modell A oder Modell B?“ — gefragt bei einer Suchmaschine, nicht bei Ihnen
Eine feste, gepflegte Gegenüberstellung mit Empfehlung: für wen A, für wen B, und wann keins von beiden. Die einzige der vier Formen, die selbst Nachfrage einsammelt, statt vorhandene zu bedienen.
Gehört in den Index Diese Seite soll ranken. Sie braucht eine stabile URL, echten Text neben der Tabelle und interne Links auf beide verglichenen Artikel.
Was dafür gebaut wird Redaktion statt Entwicklung: Recherche, Text, Empfehlung, halbjährliche Pflege
Bis hierher ging es um Form und Daten. Der letzte Teil betrifft den Ort, und er ist der Grund, warum manche Vergleiche wirken und andere leerlaufen: Ein Vergleich hilft nur dort, wo der passende Zweifel entsteht.
Zwei der vier Orte werden nach einer Migration regelmäßig übersehen.
Der erste ist die Produktseite. Wer bereits auf einem Artikel steht, hat die Auswahl im Wesentlichen getroffen und stellt nur noch eine Frage: eine Nummer größer oder nicht? Ein kompakter Abschnitt mit dem Artikel und seinen ein bis zwei nächsten Nachbarn beantwortet das an der Stelle, an der es gefragt wird. Technisch ist das der billigste Vergleich überhaupt — ein Theme-Abschnitt und ein Produkt-Referenz-Metafeld —, und er trägt bei fast jedem Sortiment.
Der zweite ist der redaktionelle Vergleichsbeitrag: eine feste, gepflegte Gegenüberstellung von zwei konkreten Modellen mit einer Empfehlung am Ende. Das ist die einzige der vier Formen, die selbst Nachfrage einsammelt, statt vorhandene zu bedienen — denn „Modell A oder Modell B“ wird zuerst bei einer Suchmaschine getippt, nicht in Ihrem Shop. Nach einer Migration ist der Zeitpunkt dafür günstig, weil Sie ohnehin an Ihrer Sichtbarkeit arbeiten; welche Rolle solche Seiten dabei spielen, ordnet SEO bei der Shopify-Migration ein.
Umgekehrt braucht der dritte Ort eine ausdrückliche Vorgabe. Eine dynamische Vergleichsseite erzeugt aus jeder Auswahlkombination eine eigene Adresse. Ohne noindex wandern beliebig viele fast identische Seiten in den Index und konkurrieren mit den Seiten, die dort hingehören. Dasselbe gilt für gefilterte Kategorieansichten mit Parametern. Diese Regel kostet nichts, wenn sie beim Bau gesetzt wird, und einige Monate Aufräumarbeit, wenn nicht — die Systematik dahinter steht in URL-Struktur und Slugs in Shopify sowie in 301-Weiterleitungen bei der Migration.
App oder Theme
Bleibt die Frage, die in fast jedem Projekt an dieser Stelle kommt: kaufen oder bauen? Beide Wege sind vertretbar, sie verschieben den Aufwand nur an unterschiedliche Stellen.
| App aus dem App Store | Abschnitt im Theme | |
|---|---|---|
| Zeit bis zur ersten Version | Tage | ein bis drei Wochen |
| Kosten | monatlich, dauerhaft | einmalig, plus Pflege |
| Ladezeit | zusätzliches Skript auf jeder Seite, auf der die Funktion sichtbar ist | fällt praktisch nicht ins Gewicht |
| Gestaltung | im Rahmen der App-Einstellungen | frei, im Stil des Shops |
| Datenquelle | eigene Konfiguration, häufig parallel zu Ihren Metafeldern | dieselben Metafelder wie Filter und Produktseite |
| Bei Theme-Wechsel | Einbindung muss neu gesetzt werden | wandert mit, wenn sauber aufgebaut |
| Beim Verlassen | Funktion ist weg, Konfiguration bleibt bei der App | Funktion bleibt, Daten bleiben |
Die Entscheidung fällt in der Praxis meist an zwei Punkten. Wenn die Funktion umstritten ist und erst einmal ausprobiert werden soll, ist eine App der ehrlichere Weg — sie ist in Tagen da und in Minuten wieder weg. Wenn dagegen ohnehin Metafelder für Filter und Produktkacheln gepflegt werden, ist der Theme-Abschnitt oft der kürzere Weg, weil er auf Daten aufsetzt, die es schon gibt, und keine zweite Pflegestelle schafft.
Ein Punkt verdient dabei mehr Aufmerksamkeit, als er üblicherweise bekommt: Apps, die Vergleichsfunktionen anbieten, laden ihr Skript in aller Regel auf jeder Seite, auf der der Knopf sichtbar sein soll — also auf allen Kategorie- und Produktseiten. Bei einer Funktion, die von wenigen Prozent der Besucher benutzt wird, zahlt der Rest die Ladezeit mit. Wie sich das messen und begrenzen lässt, steht in Lighthouse beim Shopsystem-Wechsel; die grundsätzliche Abwägung zwischen App und eigener Entwicklung behandelt Custom Liquid oder Custom App.
Checkliste
Produktvergleich beim Shopify-Wechsel: vierzehn Punkte
Die ersten vier Punkte gehören vor die Entscheidung, ob überhaupt gebaut wird — danach sind sie nur noch Rechtfertigung. Die Punkte fünf bis neun sind Datenarbeit und gehören in die Katalogmigration, nicht in ein späteres Ticket. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 14 erledigt
Was für Ihre Ausgangslage sinnvoll ist
| Ihre Situation | Empfehlung |
|---|---|
| Unter 100 Artikel, wenige Modellstufen | Feste Vergleichstabelle als Theme-Abschnitt. Alles andere ist Aufwand ohne Gegenwert |
| Großer, gleichartiger Katalog mit technischen Daten | Dynamischer Vergleich lohnt sich — vorher die Nutzungszahl aus dem Altsystem prüfen |
| Sortiment mit vielen unterschiedlichen Produkttypen | Kein freier Vergleich. Filter plus Nachbarvergleich auf der Produktseite lösen dasselbe Problem ohne leere Zellen |
| Attribute liegen überwiegend als Freitext vor | Normalisierung zuerst, Vergleich später. Umgekehrt bauen Sie eine Tabelle über Daten, die nichts hergeben |
| Aus Magento mit gepflegten Attributsets | Beste Ausgangslage. Attributsets auf Metafelddefinitionen abbilden, bevor der Import startet |
| Aus WooCommerce mit gewachsenen Custom Fields | Normalisierungsaufwand explizit im Angebot ausweisen lassen — er ist der eigentliche Posten |
| Unterschiede lassen sich nicht messen | Visueller Vergleich mit drei bis fünf Achsen. Voraussetzung: Die Skala ist begründet und wird erklärt |
| Kundenservice beantwortet täglich dieselbe Modellfrage | Redaktioneller Vergleichsbeitrag zu genau dieser Frage. Zahlt zweimal: weniger Anfragen, mehr Sichtbarkeit |
| Funktion ist im Team umstritten | App für drei Monate, dann Nutzung messen und entscheiden. Billiger als eine Grundsatzdiskussion |
| Ladezeit ist bereits ein Thema | Theme-Abschnitt statt App, und den Vergleich nur dort ausspielen, wo er gebraucht wird |
| Mehrsprachiger Shop | Attributwerte als Auswahllisten führen, nicht als freien Text — sonst wird jede Übersetzung zur Einzelpflege |
| B2B mit technischen Datenblättern | Datenblatt als Datei-Metafeld neben die Vergleichszeilen, nicht statt ihnen. Beides wird gebraucht |
Was Sie aus diesem Artikel mitnehmen sollten
Der fehlende Vergleichen-Knopf ist ein kleines Problem mit einem großen Hinterland. Drei Punkte tragen den größten Teil davon.
Der Knopf ist billig, die Zeilen sind teuer. Der Nachbau der Oberfläche ist in den meisten Fällen überschaubar. Was Geld kostet, ist die Normalisierung der Attributdaten dahinter — und dieser Posten steht in kaum einem Migrationsangebot, weil er unter „Katalog übernehmen“ verschwindet. Prüfen Sie eine einzige Spalte in zwanzig exportierten Artikeln, und Sie wissen vorher, worüber Sie sprechen.
Die Form aus dem Altsystem ist selten die richtige. Der frei zusammenstellbare Vergleich ist die aufwendigste der vier Bauformen und lohnt sich nur bei großen, gleichartigen Katalogen. Bei allen anderen leisten gute Filter und ein Nachbarvergleich auf der Produktseite dasselbe — für einen Bruchteil des Aufwands. Die Nutzungszahl aus dem alten Shop entscheidet das, nicht die Gewohnheit.
Die Datenarbeit zahlt weit über den Vergleich hinaus. Dieselben Metafelder tragen Filter, Produktkacheln, strukturierte Daten und Produktfeeds. Wer sie im Zuge der Migration ordentlich anlegt, hat den Vergleich fast geschenkt; wer sie später nachzieht, macht die Arbeit doppelt — einmal beim Import und einmal beim Nachpflegen.
Wenn Sie gerade einen Systemwechsel planen und wissen wollen, wie gut Ihre Produktdaten dafür wirklich sind: Lassen Sie uns sprechen. Wie wir Katalogmigrationen aufsetzen, steht auf Shopsystem-Migration; den Ablauf Schritt für Schritt zeigt die Migrations-Checkliste.
