Skip to content
Startseite Guides Analytics
Analytics Fortgeschritten

Tracking-Differenzen zwischen Google Analytics und Shopify beheben

Schritt-für-Schritt-Anleitung, um Datendiskrepanzen zwischen Google Analytics 4 und Shopify-Berichten zu finden und zu beheben: Ursachen, Abgleich auf Bestellebene, ein Kaufpfad im Browser, Serverpfad über Webhook und Measurement Protocol, GA4-Einstellungen und Test.

Fabian Weiss, Gründer von FW Delta Fabian Weiss
8 Min. 2 bis 4 Stunden
Das Problem

Umsatz- und Conversion-Daten stimmen nicht zwischen GA4 und dem Shopify-Backend überein und niemand kann sagen, welcher Teil der Differenz normal ist

Die Lösung

Differenz auf Bestellebene messen, genau einen Kaufpfad im Browser betreiben, Käufe und Rückerstattungen per Webhook und Measurement Protocol nachziehen und die GA4-Einstellungen prüfen, die Zahlen verändern

Google Analytics 4ShopifyGoogle Tag Manager

Warum die Zahlen nicht übereinstimmen

Wenn Google Analytics 4 (GA4) und dein Shopify-Umsatzbericht unterschiedliche Zahlen zeigen, ist das zunächst kein Fehler. Die beiden Systeme messen verschiedene Dinge mit verschiedenen Mechanismen. Shopify selbst nennt in der Hilfe zu Analytics-Diskrepanzen Browsererweiterungen, die Google Analytics blockieren, unterschiedliche Zeitzonen, das Zählen von Seiten-Reloads und die Tatsache, dass Google nur Besucher mit aktiviertem JavaScript und Cookies zählen kann.

Eine Restdifferenz bleibt also immer. Das Ziel dieser Anleitung ist keine exakte Übereinstimmung, sondern eine Differenz, die du erklären kannst. Unser Analytics-Team sieht in Shopify-Setups immer wieder dieselben Muster. Hier sind die Ursachen, die du im September 2026 kennen musst.

Typische Symptome

  • GA4 zeigt geringeren Umsatz als das Shopify-Backend
  • Bestellungen erscheinen in Shopify, aber nicht in GA4
  • GA4 zählt einzelne Käufe doppelt oder dreifach
  • Sessions und Conversion-Rate weichen zwischen beiden Systemen ab
  • GA4 meldet Bestellungen, die Shopify nicht kennt, etwa Testbestellungen

Die Ursachen im September 2026

  1. Consent. Shopify wendet die Einwilligung der Besucher auf Pixel an. In Regionen, für die du Einwilligung verlangst, sind nicht notwendige Zwecke laut Shopify standardmäßig nicht erlaubt, bis der Besucher zugestimmt hat (Customer Privacy API). Wer ablehnt, taucht in Shopify als Bestellung auf, in GA4 nicht.
  2. Ad-Blocker, Safari ITP und andere Browserrestriktionen. Shopify nennt Browsererweiterungen ausdrücklich als Grund, warum Sessions und Käufe in Google Analytics fehlen (Analytics-Diskrepanzen). Der Anteil hängt von deiner Zielgruppe ab und ist bei technikaffinem Publikum oft spürbar.
  3. Sandboxed Pixels. App-Pixel laufen laut Shopify in einer strikten Sandbox auf Basis von Web Workern, Custom Pixels in einer laxen Sandbox als iframe mit sandbox-Attribut. Alles, was das DOM ausliest oder beschreibt, funktioniert dort nicht oder nicht gleich (Über Web Pixels). Alte Tracking-Snippets, die in ein Custom Pixel kopiert wurden, feuern deshalb oft still ins Leere.
  4. Die Danke-Seite lädt nicht. checkout_completed wird laut Shopify einmal pro Checkout ausgelöst, typischerweise auf der Danke-Seite. Bei Post-Purchase-Upsells feuert es stattdessen auf der ersten Upsell-Seite. Wenn die Seite nicht lädt, feuert das Ereignis nicht (checkout_completed). Die Bestellung existiert in Shopify trotzdem.
  5. Zusätzliche Skripte und Script Tags sind Geschichte. Seit dem 28. August 2025 ist der Bereich für zusätzliche Skripte in den Checkout-Einstellungen nur noch lesbar, der 26. August 2026 war die Frist für Shops ohne Plus, ihre Danke- und Bestellstatusseiten auf die neue Version umzustellen (Checkout-Upgrade). Script Tags sind ebenfalls abgekündigt: Ab dem 1. Oktober 2026 lassen sie sich nicht mehr anlegen oder ändern, ab dem 1. März 2027 werden sie nicht mehr ausgeliefert (Shopify Changelog). Ein Kauf-Tracking, das noch auf checkout.liquid, zusätzlichen Skripten oder Script Tags beruht, sendet heute nichts mehr.
  6. Doppelzählung. Wenn die Google & YouTube App, ein Custom Pixel und ein GTM-Container denselben Kauf melden, zählt GA4 ihn mehrfach. Google warnt ausdrücklich davor, doppelte Tags zwischen App und Storefront oder Custom Pixel zu betreiben (Google-Tag auf Shopify einrichten).
  7. Unterschiedliche Umsatzdefinitionen. Shopify definiert Gesamtumsatz als Bruttoumsatz minus Rabatte minus Rückabwicklungen plus Steuern plus Zölle plus Versand plus Gebühren; Nettoumsatz ist Bruttoumsatz minus Rabatte minus Rückabwicklungen (Umsatzberichte). GA4 kennt nur den value, den dein Pixel sendet. Seit dem 30. April 2025 enthält checkout.subtotalPrice.amount in Web Pixels außerdem sowohl Produkt- als auch Bestellrabatte, vorher nur Produktrabatte (Shopify Changelog). Ein Pixel, das den Bestellrabatt selbst noch einmal abzieht, meldet seitdem zu wenig.
  8. Rückerstattungen und Stornierungen. Shopify bucht Rückabwicklungen an dem Tag, an dem sie verarbeitet wurden, nicht am Bestelltag. GA4 erfährt davon nur, wenn du ein refund-Ereignis mit derselben transaction_id sendest (E-Commerce-Ereignisse in GA4).
  9. Währung und Steuern. GA4 rechnet Käufe in die Property-Währung um, laut Google auf Basis des Wechselkurses vom Vortag (Währungsreferenz). Ein Shop mit mehreren Präsentationswährungen weicht dadurch strukturell ab. Ob dein Wert Steuern und Versand enthält, entscheidet, welche Shopify-Kennzahl überhaupt vergleichbar ist.
  10. Zeitzonen. Shopify berichtet in der Zeitzone des Shops, GA4 in der Zeitzone der Property. Eine Änderung der Property-Zeitzone wirkt laut Google nur nach vorn und erzeugt eine Delle oder einen Sprung in den Daten (Property einrichten).
  11. Sessions. Shopify hat vom 21. bis 23. September 2026 die Session-Definition umgestellt: Eine Session endet jetzt nach 30 Minuten Inaktivität statt um Mitternacht UTC und Sessions ohne Seitenaufruf werden mitgezählt. Die Conversion-Rate wird aus Sessions berechnet und verschiebt sich dadurch, auch wenn Bestellungen gleich bleiben (Änderungen an Sessions in Shopify Analytics). GA4 nutzt ebenfalls 30 Minuten als Standard, einstellbar bis 7 Stunden 55 Minuten (Sessions in GA4). Gleich ist das trotzdem nicht: Bots, Reloads und Consent werden unterschiedlich behandelt.
  12. Attributionsfenster. GA4 schreibt Schlüsselereignisse mit einem Lookback-Fenster von standardmäßig 90 Tagen zu, einstellbar auf 30 oder 60 Tage; für Akquisitionsereignisse gelten 30 oder 7 Tage (Attributionseinstellungen). Shopify ordnet Umsatz dem Bestelldatum zu. Kanalberichte aus beiden Systemen sind deshalb nie deckungsgleich.
  13. Mehr Seitenaufrufe seit Juli 2025. Web Pixels laden seit dem 21. Juli 2025 auch auf Kundenkonten und der Bestellstatusseite und senden dort page_viewed (Shopify Changelog). Wer Seitenaufrufe pro Bestellung vergleicht, sieht seitdem mehr Aufrufe nach dem Kauf.
  14. Testbestellungen. Testbestellungen über das Test-Gateway oder den Testmodus von Shopify Payments erscheinen laut Shopify nicht in Auszahlungen oder Berichten (Testbestellungen). Pixel feuern trotzdem. GA4 zählt dadurch Käufe, die Shopify nie ausweist.
  15. GA4-seitige Verarbeitung. Schwellenwerte, Reporting-Identität, Datenaufbewahrung und Hostname-Filter verändern, was du in GA4 überhaupt siehst. Dazu unten mehr in Schritt 4.

Wenn du dein Setup mit professionellen Analytics-Implementierungen vergleichst, fällt eines auf: Diese betreiben genau einen Kaufpfad im Browser und einen unabhängigen Serverpfad für den Abgleich. Genau das bauen wir jetzt.


Schritt 1: Die Differenz sauber messen

Bevor du etwas reparierst, brauchst du eine Zahl, die etwas bedeutet.

Gleiche Definition, gleicher Zeitraum, gleiche Zeitzone

  • Zeitraum: Ein abgeschlossener Zeitraum, der mindestens einen Tag zurückliegt. Shopify nennt als möglichen Grund für Abweichungen, dass Google Bestellungen später verarbeitet.
  • Zeitzone: Prüfe, dass Shop-Zeitzone und GA4-Property-Zeitzone übereinstimmen. Wenn nicht, vergleiche ganze Wochen statt einzelner Tage.
  • Kennzahl: Entscheide, was dein value enthält. Enthält er Steuern und Versand, vergleiche mit dem Shopify-Gesamtumsatz. Enthält er nur die Artikelpreise nach Rabatten, vergleiche mit dem Nettoumsatz. In GA4 findest du den Kaufumsatz unter Berichte, Monetarisierung, E-Commerce-Käufe (Bericht E-Commerce-Käufe); die Artikelumsätze dort schließen laut Google Steuern und Versand aus.
Differenz in Prozent = (Shopify-Wert - GA4-Wert) / Shopify-Wert × 100

Auf Bestellebene vergleichen

Die Prozentzahl sagt dir, dass etwas fehlt. Was fehlt, sagt sie nicht. Exportiere deshalb die Bestellnummern aus Shopify für den Zeitraum und stelle sie in einer GA4-Exploration der Dimension Transaktions-ID gegenüber. Drei Listen entstehen:

  • Bestellungen, die in beiden Systemen sind: der gemeinsame Kern
  • Bestellungen nur in Shopify: fehlende Käufe (Consent, Blocker, Danke-Seite nicht geladen)
  • Transaktions-IDs nur in GA4 oder mehrfach in GA4: Testbestellungen oder Doppelzählung

Erst diese Aufteilung sagt dir, welchen der folgenden Schritte du wirklich brauchst. Eine ausführliche Prüfliste für das gesamte Setup findest du in der Shopify Tracking Checkliste.


Schritt 2: Genau ein Kaufereignis im Browser

Google & YouTube App als Standardpfad

Shopify verbindet GA4 heute über die Google & YouTube App (Google Analytics 4 einrichten). Die App sendet die E-Commerce-Ereignisse inklusive purchase selbst und respektiert die Customer-Privacy-Einstellungen des Shops. Für die meisten Shops ist das der richtige Standardpfad, weil er ohne Theme-Code auskommt und Shopify ihn pflegt.

Prüfe danach, dass es wirklich nur diesen einen Pfad gibt:

  1. Shopify Admin, Einstellungen, Kundenereignisse: Liste alle App-Pixel und Custom Pixels. Jedes, das purchase an dieselbe Mess-ID sendet, ist ein Kandidat für Doppelzählung.
  2. Onlineshop, Themes, Code bearbeiten: Suche nach gtag, googletagmanager und G- in Theme-Dateien. Ein Google-Tag im Theme plus die App ergibt zwei Seitenaufrufe pro Seite.
  3. Google Tag Manager: Filtere nach GA4-Tags und prüfe, ob ein Purchase-Tag auf ein Ereignis der Danke-Seite hört. Exportiere den Container als Backup, bevor du etwas löschst.

Google empfiehlt, neue Conversions als primäre Conversions einzurichten und Legacy-Tags zu entfernen, statt beides parallel laufen zu lassen (Google-Tag auf Shopify einrichten).

Custom Pixel, wenn du den Kauf selbst sendest

Wenn du GA4 bewusst über ein Custom Pixel statt über die App betreibst, etwa weil du eigene Parameter brauchst, sieht ein sauberes Kaufereignis so aus. Das Pixel lädt gtag.js innerhalb der Sandbox und hört auf checkout_completed:

const script = document.createElement("script");
script.setAttribute("src", "https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX");
script.setAttribute("async", "");
document.head.appendChild(script);

window.dataLayer = window.dataLayer || [];
function gtag() {
  dataLayer.push(arguments);
}
gtag("js", new Date());
gtag("config", "G-XXXXXXXXXX", { send_page_view: false });

analytics.subscribe("checkout_completed", (event) => {
  const checkout = event.data.checkout;
  gtag("event", "purchase", {
    transaction_id: checkout.order.id,
    value: Number(checkout.totalPrice.amount),
    currency: checkout.currencyCode,
    tax: Number(checkout.totalTax.amount),
    shipping: checkout.shippingLine ? Number(checkout.shippingLine.price.amount) : 0,
    items: checkout.lineItems.map((line) => ({
      item_id: line.variant.product.id,
      item_name: line.title,
      item_variant: line.variant.title,
      price: Number(line.variant.price.amount),
      quantity: line.quantity
    }))
  });
});

Drei Dinge daran sind wichtig:

  • transaction_id ist die Bestell-ID aus checkout.order.id. Google nennt transaction_id als Mittel gegen doppelte Kaufereignisse (GA4-Ereignisreferenz). Derselbe Wert muss später auch im Serverpfad stehen.
  • value ist totalPrice, laut Shopify die Summe aller Preise inklusive Zöllen, Steuern und Rabatten. Wenn du stattdessen subtotalPrice sendest, denk an die Änderung vom 30. April 2025: Der Wert ist bereits netto aller Rabatte.
  • currency kommt aus checkout.currencyCode, nicht aus einer festen Konstante. Ohne Währung kann GA4 laut Google keine korrekten Umsatzkennzahlen berechnen.

Schritt 3: Serverpfad über Webhook und Measurement Protocol

Was der Serverpfad kann und was nicht

Das Measurement Protocol ist laut Google dafür gedacht, die Erhebung über gtag oder Tag Manager zu ergänzen, nicht zu ersetzen. Wer ausschließlich serverseitig sendet, bekommt nur eingeschränkte Berichte. Geografische und Gerätedaten übernimmt GA4 aus der letzten Browser-Interaktion derselben client_id; soll ein Ereignis zu einer bestimmten Session gehören, brauchst du die session_id und musst innerhalb von 24 Stunden nach Session-Beginn senden (Measurement Protocol Übersicht).

Der Serverpfad ist also kein Ersatz für das Pixel. Er ist der Pfad, der Consent, Blocker und nicht geladene Danke-Seiten umgeht und den du für Rückerstattungen ohnehin brauchst. Zwei Regeln:

  • Das api_secret ist laut Google privat und gehört nicht in Client-Code (Ereignisse senden). Der frühere Ansatz, das Measurement Protocol direkt aus der Bestellstatusseite aufzurufen, ist deshalb doppelt tot: Er verrät das Secret und die Skripte laufen dort seit August 2026 ohnehin nicht mehr.
  • Sende Käufe entweder aus dem Browser oder vom Server in die Berichte, nicht beides gleichzeitig mit verschiedenen client_id-Werten. Verlass dich nicht darauf, dass GA4 zwei Käufe mit gleicher transaction_id von zwei verschiedenen Clients zusammenführt.

Ein bewährtes Muster: Der Browser sendet den Kauf, wenn er darf. Der Server schickt alle Rückerstattungen und den Kauf nur für Bestellungen, für die innerhalb einer Frist kein Browser-Kauf angekommen ist. Wer die Prüfung nicht bauen will, nutzt den Serverpfad ausschließlich für Rückerstattungen und den Bestellabgleich.

Client-ID an die Bestellung heften

Damit ein Serverereignis zum richtigen Nutzer gehört, braucht es dieselbe client_id wie das Browser-Tag. Der Weg: Im Theme wird der Wert aus dem _ga-Cookie als Warenkorb-Attribut gespeichert, das Shopify als Notiz-Attribut an die Bestellung hängt (Ajax Cart API). Dieses Snippet gehört in theme.liquid innerhalb eines Script-Elements vor dem schließenden Body-Tag:

(function () {
  const match = document.cookie.match(/_ga=GA\d\.\d\.([^;]+)/);
  if (!match || sessionStorage.getItem("gaClientIdStored")) {
    return;
  }
  fetch("/cart/update.js", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ attributes: { ga_client_id: match[1] } })
  }).then(() => sessionStorage.setItem("gaClientIdStored", "1"));
})();

Das funktioniert nur, wenn das GA4-Tag ein Cookie setzen durfte. Für Besucher ohne Einwilligung gibt es keine client_id und das ist gewollt: Für sie sendet der Server keinen Kauf in die Berichte.

Webhook empfangen und Kauf senden

Lege im Shopify Admin unter Einstellungen, Benachrichtigungen, Webhooks einen Webhook für das Ereignis Bestellzahlung an (Webhooks in Shopify) oder abonniere orders/paid über deine App. Jede Zustellung trägt den Header X-Shopify-Hmac-Sha256, eine Base64-kodierte HMAC-Signatur, mit der du prüfst, dass die Anfrage von Shopify kommt (Webhooks). Der Endpunkt darf nicht auf localhost oder einer Domain des Shops liegen.

Ein minimaler Empfänger in Node, der den Kauf an das Measurement Protocol weitergibt (Measurement Protocol Referenz):

import crypto from "node:crypto";
import express from "express";

const app = express();
const webhookSecret = process.env.SHOPIFY_WEBHOOK_SECRET;
const measurementId = process.env.GA4_MEASUREMENT_ID;
const apiSecret = process.env.GA4_API_SECRET;
const endpoint = `https://www.google-analytics.com/mp/collect?measurement_id=${measurementId}&api_secret=${apiSecret}`;

function verify(req) {
  const digest = crypto.createHmac("sha256", webhookSecret).update(req.body).digest("base64");
  const header = req.get("X-Shopify-Hmac-Sha256") || "";
  return digest.length === header.length && crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(header));
}

function clientIdFromOrder(order) {
  const attribute = (order.note_attributes || []).find((entry) => entry.name === "ga_client_id");
  return attribute ? attribute.value : null;
}

app.post("/webhooks/orders-paid", express.raw({ type: "application/json" }), async (req, res) => {
  if (!verify(req)) {
    return res.sendStatus(401);
  }
  res.sendStatus(200);

  const order = JSON.parse(req.body.toString("utf8"));
  const clientId = clientIdFromOrder(order);
  if (!clientId || order.test) {
    return;
  }

  await storeClientId(order.id, clientId);

  const payload = {
    client_id: clientId,
    events: [{
      name: "purchase",
      params: {
        transaction_id: String(order.id),
        value: Number(order.current_total_price),
        currency: order.currency,
        tax: Number(order.current_total_tax),
        shipping: order.shipping_lines.reduce((sum, line) => sum + Number(line.price), 0),
        items: order.line_items.map((item) => ({
          item_id: String(item.product_id),
          item_name: item.title,
          item_variant: item.variant_title,
          price: Number(item.price),
          quantity: item.quantity
        }))
      }
    }]
  };

  await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });
});

storeClientId ist dein eigener Speicher, etwa eine Tabelle mit Bestell-ID und client_id. Du brauchst ihn gleich für Rückerstattungen. Die Felder id, current_total_price, current_total_tax, currency, note_attributes, shipping_lines und line_items sind in der Order-Ressource dokumentiert; current_total_price ist der aktuelle Gesamtpreis in der Shop-Währung. Für EU-Datenerhebung nennt Google zusätzlich den Endpunkt https://region1.google-analytics.com/mp/collect.

Wenn der Serverkauf nur als Fallback laufen soll, sende ihn nicht sofort. Warte eine festgelegte Zeit und sende ihn nur, wenn die Transaktions-ID bis dahin nicht über die GA4 Data API auftaucht. Wer das nicht bauen will, beschränkt den Serverpfad auf Rückerstattungen und den Bestellabgleich.

Rückerstattungen nachziehen

Für den Webhook refunds/create sendest du ein refund-Ereignis mit derselben transaction_id. Google verlangt currency, transaction_id und value und empfiehlt Artikeldaten für Kennzahlen auf Artikelebene (GA4-Ereignisreferenz). Die Felder order_id, transactions und refund_line_items stehen in der Refund-Ressource:

app.post("/webhooks/refunds-create", express.raw({ type: "application/json" }), async (req, res) => {
  if (!verify(req)) {
    return res.sendStatus(401);
  }
  res.sendStatus(200);

  const refund = JSON.parse(req.body.toString("utf8"));
  const clientId = await loadClientId(refund.order_id);
  if (!clientId) {
    return;
  }

  const successful = refund.transactions.filter((entry) => entry.kind === "refund" && entry.status === "success");
  if (successful.length === 0) {
    return;
  }

  const payload = {
    client_id: clientId,
    events: [{
      name: "refund",
      params: {
        transaction_id: String(refund.order_id),
        value: successful.reduce((sum, entry) => sum + Number(entry.amount), 0),
        currency: successful[0].currency,
        items: refund.refund_line_items.map((entry) => ({
          item_id: String(entry.line_item.product_id),
          item_name: entry.line_item.title,
          quantity: entry.quantity
        }))
      }
    }]
  };

  await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });
});

Stornierungen ohne Zahlung erzeugen keine Rückerstattung. Wenn dein Shop viele davon hat, abonniere zusätzlich orders/cancelled und behandle sie wie eine Rückerstattung über den vollen Betrag.

Payload validieren

Das Measurement Protocol antwortet laut Google mit einem 2xx-Statuscode, sobald die HTTP-Anfrage angekommen ist. Es liefert keinen Fehlercode, wenn die Payload fehlerhaft ist oder GA4 die Daten nicht verarbeitet (Measurement Protocol Referenz). Ein grüner Statuscode beweist also nichts. Google stellt dafür einen Validierungsendpunkt bereit, der dieselbe Payload annimmt und validationMessages zurückgibt (Ereignisse validieren):

curl -X POST "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"client_id":"123.456","events":[{"name":"purchase","params":{"transaction_id":"TEST-1","value":10,"currency":"EUR"}}]}'

Eine leere validationMessages-Liste heißt, die Payload ist formal gültig. Prüfe damit jede Änderung am Serverpfad, bevor sie live geht. Beachte außerdem die Grenzen aus der Referenz: bis zu 25 Ereignisse pro Anfrage, bis zu 25 Parameter pro Ereignis, Rückdatierung über timestamp_micros bis zu 72 Stunden.


Schritt 4: GA4-Einstellungen, die Zahlen verändern

Diese Einstellungen erzeugen Differenzen, die mit Shopify nichts zu tun haben. Prüfe sie unter Verwaltung:

  • Schwellenwerte. GA4 hält Daten zurück, wenn ein Bericht Rückschlüsse auf einzelne Nutzer zulassen könnte, etwa bei demografischen Daten oder kleinen Zeiträumen. Der Bericht zeigt dann den Hinweis, dass Schwellenwerte angewendet wurden (Datenschwellenwerte). Ein größerer Zeitraum kann die Daten wieder sichtbar machen.
  • Reporting-Identität. Die Optionen Kombiniert, Beobachtet und Gerätebasiert entscheiden, wie GA4 Nutzer zusammenführt. Kombiniert und Beobachtet nutzen die User-ID, wenn vorhanden, Gerätebasiert ignoriert alle anderen IDs (Reporting-Identität). Für den Abgleich mit Shopify ist Gerätebasiert die Einstellung, deren Zahlen am wenigsten von Modellierung abhängen.
  • Datenaufbewahrung. Die Einstellung für ereignisbezogene Daten (2 oder 14 Monate, bei 360 länger) betrifft laut Google nur Explorationen und Trichterberichte, nicht die aggregierten Standardberichte (Datenaufbewahrung). Der Bestellabgleich aus Schritt 1 läuft über eine Exploration, funktioniert also nur innerhalb dieses Fensters.
  • Hostname-Filter. Seit dem 11. Juni 2026 kannst du Ereignisse fremder Hostnames per Datenfilter ausschließen, seit dem 21. September 2026 auch eine Allowlist erlaubter Hostnames pflegen. Include-Filter blockieren automatisch Ereignisse ohne Hostname und gelten laut Google nicht für Measurement-Protocol-Ereignisse (Neuerungen in Google Analytics). Gefilterte Daten sind dauerhaft weg, teste den Filter deshalb zuerst im Testmodus (Datenfilter). Wer Käufe aus einer Staging-Domain oder Spam-Hits in seinem Umsatz hat, löst das hier.
  • Consent und Google Ads. Seit dem 15. Juni 2026 steuert allein der Consent Mode, welche Werbedaten von GA4 an ein verknüpftes Google-Ads-Konto fließen; der Google-Signals-Schalter regelt nur noch die Verknüpfung mit angemeldeten Nutzern für Verhaltensberichte (Änderungen an den Datenkontrollen). Wenn Käufe in GA4 stimmen, in Google Ads aber fehlen, liegt es seitdem an ad_storage und ad_user_data, nicht an Google Signals.
  • Session-Timeout, Währung, Zeitzone. Siehe Ursachen 9 bis 11. Ändere Währung und Zeitzone nur, wenn du weißt, dass die Daten ab dem Umstellungstag einen Bruch zeigen.

Schritt 5: Testen und abgleichen

Testbestellung

  1. Gib eine Testbestellung über das Test-Gateway oder den Testmodus von Shopify Payments auf (Testbestellungen). Merke dir die Bestell-ID.
  2. Aktiviere DebugView, indem du Tag Assistant nutzt oder debug_mode im Google-Tag setzt (DebugView). Ein URL-Parameter allein reicht nicht.
  3. Prüfe in DebugView, dass genau ein purchase mit transaction_id, value, currency und items ankommt.
  4. Prüfe im Webhook-Log, dass der Server dieselbe Bestell-ID gesehen hat und sie im Testfall übersprungen hat.
  5. Der Echtzeitbericht zeigt das Ereignis kurz darauf. Die Standardberichte brauchen länger, vergleiche sie erst am nächsten Tag.

Testbestellungen erscheinen nicht in Shopify-Berichten, in GA4 aber sehr wohl. Schließe sie über einen Filter für Entwickler-Traffic aus oder markiere sie mit einem eigenen Parameter, damit sie deinen Abgleich nicht verfälschen.

Szenarien

  • Gast-Checkout ohne Konto
  • Eingeloggter Kunde mit Kundenkonto
  • Mehrere Artikel und mehrere Mengen
  • Rabattcode auf Bestellebene und Rabatt auf Artikelebene
  • Versandkosten und kostenloser Versand
  • Verschiedene Zahlungsmethoden, insbesondere solche mit Redirect
  • Post-Purchase-Upsell, falls aktiv
  • Ablehnung im Consent-Banner
  • Teilweise und vollständige Rückerstattung

Nach dem Deployment vergleichen

Wiederhole den Abgleich aus Schritt 1 für einen vollen Zeitraum nach der Umstellung und stelle ihn dem Zeitraum davor gegenüber. Erwarte keine Null. Erwarte, dass die Liste der Bestellungen nur in Shopify auf Fälle schrumpft, die du benennen kannst: abgelehnte Einwilligung, Blocker, nie geladene Danke-Seite. Wenn du deinen Anteil beziffern willst, hilft der Tracking-Abdeckungsrechner.


Schritt 6: Laufende Überwachung

Einmal abgleichen reicht nicht. Shopify und Google ändern die Plattformen laufend, wie die Daten in dieser Anleitung zeigen. Richte eine wöchentliche Routine ein:

  • Bestellabgleich: Bestellnummern aus Shopify gegen Transaktions-IDs aus der GA4 Data API oder dem BigQuery-Export. Fehlende und doppelte IDs als Liste, nicht nur als Prozentwert.
  • Baseline und Alarm: Halte die Differenz der ersten vier sauberen Wochen als Baseline fest. Ein Alarm lohnt sich, wenn eine Woche deutlich davon abweicht, nicht bei einem festen Prozentwert, den jemand einmal aufgeschrieben hat.
  • Transaktionsanzahl und Bestellwert: Beide getrennt beobachten. Eine stabile Anzahl mit sinkendem Wert deutet auf ein Wertproblem im Pixel, etwa nach einer Plattformänderung wie der bei subtotalPrice.
  • Webhook-Fehler: Antworten ungleich 200 und Validierungsfehler des Measurement Protocol protokollieren.
  • Changelogs: Den Shopify-Entwickler-Changelog und die Neuerungen in Google Analytics einmal im Monat lesen. Was sich dort ändert, taucht Wochen später in deiner Differenz auf.

Ein Dashboard, etwa in Looker Studio, kann die beiden Datenquellen nebeneinanderstellen. Der Wert liegt im Bestellabgleich dahinter, nicht in der Grafik.


Wann DIY nicht ausreicht

Wenn du nach dieser Anleitung immer noch eine Differenz siehst, die du nicht erklären kannst, hast du wahrscheinlich:

  • Komplexe Checkout-Flows mit Upsells, Abonnements oder Teilzahlungen
  • Mehrere Zahlungsanbieter mit unterschiedlichem Redirect-Verhalten
  • Mehrere Präsentationswährungen oder Märkte mit eigener Steuerlogik
  • Internationale Kunden mit regional unterschiedlichen Consent-Regeln
  • Geerbte Apps und Pixel, die niemand dokumentiert hat

Professionelle Implementierung

Bei FW Delta bauen wir Shopify-Messsetups mit genau einem Kaufpfad im Browser, einem Serverpfad für Käufe und Rückerstattungen und einem wöchentlichen Bestellabgleich. Welche Messverluste sich überhaupt verhindern, korrigieren oder nur modellieren lassen, haben wir im Web Measurement Reliability & Recoverability Report 2026 systematisch untersucht. Was du bekommst:

  • eine Differenz, die auf Bestellebene erklärt ist, statt einer Prozentzahl
  • eine dokumentierte Zuordnung von Shopify-Kennzahlen zu GA4-Werten
  • eine datenschutzorientierte Infrastruktur, die Consent respektiert statt umgeht
  • Alarme, wenn ein Pfad ausfällt

→ Kostenloses Erstgespräch buchen


Häufig gestellte Fragen

Warum zeigt GA4 geringeren Umsatz als Shopify?

Weil GA4 nur Käufe sieht, bei denen ein Tag ausführen durfte: Einwilligung erteilt, kein Blocker, Danke-Seite geladen. Shopify zählt jede bezahlte Bestellung. Der Serverpfad aus Schritt 3 schließt einen Teil der Lücke, aber nicht den Teil, der auf abgelehnter Einwilligung beruht.

Kann ich Google Tag Manager statt der App oder eines Custom Pixels verwenden?

Ja, aber ein Web-Container läuft ebenfalls im Browser und unterliegt denselben Einschränkungen. Im Checkout muss er innerhalb eines Custom Pixels geladen werden, mit allen Sandbox-Grenzen. Ein Server-Container kann den Webhook aus Schritt 3 als Endpunkt ersetzen, ändert aber nichts an der Logik.

Wie erhalte ich das GA4 API Secret?

Verwaltung, Datenstreams, Webstream auswählen, Measurement Protocol API Secrets, Erstellen. Google beschreibt den Weg in der Measurement Protocol Referenz. Das Secret bleibt auf dem Server.

Wirkt sich das auf meine historischen Daten aus?

Nein. Alles hier verbessert nur zukünftige Daten. Das Measurement Protocol erlaubt laut Google eine Rückdatierung um höchstens 72 Stunden, ältere Bestellungen lassen sich nicht nachträglich einspielen.

Benötige ich Shopify Plus?

Nein. Custom Pixels, Webhooks und die Google & YouTube App stehen auf allen Plänen zur Verfügung. Die früheren Unterschiede bei checkout.liquid und zusätzlichen Skripten sind seit dem 26. August 2026 hinfällig, weil diese Wege für alle Shops beendet sind.

Was ist mit Rückerstattungen und Stornierungen?

Der Webhook refunds/create sendet ein refund-Ereignis mit derselben transaction_id. Für Stornierungen ohne Zahlung nutzt du orders/cancelled. Bedenke beim Abgleich, dass Shopify die Rückabwicklung am Verarbeitungstag bucht, nicht am Bestelltag.


Zusammenfassung: Aktions-Checkliste

  • Differenz für einen abgeschlossenen Zeitraum mit gleicher Kennzahl und Zeitzone messen
  • Bestellnummern aus Shopify gegen Transaktions-IDs in GA4 abgleichen
  • Alle Kaufpfade auflisten und auf genau einen im Browser reduzieren
  • Custom Pixel auf checkout_completed mit totalPrice, currencyCode und Bestell-ID prüfen
  • client_id als Warenkorb-Attribut speichern
  • Webhooks orders/paid und refunds/create mit HMAC-Prüfung empfangen
  • Payloads gegen den Validierungsendpunkt prüfen
  • Reporting-Identität, Datenaufbewahrung, Hostname-Filter und Consent-Steuerung in GA4 prüfen
  • Testbestellungen in allen Szenarien fahren und aus dem Abgleich ausschließen
  • Wöchentlichen Bestellabgleich mit Baseline einrichten
  • Konfiguration für zukünftige Teammitglieder dokumentieren

Zeitinvestition: 2 bis 4 Stunden, abhängig davon, ob du den Serverpfad selbst betreibst
Business Impact: Eine erklärbare Umsatzdifferenz und Rückerstattungen, die in GA4 ankommen


Professionelle Hilfe benötigt?

Dieses Muster tritt in den meisten gewachsenen Shopify-Setups auf.

Unser Analytics Engineering Service umfasst:

  • Vollständige Tracking-Prüfung (Shopify, GA4, GTM, Pixel-Inventar)
  • Serverpfad über Webhook und Measurement Protocol oder GTM Server-Container
  • Bestellabgleich als wiederholbare Routine
  • Validierung mit echten Testbestellungen in allen Szenarien

Nicht sicher, wo dein Tracking bricht? Buche ein kostenloses 30-minütiges Diagnose-Gespräch: Wir teilen deinen Bildschirm und identifizieren das exakte Problem.

Verwandte Services

Server-Side-Tracking bereits vorhanden? Schau dir unsere weiteren Ratgeber an, etwa die Shopify Tracking Checkliste mit 42 Prüfpunkten vor der Abnahme.

Newsletter

Research für technische Entscheidungen

Neue Reports, Benchmarks und technische Analysen zu SaaS-Ökonomie, AI Engineering und eigener Infrastruktur.

Original Research Öffentliche Quellen Keine Sales-Mails

Mit der Anmeldung erhältst du neue Analysen und Updates von FW Delta per E-Mail. Du kannst deine Einwilligung jederzeit widerrufen. Weitere Informationen in der Datenschutzerklärung.