Von vorne lockt er, von hinten schockt er! Viele Online Shopbetreiber wissen garnicht, wie ihr System unter der Haube aussieht

Quelle: ITAcadamySerbia

Seit knapp einem Jahr bietet die Firma SHOPMACHER, für die ich arbeite, sogenannte „Health Checks“ an. Damit kann man Online-Shops auf ihre technische „Gesundheit“ prüfen. Dabei prüfen meine Kollegen und ich in insgesamt sieben Kategorien — Systemarchitektur, Software, Hosting, Performance, Deployment, UX/Design und Content — das Shopsystem auf Herz und Nieren.

In 2019 haben wir so knapp 20 Online-Shops mithilfe unseres standardisierten Health Check Verfahrens analysiert. Dabei kamen uns die unterschiedlichsten Shops auf Basis verschiedenster Softwarelösungen vor die Flinte. Von der für unsere Branche üblichen Installationsgröße bis hin zu ausgeprägten Hochlast-Mircoservice-Systemen war alles dabei.

Dabei wurde uns schnell klar: Jedes laufende Setup hat mit individuellen Stärken und Schwächen zu kämpfen welche meistens historisch, oder wie ich gerne sage hysterisch, entstanden sind und welche man nur mit gezielten Code- oder Prozessänderungen bewältigen kann. Und dennoch hat sich im Verlauf der ganzen Health Checks ein Muster herausgebildet:

Gute Ergebnisse fanden wir oft in den Bereichen UX, Markenkonformität und Content. Klingt logisch; was der Kunde sieht und ihn zum Kauf animiert wird auch gepflegt und gewartet. Hier kümmern sich viele Shopbetreiber mit Herzblut und leidenschaftlicher Sorgfalt um die kleinsten Details.

Öffnet man aber mal die Motorhaube des auf hochglanz polierten Shop-Systems, sieht es meistens nicht mehr so rosig aus: Der anfangs gut geplanten Architektur des Gesamtsystems merkte man oft an, dass im laufenden Betrieb offenbar nicht immer die Zeit blieb, um neue Features sauber zu durchdenken. Weiterhin wird statt den Ursprung eines Problems (z.B. ein vom Kunden gemeldeter Fehler) zu beheben meistens nur das Symptom behoben. Kurz gesagt, Workarounds und Provisorien werden oft vorne und hinten an das System geflanscht, ohne sich Gedanken um die langfristigen Auswirkungen zu machen. Das löst vielleicht vorerst auftretende Probleme, geht aber gleichzeitig auch zulasten der Stabilität und der Updatefähigkeit des gesammten Systems.

Besonderes bei der Anbindung von Drittsystemen findet man oft „die dicksten Dinger“, wie mein Kollege Carsten gerne sagt. „Da wird fröhlich drauf los entwickelt und schwupps, hat man die Magie von zwei Jahren Customizing in einem einzigen Monster-Plugin — versuch’ dann mal ein Update zu machen. Das ist alles andere als entspanntes Arbeiten, wenn dir bei jeder Anpassung irgendwo was “um die Ohren fliegt”.

Die meisten Probleme tauchen in den Bereichen Performance, Sicherheit, Architektur und Deployment auf.

Was wir ebenfalls immer als typisches Problemfeld bei fast allen geprüften Systemen fanden, waren Schwächen in der Performance. Eigentlich verwunderlich, weil das ja unmittelbaren Impact auf die Conversionrate hat und damit super wichtig für die Shopbetreiber sein sollte. Nun ja, eigentlich ist es ihnen auch wichtig, denn die meisten Anfragen für einen Health Check kamen bei uns auf, eben weil das Shop-System so schnell lief wie ein Sack Nüsse.

Meistens zeigt sich dann aber, dass nicht die Shopsoftware an sich Schuld an den schlechten Ladezeiten ist, es sind vielmehr die zahlreichen schlecht ausgeführten Anpassungen, die das System langsam machen. Oft werden Prozesse in den Shop verlagert, die dort überhaupt nichts zu suchen haben. Zum Beispiel werden gerne mal Artikeldaten aufwendig im Shop, welcher wohlgemerkt nur als Verkaufskanal dienen sollte, angelegt und mit zahlreichen Informationen veredelt, um dann über einen CSV-Export in die eigentliche Warenwirtschaft importiert zu werden. Gezielte Regelungen für den Datenfluss und Lösungen wie eine Middleware oder ein PIM-System sind dann meistens völliges #Neuland und würden ja den etablierten Prozess gefährden. 🤦‍♂️

Bitter wird es aber besonders dann, wenn diese verbauten Systeme mit den gängigen Google-Tools bewertet werden. Die daraus resultierenden Ergebnisse sind selbst meinen versiertesten Google-Kollegen manchmal ein Rätsel. Je nachdem, welchen Richtwert man setzt, kann man komplett unterschiedliche Ergebnisse bekommen, was dazu führt, dass der Shopbetreiber nach der Prüfung mit diesen Tools auch nicht schlauer ist als zuvor. Oft heißt es dann: “Eigentlich ist der Shop schnell und performt gut, aber Analytics und die sinkende Conversionrste sehen das irgendwie anders, verstehen wir auch nicht…”

Mein persönlicher Lieblingsbereich des Health Checks ist und bleibt aber der Deployment-Prozess, welcher dafür Sorge trägt, dass die schnell angeflanschten Features letztendlich ausgerollt werden. Obwohl bisher auch einige Perlen, welche man in ein Lehrbuch hätten drucken können, dabei waren, sind die meisten “Deployments” weit unter dem, was wir heute als “ordentlich” oder “sauber” bezeichnen würden. Da werden Features teilweise noch mittels eines FTP-Programms auf die verschiedenen App-Server verteilt oder die Deploymentscripte sind samt Private-SSH-Key für jedermann von außen erreichbar. Ein wunder, dass so manch von mir geprüfter Shop zuvor nicht in Grund und Boden gehackt wurde.

Leider ist das aber oft so, dass den Bereichen, die scheinbar keinen direkten Einfluss auf das Kaufverhalten des Kunden haben, nicht so viel Aufmerksamkeit geschenkt wird. Fakt ist aber, schießt man sich mit einem Deployment den Shop weg oder wird sogar der Server gehackt, bringen mir meine ganzen Marketingmaßnahmen und fancy Transitions herzlich wenig. Ich vergleiche sowas immer gerne mit einem Haus: Ist die Basis nicht solide, stürtzt es früher oder später ein. Das ist bei einem Shop-System nicht sonderlich anders.

Letztendlich bleibt zu sagen, dass der Wert des Look & Feel eines Shops schon lange im Kopf der Shopbetreibern angekommen ist. In Punkto technische Basis und vor allem die Wartung des Systems gibt es allerdings noch viel zu lernen. Das ist mir heute mehr denn je bewusst