E-Commerce-Entwicklung: sztuczne-rosliny.pl

#sztuczne-rosliny.pl, ein Shop für künstliche Pflanzen von höchster Qualität

Der Shop verkauft künstliche Bäume, Gräser, Blumen und Pflanzgefäße an Büros, Hotels, Restaurants, Messebauer und Einkaufszentren, dazu an Innenarchitekten, die für ihre Projekte begrünte Wände und einzelne Solitärpflanzen suchen. Das Unternehmen sitzt in Warschau, hat eine Niederlassung in Białystok und führt neben dem Standardsortiment brandhemmende und UV-beständige Varianten sowie Montage und Beratung vor Ort (Quelle: sztuczne-rosliny.pl). Der Preis ist in dieser Nische das zweite Argument, das erste ist, ob die Pflanze im Raum echt wirkt.

Die Umsetzung startete und lief rund sechs Wochen. Technisch steht der Shop auf WordPress mit einem eigenen Produktmodell, Redis als Objekt-Cache, HTML5, CSS3 und SASS im Frontend, AJAX in der Suche und einem CDN vor den Bilddateien. Layout und Platzierung der Elemente kamen vom Kunden, gebaut habe ich daraus die Template-Struktur, das Datenmodell und die Integrationen.

#Warum die Lieferantendaten die erste Aufgabe waren

Ein Importeur, der bei Herstellern in Asien und in Europa einkauft, bekommt keine Datenbank geliefert, sondern Tabellen. Ein Lieferant schreibt Höhen in Zentimetern, ein anderer in Zoll, ein dritter gibt eine Spanne an, weil Blätter von Hand gesteckt werden und jede Palme leicht anders ausfällt. Farbbezeichnungen existieren in drei Schreibweisen desselben Grüns, und die Materialangabe heißt einmal PE, einmal Polyethylen und einmal Kunststoff.

Solange diese Varianten unverändert im Katalog landen, ist jeder Filter kaputt, bevor er geschrieben wurde. Ein Filter vergleicht Werte, und drei Schreibweisen desselben Materials sind für die Datenbank drei Materialien. Die Synchronisation hat deshalb eine Aufgabe, die vor allem anderen kommt: eingehende Werte auf ein festes Vokabular abbilden und alles, was sich nicht zuordnen lässt, sichtbar liegen lassen statt stillschweigend durchzuwinken. Ein unbekannter Wert, der als Fehler in einer Liste auftaucht, kostet fünf Minuten Redaktionsarbeit. Derselbe Wert, der unbemerkt in den Katalog rutscht, kostet später einen Kunden, der ein Produkt nicht findet, das im Lager liegt.

Die zweite Entscheidung ist die wichtigere und wird häufig übersprungen: Wem gehört welches Feld. Bestand und Einkaufspreis gehören dem Lieferanten und dürfen bei jedem Lauf überschrieben werden. Beschreibung, Fotos, Kategoriezuordnung und die eigenen Anwendungshinweise gehören dem Shop und dürfen es nicht, sonst löscht der nächtliche Import die Arbeit der Redaktion. Wer diese Grenze nicht zieht, erkennt das Problem immer am selben Symptom: Am Morgen nach dem Import steht bei der Hälfte des Katalogs wieder der Herstellertext.

Der dritte Fall betrifft Artikel, die beim Lieferanten auslaufen. Sie aus der Datenbank zu löschen tötet eine Adresse, die in Suchergebnissen und in Lesezeichen von Einkäufern steht. Sinnvoller ist, das Produkt als nicht verfügbar zu markieren, die Seite am Leben zu lassen und Alternativen daneben zu zeigen. In diesem Geschäft ist das Vorschlagen eines ähnlichen Baums ohnehin Teil des Verkaufsgesprächs, und Ware wird auf Anfrage beschafft. Die Seite hört also nicht auf zu arbeiten, nur weil eine Charge zu Ende ist.

#Produktdaten als Felder, nicht als Fließtext

Das Produktmodell liegt in eigenen Inhaltstypen und benutzerdefinierten Feldern. Höhe, Material, Farbe, Topfart, Hersteller und die Frage, ob eine Variante brandhemmend oder UV-beständig ist, sind Werte in der Datenbank und keine Sätze in einem Absatz.

Der Unterschied zeigt sich in dem Moment, in dem ein Einkäufer eine Höhe braucht. Steht die Angabe nur im Beschreibungstext, entsteht der Filter von einhundertzwanzig bis einhundertachtzig Zentimeter nie, weil es nichts zu vergleichen gibt. Man kann das mit Schlagworten wie hoch und sehr hoch umgehen, aber dann ist die Grenze Auslegungssache, jeder Redakteur zieht sie anders, und der Kunde erfährt das tatsächliche Maß erst auf der Produktseite. Bei einer Bestellung für eine Hotellobby mit vorgegebener Deckenhöhe ist das der Unterschied zwischen einer Minute Auswahl und einer Rücksendung von zwei Metern Ficus.

Diese Struktur hat einen Preis, den man benennen sollte. Ein Produkt anzulegen dauert länger, weil das Formular ein Dutzend Felder hat statt eines Editorfensters. Der Satz an Attributen muss vorher durchdacht werden, denn ihn später zu ändern ist eine Datenmigration und keine Textkorrektur. Bezahlt macht sich das bei jedem weiteren Hundert Artikel und bei jedem Umbau der Optik, weil Felder sich mit einem Template in ein neues Layout schieben lassen, während Angaben im Fließtext von Hand nachgezogen werden müssen.

#Filter, die teuerste Abfrage im Shop

Suche und Filter laufen asynchron, das Eingrenzen lädt also nicht die ganze Seite neu und die Liste reagiert auf jede Änderung sofort. Angenehm für den Einkäufer, teuer für die Datenbank, denn jede Bewegung des Höhenreglers ist eine eigene Abfrage.

Das Filtern über mehrere Attribute gleichzeitig ist in WordPress die aufwendigste Operation auf einer Produktliste. Die Abfrage verbindet die Tabellen für Taxonomiebeziehungen und Zusatzfelder, und mit jeder aktiven Bedingung wächst die Zahl der Verknüpfungen schneller als die Zahl der Filter. Der Engpass eines solchen Shops ist deshalb nicht die Startseite, die jeder testet, sondern die Kategorieansicht mit drei gesetzten Filtern, die niemand testet.

Drei praktische Schlüsse sind geblieben. Ergebnisse häufiger Filterkombinationen gehören separat in den Cache, weil dieselbe Kombination öfter wiederkommt, als man vermutet. Die Zähler neben den Filteroptionen, also die Angabe, wie viele Artikel sich hinter jeder Option verbergen, sind der teuerste Teil der Ansicht, und man sollte bewusst entscheiden, ob sie den Aufwand wert sind. Und getestet wird auf einer Produktionskopie mit vollem Katalog: Auf einer leeren Installation mit zwanzig Produkten ist jede Abfrage schnell, weil alles in den Speicher passt und nichts optimiert werden muss.

#Bestellstrecke und die Grenze des Caches

Der Shop ist an Zahlungsdienstleister und die Auftragsverwaltung angebunden. Hier hört die Performance-Arbeit bewusst auf, und es lohnt zu verstehen, warum.

Warenkorb, Bestellübersicht und die Seite nach der Zahlung sind für jeden Besucher anders. Diese Ansichten in einen vollen Seiten-Cache zu legen endet im schlimmsten Fehler, den ein Shop produzieren kann, nämlich dem fremden Warenkorb im eigenen Browser. Die Bestellstrecke ist deshalb vom Seiten-Cache ausgenommen, und die Beschleunigung passiert an anderer Stelle: Der Objekt-Cache in Redis verkürzt den Aufbau der Seite auch dort, wo keine fertige Antwort gespeichert werden darf.

Die Rückkehr vom Zahlungsdienstleister ist ein eigener Randfall, der auf einer Produktionskopie geprüft werden muss. Ein Kunde schließt den Browser vor der Rückleitung, kommt zweimal zurück oder die Serverbenachrichtigung des Dienstleisters ist schneller als seine eigene Weiterleitung. Der Bestellstatus muss aus dieser Benachrichtigung folgen und nicht daraus, ob ein Browser die richtige Adresse erreicht hat. Wer das umdreht, hat bezahlte Bestellungen, die im Backend als offen liegen, und das fällt erst auf, wenn jemand die Buchhaltung abgleicht.

#Bilder, CDN und Lastspitzen

In dieser Branche ist die Fotografie die Produktbeschreibung. Ein Einkäufer beurteilt am Bild den Grünton, die Blattstruktur und die Art, wie die Pflanze im Topf sitzt, denn genau das trennt eine überzeugende Kunstpflanze von einer, die aus zwei Metern Entfernung auffällt. Die Galerien sind deshalb umfangreich, die Dateien groß, und das Gewicht der Seite liegt fast vollständig hier. Wegkürzen lässt es sich nicht, also muss es die Auslieferung tragen.

Die Arbeitsteilung ist einfach. Das CDN nimmt dem Server den Transfer ab, den er gar nicht bedienen sollte, und liefert die Bilder von einem Knoten näher am Besucher. Redis verkürzt die Arbeit, die zum Zusammenbau einer Seite nötig ist, wenn keine fertige Antwort ausgeliefert werden kann. Dazu kommen Bildoptimierung und die Begrenzung von Stylesheets und Skripten, damit die Seite nicht an Beiwerk erstickt, das mit dem Produkt nichts zu tun hat.

Der Verkehr verteilt sich nicht gleichmäßig über das Jahr. Er steigt vor den Feiertagen und in den Phasen, in denen Firmen ihre Büros und Ladenflächen herrichten, und einzelne Tage bringen ein Vielfaches der gewöhnlichen Last. Eine Abstimmung auf den Monatsdurchschnitt ist deshalb wenig wert. Was zählt, ist das Verhalten in der Spitzenstunde, und dort entscheidet weniger die Geschwindigkeit des Codes als die Frage, wie viele Anfragen die Anwendung überhaupt erreichen.

#Anfragen aus dem Projektgeschäft

Ein Teil der Nachfrage kommt nicht aus dem Warenkorb, sondern aus einer Anfrage. Ein Architekt braucht vierzig gleich hohe Oliven für eine Lobby, ein Messebauer eine begrünte Wand mit fester Fläche und einem Termin, ein Hotel eine Bepflanzung, die brandschutzrechtlich abgenommen wird. Diese Vorgänge enden nicht mit einer Zahlung, sondern mit einem Gespräch, und die Seite hat dabei eine andere Aufgabe als im Direktverkauf: Sie muss den Anfragenden so weit bringen, dass die erste Rückfrage nicht mehr nötig ist.

Technisch heißt das, dass genau die Angaben strukturiert vorliegen müssen, nach denen im Projektgeschäft entschieden wird. Gesamthöhe und Topfdurchmesser, weil der Platz begrenzt ist. Brandhemmende Ausführung als eigenes Feld, weil sie in öffentlichen Gebäuden Bedingung und nicht Ausstattung ist. UV-Beständigkeit, weil eine Pflanze hinter Glas sonst innerhalb einer Saison ausbleicht. Diese drei Merkmale als Filter zu führen ist kein Komfort, sondern die Vorauswahl, die der Vertrieb sonst per Mail trifft.

Der zweite Punkt ist die Verfügbarkeit in Stückzahl. Für einen Privatkunden ist ein Artikel verfügbar oder nicht, für ein Projekt zählt, ob vierzig Stück aus derselben Charge kommen, denn Pflanzen aus zwei Lieferungen unterscheiden sich sichtbar im Grünton. Diese Information gehört auf die Seite, weil sie sonst in jeder einzelnen Anfrage abgefragt wird und die Antwort jedes Mal dieselbe ist.

#Unsere Maßnahmen

Auf unserer Seite lag die Umsetzung des Shops auf Basis des vom Kunden gelieferten Layouts: das Produktmodell mit parametrischen Feldern, Katalog- und Produktansichten, Suche mit Filtern, die Anbindung von Zahlung und Auftragsverwaltung, die Cache-Schicht und die Vorbereitung des Katalogs für die Indexierung. Wichtigste Anforderung war, dass die Person, die das Sortiment pflegt, eine neue Pflanze ohne Entwickler anlegen kann und ein Besucher in wenigen Schritten beim passenden Produkt landet.

Ein Punkt verdient in einem parametrischen Shop besondere Aufmerksamkeit. Kategorieseiten und Filterergebnisse erzeugen sehr viele Adressen, die sich nur in der Reihenfolge der Parameter unterscheiden, und das ist der klassische Weg, die Sichtbarkeit eines Katalogs zu verdünnen. Es muss vorab feststehen, welche Kombinationen eigenständige, indexierbare Seiten sein sollen und welche reines Navigationswerkzeug bleiben. Messwerte zur Wirkung dieser Arbeit liegen mir nicht vor, also nenne ich keine.

#Zusammenfassung

Über die Qualität dieses Shops hat das Datenmodell entschieden und nicht die grafische Schicht. Produktattribute als Felder statt als Sätze haben das Filtern möglich gemacht, auf dem der gesamte Kaufweg steht. Die Festlegung, welche Felder dem Lieferanten und welche dem Shop gehören, erlaubt die Synchronisation des Sortiments, ohne die Arbeit der Redaktion zu löschen. Die Herausnahme der Bestellstrecke aus dem vollen Seiten-Cache bei gleichzeitiger Beschleunigung über den Objekt-Cache bringt Geschwindigkeit und korrekte Bestellungen zusammen.

Übertragbar auf das nächste Projekt sind die technische Schicht und die Arbeitsweise: WordPress mit eigenem Produktmodell, Redis, CDN, das Prüfen von Filtern und Zahlungen auf einer Produktionskopie. Nicht übertragbar sind das Attributvokabular dieses Shops und seine Lieferantenanbindungen, denn beide sind für ein konkretes Sortiment und konkrete Dateiformate entstanden. Ein zweites Projekt beginnt mit einer Umfanganalyse, das Angebot folgt danach.