Track
E-Commerce-TrackingTutorialFortgeschrittene

Shopify-Tracking, das den gehosteten Checkout übersteht: Web Pixel, verifizierte Bestell-Webhooks und Pairing über die Bestellnummer

Warum ein Theme-Skript Shopifys Checkout nicht sieht, wie die Track-Web-Pixel-Extension und signierte orders/paid-Webhooks zusammenspielen, was der Collector verifiziert und wie der Server-Kauf Consent und Click-IDs des Kunden erbt.

Von
Track-Redaktion
Veröffentlicht
Zuletzt fachlich geprüft
Lesedauer
3 Min. Lesezeit

Das Wichtigste in Kürze

  • Shopify hostet den Checkout, ein Theme-Skript sieht den Kauf also nicht; die Web-Pixel-Extension deckt die Browser-Seite ab und liest den Consent aus der Customer Privacy API.
  • orders/paid- und refunds/create-Webhooks werden über HMAC-SHA256-Signatur und Shop-Domain verifiziert und zu source-verifizierten purchase- und refund-Events mit deterministischen IDs.
  • Der Router paart den Server-Kauf über die Bestellnummer mit dem Browser-Kauf, sodass er Consent-Eintrag, anonyme ID, Click-IDs und gehashte Kennungen erbt.
  • Ohne Browser-Kauf bleibt der Server-Datensatz operativ und erreicht nie Werbeplattformen — ein zahlender Kunde gilt nicht automatisch als eingewilligt.

Die Einschränkung

Shopifys Checkout- und Danke-Seiten werden von Shopify gehostet. Ein Skript in theme.liquid läuft im Storefront, aber nicht dort — ein reines Theme-Setup verpasst den Kauf oder stützt sich auf das abgekündigte Feld für zusätzliche Skripte. Zwei Dinge ersetzen es:

  1. Eine Web-Pixel-Extension — sandboxed Code, den Shopify auf jeder Seite inklusive Checkout ausführt, mit Zugriff auf die Standard-Kundenevents und die Customer Privacy API.
  2. Bestell-Webhooks — Shopify sendet die Bestellung an deinen Endpunkt, sobald sie bezahlt ist, signiert mit einem Secret, das nur du und Shopify kennen.

Track liefert beides: integrations/shopify/web-pixel und einen verifizierenden Empfänger im Collector.

Das Web Pixel

Das Pixel abonniert page_viewed, product_viewed, product_added_to_cart, checkout_started, payment_info_submitted und checkout_completed, bildet sie auf die Standard-Events ab und sendet sie an den Browser-Endpunkt des Collectors. Den Consent liest es aus Shopifys Customer Privacy API: analyticsProcessingAllowed wird zum Zweck Analytics, marketingAllowed zum Zweck Marketing, und ein visitorConsentCollected-Update ändert spätere Events. Aus der Sandbox wird nichts an Anbieter-Tags gespiegelt; Anbieter erhalten Events serverseitig über die konfigurierten Destinationen.

Das Event checkout_completed trägt die Shopify-Bestellnummer. Genau sie macht den nächsten Schritt ehrlich.

Der verifizierte Webhook

Im Shopify-Admin legst du unter Einstellungen → Benachrichtigungen → Webhooks orders/paid und refunds/create auf die Webhook-URL der Verbindung an — eine URL, die für deine Site eindeutig ist und ein nicht erratbares Token trägt. Shopify signiert jede Zustellung mit X-Shopify-Hmac-Sha256, dem base64-kodierten HMAC-SHA256 des rohen Bodys unter dem Signatur-Secret, das unter der Webhook-Liste steht. Dieses Secret speicherst du im Tresor von Track; der Collector berechnet den HMAC neu, vergleicht in konstanter Zeit und prüft zusätzlich X-Shopify-Shop-Domain gegen die verbundene Domain.

Ein akzeptiertes orders/paid wird zu einem purchase mit source: shopify und source_verified: true: Bestellnummer, Währung, Summen, Steuern, Versand, Gutscheincode, Positionen mit Varianten-IDs sowie E-Mail, Telefon und Adresse des Kunden als rohe Matching-Daten, die der Router hasht. orders/create wird nur akzeptiert, wenn die Bestellung bereits bezahlt ist; refunds/create wird zu einem refund mit den erstatteten Transaktionsbeträgen. Wiederholte Zustellungen ergeben dieselbe deterministische Event-ID und werden von der Dedup-Sperre verworfen.

Pairing über die Bestellnummer

Der Webhook weiß nichts über Consent. Der Kauf des Pixels schon. Trifft der Server-Kauf ein, sucht der Router einen Browser-Kauf mit derselben Bestellnummer aus den letzten 30 Tagen und lässt das Server-Event, wenn es einen findet, dessen Consent-Eintrag, anonyme ID, Click-IDs und gehashte Kennungen erben — mit einer Provenienz, die den Consent als vom Browser-Event abgeleitet markiert. Der verifizierte Server-Datensatz ersetzt dann die Browser-Beobachtung in der Conversion-Tabelle, und beide Events werden geroutet: Anbieter, die über die Event-ID deduplizieren, erhalten purchase:<Bestellnummer> von beiden Wegen und zählen einmal.

Gibt es keinen Browser-Kauf — der Kunde hat abgelehnt oder das Pixel blockiert — wird der Server-Kauf als operativer Datensatz gespeichert und erreicht nur Destinationen, die keinen Consent brauchen. Er wird nie unter der Annahme an Werbeplattformen gesendet, ein zahlender Kunde müsse wohl eingewilligt haben.

Einrichtung

  1. Site → Shop-Verbindung → Shopify: dein-shop.myshopify.com eintragen, speichern, Webhook-URL kopieren.
  2. Die beiden Webhooks im Shopify-Admin im JSON-Format anlegen; das Signatur-Secret in die Verbindung kopieren.
  3. Die Web-Pixel-Extension mit deiner Tracking-ID deployen (und einem First-Party-Collector-Host, falls du einen nutzt).
  4. Eine Testbestellung aufgeben. Die Verbindung zeigt nach dem ersten verifizierten Webhook verbunden; der Event-Debugger zeigt den Pixel-Kauf und den shopify-Kauf mit derselben Bestellnummer, und der Destination-Monitor eine Zustellung je Destination und Weg.

Was du monatlich prüfst

  • Signaturfehler im letzten Fehler der Verbindung: ein in Shopify rotiertes Secret ohne Aktualisierung des Tresors.
  • Bestellungen mit Server-Kauf, aber ohne Browser-Kauf: Der Anteil zeigt, wie viele Kunden ablehnen oder blockieren — und ist die Obergrenze für die Werbe-Attribution.
  • Erstattungsabdeckung: refunds/create muss abonniert sein, sonst driften Anbieterwerte nach oben.

Primärquellen

Dokumentationen und Standards, auf denen dieser Artikel beruht.

  1. Shopify — Web Pixels APIshopify.dev
  2. Shopify — Webhooks: Webhook verifizierenshopify.dev

War dieser Artikel hilfreich?

Fachlich verantwortlich

Track-Redaktion

Produkt & Engineering

Die Menschen hinter Track: Engineers und Analysts, die täglich an Server-Side Tracking, Consent-Tooling und Connector-Integrationen arbeiten.