Conversion Engine. Stores, die in Tagen testen.
Custom Shopify Themes auf Dawn-Basis. mit Section Library, idempotenten Generatoren und PDP Pattern, die mit deiner Brand wachsen. Statt jeden Test fünf Tage zu warten, iterierst du täglich.
Standard-Themes lernen nicht. Sie sind statisch.
Du hast wahrscheinlich ein Premium-Theme gekauft. Dawn-Fork, Impulse, Prestige, was auch immer. Es sah im Demo gut aus. Heute willst du eine neue PDP-Variante testen. und dein Theme Dev sagt: „Drei Tage." Eine neue Bundle Logik? „Eine Woche." Ein neues Section Layout für eine Aktion? „Ist nicht eingeplant."
Das ist kein Theme-Problem. Das ist ein Architektur Problem. Standard-Themes sind als Display-Layer gebaut, nicht als Lern-Maschine. Jede neue Section ist Custom Code, jede Variation hartcodiert, jeder Test eine Sonderlocke.
Eine Conversion Engine dreht das um: Der Store besteht aus 80–100 modularen Sections, jede konfigurierbar via Shopify Schema. Brand Owner oder Marketer können neue PDP Varianten in Minuten zusammenstecken. ohne Dev.
Vier Bausteine. Ein Theme.
So strukturieren wir jeden Conversion Engine-Build. Dawn als Basis, weil es schnell, accessibility-ready und Shopify-konform ist. alles darüber ist Custom.
Dawn als Basis
Wir starten nie auf Premium-Themes. Dawn ist Shopify-first, accessibility-konform, schnell. und alles, was wir draufbauen, bleibt update-fähig. Keine Theme Lock In, keine Custom Forks ohne Migration Pfad.
Section Library (82+)
Jede neue Brand zieht aus einer Library mit aktuell 82+ Sections. Hero Patterns, PDP-Bausteine, Trust Strips, Bundle Logiken. Statt jede Section neu zu bauen, kombiniert man bestehende. Iterations Speed steigt massiv.
Idempotente Generatoren
15 PDPs, alle mit ähnlicher Struktur aber unterschiedlichem Content? Statt Copy-Paste-Manuell ein Script, das aus einer CSV alle PDPs generiert. Idempotent. du kannst es 100× laufen lassen, ohne Schaden. Re Runs sind sicher.
Brand System-Hook
Jede Section liest Color Schemes und Typo aus Brand Tokens (Schicht 1). Wenn der Designer den Primary-Token ändert, sind alle 82 Sections eine Pageload später aktualisiert. Ohne Code Touch.
So sieht eine Section Library in echt aus.
Auszug aus der aktuellen Bachgold Library. Jede Section ist einmal gebaut, mehrfach genutzt. Spalte „Wiederverwendet" zeigt: derselbe Code trägt 6–15 verschiedene Seiten. Time Save bei Edits ist multiplikativ.
Wenn der Designer eine Hero Pattern-Änderung will: ein Edit, 15 PDPs aktualisiert. Iterations Speed steigt mit jeder neuen Section in der Library.
Live: Wie wir das bei Bachgold gebaut haben.
Bachgold ist eine etablierte DACH Wasserfilter Brand. Solider Traffic, gutes Produkt, aber das alte Theme war ein App Sprawl. sechs Bundle Apps, zwei Quiz Apps, drei Review Widgets, alles fragmentiert. Conversion Iteration war Tage-Arbeit, nicht Minuten.
Was wir gebaut haben
Conversion Engine komplett neu. auf Dawn-Basis, mit eigener Section Library und einem Generator Skript, das alle 15 Produkt-PDPs aus einem CSV Master erzeugt. Bundle Logik aus den sechs Apps eliminiert, durch ein einheitliches Bundle Master-System ersetzt.
Was sich operativ geändert hat
- Neue Bundle Variante: früher 3 Tage Dev-Aufwand, heute 15 Minuten im Theme Editor.
- PDP Update für alle 15 Produkte: früher 15× manuell, heute eine CSV Änderung + Re Run.
- App Stack reduziert: von 11 aktiven Apps auf 4 essentielle. Theme Speed deutlich verbessert.
- Cutover ohne Downtime: alte URL-Struktur 1:1 gemappt. kein SEO-Bruch.
"Was Standard-Agenturen 6 Monate kosten würde, lief bei uns in 8 Wochen. ohne dass wir am Setup leiden."
Vier Anti Patterns, die jede Conversion Engine ausbremsen.
Wenn der Store nicht iteriert, liegt es selten am Theme alleine. meist an strukturellen Setup-Fehlern. Die häufigsten vier:
Premium-Theme als Lösung
„Wir haben ein 300-€-Theme gekauft." Resultat: starre Templates, harte Updates, fremde Component-Logik. Jede Anpassung ist Custom Code gegen den Theme-Autor. Fix: Dawn als Basis, alles darüber ist deins.
App Sprawl statt System
Eine App für Bundles, eine für Reviews, eine für Quiz, eine für Upsell. 11 Apps × 19 €/Monat × Theme-Konflikt. Fix: modulare Sections im Theme, eine Bundle Logik, App Stack auf 3–4 essentielle reduziert.
PDPs hardcoded statt generiert
Jede der 15 PDPs einzeln im Shopify Admin gepflegt. Content Update für „neue Bullets bei allen Produkten" = 15× manuell. Fix: CSV als Master + Generator-Script, das idempotent alle PDPs neu schreibt.
A/B-Tests in Drittanbieter Apps
Optimizely / VWO / Google Optimize laden externe JS-Scripts, flackern beim Render, brechen Theme Logik. Fix: A/B-Tests via Shopify Markets oder URL-Parameter + nativem Theme Code.
Von Theme Lock In zur Iteration-Maschine in 5 Schritten.
Konkrete Reihenfolge. kann sequenziell als 8-Wochen-Migration laufen oder parallel als Greenfield-Build. Jeder Step liefert ein klares Artefakt, das du danach im Repo committen kannst.
App- und Theme-Audit
Liste alle aktiven Shopify Apps mit Monatskosten + Funktion. Markiere: tragen Revenue · sind Legacy · überlappen sich. Plus: Theme Lock In-Check. wie lange dauert eine neue Section ohne externen Dev?
Migration Plan auf Dawn-Basis
Dawn als Basis Fork klonen. Pro Section/Feature: bleibt im neuen Theme · wird durch native Logik ersetzt · entfällt komplett. Wichtig: alte URL-Struktur 1:1 mappen (sonst SEO-Bruch beim Cutover).
Live-Switch via Shopify Theme-Preview, dann Publish in einem Klick. Cutover ohne Downtime ist Standard bei sauberer Migration.
Erste 3 wiederverwendbare Sections bauen
Patterns identifizieren, die du auf 5+ Seiten brauchst. Klassiker für DTC:
Trust Strip (Press Logos + Garantie) · FAQ Block (Accordion mit Schema Markup, SEO-friendly) · Brand Story Block (Image + Story in PDP-Flow). Jede Section mit Shopify Schema-Settings, damit Marketing sie selbst konfiguriert.
Generator Workflow für PDPs
Produkt-Content in CSV Master strukturieren. Name, USPs, Bullets, FAQ Block, Bundle Verknüpfung. Generator-Script (Node.js oder Python) liest CSV und schreibt pro Produkt eine templates/product.{handle}.json.
Idempotent: 100× laufen = identischer Output. Re Runs sind sicher. Massen-Updates (z.B. „Trust Bar bei allen Produkten") = eine CSV Änderung + Re Run.
A/B-Setup ohne Drittanbieter
Native A/B-Optionen in Shopify: Markets (verschiedene Theme-Versionen pro Region/Segment) oder URL-Parameter (?variant=hero-b → Liquid-Check + alternative Section). Keine externe JS-Library, kein Flicker, sauberes Tracking via Shopify Pixel + GA4-Events.
Plus: Iterations Cycle definieren. Test Length 14 Tage, Mindest-Stichprobe per Test, Decision Doc nach jeder Iteration.
Wo Conversion Engine die anderen Schichten trifft.
Eine Iteration-Maschine ohne Brand, Lifecycle und AI bleibt mechanisch. Im Stack entsteht Profit Hebelwirkung:
Brand System
Jede Section zieht Tokens via CSS Variablen. Theme bleibt automatisch on-brand bei jedem Brand Update. ohne manuellen Section Refactor.
→Lifecycle Loops
Theme-Events (View Product, Add to Cart, Checkout) triggern Klaviyo Flows. Browse- und Cart Recovery werden vom Theme befeuert. kein Drittanbieter Pixel nötig.
→AI Operations
PDP Texte werden vom AI Generator on-brand produziert und über den CSV Generator (Step 4) in den Store geschrieben. SKU-Onboarding von Wochen auf Stunden.
Frameworks in diesem Pillar.
Dieser Pillar bündelt mehrere Frameworks. Die folgenden sind live und 1:1 nachbaubar: