Shopify Server-Side Tracking mit Stape: Die komplette Anleitung (inkl. der Sandbox-Fallen, die alle anderen übersehen)

Warum Shopify schwerer ist als ein normaler Server-Side-Stack

Server-Side Tracking als solches ist 2026 keine Streitfrage mehr. Third-Party-Cookies sind in Safari und Firefox standardmäßig tot, in Chrome hat Google sie nach dem Rückzieher von 2024/25 behalten. Heißt für dich: kein sauberer Cookie-Tod, sondern ein fragmentierter Browser-Mix, in dem rund die Hälfte deiner Besucher schon cookieless unterwegs ist und der Rest an Consent hängt. Safari ITP setzt zusätzlich Client-Side-Cookies nach sieben Tagen zurück, Meta CAPI und Google Enhanced Conversions funktionieren server-seitig messbar besser. Den allgemeinen Fall haben wir in Server-Side Tracking mit stape.io auseinandergenommen, inklusive der Kostenfrage Stape Cloud gegen GCP. Lies den zuerst, wenn dir das Warum noch fehlt.

Shopify ist ein Sonderfall. Der Grund ist die Custom-Pixel-Sandbox: Shopify isoliert deinen Tracking-Code seit Checkout Extensibility in einem iframe mit sandbox-Attribut. Das ist Absicht, es schützt den Checkout vor fremdem JavaScript. Es bricht aber fast jede Tracking-Annahme, die aus der klassischen GTM-Welt stammt.

Dazu kommt ein hartes Datum. Shopify hat checkout.liquid und das Feld Additional Scripts in den Ruhestand geschickt. Für Basic-, Shopify- und Advanced-Stores feuert beides ab dem 26. August 2026 nicht mehr. Web Pixels über Einstellungen, Kundenereignisse sind der einzige unterstützte Weg, um aus dem Checkout heraus Events zu schicken. Wer noch Code im alten Feld kleben hat, verliert ihn an diesem Stichtag.

Diese Anleitung dokumentiert ein reales Setup. Anonymisiert: ein DACH-MedTech-Shop, der medizinische Geräte verkauft, mit Paid Search und Meta als Haupt-Kanälen. Die Befunde sind echt. Die IDs und Domains sind Platzhalter (GTM-XXXXXXX, sst.example.com, G-XXXXXXXXXX).

Die Architektur: drei Laufzeiten, nicht zwei

Die meiste Verwirrung bei Shopify-plus-Stape kommt aus einem einzigen Missverständnis. Leute denken in zwei Schichten, Browser und Server. In Wahrheit hast du drei Laufzeiten.

• Storefront-GTM über die theme.liquid. Lädt auf den Shop-Seiten (Produkt, Kollektion, Cart), idealerweise über den Stape Custom Loader mit obfuskiertem Pfad und Cookie Keeper. Das ist deine normale GTM-Laufzeit mit eigenem window und eigenem dataLayer.
• Custom-Pixel-GTM in der Sandbox. Lädt eine eigene GTM-Instanz desselben Containers, abgeschottet im iframe. Eigenes window, eigener dataLayer. Hier läuft der ganze E-Commerce- und Checkout-Funnel.
• Stape sGTM unter eigener Domain (sst.example.com). Der eine Server-Endpoint, an den beide Browser-Laufzeiten schicken und der von dort an GA4, Meta CAPI und Google Ads verteilt.

Der entscheidende Satz: Storefront-GTM und Pixel-GTM sind dasselbe Container, aber zwei vollständig getrennte Laufzeiten. Ein dataLayer.push in der Storefront ist für den Pixel unsichtbar und umgekehrt. Wer das einmal verinnerlicht hat, versteht plötzlich, warum die Hälfte seiner Tags „manchmal" feuert.

Schritt 1: sGTM plus eigene Domain bei Stape

Der Server ist der einfache Teil. Du legst bei stape.io einen Server-Container an, verbindest ihn mit deinem Web-Container und richtest eine eigene Subdomain ein, hier sst.example.com. Stape liefert die EU-DPA und das Hosting in Frankfurt out-of-the-box, der Setup dauert eine halbe Stunde.

Zwei Schalter, später entscheidend. Aktiviere den Cookie Keeper und den Custom Loader. Der Cookie Keeper schreibt First-Party-Cookies serverseitig per Set-Cookie, sie leben dadurch 400 Tage statt der sieben Tage, die ITP übrig lässt. Der Custom Loader verteilt das GTM-Skript über deine eigene Domain mit obfuskiertem Pfad, damit Adblocker es nicht an googletagmanager.com erkennen. Stape-Doku hat die Details, sie sind nicht der spannende Teil.

Eine ehrliche Grenze: Die 400 Tage gelten nicht überall. Safari ITP kappt server-gesetzte Cookies wieder auf sieben Tage, sobald es CNAME-Cloaking erkennt, also eine First-Party-Subdomain, die per CNAME auf einen Drittanbieter wie Stape zeigt. Auf Safari-lastigen Shops prüf dein DNS-Setup. Erst wenn die Subdomain nicht als Cloaking erkannt wird, hältst du die langen Laufzeiten auch dort.

Schritt 2: Web-GTM in der theme.liquid

Für die Storefront bindest du GTM klassisch ein, aber über den Stape Custom Loader. Der Snippet gehört als Erstes in den <head>, gerendert aus einer eigenen gtm-head.liquid:

<!-- snippets/gtm-head.liquid -->
<script>
  (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push(
    {'gtm.start': new Date().getTime(), event:'gtm.js'});
   var f=d.getElementsByTagName(s)[0],
       j=d.createElement(s);j.async=true;
   j.src='https://sst.example.com/abc123.js?id='+i;
   f.parentNode.insertBefore(j,f);
  })(window,document,'script','dataLayer','GTM-XXXXXXX');
</script>

Die Falle hier ist banal und kostet trotzdem Wochen. Viele Themes haben zwei Layout-Dateien, theme.liquid und etwa ein theme-alt.liquid für bestimmte Templates. Wer den Snippet nur in eine packt, hat auf der Hälfte der Seiten kein GTM, und die Lücke zeigt sich nur auf genau den Templates, die das zweite Layout nutzen. Render den Snippet in beide.

Schritt 3: Der Custom Pixel, das Herzstück

Hier entscheidet sich alles. Shopify bietet in seinem App-Ökosystem einen bequemen Weg: die Stape-App hat eine Checkbox „Add ecommerce DataLayer events", die dir einen Pixel generiert. Bequem, und in zwei Punkten gefährlich.

Warum der App-generierte Pixel nicht reicht

Der generierte Pixel macht zwei Dinge, die du nicht willst. Er fetcht seinen eigentlichen Tracking-Code zur Laufzeit von sp.stapecdn.com und abonniert die Shopify-Events erst, nachdem dieser Netzwerk-Roundtrip aufgelöst ist. Das erzeugt zwei Fehlermodi.

Erstens eine Race-Condition. Ein schneller Add-to-Cart feuert, bevor der Subscriber überhaupt existiert. Shopify spielt Events nicht an spät registrierte Subscriber nach, das Event ist verloren. Zweitens eine externe Abhängigkeit. stapecdn.com steht auf Adblock-Listen, ein blockierter fetch heißt null Events.

Das Symptom in echten Daten ist unverwechselbar: mehr Käufe als Add-to-Carts, ein invertierter Funnel. Der Kauf feuert auf einer ruhigen Danke-Seite, wo der fetch in Ruhe durchläuft. Der Add-to-Cart feuert bei einer schnellen Storefront-Interaktion, wo das Rennen verloren geht. Genau dieses Muster fanden wir im MedTech-Shop.

Die Lösung ist ein selbstständiger Pixel, der seinen kompletten Code inline trägt und alle Subscriptions synchron beim Start registriert:

// Alle Subscriptions SYNCHRON beim Init, kein fetch davor.
analytics.subscribe('product_added_to_cart', (event) => {
  pushToGtm('add_to_cart', mapCartLine(event));
});
analytics.subscribe('checkout_completed', (event) => {
  pushToGtm('purchase', mapOrder(event));
});
// ... alle weiteren Events direkt hier, nichts wird nachgeladen.

Falle 1: die iframe-URL in GA4

In der Sandbox liefert event.context.document.location die URL des iframes, nicht die der Shop-Seite. Das Symptom siehst du in GA4 Realtime als Seitenpfade wie /web-pixels@.../sandbox/modern/products/.... Deine ganze Seiten-Dimension ist Müll.

Der Fix steht in Shopifys eigener Doku: nimm event.context.window.location für die echte Top-Frame-URL. Dasselbe gilt für init.context.window.location. document.title und document.referrer bleiben korrekt auf document, die musst du nicht anfassen.

// Falsch: liefert die Sandbox-iframe-URL
const badUrl = event.context.document.location.href;

// Richtig: echte Top-Frame-URL der Shop-Seite
const pageUrl = event.context.window.location.href;
const pagePath = event.context.window.location.pathname;

Falle 1b: Click-IDs in der Sandbox (gclid, wbraid, gbraid, fbclid)

Dieselbe iframe-Falle trifft deine Klick-IDs. Liest du die URL über document.location, bekommst du die Sandbox-URL ohne deine echten Query-Parameter. Für gclid/wbraid/gbraid (Google Ads), fbclid → fbc (Meta) und ttclid (TikTok) brauchst du den Top-Frame:

const params = new URLSearchParams(event.context.window.location.search);
const gclid  = params.get('gclid') ?? params.get('wbraid') ?? params.get('gbraid');
const fbclid = params.get('fbclid');

Ohne diese IDs sinkt deine Enhanced-Conversions- und CAPI-Match-Qualität, und Smart Bidding bekommt weniger Signal als es könnte. In der Praxis legst du die IDs beim ersten Pageview in einen First-Party-Cookie (server-seitig via Cookie Keeper), damit sie beim Kauf auf der Danke-Seite noch da sind.

Falle 2: der Cookie-SecurityError, die kaputte Attribution

Die teuerste Falle. In der Sandbox wirft jeder Zugriff auf document.cookie einen SecurityError. Dein Pixel-GTM kann damit das _ga-Cookie nicht lesen, prägt pro Kauf eine frische zufällige client_id und erzeugt verwaiste Sessions. Das Ergebnis in GA4: Käufe landen unter (direct) oder (unassigned), Transaktionen wirken „verschwunden", obwohl sie ankamen.

Der Fix nutzt die sandbox-sichere Browser-API. browser.cookie.get() läuft asynchron im Top-Frame und liefert dir die echten GA-Cookies. Du liest _ga und _ga_<MEASUREMENT_ID>, ziehst client_id und session_id heraus und pushst sie in den dataLayer, wo der GA4-Tag sie konsumiert. Der Handler muss async sein, sonst akzeptiert der Editor das await nicht.

analytics.subscribe('checkout_completed', async (event) => {
  const ga = await browser.cookie.get('_ga');               // GA1.1.123.456
  const clientId = ga ? ga.split('.').slice(-2).join('.') : undefined;
  const gaSession = await browser.cookie.get('_ga_G_XXXXXXXXXX');
  pushToGtm('purchase', {
    ...mapOrder(event),
    client_id: clientId,
    session_id: parseGaSession(gaSession).session_id,
  });
});

Vorsicht beim Session-Cookie: Es gibt zwei Formate, GS1.1.<sid>.<n>.… (neuer, punktgetrennt) und GS2.1.s<sid>$o<n>$… (älter). Ein einfaches split('.')[2] trifft nur das erste und liefert beim zweiten Müll. Parse formatunabhängig, wie der Handler oben über parseGaSession:

function parseGaSession(raw){
  if(!raw) return {};
  const m = raw.match(/^GS1\.1\.(\d+)\.(\d+)\./);          // Punkt-Format
  if(m) return { session_id: m[1], session_number: m[2] };
  return {                                                 // $-Format
    session_id:     (raw.match(/s(\d+)\$/)  || [])[1],
    session_number: (raw.match(/\$o(\d+)/)  || [])[1]
  };
}

Eine ehrliche Grenze: Secure-Cookies bleiben auch über diese API unlesbar, das ist eine Browser-Regel, kein Stape-Problem. Für _ga reicht es trotzdem.

Falle 2b: der Cross-Domain-Bruch bei Shop Pay und Express

browser.cookie.get('_ga') rettet die Attribution nur, solange der Checkout auf deiner Domain abschließt. Shop Pay und die Express-Buttons schließen auf shop.app bzw. pay.shopify.com ab, dort ist dein _ga-Cookie nicht lesbar, der Fallback greift ins Leere, und der Kauf feuert wieder ohne client_id. In echten Daten ist das der Grund, warum kein einziger Shop-Pay-Kauf sauber attribuiert ankommt: Käufe landen unter (not set)/(direct).

Der Fix: Identität nicht aus dem Cookie lesen, sondern als Cart-Attribut mitschicken. Auf der Storefront schreibst du client_id/session_id (plus den Consent-Status) per /cart/update.js in attributes. Die reisen mit der Bestellung über die Domain-Grenze und landen als checkout.attributes im Pixel und als order.note_attributes im Webhook.

// Storefront (Theme, nach Analytics-Consent): Identität in den Warenkorb schreiben
fetch('/cart/update.js', {
  method: 'POST', headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ attributes: {
    _ga_client_id:  clientIdFromGa(),     // aus _ga
    _ga_session_id: sessionIdFromGa(),    // aus _ga_G_XXXXXXXXXX
    _consent_analytics: analyticsGranted ? 'granted' : 'denied'
  }})
});

// Pixel: Attribut zuerst, Cookie nur als Fallback
function readAttr(checkout, key){
  return (checkout.attributes || []).find(a => a.key === key)?.value;
}
const clientId = readAttr(checkout, '_ga_client_id')
  || (await browser.cookie.get('_ga'))?.split('.').slice(-2).join('.');

Ehrliche Rest-Grenze: Ein Express-Button direkt von der Produktseite, der den persistenten Warenkorb überspringt, trägt das Attribut nicht, diese Bestellungen rettest du nur noch über den Webhook (Count, ohne Session). Standard-Cart- und Dynamic-Checkout-Flows sind vollständig abgedeckt.

Fallen 3 bis 6, kürzer

Das doppelte page_view. Steht im Google-Tag „send page view on load" an, feuert GA4 ein eigenes page_view mit der Sandbox-URL, unabhängig von deinem Handler. Schalt das automatische page_view ab und treib es aus deinem eigenen page_view-Event.

localStorage. Zugriff darauf kann in der Sandbox werfen. Kapsel jeden Zugriff mit typeof plus try/catch, sonst stirbt dein ganzer Handler an einer Zeile.

Der Typechecker im Editor. Der Pixel-Editor prüft statisch und lehnt Felder ab, die in Shopifys Doku stehen, aber nicht in seinen Typdefs (etwa checkout.payment.paymentMethod). Der Editor gewinnt. Für den Zahlungsanbieter nimmst du transactions[].gateway, das paymentMethod-Feld existiert erst seit Checkout Extensibility.

PII im Legacy-Checkout. Vor Checkout Extensibility entfernt Shopify E-Mail, Telefon und Name aus checkout_completed, deine user_data-Hashes sind leer und CAPI plus Enhanced Conversions matchen schlecht. Das ist kein Pixel-Bug, das ist ein Shopify-seitiges Upgrade auf Checkout Extensibility.

Auf den neuen, upgegradeten Danke- und Bestellstatus-Seiten dreht sich das: Mit der richtigen Pixel-Berechtigung und gesetztem Marketing-Consent liefert checkout_completed wieder E-Mail und Telefon. Genau das ist der Hebel, du hashst sie (SHA-256, normalisiert) für Google Enhanced Conversions und Metas Advanced Matching und holst die Match-Qualität zurück, die der Legacy-Checkout dir genommen hat. Ohne Consent bleibt das Feld leer. Kein Bug, sondern die DSGVO-Grenze.

Schritt 4: volle GA4-Event-Abdeckung

Fast jedes Shopify-Customer-Event mappt auf ein GA4-Standard-Event. Die Zuordnung:

Zwei Standard-Events fehlen bewusst: checkout_contact_info_submitted und checkout_address_info_submitted haben kein GA4-Standard-Pendant. Brauchst du sie für Funnel-Schritte, schick sie als Custom-Events, nicht als erzwungenes add_*.

Vier nützliche Events sind keine nativen Shopify-Customer-Events: select_item, view_promotion, add_to_wishlist brauchen ein Shopify.analytics.publish() aus dem Theme, refund kommt nur über einen Webhook (dazu gleich).

Auf Item-Ebene füllst du affiliation, den per-Item-discount und item_category aus product.type. Achtung vor der Daten-Hygiene-Falle: ist das Feld Produkttyp im Shop leer, steht in GA4 bei allen Produkten „Uncategorized". Das fixt kein Code. Das ist Merchandising-Arbeit im Shopify-Admin.

Deduplizierung: Browser- und Server-Event sind dasselbe Event

Sobald derselbe Kauf client-seitig aus einem Container und server-seitig aus dem sGTM rausgeht, zählst du ihn doppelt. Drei Plattformen, drei Dedup-Schlüssel, die du explizit setzen musst:

• Meta CAPI: Pixel- und CAPI-Event brauchen dieselbe event_id. Setz sie auf die Order-ID und gib sie in beiden Pfaden mit. Fehlt der Match, bläht Meta deine Conversions auf, und das Bidding optimiert auf Phantome.
• GA4: dedupliziert über transaction_id. Für denselben Kauf nie zwei verschiedene IDs aus Browser und Server schicken.
• Google Ads / Enhanced Conversions: dedupliziert über die Order-ID plus die gehashten user_data. Inkonsistente IDs zwischen den Pfaden killen den Match.

Der saubere Weg: eine Quelle der Wahrheit für die Order-ID, in allen Pfaden identisch durchgereicht. Ob die Zahlen am Ende zusammenpassen, prüfst du mit der Bestellzahl-Abstimmung aus dem QA-Teil oder einem schnellen Measurement Health Check.

Zwei Stolpersteine bei der transaction_id:

• Kein Token-Fallback. Nutze ausschließlich checkout.order.id. Ein Fallback auf checkout.token erzeugt einen Schlüssel, der gegen den Server-Webhook und Googles native S2S nicht dedupliziert, also Doppelzählung.
• Order-ID ≠ Bestellnummer. Der Pixel sendet die interne Order-ID (z. B. 7837775790422), nicht die sichtbare Bestellnummer (#1660075). Beim Abgleich Shopify↔GA4 musst du auf der Order-ID joinen (Admin-URL-Slug bzw. legacyResourceId in der GraphQL-API), sonst sieht die Abstimmung kaputt aus, obwohl sie stimmt.

Schritt 5: Bundles, Refunds, Consent

Bundles (Bundler – Product Bundles). Komponenten-Positionen teilen sich ein _bundler_id als Line-Property. Für GA4 kollabierst du sie zu einem Item: Nettopreis gleich Brutto minus zugeordnetem Rabatt, Menge 1, der Umsatz bleibt sauber abgestimmt. Prüf pro App-Version drei Annahmen: den Property-Key, wo die Rabatt-Allokation sitzt, und das Mengenverhalten bei mehreren Bundles im Warenkorb.

Refunds. Erstattungen passieren im Shopify-Admin, wo kein Pixel läuft. Du routest orders/paid plus das Refund-Event über den Webhook-Tab in Stape zu einem Data Client im sGTM und schickst von dort ein GA4-refund-Event plus einen Meta-CAPI-Backup. Dedupliziere mit event_id gleich Order-ID über Browser- und Webhook-Pfad, sonst zählst du doppelt.

Consent, der DACH-kritische Teil. OneTrust oder Usercentrics setzen Consent Mode v2 in der richtigen Reihenfolge: default vor GTM, update auf die Wahl. Der Storefront-Banner regiert aber nicht über den Sandbox-Pixel. Das Consent-Gating für Pixel-Events gehört in die CMP plus Consent Mode innerhalb der Sandbox, oder server-seitig in den sGTM. Wie das im Detail aussieht, steht in Consent Mode v2 in der Praxis und Usercentrics mit Server-Side GTM.

Ein Detail, das in der Sandbox oft untergeht: Der Pixel bekommt Shopifys eigenes Consent-Signal über api.customerPrivacy bzw. init.customerPrivacy (analytics, marketing, preferences, sale_of_data). Das ist nicht automatisch derselbe Status wie in deiner CMP (Usercentrics, OneTrust). Leg eine Quelle der Wahrheit fest. In der DACH-Praxis regiert die CMP, und du spiegelst ihren Status in Shopifys Customer Privacy API, damit Shopify selbst keine Events sendet, die dein Banner gerade abgelehnt hat. Prüf beide Seiten, sonst feuert es doppelt oder gar nicht.

Die ehrliche Grenze, die jeder DACH-Shop kennen muss: Server-Side modelliert keine abgelehnten Conversions. Bei hohen DE-Ablehnungsraten erklärt das einen Teil der vermeintlich „fehlenden" Käufe, aber Vorsicht mit der Gewichtung. In genau diesem Shop fehlten bei einem Wochenend-Abgleich 38 von 60 Käufen in GA4, und die Lücke lag nicht am Consent: Die fehlenden Bestellungen häuften sich auf (none)-Referrer und Cross-Domain-Abschlüsse (Shop Pay, Express), nicht auf abgelehnten Sessions. Der größere Teil der Lücke ist also wiederherstellbar, Cross-Domain-client_id über Cart-Attribute (Falle 2b) plus serverseitiger Kauf aus orders/paid. Nur der echte Ablehnungs-Rest ist die harte, rechtliche Grenze. Wer die ganze Lücke auf Consent schiebt, lässt messbare Käufe liegen.

Schritt 6: Custom Dimensions, die echten Mehrwert bringen

Über die Standard-Events hinaus lohnen sich ein paar Custom Dimensions. Sie sind die Schicht, die aus „wir messen Käufe" ein „wir verstehen, wer kauft" macht.

Zwei Hinweise aus der Praxis. customer_type aus dem Bestellobjekt ist nur für eingeloggte Kunden verlässlich, Gäste haben keine Historie. Genau dafür ist buyer_type über einen eigenen First-Party-Cookie der robustere Weg, er funktioniert auch beim Gast-Checkout.

Jede Dimension musst du in GA4 registrieren (Admin, Custom Definitions) und als dataLayer-Variable in GTM anlegen. Der Scope ist nicht egal:

Eine harte Grenze, die viele erst im Livebetrieb merken: GA4 erlaubt maximal 10 item-scoped Custom Dimensions. Plan sie bewusst, bevor du sie verbrennst.

QA: wie du beweist, dass es zählt

Ein Setup ist erst fertig, wenn du seine Korrektheit zeigen kannst. Drei Methoden.

rmDebug in der Konsole. Bau in den Pixel einen Debug-Schalter, der jedes gemappte Event vor dem Push in die Konsole loggt. Du schaltest ihn per Cookie oder Query-Parameter, nicht für alle Besucher.

Frame-Switching in den DevTools. Stell die Konsole bewusst auf den sandbox-Frame um (Dropdown oben links). Nur dort siehst du den dataLayer des Pixels. Im Top-Frame inspizierst du ins Leere.

Die Bestellzahl-Abstimmung. Der wichtigste Test. Nimm einen festen Zeitraum, zähl die bezahlten Bestellungen im Shopify-Admin und stell sie den purchase-Events in GA4 (DebugView und Reports) gegenüber. Liegt die Differenz unter deiner bekannten Consent-Ablehnungsrate plus ein paar Prozent, ist das Setup gesund. Klafft sie weiter auf, hast du noch ein Leck. Join dabei auf der internen Order-ID, nicht auf der Bestellnummer (siehe Dedup-Abschnitt), sonst vergleichst du zwei verschiedene Schlüssel.

„Warum nicht einfach die Google- & Meta-App von Shopify?"

Berechtigte Frage. Shopifys Google & YouTube-App und die Meta-App sind seit Checkout Extensibility kompatibel und installieren GA4-E-Commerce-Events kostenlos. Für einen kleinen Shop ohne nennenswertes Paid-Budget reicht das oft.

Was die nativen Apps nicht geben:

• Keine eigene Kontrolle über Meta CAPI (Event-Qualität, Dedup, Advanced Matching, eigene event_id).
• Server-seitige First-Party-Cookies fehlen, also kein Schutz gegen ITP und Adblocker.
• Consent Engineering endet an der CMP, kein server-seitiges Consent-Gating.
• Begrenzte Custom Dimensions, keine Anreicherung (buyer_type, customer_type, payment_type).
• Eine Blackbox, die du im Fehlerfall weder debuggen noch erweitern kannst.

Update Juli 2026. Google rollt für Stores mit der Google-&-YouTube-App eine native Server-zu-Server-Verbindung aus, die den purchase direkt aus Shopifys Backend an die GA4-API schickt, opt-out, automatisch. Das hebt die Anzahl (es fängt die nie zurückgekehrten Käufe), aber nicht die Attribution: session_start und add_to_cart bleiben browserseitig, der Kauf landet oft als (not set)/(direct). Es respektiert deine CMP nicht (Shopify hält keinen Consent-State) und füttert nur Googles Ökosystem, kein Meta CAPI. Für einen DACH-MedTech-Shop heißt das: nett als Backstop, kein Ersatz für den sGTM-Stack, der Attribution, Consent-Gating und Meta zusammen liefert. Entscheide vor Juli, welche Quelle kanonisch ist (Empfehlung: der consent-gegatete Webhook), sonst kollidieren drei Purchase-Quellen auf demselben Schlüssel.

Faustregel: native App, solange Tracking ein Nebenschauplatz ist. Eigener sGTM-Stack, sobald Paid Media den Umsatz trägt und die Datenqualität über das Bidding entscheidet.

Das ist viel. Hier ist die Abkürzung.

Die QA-Checkliste oben kannst du direkt benutzen, sie ist frei. Was Wochen spart, ist das fertige Skript.

Diese Anleitung bringt dich auf rund 90 %. Die letzten 10 %, Consent-Edge-Cases, CAPI-Match-Quality-Monitoring, gclid-Restore und die Abstimmung, die beweist, dass es trägt, sind die Stelle, an der die meisten Setups still lecken. Genau das ist unser Audit. Im selben Setup, das diese Anleitung dokumentiert, haben wir den Anteil „Direct Traffic" von 30 % auf 5 % gedrückt, weil Sessions wieder ihre echte Quelle behalten.

Zwei Wege, je nach Bindung:

• Audit Sprint anfragen wenn du willst, dass wir es auf deinem Store installieren und nachweisbar abstimmen.
• 30-Minuten-Intro wenn du erst sortieren willst, wo dein Tracking heute steht.