WooCommerce-Purchase-Tracking in GA4, Google Ads und GTM prüfen

Prüfe, ob [WordPress site] Käufe korrekt an GA4 und an [Google Ads account] meldet. 1. Täglicher Vergleich, letzte 14 vollständige Tage: - WooCommerce: Blättere durch wordpress_woo_orders, bis du bei Bestellungen angekommen bist, die älter als 14 Tage sind. Zähle pro Tag nur abgeschlossene (completed) und in Bearbeitung befindliche (processing) Bestellungen. Sag mir Bescheid, wenn die Bestellungen vor Tag 14 enden, und behandle Bestellungen, die nach Tests aussehen (mein eigener Name, Summe 0), separat. - GA4: Führe ga4_report mit der Dimension "date" und dimension2 "event" aus und nimm nur die Anzahl des purchase-Events. Verwende nicht die Gesamtzahl der Conversions, denn sie summiert alle Key Events. - Google Ads: Führe google_ads_query auf die Purchase-Conversion-Aktion aus, segmentiert nach segments.date und segments.conversion_action_name, damit andere Aktionen die Zahl nicht aufblähen. Beachte, dass Google Ads Conversions nach Klickdatum meldet, sodass sich die letzten Tage noch nachträglich füllen können. - Notiere die Zeitzonen von Shop, GA4-Property und Ads-Konto, falls sie voneinander abweichen, da sich dadurch Bestellungen auf andere Tage verschieben. 2. Einstellungen: - Bestätige mit ga4_list_conversions, dass purchase ein Key Event ist. - Bestätige mit list_conversion_actions und get_conversion_settings, dass die Ads-Purchase-Aktion aktiviert ist, in den Conversions enthalten ist (primär) und Daten aufgezeichnet hat, und prüfe die Zählart. MANY_PER_CLICK bei einer Purchase-Aktion ist eine häufige Ursache für Überzählung. 3. Tag-Inventar: - wordpress_tracking für jede Stelle, an der ein GA4- oder GTM-Tag ausgelöst wird (Plugins, WPCode-Snippets, Header-/Footer-Code, Theme-Optionen). Lies jedes verdächtige Snippet mit wordpress_snippet und jede Theme-Option, auf die es verweist, mit wordpress_option. - wordpress_list_plugins für Plugins, die Purchase-Daten eigenständig senden (zum Beispiel GTM4WP, WooCommerce Google Analytics, Site Kit, PixelYourSite). - Liste in GTM die Tags und Trigger im Workspace des Live-Containers auf und markiere jeden Tag, der purchase an GA4 oder eine Google-Ads-Conversion sendet, mit Conversion-ID/-Label und Trigger-Bedingungen. Nutze gtm_workspace_status, um zu sehen, ob eine Purchase-Änderung unveröffentlicht herumliegt. - Der Consent Mode lässt sich nicht als einzelne Einstellung auslesen. Berichte, was das Tag-Inventar zeigt (ein Consent-Plugin, Consent-Einstellungen in GTM-Tags, ein Consent-Snippet), und sag klar, wenn du es nicht beurteilen kannst. Ergebnis: - Eine Tagestabelle mit diesen Spalten: Datum, Bestellungen, GA4-Käufe, Google-Ads-Conversions, GA4-Abweichung in % ggü. Bestellungen, Ads-Abweichung in % ggü. Bestellungen. - Eine nummerierte Liste der Befunde, jeweils mit den Belegen, die sie stützen. Nutze diese Schwellenwerte nur als Anhaltspunkte und bestätige die Ursache dann anhand des Inventars: - Mehr als 10 % über den Bestellungen: Suche nach zwei Quellen, die denselben Kauf senden (ein Plugin plus ein GTM-Tag, zwei Container), einer fehlenden transaction_id, MANY_PER_CLICK-Zählung oder einem Danke-Seiten-Trigger, der beim Neuladen erneut auslöst. - Mehr als 25 % unter den Bestellungen: Suche nach einem fehlenden oder unveröffentlichten Tag, einer Trigger-Bedingung, die die Danke-URL verfehlt, Consent-Blockierung oder einem Zahlungsanbieter, der nicht zur Danke-Seite zurückleitet. Wenn die Bestelldaten die Zahlungsart nicht zeigen, frag mich, welche Zahlungsanbieter wir nutzen. Schlage Korrekturen vor und nenne dabei genau den Tag, Trigger, das Snippet oder Plugin, das geändert werden soll. Nimm keine Änderungen vor, bis ich eine Vorschau der jeweiligen Änderung freigegeben habe.