Tracking V2: Ereignisse und Fehlersuche

Tracking V2 trennt Browseraktionen und fachliche Ereignisse aus edoobox. Ein Klick auf «Buchen» ist noch kein bestätigter Kauf; ein Zahlungseingang ist nicht automatisch ein zweiter Kauf. Verwenden Sie diese Unterscheidung für Berichte und Conversion-Ziele.

Browserereignisse im Buchungsweg

Ereignis	Auslöser
view_item_list	Eine tatsächliche Angebots-/Listenansicht.
view_item	Eine tatsächliche Angebotsdetailansicht.
select_item	Klick auf einen Angebots-Detailslink.
add_to_cart	Tatsächliche Erhöhung einer Preis- oder Zusatzleistungsmenge. Unveränderte oder reduzierte Mengen erzeugen diesen Auslöser nicht.
begin_checkout	Der erste angezeigte Buchungsschritt, einmal je Vorgang und Browsersitzung.
add_payment_info	Auswahl einer Zahlungsmethode oder Absenden der vorausgewählten Methode.
waitlist_join	Zugelassener Integrationshook; die fachliche Bestätigung der Wartelistenanmeldung wird serverseitig bestimmt.

Im dataLayer heissen die V2-Trigger edoobox_v2_<ereignis>. Zusätzlich stehen edoobox_event_name und edoobox_analytics_version: 2 zur Verfügung. Der exportierte Container leitet die zugelassenen Standardnamen weiter. Im iFrame-Betrieb gelangen diese Ereignisse über den geprüften Kanal in den dataLayer der Elternwebsite.

Namen, E-Mail-Adressen und freie Formularwerte werden nicht als allgemeine Funnel-Parameter übernommen.

Kauf, Zahlung und Rückabwicklung

Ereignis	Bedeutung
purchase	Abgeschlossene, bestätigte Buchung ohne Wartelisten-, MustPay- oder Annullierungsstatus.
payment	Eine tatsächliche Zahlung im zugehörigen Vorgang.
booking_cancelled	Annullierung der Buchung.
refund	Erfasste Rückzahlung beziehungsweise fachliche Rückabwicklung.

Ein MustPay-Abschluss oder eine Wartelistenanmeldung darf nicht schon als definitiver Kauf ausgewertet werden. Wenn sich der Status später ändert, muss die Auswertung den tatsächlichen Zustand berücksichtigen.

Die Google-Kaufwerte unterscheiden Nettowert (value), Steuer (tax) und Bruttowert (booking_gross_value). Die Transaktionskennung verbindet die öffentliche Buchungsreferenz mit der Währung. Eine Buchung mit mehreren Währungen darf deshalb nicht anhand eines blossen Browserklicks zu einer einzigen beliebigen Summe zusammengefasst werden.

Unterschiede zwischen den Anbietern

Google Analytics: erhält die dafür zugelassenen Ereignisse mit dem erfassten Analysekontext.
Microsoft Ads: erhält Kauf, Zahlung, Storno, Erstattung und Warteliste als getrennte benutzerdefinierte Ereignisse.
ChatGPT / OpenAI Ads: erhält den Kauf als order_created; die übrigen Zustände als benutzerdefinierte Ereignisse.

Bei Microsoft und OpenAI ziehen Storno-/Erstattungsereignisse eine ursprüngliche Kauf-Conversion nicht automatisch zurück. Richten Sie Ihre Ziele so ein, dass zusätzliche Zahlungsereignisse keine weiteren Käufe zählen.

Letzte Ereignisse und Verbindungsprüfung

Öffnen Sie Einstellungen → Google & E-Commerce → Serverseitiges Tracking V2.
Prüfen Sie unter Letzte Ereignisse Anbieter, Ereignisname, Buchungsbezug, Status, Fehlercode und Zeitpunkt.
Prüfen Sie nach Änderungen an Zugangsdaten zuerst die gespeicherte Verbindung beziehungsweise Konfiguration.
Vergleichen Sie anschliessend einen kontrollierten Vorgang mit dem tatsächlichen Bericht im Zielsystem.

Eine erfolgreiche Prüfung hat je Anbieter einen anderen Umfang: Google prüft den Prüfaufruf und dessen Rückmeldungen; Microsoft prüft lokal die Konfigurationsvollständigkeit; OpenAI validiert ohne Speicherung eines Conversion-Ereignisses. Keine dieser Anzeigen garantiert allein eine spätere Attribution in einem Bericht.

Auch eine HTTP-Annahme durch einen Anbieter beweist noch keine vollständige Verarbeitung. Bei einer ungewissen Übertragung darf eine erneute Buchung nicht als technische Wiederholung verwendet werden.

Häufige Fehlerbilder eingrenzen

Beobachtung	Prüfen Sie
Keine Browserereignisse	Aktive V2-Konfiguration, Google-Tag für dieselbe Mess-ID, Einwilligung, V2-Web-Container und Website-Helper.
iFrame sendet keinen Kontext	Exakte iFrame-ID, bookingOrigin, Mess-ID, Anbieterwahl und Referrer-Einstellung. Nach einer CMP-Änderung den Helper aktualisieren.
Funnel vorhanden, Kauf fehlt	Definitiver Buchungsstatus, gespeicherte Zielkonfiguration, zulässiger Kontext und serverseitige Ereignisliste. Warteliste/MustPay sind kein definitiver Kauf.
Kauf wird doppelt gezählt	Alte edoobox-Kauf-Tags, weitere Browserpixel und Conversion-Ziele für payment/refund kontrollieren.
Werbeereignis fehlt	Aktiven Anbieter, dessen Zugang, Website-Anbieterschalter und getrennte Freigaben für ad_storage und ad_user_data.
Nach Änderung weiterhin falsches Ziel	Speichern in edoobox und passende Helper-Konfiguration auf der Website; jede eingebettete Instanz gehört zum vorgesehenen Konto.

Für eine Supportanfrage genügen Konto, Anbieter, Buchungsreferenz, Zeitpunkt und sichtbarer Fehlercode. Versenden Sie keine API-Secrets oder ungekürzten Anfrageinhalte mit Teilnehmerdaten.

Beispiel: Warteliste und Zahlung getrennt auswerten

Ein ausgebuchtes Seminar erzeugt zunächst eine Wartelistenanmeldung. Das Team zählt diese als Interesse, nicht als Kauf. Erst nach Übernahme in eine bestätigte Buchung wird ein Kauf erwartet. Eine spätere Bankzahlung ist ein Zahlungseingang. Der Bericht zählt die Person deshalb nicht bei jeder Zustandsänderung nochmals als neuen Kauf.

Weiter: Tracking V2 einrichten · iFrame und Consent verbinden

Ungewisse Übertragung und doppelte Conversion vermeiden

Ein Timeout kann nach Annahme eines Ereignisses auftreten. Verwenden Sie weder eine neue Buchung noch eine künstlich neu datierte Conversion, um einen unsicheren Versand zu wiederholen. Lassen Sie Ereigniskennung, Zeitpunkt, Ziel und sichtbaren Status anhand desselben Vorgangs prüfen.

Wenn ein zusätzlicher Microsoft- oder OpenAI-Browserpixel dieselbe Conversion meldet, benötigt die vorgesehene Deduplizierung übereinstimmende Ereigniskennungen und Ereignisnamen. Ohne eine bewusst abgestimmte Umsetzung deaktivieren Sie den parallelen Conversion-Versand für denselben Abschluss. Ein payment-Ziel als weiterer Kauf erzeugt ebenfalls eine falsche Mehrfachzählung.