Conversion-Tracking im Onlineshop: das Fundament richtig bauen

Abgenommen wird die Entscheidung, nicht das Tag

Ein Tag, das feuert, beweist wenig. Fertig ist das Tracking aus meiner Sicht erst, wenn feststeht, welche kaufmännische Entscheidung die Zahl tragen darf: einen Monatsreport, ein Gebotsziel oder einen Budgetsprung. Das ändert auch, was du von Agentur oder Entwicklung einforderst. Im Auftrag steht dann ein prüfbares Ergebnis, das Werkzeug wählt der Umsetzer. Daraus ergeben sich drei Reifestufen.

Die Reihenfolge lässt sich nicht tauschen. Enhanced Conversions auf einer doppelt zählenden Aktion füllen eine Lücke in einer falschen Zahl, und Retouren lassen sich ohne eigene Bestellnummern gar nicht zuordnen. Ein Shop mit kaum Retouren bleibt dagegen auf Stufe 2 und verliert nichts.

Welche Conversions sind primär? Der Kauf, in genau einer Aktion

Primär ist im Shop der abgeschlossene Kauf. Laut Google landen primäre Aktionen in der Spalte Conversions und in der Gebotsstrategie, sofern ihr Standardziel für Gebote genutzt wird. Alles, was du dort einträgst, ist also ein Auftrag an den Algorithmus, mehr davon zu beschaffen.

Warenkorb, Checkout-Start und Newsletter gehören deshalb auf sekundär. Sekundäre Aktionen stehen laut Google nur zur Beobachtung unter Alle Conversions. Die Ausnahme steckt in den benutzerdefinierten Zielen: Ist eine sekundäre Aktion Teil eines solchen Ziels, bestimmt sie die Gebote mit. Ein Blick auf die Statusspalte reicht bei der Prüfung also nicht, die benutzerdefinierten Ziele gehören dazu.

Ein Bauplanfehler liegt eine Ebene tiefer: Derselbe Kauf wird über das Google-Ads-Tag und über Google Analytics gemessen, beide Aktionen sind primär. Laut Google darfst du nur eine der beiden als primäres Ziel verwenden, sonst zählt derselbe Kauf doppelt in den Kampagnen. Die andere bleibt sekundär zum Vergleich. Wer Stufe 3 plant, klärt vorher, ob die primäre Aktion Korrekturen annimmt, gerade wenn sie aus Analytics importiert ist.

Wann die Regel nicht gilt: Schließt der Kauf regelmäßig außerhalb des Shops ab, etwa im B2B über Anfrage und Angebot, ist die qualifizierte Anfrage ein legitimer primärer Kandidat. Anders sehe ich den Shop mit wenigen Käufen, der den Warenkorb hochstuft, um mehr Signale zu bekommen. Ein Warenkorb ist kein Umsatz, die wertbasierte Gebotsstrategie lernt dann das Falsche. Zu wenig Käufe sind eine Frage der Gebotsstrategie und kein Grund, das Ziel umzudeuten.

Welche Parameter braucht der Kauf?

Für das GA4-Event purchase sind die Regeln in der Event-Referenz festgelegt. Die Google-Ads-Hilfe ergänzt die Anforderungen an die Transaction-ID. Vier Felder musst du dir vorlegen lassen:

An der Transaction-ID hängen zwei Folgen, die erst später teuer werden. Eine feste oder wiederholte ID führt laut Google zu deutlicher Untererfassung, weil eventuell nur der erste Eingang zählt. Und eine ID mit dem Präfix GG_ zeigt laut Google, dass der Shop gar keine eigene ID übergibt. Solche IDs taugen nicht für Conversion-Anpassungen, Stufe 3 ist damit verbaut. Für Käufe empfiehlt Google die Transaction-ID zusammen mit der Zählung aller Conversions, die Einstellung Eine ist für einen Lead je Klick gedacht.

Der Wert ist die Stelle, an der Technik zur Kaufmannsfrage wird. Angenommen, eine Bestellung kostet 119 Euro inklusive 19 Prozent Umsatzsteuer und die Anzeigen haben dafür 10 Euro gekostet. Netto gemeldet ergibt das ROAS 10, brutto gemeldet ROAS 11,9, bei identischem Geschäft. Du kannst auch anders melden, musst dann aber den Ziel-ROAS auf derselben Basis aus der Marge herleiten. Wer die Basis nicht kennt, vergleicht Zahlen, die nicht vergleichbar sind.

So nimmst du Stufe 1 ab

Die Abnahme besteht aus zwei Teilen: einem Testkauf für die Parameter und einem Abgleich mit den echten Bestellungen für die Vollständigkeit. Der Testkauf allein zeigt nur, dass es einmal funktioniert hat.

1. Testkauf je relevanter Zahlungsart, mit erteilter Einwilligung. Geprüft wird in Tag Assistant oder in den Chrome-Entwicklertools, wo die Transaction-ID laut Google typischerweise als Parameter oid in der Conversion-Anfrage steht.
2. Genau ein Eingang je Aktion. Pro Testkauf sendet jede Aktion einmal. Melden zwei primäre Aktionen denselben Kauf oder eine Aktion zwei verschiedene IDs, laufen vermutlich Lösungen parallel.
3. Bestellabgleich. Die Liste der erfassten Bestellnummern eines Zeitraums wird gegen den Export aus dem Shop-Backend gelegt. Wie die Liste entsteht, zeigt dir der Umsetzer, Details stehen im Artikel zum Abgleich mit dem Shopsystem.

Beim Abgleich suchst du Muster, keine Punktlandung. Eine belegte Prozentgrenze, ab der Tracking als defekt gilt, kenne ich nicht. Volle Deckung erwarte ich schon wegen der Einwilligungen nicht. Gleichmäßig fehlende Bestellungen sprechen eher für Einwilligung und Blocker. Fehlen dagegen fast alle Bestellungen einer Zahlungsart, eines Landes oder eines Geräts, ist das nach meiner Einschätzung ein technischer Fehler, und den kann man beheben. Doppelte Bestellnummern in der Liste sind ein Fehler.

Trenne dabei zwei Dinge, die gern vermischt werden: Eine Bestellung, die innerhalb einer Plattform doppelt zählt, ist ein Tracking-Fehler. Zwei Plattformen, die dieselbe Bestellung je einmal beanspruchen, sind eine Attributionsfrage. Nur Ersteres gehört in diese Abnahme.

Tag Manager oder Plugin? Die Abnahme entscheidet

Die Werkzeugfrage wird oft zur Glaubensfrage, dabei reichen zwei Prüffragen: Besteht die Lösung die Abnahme, und wer hält sie instand? Beide Wege haben dokumentierte Grenzen, die sich im Test zeigen.

Das WooCommerce-Plugin für Google Analytics erfasst Käufe nur, wenn die Zahlungsart nach der Zahlung auf die Danke-Seite zurückleitet. Eine Zahlungsart ohne diese Rückleitung fehlt also im Report, obwohl jeder Testkauf mit einer anderen Zahlungsart sauber aussieht. Deshalb steht oben "je relevanter Zahlungsart".

Auf Shopify läuft der Tag Manager in einer Sandbox mit denselben Einschränkungen wie andere Pixel, und die Troubleshoot-Funktion von Tag Assistant ist dort nicht kompatibel. Der Tag Manager bringt hier also nicht automatisch mehr Kontrolle, und der Prüfweg muss vorab vereinbart sein.

Meine Faustregel, die Abnahme überstimmt sie jederzeit:

Die dritte Zeile halte ich für die teuerste: Plugin und Container nebeneinander ergeben die Doppelzählung, die der Testkauf in Schritt 2 aufdeckt.

Stufe 2: Enhanced Conversions erst auf sauberer Zählung

Enhanced Conversions gleichen laut Google gehashte Erstanbieterdaten mit Daten eingewilligter, angemeldeter Google-Nutzer ab und füllen so Lücken bei Google-Ads-Interaktionen, die sonst nicht beobachtbar wären. Die Variante in Analytics ist eine offene Beta (Stand November 2026), rechne dort also mit Änderungen.

Kaufmännisch verschiebt das nach meiner Einschätzung die Zuordnung, nicht deinen Umsatz. Der Shop verkauft danach nicht mehr, die Kampagne sieht nur mehr von dem, was sie ausgelöst hat. Das hilft der Gebotsstrategie, und es kann den ausgewiesenen ROAS anheben, ohne dass etwas besser geworden wäre. Ändere deshalb nicht gleichzeitig Ziele und Budgets, sonst lässt sich der Effekt nicht mehr trennen. Aufwand und Datenschutzfragen behandelt der Artikel zu Enhanced Conversions im Shop, die Consent-Seite der Artikel Consent Mode v2 aus Händlersicht.

Abgenommen ist Stufe 2, wenn der Datenschutz freigegeben hat, der Testkauf die Übergabe gehashter Kundendaten zeigt und der Bestellabgleich aus Stufe 1 keine neuen Doppelzählungen meldet.

Stufe 3: Die Korrektur erreicht das Gebot nur sieben Tage lang

Laut Google wirken Conversion-Korrekturen nur bis 7 Tage nach Erfassung auf automatische Gebote, in Berichten sind sie bis 54 Tage möglich. Eine Retoure, die nach Tag 7 hereinkommt, bereinigt also den Bericht, nicht das Signal, von dem die Gebotsstrategie gelernt hat.

Daraus folgen zwei Dinge. Erstens gehört der Upload nicht in einen Monatsrhythmus: Wer einmal im Monat korrigiert, verfehlt das Gebotsfenster bei den meisten Bestellungen und pflegt nur noch den Report. Ich würde täglich übertragen, laut Google am besten frühestens 24 Stunden nach der Conversion. Die Umsetzung beschreibt der Artikel Retouren in Google Ads übertragen. Zweitens bleibt auch bei täglichem Upload ein Rest, und der gehört in den Ziel-ROAS.

Das Rechenbeispiel, alle Zahlen angenommen: 100.000 Euro gemeldeter Wert, 20 Prozent Retouren, davon drei Viertel nach Tag 7.

Die Korrekturformel dazu ist eine einfache Verhältnisrechnung: Ziel-ROAS im Konto = Soll-ROAS auf behaltenem Umsatz × Wert im Signal ÷ behaltener Umsatz. Soll das Konto ROAS 5 auf behaltenen Umsatz bringen, ergibt das 5 × 95.000 ÷ 80.000, also rund 5,9. Ohne jede Korrektur stünde im Signal der volle Wert, und der Zielwert läge bei 6,25. Wie du den Soll-ROAS bestimmst, steht in Ziel-ROAS aus der Marge herleiten.

Das ist meine Einschätzung, keine Google-Empfehlung, und sie hat Grenzen. Sie setzt voraus, dass der Shop Rückläufe je Bestellnummer auswertet und die Quote nach Tag 7 kennt. Hast du Retouren im Soll-ROAS schon eingerechnet, ziehst du sie hier nicht ein zweites Mal ab. Unterscheiden sich die Quoten stark zwischen Sortimenten, ist ein Kontofaktor grob, dann rechnest du je Margen- oder Warengruppe. Und ein höheres Ziel kostet Volumen, was bewusst entschieden sein will. Wer kaum späte Retouren hat, braucht den Abschlag nicht.

Was im Auftrag an Agentur oder Entwicklung stehen sollte

Der Auftrag beschreibt Ergebnisse, die du selbst nachprüfen kannst. Diese Punkte würde ich hineinschreiben:

• Genau eine primäre Kauf-Aktion, Liste aller übrigen Aktionen mit Status, benutzerdefinierte Ziele offengelegt
• Transaction-ID aus dem Shop, kein GG_-Präfix, keine Kundendaten, Wert ohne Versand und Steuern
• Testkauf-Protokoll je relevanter Zahlungsart mit Bestell-ID, Wert, Währung und Ziel
• Bestellabgleich gegen das Backend für einen festen Zeitraum, mit Erklärung der gefundenen Muster
• Benannte Person, die nach Checkout- oder Plugin-Änderungen neu abnimmt
• Ab Stufe 3: tägliche Korrekturübertragung auf einer Aktion, die Korrekturen annimmt, und eine ausgewiesene Quote später Retouren

Fehlt einer dieser Nachweise, ist der ROAS im Report eine Behauptung, und ich würde auf ihm kein höheres Budget freigeben. Serverseitiges Tagging und Warenkorbdaten lasse ich hier bewusst weg: Beides kann später sinnvoll werden, ändert aber nichts an dieser Abnahme, denn auch ein serverseitiger Aufbau muss denselben Bestellabgleich bestehen.