Dieselbe Property, neuer Absender: GA4-Tracking beim Shopify-Umstieg

Ein Händler für Fahrradzubehör, bisher Shopware 6, rund 2.000 Bestellungen im Monat. Gemessen wird seit Jahren mit derselben Google-Analytics-Property. Die E-Commerce-Ereignisse schreibt ein Plugin in den Data Layer, ein Tag-Manager-Container schickt sie an GA4 und an Google Ads. Zum Go-live auf Shopify verbindet die Agentur die Property über die Google-&-YouTube-App. Der Entwickler, der den Container betreut, baut ihn zusätzlich als Custom Pixel nach, damit die Werbe-Tags weiterlaufen. Die GA4-Tags wandern dabei mit.

Nach der ersten vollen Woche liegen drei Zahlen auf dem Tisch. Shopify zählt 468 Bestellungen im Onlineshop, GA4 meldet 791 Käufe. Der Umsatz pro Kauf liegt in GA4 um 24 Prozent über dem Vorjahr. Und im Artikelbericht steht die meistverkaufte Fahrradlampe zweimal: bis zum Go-live unter ihrer Artikelnummer BL-2210-RD, danach unter einer langen Zahl.

Shopify hat sich nicht verzählt. Jede Testbestellung kommt in der DebugView von GA4 zweimal an, einmal von der App und einmal vom Pixel, mit zwei verschiedenen Werten für die transaction_id. Ohne die Dopplung wären es knapp 400 Käufe, gut 85 Prozent der Bestellungen. Das ist plausibel, weil nicht jeder Besucher der Messung zustimmt. Das alte Plugin hat als Umsatz den Warenwert netto gesendet, im neuen Shop kommt der Gesamtbetrag mit Versand und Steuer an. Und als Artikelkennung hat es die Artikelnummer genommen, der neue Shop nimmt eine Shopify-ID. Drei Entscheidungen, die vor Jahren jemand im Plugin getroffen hat und die beim Umstieg niemand neu getroffen hat.

Shopify hat am 7. Oktober eine Anleitung zum E-Commerce-Tracking mit Google Analytics veröffentlicht. Sie stellt die Ereignisse vor, die GA4 für Onlineshops empfiehlt, von view_item bis refund, und zwei Wege, sie aus Shopify zu senden: die Verbindung über die Google-&-YouTube-App, die Shopify ausdrücklich empfiehlt, und den Google Tag Manager in einem Custom Pixel als „Advanced-Modus“. Sie zeigt, wie aus Shopify-Kundenereignissen wie checkout_completed GA4-Ereignisse wie purchase werden, und warnt davor, dieselben Ereignisse auf beiden Wegen zu senden.

Für einen Shop, der neu anfängt, reicht das. Wer umsteigt, führt dagegen eine Property weiter, in der Jahre an Daten aus dem alten Shop liegen, und misst die neuen Zahlen an den alten. Dafür muss der neue Shop dieselben Ereignisse mit denselben Kennungen und denselben Werten senden wie der alte, oder Sie müssen wissen, wo er es nicht tut. Dieser Beitrag zeigt, woher jedes Ereignis im neuen Shop kommt, welche drei Werte bisher das Plugin entschieden hat und wie Sie in den ersten zwei Wochen prüfen, ob die Käufe stimmen. Wie Sie die Conversion Rate über den Go-live vergleichen, steht in Conversion Rate beim Shopify-Umstieg. Welche Tags vor der Einwilligung laden dürfen, steht in Cookie-Banner beim Shopify-Umstieg.

Woher die Ereignisse im neuen Shop kommen

In Shopware, Magento und WooCommerce erzeugt der Server jede Seite selbst, auch die Bestellbestätigung. Ein Plugin schreibt dabei die Ereignisse samt Produkten, Preisen und Bestellnummer in den Data Layer der Seite. Der Tag-Manager-Container liest sie dort und reagiert außerdem auf Seitenpfade, Klicks und Formulare. Wer etwas messen wollte, das das Plugin nicht kannte, hat einen Trigger gebaut.

Bei Shopify sieht das Theme den Checkout nicht, und auf der Danke-Seite laufen keine frei eingefügten Skripte mehr. Stattdessen meldet der Shop selbst Kundenereignisse: fünfzehn Standardereignisse vom Seitenaufruf bis zum abgeschlossenen Checkout, die er an jedes Pixel weiterreicht, das sie abonniert. Welches Pixel daraus GA4-Ereignisse macht, entscheiden Sie: die App oder Ihr eigenes.

Ereignis-Übersetzung

Vom Data Layer zu den Kundenereignissen

Links das GA4-Ereignis und wo es im alten Shop entstand, rechts das Kundenereignis, aus dem es bei Shopify wird. 11 Ereignisse kommen fertig aus der Google-&-YouTube-App, für 4 braucht es eigene Arbeit.

• App sendet
• App sendet, neu
• nicht dokumentiert

Stöbern

1. page_view Google-Tag oder Container im Seiten-Template, auf jeder Seite
   ←
   page_viewed App sendet

   Im Custom Pixel die Seitenadresse aus dem Ereignis übergeben. Sonst steht die Adresse der Pixel-Sandbox im Bericht.

2. search Suchergebnisseite
   ←
   search_submitted App sendet
3. view_item_list Kategorie- oder Listingseite
   ←
   collection_viewed App sendet, neu

   Gilt für Kollektionsseiten. Empfehlungsleisten und Suchtreffer melden kein eigenes Listenereignis.

4. select_item Klick auf eine Produktkachel
   ←
   kein Kundenereignis nicht dokumentiert

   Eigenes Ereignis aus dem Theme mit Shopify.analytics.publish, im Pixel in select_item übersetzen.

5. view_promotion · select_promotion Teaser in Einkaufswelten, Startseitenbanner
   ←
   kein Kundenereignis nicht dokumentiert

   Wie select_item: nur über eigene Ereignisse.

Produkt und Warenkorb

1. view_item Produktdetailseite
   ←
   product_viewed App sendet
2. add_to_cart Klick auf „In den Warenkorb“, oft per Ajax-Antwort des Plugins
   ←
   product_added_to_cart App sendet
3. remove_from_cart Löschen im Warenkorb oder Off-Canvas-Warenkorb
   ←
   product_removed_from_cart App sendet, neu
4. view_cart Warenkorbseite
   ←
   cart_viewed App sendet, neu

Checkout

1. begin_checkout Erster Checkout-Schritt, etwa /checkout/confirm in Shopware
   ←
   checkout_started App sendet
2. add_shipping_info Adress- oder Versandschritt
   ←
   checkout_address_info_submitted App sendet, neu

   Für die Versandart gibt es zusätzlich checkout_shipping_info_submitted.

3. add_payment_info Auswahl der Zahlungsart
   ←
   payment_info_submitted App sendet

Kauf und danach

1. purchase Bestellbestätigung: /checkout/finish, /checkout/onepage/success, /checkout/order-received
   ←
   checkout_completed App sendet

   Einmal pro Checkout, meist auf der Danke-Seite, mit Upsell-App auf der ersten Upsell-Seite. Lädt diese Seite nicht, kommt kein Kauf an.

2. refund Gutschrift im Backend, vom Plugin serverseitig gemeldet
   ←
   kein Kundenereignis nicht dokumentiert

   Erstattungen entstehen im Admin, nicht im Browser. Nur serverseitig über das Measurement Protocol.

Außerhalb des Kaufprozesses

1. generate_lead · eigene Ereignisse Klick-, Formular- und Scroll-Trigger im Tag Manager
   ←
   clicked · form_submitted nicht dokumentiert

   DOM-Ereignisse von Shopify statt Trigger, die die Seite lesen. Im Pixel sehen die Trigger des Tag Managers nur das iframe.

Kundenereignisse nach der Web Pixels API von Shopify, Stand Oktober 2026. Was die App sendet, steht in der Shopify-Hilfe zu GA4 und in der Google-Hilfe zur Einrichtung des Google-Tags für Shopify. Die Pfade der Bestellbestätigung gehören zu Shopware 6, Magento 2 und WooCommerce.

Drei Dinge daraus gehören in die Planung.

Der Kaufprozess ist abgedeckt, die Ränder nicht. Zu jedem Schritt von page_view bis purchase gibt es ein Kundenereignis, und die App sendet nach der Google-Hilfe zur Einrichtung inzwischen auch view_item_list, view_cart, remove_from_cart und add_shipping_info. Klicks auf Produktkacheln und Aktionsbanner meldet Shopify dagegen nicht. Wer select_item oder die Berichte zu Promotions nutzt, veröffentlicht dafür eigene Ereignisse aus dem Theme mit Shopify.analytics.publish und übersetzt sie im Pixel. Shopify weist darauf hin, dass solche Ereignisse auch jeder Besucher über die Browser-Konsole auslösen kann. Für Berichte reicht das, für die Abrechnung von Provisionen nicht.

Erstattungen gibt es im Browser nicht. Google empfiehlt, Erstattungen mit dem Ereignis refund zu melden, mit der transaction_id der ursprünglichen Bestellung und den erstatteten Artikeln. Eine Erstattung entsteht aber im Shopify-Admin, nicht beim Besucher, und dafür gibt es kein Kundenereignis. Manche Plugins haben Gutschriften im alten Shop serverseitig an GA4 gemeldet. Wer das ersetzen will, braucht wieder einen serverseitigen Weg: das Measurement Protocol, das Google für Ereignisse außerhalb des Browsers vorsieht, meist über eine App, die Erstattungen aus Shopify abholt. Ohne Ersatz zeigt GA4 nach dem Go-live mehr Umsatz als vorher, weil die Abzüge fehlen.

Trigger ziehen nicht mit. Ein Custom Pixel läuft laut der Dokumentation der Web Pixels API in einem abgeschotteten iframe ohne Zugriff auf die eigentliche Seite. Die Klick-, Sichtbarkeits- und Scroll-Trigger des Tag Managers sehen dort nur das iframe, nicht den Shop. Shopify liefert stattdessen DOM-Ereignisse wie clicked und form_submitted an das Pixel, auf den Shopseiten, im Checkout und auf der Danke-Seite, nicht aber im Kundenkonto. Jeder Trigger im alten Container braucht deshalb eine neue Grundlage, oder er fällt weg.

Drei Entscheidungen, die bisher das Plugin getroffen hat

Im alten Container waren drei Dinge eingestellt, an die sich nach Jahren kaum jemand erinnert: was als Umsatz eines Kaufs zählt, welche Kennung eine Bestellung trägt und welche ein Artikel. Im neuen Shop entscheidet sie die App nach ihren Regeln oder Ihr Pixel nach seinem Code. Jeder Unterschied zeigt sich am Go-live als Sprung in den Berichten, und keiner löst eine Warnung aus.

Was als Umsatz zählt

GA4 übernimmt als Umsatz eines Kaufs, was im Parameter value steht. Ob das der Warenwert netto war, der Warenwert brutto oder der Gesamtbetrag mit Versand, hat das Plugin festgelegt, oft mit einer Voreinstellung, die beim Einrichten niemand geändert hat. Im Kundenereignis checkout_completed liegen Gesamtbetrag, Zwischensumme, Steuer und Versand einzeln vor. Ein eigenes Pixel kann also jede Definition senden. Welche die App verwendet, dokumentieren weder Shopify noch Google. Ein Testkauf mit bekannten Beträgen zeigt es.

Rechner

Eine Bestellung, vier Umsätze

Stellen Sie eine typische Bestellung ein und wählen Sie, was der alte Shop als value gesendet hat und was der neue sendet. Der Rechner zeigt, um wie viel sich der Umsatz pro Kauf in GA4 am Go-live verschiebt, ohne dass ein Kunde mehr oder weniger ausgibt.

Warenkorb brutto

129,00 €

Rabatt auf die Ware

10 %

Versand brutto

4,90 €

Steuersatz

19 % 7 %

alt neu

• Warenwert netto 97,56 €

  nach Rabatt, ohne Steuer und Versand
  Warenwert netto hat der alte Shop gesendet Warenwert netto sendet der neue Shop
• Warenwert brutto 116,10 €

  nach Rabatt, mit Steuer, ohne Versand
  Warenwert brutto hat der alte Shop gesendet Warenwert brutto sendet der neue Shop
• Gesamtbetrag 121,00 €

  was der Kunde bezahlt, mit Versand
  Gesamtbetrag hat der alte Shop gesendet Gesamtbetrag sendet der neue Shop
• Gesamtbetrag netto 101,68 €

  mit Versand, ohne Steuer
  Gesamtbetrag netto hat der alte Shop gesendet Gesamtbetrag netto sendet der neue Shop

+24 %

Umsatz pro Kauf in GA4 nach dem Go-live, bei gleichem Einkauf. Dieselbe Verschiebung steckt im Umsatz jeder Kampagne und jedes Produkts.

Vereinfacht: ein Steuersatz für Ware und Versand, Rabatt nur auf die Ware. Welche Definition Ihr altes Plugin genutzt hat, zeigt ein Testkauf im alten Shop: Der value des purchase-Ereignisses in der DebugView von GA4 lässt sich mit der Bestellung vergleichen.

Bei Bruttopreisen und 19 Prozent Steuer liegt allein zwischen netto und brutto ein Sprung von 19 Prozent. Kommt der Versand dazu, wird es mehr, und zwar umso mehr, je kleiner der Warenkorb ist. Der Durchschnittsbon und der Umsatz je Kampagne verschieben sich am Go-live um denselben Faktor, und wenn Google Ads die Käufe aus GA4 übernimmt, auch der Return on Ad Spend, auf den eine Gebotsstrategie optimiert.

Die Gegenmaßnahme ist kurz. Machen Sie im alten Shop vor dem Go-live einen Testkauf und lesen Sie in der DebugView ab, welcher value ankommt. Im neuen Shop senden Sie dieselbe Definition. Geht das nicht, weil die App eine andere sendet, notieren Sie den Bruch mit Datum als Anmerkung in GA4, bevor jemand den ersten Monatsbericht schreibt.

Welche Kennung ein Kauf trägt

Kennungen

Drei Kennungen, die am Go-live wechseln

GA4 verknüpft Ereignisse über Kennungen: Käufe über die Bestellung, Produkte über den Artikel, Besuche über den Kunden. Ändert sich die Form am Go-live, beginnt in der Property eine neue Reihe, während die alte einfach aufhört.

1. transaction_id

   Kennung der Bestellung

   Alter Shop

   • Shopware 6 10045
   • Magento 2 000001234
   • WooCommerce 8812

   Go-live

   Shopify

   • im Ereignis Bestell-ID
   • im Admin #1001

   Das Kundenereignis enthält die interne Bestell-ID von Shopify. Die Bestellnummer aus dem Admin steht nicht darin.

   Was bricht

   GA4 fasst zwei Käufe nur zusammen, wenn die transaction_id gleich ist. Zwei Absender mit verschiedenen Kennungen zählen jede Bestellung doppelt.

   Was hilft

   Eine Kennung für alle Absender festlegen und in der DebugView prüfen, welche Form ankommt, bevor jemand Abgleichtabellen baut.

2. item_id

   Kennung des Artikels

   Alter Shop

   • Shopware 6 BL-2210-RD
   • Magento 2 BL-2210-RD
   • WooCommerce 4711 oder SKU

   Go-live

   Shopify

   • Produkt Produkt-ID
   • Variante Varianten-ID
   • SKU BL-2210-RD

   Das Ereignis liefert für jede Position Produkt-ID, Varianten-ID und die SKU der Variante. Welche davon als item_id ankommt, entscheidet der Absender.

   Was bricht

   Der Artikelbericht zerfällt am Go-live in zwei Hälften: Jedes Produkt steht einmal mit alter und einmal mit neuer Kennung. Dynamisches Remarketing findet zu den angesehenen Produkten keine Anzeige mehr, wenn Tag und Feed verschiedene IDs senden.

   Was hilft

   Artikelnummern 1:1 als SKU übernehmen und im eigenen Pixel die SKU senden. Mit der App vor dem Go-live prüfen, welche Kennung ankommt, und den Bruch notieren.

3. user_id

   Kennung eingeloggter Kunden

   Alter Shop

   • Shopware 6 Kundennummer
   • Magento 2 customer_id
   • WooCommerce Benutzer-ID

   Go-live

   Shopify

   • Kunde neue Kunden-ID

   Shopify vergibt jedem importierten Kunden eine neue Kunden-ID. Die alte Kundennummer kennt das Ereignis nicht.

   Was bricht

   Wer user_id nutzt, für den beginnen geräteübergreifende Berichte und Zielgruppen, die auf der Kennung beruhen, am Go-live von vorn. Eingeloggte Bestandskunden tragen ab dann eine neue Kennung.

   Was hilft

   Den Bruch mit Datum in der Property notieren und Zielgruppen, die auf user_id beruhen, nach dem Go-live neu aufbauen lassen.

Beispielwerte für typische Einstellungen der alten Systeme, je nach Plugin auch anders. Felder des Kundenereignisses checkout_completed nach der Web Pixels API von Shopify, Stand Oktober 2026.

Die transaction_id verdient einen zweiten Blick, weil an ihr die Dopplung aus dem Beispiel hängt. Nach der Google-Hilfe zu Transaktions-IDs fasst GA4 Käufe mit derselben transaction_id zusammen. Senden App und Pixel dieselbe Kennung, bleibt eine doppelte Meldung folgenlos. Senden sie verschiedene, zählt GA4 zwei Käufe. Im Beispiel hat das Pixel eine andere Kennung genommen als die App. Das fällt in keinem Test auf, der nur prüft, ob überhaupt ein purchase ankommt.

Bei der item_id beginnt die beste Lösung schon vor dem Go-live: Übernehmen Sie die Artikelnummern unverändert als SKU der Varianten. Dann kann ein eigenes Pixel die SKU als item_id senden, und der Artikelbericht läuft über den Go-live weiter. Dieselbe Frage stellt sich beim Shopping-Feed, dort mit noch mehr Folgen für Kampagnen und Remarketing. Wie Sie dort entscheiden, steht in Google-Shopping-Feed beim Shopify-Umstieg.

Ein Absender pro Ereignis

Die Shopify-Anleitung und die Google-Hilfe warnen beide vor doppeltem Tracking. In Migrationen entsteht es auf drei Wegen. Die App wird verbunden, und der alte Container läuft als Custom Pixel mit seinen GA4-Tags weiter. Jemand fügt aus Gewohnheit den Google-Tag in theme.liquid ein. Oder eine weitere App, etwa für Bewertungen oder Analysen, bringt eine eigene GA4-Anbindung mit. Wer was sendet, gehört deshalb vor den Go-live entschieden, und zwar für jedes Ereignis einzeln.

Aufbau

App, eigenes Pixel oder beides

Drei Aufbauten, die funktionieren, und einer, der in Migrationen ständig entsteht. Jeder Chip steht für ein Ereignis und zeigt, wer es an GA4 sendet. refund sendet in keinem der Wege jemand: Dafür gibt es kein Ereignis im Browser.

• App
• Pixel
• niemand
• doppelt

1. Weg A

   Nur die App

   Der alte Container hat vor allem GA4 und Google Ads bedient.

   • page_view App
   • view_item App
   • add_to_cart App
   • begin_checkout App
   • purchase App
   • select_item niemand
   • generate_lead niemand
   • refund niemand

   Sie legen fest

   Fast nichts. Kennungen und Werte bestimmt die App.

   Prüfen mit

   DebugView und Echtzeitbericht in GA4.

   Pflege

   Shopify und Google.

2. Weg B

   Tag Manager im Custom Pixel

   Sie wollen Kennungen und Werte selbst bestimmen oder betreiben viele eigene Tags.

   • page_view Pixel
   • view_item Pixel
   • add_to_cart Pixel
   • begin_checkout Pixel
   • purchase Pixel
   • select_item Pixel
   • generate_lead Pixel
   • refund niemand

   Sie legen fest

   Alles, was im Pixel übersetzt wird.

   Prüfen mit

   Shopify Pixel Helper. Die Tag-Fehlerbehebung des Tag Assistant funktioniert mit Custom Pixels nicht.

   Pflege

   Sie oder Ihre Agentur. Der Shopify-Support hilft bei Custom Pixels nicht.

3. Weg C

   App für den Kaufprozess, Pixel für den Rest

   Die App reicht, aber einzelne Ereignisse wie Produktklicks oder Anfragen fehlen.

   • page_view App
   • view_item App
   • add_to_cart App
   • begin_checkout App
   • purchase App
   • select_item Pixel
   • generate_lead Pixel
   • refund niemand

   Die Regel

   Das Pixel sendet kein Ereignis, das die App schon sendet. Vor allem kein purchase.

   Prüfen mit

   DebugView und Pixel Helper, dazu ein eigener Parameter im Pixel, der die Herkunft zeigt.

   Pflege

   Shopify und Google für die App, Sie für das Pixel.

Fehlbild

App und nachgebauter Container senden beide

Die App ist verbunden, und der alte Container läuft als Custom Pixel weiter, mit seinen GA4-Tags. Jeder Seitenaufruf und jeder Kauf kommt zweimal an. GA4 fasst Käufe nur zusammen, wenn beide Absender dieselbe transaction_id senden.

• page_view doppelt
• view_item doppelt
• add_to_cart doppelt
• begin_checkout doppelt
• purchase doppelt
• select_item Pixel
• generate_lead Pixel
• refund niemand

Nach der Shopify-Anleitung zu GA4 vom 7. Oktober 2026, der Google-Hilfe zur Einrichtung des Google-Tags für Shopify und der Dokumentation der Pixel-Sandbox auf shopify.dev.

Für die meisten Shops ist Weg A oder C richtig. Weg B lohnt sich, wenn Kennungen und Werte über den Go-live gleich bleiben müssen und die App sie anders sendet, oder wenn der Container viel mehr trägt als GA4. Zwei Eigenheiten nennt die Shopify-Anleitung selbst. Die Tag-Fehlerbehebung im Google Tag Assistant funktioniert mit Custom Pixels nicht, geprüft wird mit dem Shopify Pixel Helper. Und weil das Pixel in der Sandbox läuft, landet ohne Gegenmaßnahme die Adresse der Sandbox als Seitenadresse in GA4. Das Pixel sendet page_view deshalb selbst, ausgelöst von page_viewed und mit der Adresse aus dem Ereignis.

Gleich in welchem Weg: Geben Sie jedem Ereignis aus dem eigenen Pixel einen Parameter mit, der die Herkunft zeigt, etwa sender mit dem Wert pixel. Für die Ereignisse der App nennt Google den Parameter shopify_event_name, über den sich Filter bauen lassen. In der DebugView sehen Sie dann bei jedem Ereignis sofort, wer es geschickt hat.

Die Abnahme: erst Käufe zählen, dann Berichte lesen

Solange der neue Shop mit Passwort geschützt ist, erfasst GA4 laut Shopify keine Ereignisse. Die eigentliche Abnahme beginnt deshalb mit dem Öffnen. Machen Sie in der ersten Stunde drei Testbestellungen mit bekannten Beträgen, eine davon mit Rabattcode und eine mit zwei Artikeln. Prüfen Sie in der DebugView für jede: genau ein purchase, die erwartete transaction_id, ein value nach der festgelegten Definition und alle Artikel im items-Array mit der richtigen item_id. Danach stornieren Sie die Bestellungen.

In den zwei Wochen darauf zählt jeden Tag ein einziger Vergleich: Bestellungen im Onlineshop laut Shopify gegen Käufe in GA4. Nehmen Sie nur den Vertriebskanal Onlineshop, ohne Kassensystem, Entwürfe und Marktplätze. Fünf Regeln helfen beim Lesen:

• Unter 100 Prozent ist normal. Wer nicht zustimmt oder einen Werbeblocker nutzt, fehlt in GA4. Entscheidend ist, dass der Anteil von Tag zu Tag stabil bleibt.
• Über 100 Prozent ist ein Fehler. Dann sendet ein zweiter Absender, fast immer mit einer anderen transaction_id.
• Ein fester Abstand beim Umsatz pro Kauf zwischen GA4 und Shopify deutet auf die Definition von value. Liegt GA4 bei 19 Prozent Steuer dauerhaft rund ein Sechstel darunter, kommt netto an, wo Shopify brutto zeigt.
• Käufe ohne Artikel zeigen ein Pixel, das das items-Array nicht befüllt. Der Umsatz stimmt dann, der Artikelbericht bleibt leer.
• Mit einer Upsell-App nach dem Kauf löst die erste Upsell-Seite das Kaufereignis aus, nicht die Danke-Seite. Testen Sie diesen Weg mit einer eigenen Bestellung.

Checkliste

GA4 beim Umstieg: zwölf Punkte

Die ersten sieben Punkte gehören in die Wochen vor dem Go-live, die nächsten drei an den Umstellungstag, die letzten zwei in die Wochen danach. Ihre Häkchen bleiben in diesem Browser gespeichert.

• Alten Container und Plugin-Einstellungen exportiert, mit einer Liste aller Tags, Trigger und Ereignisse
• Im alten Shop einen Testkauf in der DebugView geprüft und notiert, welcher value, welche item_id und welche transaction_id ankommen
• Für jedes Ereignis festgelegt, wer es sendet: die App, das eigene Pixel oder niemand
• Artikelnummern unverändert als SKU der Varianten übernommen
• Ersatz für Klick-, Formular- und Scroll-Trigger geplant, mit DOM-Ereignissen oder eigenen Ereignissen aus dem Theme
• Entschieden, ob Erstattungen serverseitig an GA4 gehen oder der Bruch im Umsatz dokumentiert wird
• Im Custom Pixel page_view aus page_viewed mit der echten Seitenadresse gesendet und einen Parameter für die Herkunft ergänzt
• GA4-Tags im Pixel abgeschaltet, wo die App dieselben Ereignisse sendet, und keinen Google-Tag im Theme
• Nach dem Öffnen drei Testbestellungen geprüft: je genau ein purchase mit erwarteter transaction_id, value und vollständigem items-Array
• Go-live und jeden bekannten Bruch bei value, item_id und user_id als Anmerkung in GA4 notiert
• Zwei Wochen lang täglich Bestellungen im Onlineshop gegen Käufe in GA4 verglichen
• Conversions in Google Ads auf doppelte Käufe und geänderte Werte geprüft, bevor Gebotsstrategien damit weiterlernen

---

Was für Ihre Ausgangslage sinnvoll ist

Ihre Situation	Empfehlung
Der Container trägt im Wesentlichen GA4 und Google Ads	Weg A: die Google-&-YouTube-App verbinden, den Container nicht nachbauen und keinen Google-Tag ins Theme setzen
Großer Container mit Werbe-, Affiliate- und Analyse-Tags	Die App für GA4 und Google Ads, die übrigen Tags als App-Pixel der Anbieter oder in einem Custom Pixel ohne GA4-Kaufereignisse
select_item, Promotions oder Anfragen werden ausgewertet	Eigene Ereignisse aus dem Theme mit Shopify.analytics.publish, im Pixel unter eigenem Namen an GA4, nie zusätzlich ein purchase
Artikelberichte mit Vorjahresvergleich sind wichtig	Artikelnummern als SKU übernehmen und im eigenen Pixel die SKU als item_id senden. Mit der App vorher prüfen, welche Kennung ankommt
Das alte Plugin hat Gutschriften als refund gemeldet	Eine serverseitige Lösung über das Measurement Protocol einplanen oder den Bruch im Umsatz dokumentieren
Eine Upsell-App nach dem Kauf ist geplant	Das Kaufereignis auf der ersten Upsell-Seite testen, nicht nur auf der Danke-Seite
Bisher Matomo oder etracker statt GA4	Die Fragen sind dieselben: Kaufereignis, Kennungen, Wert. Gemessen wird über ein Custom Pixel, verglichen wie im Beitrag zur Conversion Rate

Was Sie aus diesem Artikel mitnehmen sollten

Shopify macht das E-Commerce-Tracking in vielem einfacher als der alte Shop: Die Ereignisse des Kaufprozesses kommen fertig aus dem Shop, auch aus dem Checkout, und die Google-&-YouTube-App sendet sie ohne eine Zeile Code an GA4. Was der alte Shop an eigenen Regeln mitbrachte, kommt aber nicht von selbst mit.

Der Absender wechselt, die Property bleibt. GA4 merkt nicht, dass ein anderer Shop sendet. Jede Abweichung bei Ereignissen, Kennungen und Werten landet unbemerkt in derselben Reihe wie die Daten der letzten Jahre.

Drei Werte entscheiden über die Vergleichbarkeit. value, item_id und transaction_id hat bisher das Plugin festgelegt. Wer sie vor dem Go-live im alten Shop abliest, kann sie im neuen gleich setzen oder den Bruch benennen, bevor ihn jemand als Umsatzplus feiert.

Ein Ereignis, ein Absender. App und eigenes Pixel vertragen sich, solange sie sich die Ereignisse teilen, statt sie doppelt zu senden. Der tägliche Abgleich von Bestellungen und Käufen zeigt schon in den ersten Tagen, ob das gelingt.

Wenn Sie einen Umstieg planen und Ihre Zahlen ihn vergleichbar überstehen sollen: Lassen Sie uns sprechen. Wie wir Migrationen angehen, steht auf Shopsystem-Migration, was sie zum Festpreis kosten, auf Shopify-Migration zum Festpreis. Die systemspezifischen Fälle finden Sie auf Shopware zu Shopify, Magento zu Shopify, WooCommerce zu Shopify und JTL-Shop zu Shopify.