A/B-Testing für Headless Commerce — Wie es mit Hydrogen, commercetools, Saleor & Custom Stacks funktioniert

Headless Commerce ist mittlerweile der Standard für seriöse Mid-Market- und Enterprise-D2C-Marken. Das Frontend (React, Vue, Astro, custom) existiert getrennt vom Commerce-Backend (Shopify, commercetools, Saleor, BigCommerce). Du erhältst Performance, Design-Flexibilität und eine saubere Developer-Experience. Du erhältst auch eine andere Beziehung zu A/B-Testing-Tools, weil die meisten davon mit der Annahme entwickelt wurden, dass du ein Theme hast.

Diese Seite erklärt den architektonischen Unterschied zwischen Testing auf einem theme-basierten Shop und Testing auf einem Headless-Storefront, führt durch die Integration auf jedem größeren Stack und zeigt, was sich ändert, wenn du dich zwischen client-seitiger und server-seitiger Experimentierung entscheidest. Es ist eine Erklärung, kein Tool-Ranking.

Was sich ändert, wenn du Headless wirst

Falls du schon einmal ein A/B-Testing-Tool auf einem Shopify Liquid Theme oder einer WooCommerce-Seite installiert hast, war der Workflow einfach. Snippet in den Theme-Header einfügen, speichern, fertig. Dieser Workflow setzt drei Dinge voraus, die alle bei Headless Commerce verschwinden.

Es gibt keinen Theme-Editor. Monolithische Plattformen kommen mit einem bekannten Integrationspunkt: dem Theme-Header. Bei Headless ist dein Frontend eine custom Anwendung, die in React, Vue, Next.js, Hydrogen oder einem anderen Framework deiner Wahl gebaut ist. Das Testing-Snippet muss in deinen Anwendungscode integriert oder von einem CDN geladen werden. Es ist eine einmalige Entscheidung, die dein Entwickler trifft, aber es ist eine Entscheidung, nicht ein Copy-Paste-Schritt.

Die Build-Pipeline gehört dir. Hydrogen baut mit Vite. Ein commercetools Storefront nutzt oft Next.js. Saleor Frontends sind typischerweise Next.js oder Nuxt. Jedes Projekt hat seinen eigenen Bundler, Dependency Graph und Deployment Target. Ein Testing-Tool, das ein einzelnes Drop-in Script Tag liefert, funktioniert überall. Ein Tool, das SDK-Installation und Bundler-Konfiguration benötigt, funktioniert auf manchen Stacks und auf anderen nicht.

Rendering läuft anders. Bei einem monolithischen Shopify Store wird HTML von Shopifys Servern gerendert. JavaScript läuft im Browser, und client-seitiges Testing ist die naheliegende Wahl. Bei Headless könntest du server-side rendering (Next.js SSR), static site generation (Hydrogen, Astro), incremental regeneration oder reines client-side rendering nutzen. Jede dieser Optionen verschiebt, wo Variant Assignment stattfinden sollte. Das wird zur zentralen Entscheidung für Headless A/B Testing, und wir behandeln es unten.

Wie A/B Testing auf jedem größeren Headless Stack funktioniert

Shopify Hydrogen

Hydrogen ist Shopifys React Framework für Headless Storefronts, deployed auf Oxygen. Es nutzt Remix unter der Haube und rendert server-seitig. Für A/B Testing hast du zwei Wege:

• Client-seitig: Lade das Testing-Snippet im Root Layout (root.tsx). Variant Assignment läuft im Browser nach der Hydration. Funktioniert für jeden UI-Level Test (Hero, PDP Layout, CTA Platzierung, Trust Badges). Das wählen die meisten Teams.
• Server-seitig: Nutze Hydrogens Loader Functions, um Variant Assignments von der API deines Testing-Tools zu fetchen, und gib sie dann als Props an die gerenderten Komponenten weiter. Kein Flackern, höherer Implementierungsaufwand.

Beachte, dass Shopifys native A/B Testing App nicht auf Hydrogen funktioniert. Sie ist nur für Liquid Themes gebaut.

commercetools (mit beliebigem Frontend)

commercetools ist ein Headless Commerce Backend. Das Frontend ist typischerweise Next.js, Nuxt oder custom. Der Testing-Ansatz hängt vom Frontend ab, nicht von commercetools selbst. Die meisten Teams lassen ein Snippet in den HTML Head des Frontends fallen und laufen client-seitig. Server-seitig ist möglich, indem man die API des Testing-Tools von den Server Functions des Frontends aus aufruft.

Saleor

Saleor ist eine Open-Source Headless Commerce Plattform mit einer Next.js oder React Storefront Referenzimplementierung. Das Saleor Backend diktiert nicht den Testing-Ansatz. Client-seitig via Snippet in _app.tsx oder Root Layout ist das Standard-Pattern.

BigCommerce headless

BigCommerce unterstützt Headless via seinem Catalyst Next.js Referenz-Storefront oder jedem custom Frontend. Gleiches Pattern wie die anderen: client-seitiges Snippet im Next.js Root, optional server-seitig via API für SSR Variants.

Custom Next.js, Remix, Astro, SvelteKit

Jedes custom Commerce Frontend funktioniert genauso. Lass das Testing-Snippet in der Root-Komponente oder im Layout fallen. Wenn du server-seitige Variants brauchst (typischerweise für Checkout-Seiten, wo Flackern inakzeptabel ist), rufe die Testing-API in deinen Server Functions auf und gib Ergebnisse als Props weiter.

Server-seitig vs client-seitig bei Headless: wann welches wählen

Headless gibt dir eine echte architektonische Wahl zwischen server-seitigem und client-seitigem Testing. Bei einem Shopify Liquid Store ist die Frage kaum relevant. Bei Headless schon.

Client-seitiges Testing funktioniert auf jedem Headless Stack. Setup dauert Minuten (Snippet in das Root Layout einfügen), der Visual Editor bleibt verfügbar, und Marketer können Tests ohne Engineering-Beteiligung laufen lassen. Tools in dieser Kategorie sind Varify.io, VWO, AB Tasty und Convert. Das winzige Risiko ist Flackern bei langsamen Netzwerken, was eine gute Anti-Flicker-Implementierung auf unter 30 Millisekunden reduziert.

Server-seitiges Testing funktioniert am besten auf SSR oder SSG Stacks wie Hydrogen, Next.js SSR und Astro. Die Variant-Entscheidung passiert bevor HTML den Browser erreicht, also ist Flackern null. Der Preis ist Implementierungsaufwand: jeder Test erfordert SDK-Integration, Deployment-Pipeline-Änderungen und Backend-Logik für Variant-Routing. Tools in dieser Kategorie sind GrowthBook, Optimizely Full Stack und LaunchDarkly Experimentation. Das ist der richtige Weg, wenn du Engineering-Kapazität hast und einen checkout-kritischen oder Backend-Logik-Test, wo Flackern inakzeptabel ist.

Für etwa 80% der Headless Commerce A/B Tests ist client-seitig die richtige Wahl. Die Ausnahmen sind checkout-kritische Tests, wo Flackern wichtig ist, und Tests von Backend-Logik wie Pricing Engines oder Recommendation Algorithmen. Für diese machen server-seitige oder hybride Setups Sinn. Unser client-seitig vs server-seitig Vergleich hat die vollständige Aufschlüsselung.

Wie Varify.io mit einem Headless-Storefront integriert

Drei Gründe, warum Varify.io gut zu Headless Commerce passt.

• Ein Snippet, jedes Frontend. Ein 11,5 KB JavaScript-Snippet, einmal in deinem Root-Layout hinzugefügt. Funktioniert mit React, Vue, Astro, SvelteKit, Hydrogen, Next.js und allem anderen, was JavaScript im Browser lädt. Keine SDK-Installation, keine Bundler-Konfiguration, kein Framework-spezifisches Paket, das aktuell gehalten werden muss.
• SPA-bewusst. Headless-Stores sind typischerweise Single-Page-Anwendungen. Varify erkennt Route-Änderungen in React Router, Next.js Routing und Hydrogen Navigation und wendet Varianten automatisch auf der neuen Seite an. Keine manuelle SPA-Konfiguration erforderlich.
• Cookie-los, kein Consent-Gate. Varianten-Zuweisung nutzt localStorage, das unabhängig vom Consent-Banner-Status und unabhängig von Safari ITP funktioniert. Das ist wichtig für Headless-Stores mit hohem Mobile-Traffic und EU-Kundenstamm. Siehe Cookie-loses A/B-Testing für die Architektur-Details.

Die typische Integration auf einem Next.js oder Hydrogen Storefront sieht so aus:

// app/layout.tsx or root.tsx
<script
  async
  src="https://cdn.varify.io/snippet/YOUR_ID.js"
/>

Das ist die gesamte Integration für die meisten Headless-Storefronts. Sobald das Snippet live ist, werden Experimente im Varify Dashboard verwaltet, und es sind keine weiteren Code-Änderungen für neue Tests nötig.

Für performance-kritische Seiten, wo Flicker inakzeptabel ist, unterstützt Varify auch den Aufruf der Assignment-API vom Server-seitigen Code und das Einspritzen von Varianten-Daten in den initialen HTML-Render. Die meisten Teams brauchen das nicht, und der client-seitige Standard ist für die Mehrheit der Tests ausreichend.