Storefront-Optimierung mit nur wenigen Code-Zeilen Storefront-Optimierung mit nur wenigen Code-Zeilen

Optimierung Deiner Storefront mit Convertly

Hallo liebe Community,

mein Name ist Hendrik Bonke, ich bin 25 Jahre alt und seit 2017 Entwickler bei 8mylez. Als einer der ersten Azubis bei 8mylez reichen meine Erfahrungen zurück bis zu Shopware 4. Inzwischen genieße ich die Rolle eines Full-Stack Entwicklers, in der ich mich mit verschiedenen Aufgaben im Shopware-Kosmos auseinandersetze.

Convertly begann für mich als Side-Project, mit der Herausforderung, ein besonders gut integriertes A/B/n-Tool für Shopware zu bauen. In der technischen Konzeption und Umsetzung konnte ich meiner Kreativität dabei freien Lauf lassen. Ich nehme mir die Zeit, jedes Feature bestmöglich an diese Anforderung anzupassen, denn Convertly soll nicht nur ein weiteres A/B/n-Tool werden, sondern das A/B/n-Tool für Shopware werden.


Du betreibst einen erfolgreichen Onlineshop und möchtest Deine Storefront optimieren, um die Nutzererfahrung zu verbessern und Deine Conversion-Rate langfristig zu steigern. Doch wo fängst Du an? Eine bewährte Methode ist das A/B/n-Testing, bei dem verschiedene Varianten getestet werden, um herauszufinden, welche bei Deinen Kunden am besten ankommt. Was A/B/n Tests sind und was dabei zu beachten ist, kannst Du im Blogbeitrag zu Mein erster A/B Test für Shopware mit Convertly nachlesen. Aber was, wenn die Standardfunktionen von Shopware 6 rund um den Rule Builder nicht flexibel genug sind, um Deine Ideen umzusetzen? Hier haben wir innerhalb von 8mylez.com mit Convertly eine einfache Möglichkeit geschaffen, Code Anpassungen zu testen.

Mit Convertly kannst Du A/B/n-Testing in Shopware optimieren und Deine Experimente direkt in Deiner Storefront effizient und unkompliziert umsetzen. Mit der Twig-Funktion convertly([...]) können Sie Ihre Storefront-Elemente dynamisch steuern und so maßgeschneiderte Varianten ausspielen. Noch besser: Convertly kümmert sich um das Cache-Handling und erzeugt für jede Experiment-Variante einen eigenen Cache-Pool. Das bedeutet, dass keine ungewollten Darstellungen Ihrer Storefront bei Nutzern auftauchen. Klingt spannend? Lass uns tiefer eintauchen.


Warum ein Fallback entscheidend ist

Bevor wir zu den technischen Details kommen, ist ein Punkt besonders wichtig: die Fallback-Variante. Diese sollte immer definiert werden, um sicherzustellen, dass:

  1. Kunden ohne aktives Experiment eine vollständige und funktionsfähige Storefront sehen.
  2. Bots und Crawler die Shop-Inhalte korrekt erfassen können.
  3. Saubere Statistiken für die Entscheidungsfindung entstehen.

Mit einer gut durchdachten Fallback-Option stellen Sie sicher, dass alle Nutzer, auch diejenigen außerhalb eines Tests, eine konsistente und funktionale Storefront erleben.


So funktioniert die Convertly-Funktion

Die convertly()-Funktion kann entweder als einfache Abfrage genutzt werden, um den aktuellen technischen Schlüssel einer Variante zu ermitteln, oder in Kombination mit if-Statements für komplexere Logiken:

Einfacher Check:

 {{ convertly('experiment_key') }}

Hier erhältst Du den technischen Schlüssel der aktiven Variante als string oder booleschen Wert. Wenn keine Variante aktiv ist, gibt die Funktion false zurück.

Gezielte Variante prüfen:

{{ convertly('experiment_key', 'variant_key') }} 

Diese Abfrage liefert einen booleschen Wert, der anzeigt, ob eine spezifische Variante gerade aktiv ist.


Die Nutzung kann wie in folgendem Szenarium aussehen:

Fall: A/B/n-Test mit 3 Varianten für die unterschiedliche Darstellung des Home-Buttons in der Navigation

Convertly: Aktives Experiment mit dem technischen Schlüssel experiment_navigation

  • Varianten mit folgenden technischen Schlüsseln
    • menu_hide_home
    • menu_replace_home
    • menu_default

Wir legen ein if-Statement mit der neuen convertly-Funktion an. Als erstes Argument wird der technische Schlüssel des Experiments angegeben. Wenn wir als 2ten Parameter die Variante hinterlegen, erhalten wir für diese Variante einen booleschen Wert – je nach dem welche Variante aktiv ist.

In diesem Szenarium müssen wir 3 Fälle abdecken. Im ersten Fall entfernen wir den Home-Button vollständig und geben an dieser Stelle nichts weiter aus. Im zweiten Fall wollen wir für den Nutzer eine Alternative ausspielen (bspw. ein Icon) und als Fallback bzw. als Default wird der Standard ausgespielt.

Es ist wichtig einen Fallback bzw. einen Standard zu definieren, damit Kunden ohne Variante bzw. damit Bots/Crawler die keinen A/B-Test starten, eine korrekte Darstellung der Storefront erhalten. Außerdem erhalten wir für diesen Fallback interpretierbare Statistiken damit die Entscheidungen getroffen werden können.

Twig-Codebeispiel zur Nutzung der Convertly-Funktion in einer Shopware-Storefront. Der Code definiert eine Navigation mit A/B/n-Tests und prüft Varianten wie 'menu_hide_home', 'menu_replace_home' und 'menu_default' mithilfe von if-Statements.

Als Alternative kann auch die convertly-Funktion ohne 2. Paramter abgefragt werden – in diesen Fällen erhalten wir als String den technischen Schlüssel der Variante. Falls für das angegebene Experiment keine Varianten aktiv ist, erhalten wir in diesem Fall den booleschen Wert false.

Code-Beispiel für die Implementierung der Convertly-Funktion in einer Shopware-Storefront. Der Code zeigt ein Twig-Snippet mit if-Statements zur Steuerung der Navigation basierend auf A/B/n-Test-Varianten wie 'menu_hide_home', 'menu_replace_home' und 'menu_default'.

Fazit: Mehr Flexibilität für Deine Tests

A/B/n-Testing mit Convertly in Shopware optimieren bedeutet nicht nur, verschiedene Varianten zu testen, sondern auch, ein strukturiertes Cache-Handling und saubere Statistiken zu gewährleisten. Mit der richtigen Implementierung und einer durchdachten Fallback-Strategie kannst Du Deine Storefront effizient optimieren und fundierte Entscheidungen treffen.

Probiere gerne aus, wie einfach es sein kann, Experimente effizient und flexibel umzusetzen. Bei Fragen helfen wir sehr gerne! 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert