Checkout-Funnel

Der Checkout-Funnel zählt, wie weit Besucher durch deinen Shop kommen. Er zählt pro Besucher aus Stage-Events, welche Stufen er erreicht hat, und registriert die Warenkorb-Requests deiner Shopseiten.

Wie ein Pageview seine Stufe bekommtCopy Anchor Link

Beim Ingest gleicht der Collector die bereinigte Seiten-URL (Origin und Pfad, plus freigegebene Query-Keys) mit einer Liste von Mustern pro Stufe ab und stempelt cart, checkout oder success auf den Pageview. Ein Pageview mit Stufe schreibt zusätzlich ein Stage-Event, und nur das zählt der Funnel. Der Tracker schickt kein zusätzliches Feld.

Die eingebauten Muster decken Shopware 5 und 6, WooCommerce (englische und deutsche Slugs), Magento 2, PrestaShop, JTL Shop 5 und Shopify ab. Jedes Muster toleriert ein Sprach- oder Shop-Präfix, /de/warenkorb und /fr/cart zählen also wie ihre Root-Varianten.

Die Prüfreihenfolge ist fest: success, dann cart, dann checkout.

Markierung und Stage-Event entstehen beim Ingest und werden nie neu berechnet. Änderst du die Muster, wirkt das auf Pageviews ab diesem Moment.

Eingebaute MusterCopy Anchor Link

Die Muster folgen der Mustersyntax weiter unten.

Die Muster enden an Wortgrenzen: */cart trifft die Warenkorbseite, aber nicht /cartoons, und */thank-you trifft nicht /thank-you-for-subscribing. /order ist exakt und nur auf Root-Ebene gemeint, sonst würde es Shopwares /account/order treffen.

Der Schalter läuft auf jeder Site, Shop oder nicht. Auf einer Site mit Pfaden wie /docs/checkout/setup bekommen diese Pageviews eine Stufe; Abhilfe schaffen eigene Muster oder das Abschalten. OXID liest seinen Controller cl, Shopify die Checkout-Events.

MustersyntaxCopy Anchor Link

Ein Muster beschreibt den ganzen Pfad, Groß- und Kleinschreibung spielt keine Rolle. Checkout-Pfade und URL-Regeln verstehen einen Teil der Pathname-Syntax von URLPattern:

Ein Muster ohne wörtliches ? prüft nur den Pfad, /checkout trifft also auch /checkout?step=2. Ein Muster mit ? prüft Pfad und Query zusammen. Pro Muster darf nur ein Teil auf mehrere Arten passen, etwa ein * vor dem Ende oder ein (...). Ein Muster, das eine Regel verletzt, zum Beispiel ein eingefügter regulärer Ausdruck, wird beim Speichern abgelehnt.

Warenkorb-InteraktionenCopy Anchor Link

Die URL-Stufen sehen Seiten. Ein Besucher, der ein Produkt aus einer Liste oder einem Offcanvas-Warenkorb hinzufügt, lädt nie eine Warenkorbseite. Deshalb registriert der Funnel zusätzlich Warenkorb-Interaktionen: ein First-Party-POST an einen bekannten Warenkorb-Endpunkt, gelesen aus der Fetch/XHR-Telemetrie, die der Tracker ohnehin erfasst. Wo der Endpunkt es verrät, trägt die Interaktion eine Art.

Bei Shopify ist Menge 0 ein Entfernen und kommt als change an. Die Art einer other-Zeile steht nur im Request-Body, den fastmon nie liest.

Warenkorb-Interaktionen brauchen collect_fetch_xhr (im Preset Standard an). Ist es aus, funktionieren die URL-Stufen weiter, und die Interaktionszahlen bleiben leer. Hinzufügen per klassischem Formular-POST (OXID, WooCommerce-Produktseiten) ist für Fetch/XHR unsichtbar.

Warenkorb-Interaktionen stehen neben den Funnel-Schritten, nie als einer davon.

Stage-Events und SamplingCopy Anchor Link

Der Funnel zählt nur Events. Das checkout_stage eines Pageviews allein ist keine Stufe mehr. Ein Besucher erreicht eine Stufe mit jedem Event dieser Namen, egal wer es geschickt hat:

• Checkout-Seiten schreiben für jeden Pageview mit Stufe ein Stage-Event mit source collector. Dafür braucht es Checkout-Tracking, einen Shop und einen gespeicherten stitch, und diese Events lassen sich weder bearbeiten noch löschen.
• Das Shopify-Pixel schickt begin_checkout und order_placed, siehe Shopify-Checkout-Events.
• Deine eigenen Events zählen ebenso, etwa ein GA4-purchase aus dem dataLayer. Ein Käufer mit order_placed und purchase zählt einmal.

Events werden nie gesampelt. Schritte, Kohortengrößen, Stufen-Verlauf und Käufe sind deshalb bei jeder Rate exakt. visitors_total und die Warenkorb-Interaktionen stammen aus gesampelten Pageviews und sind hochgerechnet, die Conversion-Rate teilt also exakte Käufer durch geschätzte Besucher.

FilterCopy Anchor Link

• Site, Land, Gerät und die übrigen Edge-Dimensionen grenzen die Events exakt ein.
• Seitenfilter (URL, Seitentyp, Login-Status, Verbindung, Viewport-Klasse) grenzen die Events exakt nach der Seite ein, von der sie kamen. Events von vor dem 16.10.2026 tragen keine Seite und treffen keinen davon.
• Kampagne und Referrer prüfen den Einstiegs-Pageview des Besuchers. Auf einer gesampelten Application ist das Ergebnis dann hochgerechnet, und meta.sampling.estimated_metrics sagt das.
• Mit 422 abgelehnt: die technischen Seitenfilter (Navigationstyp, Protokoll, Cache-Status, Origin-Host, Fehler-Herkunft, Third-Party-Kategorie), ein Metrikbereich, checkout_stage und die Identität session.

Was die Zahlen bedeutenCopy Anchor Link

• Conversion-Rate: Besucher mit Abschluss geteilt durch alle Besucher im Zeitraum, die Zahl, die auch GA4 und Shopify melden. Vergleichbar mit dem üblichen Shop-Benchmark von 1 bis 3 %. Der Nenner ist visitors_total, und jeder Punkt der Zeitreihe trägt eigene visitors.
• reach_rate pro Schritt: der Anteil am ersten Schritt. Er kann über 100 % liegen, weil ein Besucher einen späteren Schritt erreichen kann, ohne dass der frühere beobachtet wurde (Deep-Link, Offcanvas-Warenkorb, Express-Checkout).
• Besucher pro Schritt. Jeder Besucher zählt einmal pro Schritt, den er im Zeitraum erreicht hat, gruppiert über die Besucher-Identität (standardmäßig stitch, siehe Besucher und Sessions). Pro Besucher wird nichts gespeichert, die Gruppierung passiert zur Abfragezeit.
• Einsortiert nach Einstieg. In der Zeitreihe landet ein Besucher im Bucket seiner ersten Funnel-Zeile, nicht dem seines Abschlusses. Die Bucket-Besucher addieren sich nicht zur Gesamtzahl. Ein Tag ist endgültig, sobald der Tag, das 24-Stunden-stitch-Fenster und die Ingest-Verzögerung vorbei sind.
• Warenkorb-Rate (cart_interaction_rate): Besucher mit Warenkorb-Interaktion geteilt durch alle Besucher, üblich sind 5 bis 6 %. Lies sie als Untergrenze, wo die Warenkorb-Calls des Shops für Fetch/XHR unsichtbar sind.
• Besucher mit fehlgeschlagenen Warenkorb-Calls (cart_interaction_error_visitors): gegen cart_interactions gelesen der Anteil der Käufer, die auf einen kaputten Warenkorb gestoßen sind.
• Dauer bis zum Kauf (time_to_success_seconds): Sekunden vom Funnel-Einstieg bis zum ersten Abschluss, als p50, p75 und p90.
• Abschluss heißt Seite oder Event, nicht Zahlung. Ohne Shopify-Pixel und ohne purchase-Event zeigt ein Shop, dessen Danke-Seite den Tracker nicht lädt, Checkouts ohne Abschlüsse. Das ist der häufigste Einrichtungsfehler.
• Eine Rate, die nicht gemessen werden konnte, fehlt. Läuft die Besucherzählung in einen Timeout, behält die Antwort ihre Schritte und lässt visitors_total und conversion_rate weg, statt 0 % zu melden.

Shopify-Checkout-EventsCopy Anchor Link

Shopify betreibt den Checkout auf eigener Infrastruktur, wo dein Theme-Skript nie lädt; die URL-Stufen enden deshalb am Warenkorb. Ein Custom Pixel meldet drei Checkout-Schritte als Events: Checkout betreten, Zahlung abgeschickt, Bestellung aufgegeben. Einrichtung und Grenzen der Abdeckung stehen in Shopify-Checkout messen.

Was sich im Funnel ändert, sobald das Pixel läuft:

• checkout und success kommen aus Events, ohne Pageview auf beiden. Besucher, die nur im Checkout auftauchen, zählen in visitors_total mit.
• payment_submitted_visitors steht als Fakt neben den Schritten: Besucher, die die Zahlung abgeschickt haben. Das Feld fehlt, statt 0 zu sein, wenn für den Zeitraum kein Event gelesen wurde.
• Käufe sind eine Untergrenze. Shopify feuert sein Checkout-abgeschlossen-Event bei den meisten Shop-Pay- und Apple-Pay-Bestellungen nicht. Ein Besucher mit Zahlung und ohne Abschluss hat meistens über ein Wallet gekauft.
• Content-Blocker stoppen das Pixel. Die EasyPrivacy-Liste des EasyList-Projekts blockt den Sandbox-Pfad von Shopifys Custom Pixels, und uBlock Origin liefert diese Liste ab Werk mit. Diese Besucher liefern Storefront-Pageviews, aber keine Checkout-Events, die Conversion-Rate liest sich also zu niedrig. Siehe Content-Blocker.
• Warenkorb zu Checkout kann über 100 % liegen. Wer direkt in den Checkout springt, hat nie eine Warenkorbseite geladen.
• Seitenfilter treffen die Pixel-Events über den Seitentyp checkout, die Viewport-Klasse und die Verbindungsklasse. Events von vor dem 18.10.2026 tragen nichts davon.
• Ein Filter auf den Login-Status gibt einen 422, sobald eine Shopify-Application im Scope ist, denn das Pixel liest keine Kundendaten. Das Dashboard zeigt dann keine Bestellungen und bietet „Login-Filter entfernen" an.
• Im Checkout gibt es keine Pageviews. Ein Käufer, der nur im Checkout auftaucht, zählt in einer Kohorte ohne Web Vitals, und der Sessions-Explorer zeigt den Shopify-Checkout nicht.

Die Events tragen den Schritt, Land, Gerät, Browser, Viewport, Verbindung und Traffic-Klasse des Besuchers sowie die Edge-Kennung. Keine URL, keine Session-ID, kein Bestellwert: Der Shopify-Checkout wird gezählt, nicht gemessen.

Wo es auftauchtCopy Anchor Link

• Analytics-Dashboard. Bestellungen und Conversion sind zentrale Kennzahlen. Bestellungen zeichnet die Abschluss-Serie, mit Warenkorb und Checkout als Kontextlinien. Conversion zeichnet die Rate gegen die Vorperiode, und der Tooltip nennt die Besucher hinter jedem Punkt.
• Checkout-Karte. Die Schritte, die Warenkorb-Requests nach Art, die Besucher mit kaputtem Warenkorb und die Zeit bis zum Kauf.
• Käufer im Vergleich. Eine Karte ganz unten, standardmäßig zugeklappt, stellt Besucher mit gesehenem Kauf denen gegenüber, die ohne Kauf bis in den Checkout kamen. Sie lädt erst, wenn du sie öffnest.
• Stufen-Chart. Besucher pro Stufe über die Zeit, gezählt zum Zeitpunkt des Erreichens, gegen die Vorperiode.
• Filter checkout_stage. Warenkorb, Checkout und Bestellt sind feste Optionen in der Filterleiste, den Chips und der Befehlspalette. Auf den Metrikseiten sind Web Vitals pro Funnel-Stufe eine gefilterte Abfrage.
• Explorer. Gruppiere nach Checkout-Stufe, zeichne Warenkorb-Aktionen und fehlgeschlagene Warenkorb-Aktionen, und lies Stufe und Arten als Spalten. Ein Preset „Checkout" bringt Stufen über die Zeit und LCP pro Stufe.
• Besucher. Filtere die Liste auf alle, die eine Stufe erreicht oder eine Warenkorb-Interaktion ausgelöst haben. Auf der Journey trägt jeder Pageview einen Funnel-Chip in der Farbe seiner Stufe.
• Business Impact. Wo der Funnel Daten hat, zeigt die Seite dieselbe Conversion-Rate statt der aus LCP und INP geschätzten.

Die Checkout-Zahlen folgen den Filtern der Seite. Einen Filter, den der Checkout nicht nutzen kann, nennt das Checkout-Panel mit einem Button zum Entfernen. Sie erscheinen nur bei einem Shop: Eine Application mit unbekannter Plattform gilt als Shop, bis shop.active auf false steht.

EinstellungenCopy Anchor Link

Schalter und Muster liegen an der Application unter Einstellungen → Shop & Seitentypen und auf der API unter shop.checkout (siehe Applications).

• checkout_tracking ist standardmäßig an und ist das Opt-out. Es umfasst URL-Stufen und Warenkorb-Interaktionen zusammen. Die Markierung wirkt nur vorwärts, Abschalten hinterlässt also eine Lücke, die sich später nicht füllen lässt.
• Pfade pro Stufe. Jede Stufe erbt entweder die eingebauten Muster (der Default, null) oder ersetzt sie komplett. Es gibt keine Mischung. Bis zu 10 Muster pro Stufe, jedes bis zu 200 Zeichen, druckbares ASCII in Kleinbuchstaben, in der Mustersyntax. Verbesserungen an der eingebauten Liste erreichen jede Site, die diese Stufe nicht überschrieben hat.
• Voraussetzungen. Besucher pro Stufe zu zählen braucht den gespeicherten stitch. Ohne ihn oder unter der Identität session antworten die Funnel-Endpunkte mit 422. Warenkorb-Interaktionen brauchen zusätzlich collect_fetch_xhr.

Query-basierte Checkouts (OXID und andere)Copy Anchor Link

OXID hält den gesamten Checkout auf index.php und nennt den Schritt im Query-Parameter cl. Bei einer OXID-Application behält die gespeicherte URL cl, etwa /index.php?cl=thankyou, und der Funnel braucht keine Einrichtung: basket ist der Warenkorb, user, payment und order der Checkout, thankyou der Abschluss. Eigene *?cl=*-Muster haben weiter Vorrang, und eine Stufe mit eigener Pfadliste, auch [], bekommt nichts vom Controller.

Ein generischer ?step=-Checkout braucht den Key in collect_query_values_for und eigene Muster wie *?step=payment*.

DatenschutzCopy Anchor Link

Die Stufe ist ein Label mit vier Werten, berechnet aus der URL, die die Site ohnehin speichert; die Warenkorb-Interaktion ist ein Merker aus Fetch/XHR-Pfaden, die sie ohnehin speichert. Keines von beiden fügt dem Beacon ein Feld hinzu oder erhöht die Besucher-Entropie, und ein Stage-Event übernimmt nur, was die Pageview-Zeile ohnehin enthält. Der Funnel wird zur Abfragezeit berechnet, in jedem Erfassungsmodus, auch in anonymous.

Was das Shopify-Pixel trägt, steht unter Shopify-Checkout-Events, was deine eigenen Events tragen, unter Datenschutz.

APICopy Anchor Link

• POST /organizations/{org_id}/analytics/funnels/checkout: die Schritte mit Besucherzahlen und reach_rate, dazu conversion_rate und visitors_total für den Zeitraum, die Warenkorb-Interaktionen nach Art, time_to_success_seconds und die Zeitreihe, gebucketet nach Funnel-Einstieg. Siehe die Referenz (nur auf Englisch).
• POST /organizations/{org_id}/analytics/funnels/checkout/cohorts: Besucher mit beobachtetem Abschluss gegen die, die den Checkout ohne Abschluss erreicht haben. Pro Gruppe die Web Vitals über die ganze Journey und pro Stufe, dazu Anzahl, Dauer und Fehler der Warenkorb-Calls. Siehe die Referenz.
• POST /organizations/{org_id}/analytics/funnels/checkout/stages: die Besucher, die jede Stufe erreicht haben, pro Stunde oder Tag, Checkout-Events eingeschlossen, für das Stufen-Chart. compare_to ergänzt einen zweiten Zeitraum, in denselben Formen wie bei /analytics/query. Reicht der Vergleich vor die Installation eines Shopify-Pixels zurück, zeigt er die Installation als Anstieg.
• POST /organizations/{org_id}/analytics/funnels/checkout/journeys: die Pageviews rund um den Treffer eines Besuchers auf einem Schritt, mit seinen Checkout-events neben pages. Mit full_journey: false enthält pages die Seiten, von denen die Stage-Events kamen. Siehe die Referenz.
• POST /organizations/{org_id}/analytics/visitors nimmt contains_checkout_stage und contains_cart_interaction als Filter, und die Stufe kommt aus Events. Unter der Identität session antwortet er auf contains_checkout_stage mit 422 und lässt outcome, ordered_visitors und checkout_visitors weg. Das Besucher-Detail antwortet mit events neben pages.
• POST /organizations/{org_id}/analytics/events listet die Checkout-Events neben deinen eigenen, neueste zuerst. So kannst du eine Testbestellung gegen die Shopify-Bestellliste halten. Siehe Eigene Events.
• checkout_stage ist auf jedem Analytics-Endpunkt mit filters eine Filter- und Ausschlussdimension (exclude: {checkout_stage: ['']} behält nur Funnel-Pageviews) und in POST /analytics/query eine Gruppierungsdimension. cart_interactions und cart_interaction_errors sind dort Metriken (und damit in Benachrichtigungsregeln nutzbar) sowie Metrikbereiche. POST /analytics/beacons projiziert checkout_stage, die beiden Zähler und die Map cart_interaction_kinds auf jede Zeile.

WeiterlesenCopy Anchor Link

• Shopify-Checkout messen: das Pixel, seine zwei Erklärungen und was zu prüfen ist.
• Applications: die Felder und wo sie liegen.
• Tracker-Einstellungen: die zwei Einstellungen, von denen der Funnel abhängt.
• Besucher und Sessions: die Identität, über die der Funnel gruppiert.