Externe Analytics und Consent einrichten

Verwenden Sie diesen Ablauf, wenn Sie Online-Ticketkäufe an eine kundenseitig verwaltete Analytics-Plattform, einen Tag-Manager, ein Marketing-Pixel oder eine andere Zielplattform senden möchten. KORONA Event stellt einen einwilligungsabhängigen Vertrag für Kauf-Events bereit. Ihr Team oder Ihre Agentur stellt den Consent-Manager, den Zielplattform-Code sowie erforderliche Adapter und Feldtransformationen bereit.

KORONA Event ist der Produktname. toucantix_booking_event ist der bisherige technische Namespace im Datenschichtvertrag. Übernehmen Sie diesen Namespace bei der Einrichtung einer Integration unverändert.

Was wird unterstützt?

Anforderung	Unterstützung durch KORONA Event	Wer schließt die Einrichtung ab?
Externe Analytics oder Tag-Manager	Kundenseitig verwalteter HTML- und JavaScript-Code kann auf Shop-, Zahlungs- und Erfolgsseiten von KORONA Event geladen werden, jedoch nicht auf der Website eines externen Zahlungsanbieters.	Ihr Team oder Ihre Agentur installiert, veröffentlicht und verwaltet den Anbieter-Code oder Container.
Marketing-Pixel oder andere Browser-Zielplattform	Ein Event-Adapter kann auf `purchase` reagieren und nach der zielplattformspezifischen Einwilligung ein kompatibles SDK oder eine API aufrufen.	Prüfen Sie die Kompatibilität, implementieren Sie erforderliche Feldtransformationen und konfigurieren Sie die Consent-Steuerung der Zielplattform.
Erfolgreiche Bestellung oder Danke-Seite	Eine bezahlte Bestellung löst auf der Erfolgsseite `purchase` aus, wenn die Analytics-Einwilligung bereits aktiv ist.	Lösen Sie die Zielplattform durch `purchase` aus. Verwenden Sie nicht ausschließlich die Seiten-URL.
Kaufdetails	Das Kaufobjekt enthält Transaktions-ID, Brutto-Bestellwert, Währung, Steuer, angewendete Gutscheinnummern und Artikel. Die Bedeutungen können vom Schema einer Zielplattform abweichen.	Lesen Sie den Payload-Vertrag und transformieren Sie Werte vor der Weiterleitung, wenn die Zielplattform andere Bedeutungen verwendet.
Kampagnenzuordnung	Kampagnenparameter und Anzeigen-Klick-IDs aus der Shop-Landingpage können einwilligungsbasierten Events beigefügt werden.	Erhalten Sie die Parameter beim Link in den Shop und ordnen Sie sie nur dort zu, wo die Zielplattform diese Verwendung unterstützt.
Ausgearbeitetes Google-Beispiel	Das dokumentierte Beispiel behandelt GTM, GA4, Google Ads-Kauf-Conversions, Google Consent Mode und Google-spezifische Zuordnungsmechanismen.	Erstellen und konfigurieren Sie die Google-Konten, Tags, Consent-Steuerung und erforderlichen Transformationen.
Cookie- oder Consent-Banner	Eigener Consent-Manager-Code kann auf allen Shop-Seiten eingebunden werden.	Wählen, lizenzieren, konfigurieren und rechtlich prüfen Sie den Consent-Manager. KORONA Event stellt kein integriertes Cookie-Banner bereit.
Serverseitige Benachrichtigung über bezahlte Bestellungen	Der Webhook Bestellung abgerechnet meldet abgerechnete Bestellungen.	Erstellen und betreiben Sie den empfangenden Dienst. Der Webhook enthält keine Browser-Kampagnenparameter oder Anzeigen-Klick-IDs.

KORONA Event stellt keine native oder verwaltete Verbindung zu einer bestimmten Analytics-Plattform, einem Tag-Manager, Pixel, Marketing-Ziel oder einer Consent-Management-Plattform bereit. Benutzerdefinierte HTML- und JavaScript-Schnipsel und der Vertrag des Kauf-Events sind Erweiterungsmöglichkeiten. Ein anderer Anbieter kann sie nur verwenden, wenn Ihr kundenseitig verwalteter Schnipsel oder Adapter den dokumentierten Vertrag verarbeiten und die technischen, Consent- und Datenanforderungen des Anbieters erfüllen kann.

Bevor Sie beginnen

Bereiten Sie Folgendes vor:

das Zielplattform-Konto und die Dokumentation für SDK, Container, Pixel oder API
eine Feldzuordnung vom dokumentierten Kauf-Event-Vertrag zu den Bedeutungen, die die Zielplattform verlangt
einen Consent-Manager, der die gespeicherte Entscheidung des Besuchers wiederherstellen und bei Änderungen JavaScript aufrufen kann
die Anforderungen der ausgewählten Zielplattform an Kampagnenlinks und domainübergreifende Verknüpfung
die rechtliche Freigabe für Einwilligungskategorien, Speicherdauer und Zielplattformen
einen bezahlten Test-Checkout und Zugriff auf die Vorschau- oder Diagnoseansicht der Zielplattform

Bereiten Sie für das Google-Beispiel zusätzlich die GTM-Container-ID oder den freigegebenen gtag-Code, die GA4-Property, die Google Ads-Conversion-Aktion, Google Ads Auto-Tagging, ein websiteweites Google-Tag oder einen Conversion Linker sowie eine gegebenenfalls erforderliche domainübergreifende Verknüpfung vor.

Legen Sie vor dem Start fest, wer welche Ebene verantwortet: KORONA Event erzeugt das Kauf-Event, der Consent-Manager entscheidet über optionales Tracking, Ihr Schnipsel oder Adapter transformiert und leitet das Event weiter und die externe Zielplattform zeichnet es auf. Ihre Organisation bleibt für Anbieterkompatibilität und Kontokonfiguration verantwortlich.

1. Analytics-Modus auswählen

Die Modi unterscheiden sich darin, welche Daten KORONA Event selbst erfasst, was Ihre Datenschicht erreicht und ob Kampagnenparameter erfasst werden:

Modus	Interne Erfassung durch KORONA Event	Kundenseitige Datenschicht und Kampagnenerfassung
Datenschutzfreundlich	Erfasst bereinigte Shop-Events ohne Besucher-, Kontakt-, Bestell-, Rechnungs-, Sitzungs- oder Kampagnenkennungen. Shop- und Seitenkontext sowie Commerce-Messwerte können enthalten sein.	Keine von KORONA Event erzeugten Buchungs- oder E-Commerce-Events erreichen `window.dataLayer`. Kampagnen- und Klickparameter werden nicht erfasst oder gespeichert. Dies ist die Standardeinstellung.
Einwilligungsbasiert	Erfasst vor der Analytics-Einwilligung dieselben bereinigten Events wie Datenschutzfreundlich. Bei aktiver Einwilligung wird der umfangreichere Analytics-Kontext erfasst.	Vor der Analytics-Einwilligung erreicht nichts `window.dataLayer` und Kampagnenparameter werden nicht erfasst. Bei aktiver Einwilligung werden E-Commerce-Events und Kampagnenkontext hinzugefügt.
Deaktiviert	Erzeugt keine Shop-Analytics-Events von KORONA Event.	Keine KORONA Event-Analytics-Events erreichen `window.dataLayer`. Kampagnen- oder Klickparameter werden nicht erfasst oder gespeichert.

Öffnen Sie im Backoffice Shops und wählen Sie den Shop aus.
Öffnen Sie Checkout.
Wählen Sie unter Analytics als Modus für die Einrichtung in diesem Artikel Einwilligungsbasiert.
Speichern Sie den Shop.

Öffnen Sie für den Shop Code-Schnipsel.
Fügen Sie unter Benutzerdefinierte HTML- und JavaScript-Schnipsel die Consent-Brücke und den Consent-Manager hinzu. Wählen Sie unter Platzierung die Option Oben in <head>. Die Brücke muss ausgeführt werden, bevor der Consent-Manager seinen Melde-Callback aufruft. Die gespeicherte Einwilligung muss wiederhergestellt sein, bevor eine bezahlte Bestellung das Erfolgs-Event erreicht.
Fügen Sie GTM oder anderen Analytics-Code als eigenen Schnipsel hinzu. Verwenden Sie Oben in <head>, wenn der Anbieter eine frühe Initialisierung verlangt und Ihr Consent-Manager das Skript korrekt blockiert. Verwenden Sie Anfang von <body> für optionale Skripte, die bis nach dem Laden der Seite warten können.
Behalten Sie bei voneinander abhängigen Schnipseln die benötigte Reihenfolge bei und speichern Sie den Shop.

Benutzerdefinierte HTML- und JavaScript-Schnipsel für Consent-Manager und Analytics-Tags — Fügen Sie Consent-Manager, Consent-Brücke und GTM- oder Analytics-Schnipsel getrennt hinzu, damit Reihenfolge und Platzierung eindeutig sind.

Schnipsel am Anfang von <body> starten nach dem ersten Laden der Seite, sobald der Browser freie Zeit hat. Ein geordnetes externes Body-Skript, das nicht innerhalb von 10 Sekunden lädt, wird übersprungen, damit nachfolgende Schnipsel fortfahren können. Legen Sie die Wiederherstellung der Einwilligung nicht ausschließlich in einen verzögerten Body-Schnipsel: Das Erfolgs-Event einer bezahlten Bestellung kann vorher ausgelöst werden.

Bei jedem vollständigen Laden einer Shop-, Zahlungs- oder Erfolgsseite muss Ihr Consent-Manager seine gespeicherte Entscheidung lesen und den aktuellen Status erneut melden. Er muss auch eine spätere Zustimmung, Ablehnung oder einen Widerruf melden. KORONA Event speichert die Entscheidung des Besuchers aus Ihrem Consent-Manager nicht für Sie.

Der Shop stellt zwei gleichwertige Controller-Namen bereit:

javascript

window.ShopBookingAnalytics;
window.__SHOP_BOOKING_ANALYTICS__;

Die folgende anbieterunabhängige Brücke wartet kurz auf den Controller. Fügen Sie sie weit oben in den Schnipseln mit der Platzierung Oben in <head> hinzu. Rufen Sie anschließend window.reportKoronaEventConsent beim Wiederherstellen des Anfangsstatus und bei jeder Änderung im Consent-Manager auf:

html

<script>
  (function () {
    var latestChoice = { analytics: false, marketing: false };
    var retryStartedAt = 0;
    var retryTimer = null;

    function warn(message, error) {
      if (window.console && typeof window.console.warn === "function") {
        window.console.warn(message, error || "");
      }
    }

    function applyChoice() {
      var analytics = window.ShopBookingAnalytics || window.__SHOP_BOOKING_ANALYTICS__;

      if (analytics && typeof analytics.setConsent === "function") {
        try {
          analytics.setConsent(latestChoice);
        } catch (error) {
          warn("[KORONA Event analytics] Could not apply consent.", error);
        }
        retryTimer = null;
        return;
      }

      if (Date.now() - retryStartedAt < 10000) {
        retryTimer = window.setTimeout(applyChoice, 50);
      } else {
        retryTimer = null;
        warn("[KORONA Event analytics] Consent controller did not become available within 10 seconds.");
      }
    }

    window.reportKoronaEventConsent = function reportKoronaEventConsent(choice) {
      choice = choice || {};
      latestChoice = {
        analytics: choice.analytics === true,
        marketing: choice.marketing === true,
      };
      retryStartedAt = Date.now();

      if (retryTimer === null) {
        applyChoice();
      }
    };
  })();
</script>

Passen Sie die Namen der Callbacks an Ihren Consent-Manager an. Die Aufrufe selbst folgen diesem Muster:

javascript

// Analytics- und Marketing-Einwilligung wiederherstellen oder erteilen.
window.reportKoronaEventConsent({ analytics: true, marketing: true });

// Optionale Analytics- und Marketing-Einwilligung ablehnen oder widerrufen.
window.reportKoronaEventConsent({ analytics: false, marketing: false });

Verwenden Sie die für Ihre Organisation tatsächlich freigegebenen Kategorien. Kopieren Sie das Beispiel mit true nicht als voreingestellte Einwilligung.

Der Wert analytics steuert die einwilligungsbasierte Speicherung und die Datenschicht-Events von KORONA Event. Deshalb kann ein purchase-Event window.dataLayer erreichen, wenn analytics den Wert true und marketing den Wert false hat. Der Wert marketing ersetzt nicht die Werbe-Einwilligung, die Ihr Consent-Manager, GTM, Google Consent Mode, Google Ads oder geltendes Recht verlangt. Konfigurieren Sie diese Anforderungen getrennt, damit Werbe-Tags nicht bei einer reinen Analytics-Einwilligung ausgelöst werden.

Die Einwilligung muss vor dem Kauf-Event aktiv sein

KORONA Event hält kein Kauf-Event zurück und wiederholt es nicht, während das System auf einen Consent-Manager wartet. Die Erfolgsseite erzeugt das Event clientseitig, nachdem die Seite eingebunden wurde und ihre Rechnungsabfrage abgeschlossen ist. Das Event ist nicht an DOMContentLoaded gebunden. Für eine asynchron geladene CMP gibt es keine garantierte Wartezeit. Deshalb kann ein CMP-Skript von einem CDN eine bezahlte Conversion verlieren, wenn es eine bereits gespeicherte Auswahl zu spät wiederherstellt. Verwenden Sie den unterstützten synchronen Bootstrap oder die Inline-API der CMP unter Oben in <head>, um die vorhandene Entscheidung aus dem First-Party-Cookie oder Local Storage zu lesen und vor dem asynchronen CMP-Skript zu melden. Rekonstruieren Sie das Speicherformat der CMP nicht selbst. Wenn die Erfolgsseite purchase erzeugt, bevor die Brücke analytics: true meldet, wird diese Conversion auf derselben Seite später nicht zu window.dataLayer hinzugefügt.

Wurde ein Kauf bei abgelehnter Analytics-Einwilligung erzeugt, kann er nach einer späteren Zustimmung beim Neuladen der Erfolgsseite gesendet werden, sofern die gespeicherte Auswahl vor Abschluss der Rechnungsabfrage wiederhergestellt wird. Für das abgelehnte Event wurde kein einwilligungsbasierter Browser-Ledger geschrieben. Wurde der Kauf bereits mit Einwilligung gesendet und im Ledger erfasst, wird das Neuladen dedupliziert. Verwenden Sie das Neuladen der Erfolgsseite nicht als Ablauf zur Wiederherstellung von Einwilligungen oder Conversions.

Die Meldung analytics: false stoppt neue einwilligungsbasierte Datenschicht-Events und die weitere Verwendung des Analytics-Speichers. Sie löscht keinen bereits im Browser gespeicherten Analytics-Kontext, entfernt kein bereits an window.dataLayer übergebenes Event und ruft keine Daten zurück, die ein Tag bereits an GA4, Google Ads oder einen anderen Anbieter weitergeleitet hat oder die dort gespeichert sind. Ihre Organisation ist für die Bereinigung durch CMP und Tags, die Speicherdauer sowie alle erforderlichen anbieterseitigen Aufbewahrungs- oder Löschprozesse verantwortlich.

Der Shop sendet kein öffentliches Event, sobald der Controller bereit ist. Deshalb ist das zeitlich begrenzte Polling in der Brücke das primäre Muster. Eine Integration, die nachweislich erst nach dem Shop-Controller startet, kann stattdessen dieses Browser-Event senden:

javascript

window.dispatchEvent(
  new CustomEvent("shop-booking-analytics:consent-update", {
    detail: { analytics: true, marketing: true },
  }),
);

Die KORONA Event Consent-Brücke und Google Consent Mode steuern unterschiedliche Ebenen. Die Brücke legt fest, wann KORONA Event Analytics-Kontext speichern und E-Commerce-Events zu window.dataLayer hinzufügen darf. Google Consent Mode steuert das Verhalten der Google-Tags. Verbinden Sie beide Ebenen mit demselben Consent-Manager und verwenden Sie die für Ihre Organisation freigegebenen Kategorien und Standardwerte.

Wenn Sie GTM verwenden:

Verwenden Sie nach Möglichkeit die Vorlage Ihrer Consent-Management-Plattform aus der Community Template Gallery.
Lösen Sie die Consent-Vorlage mit Consent Initialization - All Pages aus, damit sie Standardwerte vor allen Tags festlegt, die Messdaten senden.
Verwenden Sie in einer eigenen GTM-Vorlage die Tag-Manager-Consent-APIs setDefaultConsentState und updateConsentState. Ersetzen Sie diese APIs in der Vorlage nicht durch eingereihte gtag('consent', ...)-Befehle.
Aktualisieren Sie alle relevanten Consent-Typen, sobald der Besucher eine Auswahl ändert, und stellen Sie die gespeicherte Auswahl bei jedem weiteren Seitenladen wieder her.

Wenn Sie das Google-Tag ohne GTM direkt verwenden, setzen Sie einen standardmäßig abgelehnten Status vor den Google-Tag-Loader und vor jeden config- oder event-Befehl:

html

<script>
  window.dataLayer = window.dataLayer || [];
  window.gtag =
    window.gtag ||
    function () {
      window.dataLayer.push(arguments);
    };

  window.gtag("consent", "default", {
    analytics_storage: "denied",
    ad_storage: "denied",
    ad_user_data: "denied",
    ad_personalization: "denied",
  });
</script>

Rufen Sie ein Update aus dem Consent-Manager auf, sobald der Besucher eine Auswahl speichert oder ändert. Verwenden Sie getrennte Werte, damit die Zuordnung Ihren freigegebenen Kategorien folgen kann:

html

<script>
  window.updateGoogleConsent = function updateGoogleConsent(choice) {
    window.gtag("consent", "update", {
      analytics_storage: choice.analyticsStorage === true ? "granted" : "denied",
      ad_storage: choice.adStorage === true ? "granted" : "denied",
      ad_user_data: choice.adUserData === true ? "granted" : "denied",
      ad_personalization: choice.adPersonalization === true ? "granted" : "denied",
    });
  };
</script>

Google Consent Mode speichert die Entscheidung des Besuchers nicht für Sie. Legen Sie bei jedem vollständigen Seitenladen zuerst den Standardstatus fest. Anschließend muss der Consent-Manager seine gespeicherte Auswahl lesen und das Update aufrufen, sobald die Auswahl bekannt ist. Senden Sie ein weiteres Update, wenn der Besucher seine Einwilligung ändert oder widerruft.

Betrachten Sie die Eigenschaftsnamen in diesem Beispiel nicht als allgemeingültige Kategoriezuordnung. Ihre Organisation muss festlegen, wie ihre rechtlich freigegebenen CMP-Kategorien analytics_storage, ad_storage, ad_user_data und ad_personalization zugeordnet werden. Sie muss außerdem zwischen Basic Consent Mode, der Google-Tags vor der Einwilligung blockiert, und Advanced Consent Mode wählen, bei dem Google-Tags mit abgelehnten Consent-Statuswerten geladen werden können. Diese Wahl ändert die KORONA Event-Regel nicht: purchase erreicht window.dataLayer erst, nachdem die Brücke analytics: true erhalten hat.

Einzelheiten zur anbieterspezifischen Umsetzung finden Sie in der Google-Dokumentation zum Einrichten des Consent Mode und zum Erstellen einer GTM-Consent-Vorlage.

3. Externe Zielplattform verbinden

Verwenden Sie diesen anbieterunabhängigen Ablauf für eine Analytics-Plattform, einen Tag-Manager, ein Pixel oder eine andere Browser-Zielplattform:

Lesen Sie den Vertrag der Purchase-Payload, einschließlich der Bedeutungen von KORONA Event für Wert, Steuer, Gutscheine, Artikel und Kampagnenfelder.
Erstellen Sie einen kundenseitig verwalteten Schnipsel oder Event-Adapter, der auf purchase reagiert, die Felder in die Semantik der Zielplattform transformiert und anschließend ein kompatibles SDK oder eine API der Zielplattform aufruft.
Lassen Sie diesen Aufruf erst nach der zielplattformspezifischen Einwilligung zu, die Ihr freigegebenes CMP-Konzept verlangt. analytics: true in KORONA Event steuert das Kauf-Event, erteilt aber nicht automatisch die Einwilligung für jede externe Zielplattform.
Verwenden Sie die Transaktions-ID zur zielseitigen Deduplizierung, sofern diese unterstützt wird, und legen Sie fest, wie Ihre Integration mit Lebenszyklus-Events umgeht, die die Purchase-Payload nicht bereitstellt.
Prüfen Sie einen bezahlten Kauf bei erteilter, abgelehnter und später widerrufener Einwilligung. Ablehnung und Widerruf müssen weitere Aufrufe der Zielplattform verhindern. Ein Widerruf kann bereits gesendete Daten nicht zurückrufen.

Der Code der Zielplattform, der Adapter, Transformationen, die Consent-Zuordnung und die Kontokonfiguration bleiben kundenseitig verwaltet. Dieser Ablauf bedeutet keine native Kompatibilität mit einem bestimmten Anbieter.

Anwendungsbeispiel: GTM, GA4 und Google Ads

Der folgende Ablauf verwendet GTM, um einen Kauf an GA4 und Google Ads weiterzuleiten. Wenn Sie eine andere Zielplattform verwenden, setzen Sie stattdessen den oben beschriebenen anbieterunabhängigen Ablauf mit dem unterstützten SDK oder der API dieses Anbieters um.

Gehen Sie in Ihrem GTM-Container wie folgt vor:

Erstellen Sie Datenschichtvariablen für die Felder, die Ihre Zielplattform benötigt:

Zweck	Datenschichtpfad
ID der einzelnen Event-Ausgabe	event_id
Version des Kaufvertrags	ecommerce.contract_version
Transaktions-ID	ecommerce.transaction_id
Währungsgerechter Brutto-Bestellwert	ecommerce.gross_value
Bisheriger Brutto-Bestellwert	ecommerce.value
Netto-Warenwert	ecommerce.items_net_value
Netto-Versandkosten	ecommerce.shipping
Währung	ecommerce.currency
Gekaufte Artikel	ecommerce.items
Währungsgerechte Gesamtsteuer	ecommerce.total_tax
Zahlungsart	ecommerce.payment_method
Nummern verwendeter Gutscheine, durch Kommas getrennt	ecommerce.coupon
Primäre Kategorie des ersten Artikels	ecommerce.items.0.item_category
Sekundäre Kategorie des ersten Artikels	ecommerce.items.0.item_category2
Erfasste Google Ads-Klick-ID für Diagnose oder eigene Integrationen	toucantix_booking_event.gclid
Kampagnenquelle	toucantix_booking_event.utm_source
Kampagnenmedium	toucantix_booking_event.utm_medium
Kampagnenname	toucantix_booking_event.utm_campaign
Kampagnenbegriff	toucantix_booking_event.utm_term
Kampagneninhalt	toucantix_booking_event.utm_content
Meta-Klick-ID	toucantix_booking_event.fbclid
Kampagnen-ID	toucantix_booking_event.campaign_id
Platzierungs-ID	toucantix_booking_event.placement_id

Für Felder auf Artikelebene sollten die meisten Integrationen das vollständige Array ecommerce.items übergeben. Die oben gezeigten Pfade mit .0. greifen nur auf den ersten Artikel zu und zeigen, wo sich diese Felder befinden.

Erstellen Sie einen Trigger vom Typ Benutzerdefiniertes Ereignis. Der Ereignisname lautet exakt purchase.
Erstellen Sie für GA4 ein GA4-Event-Tag für purchase. Transformieren Sie die Geld- und Gutscheinfelder wie unten beschrieben oder lassen Sie sie weg, bevor Sie sie GA4 zuordnen.
Erstellen Sie für Google Ads ein Google Ads-Conversion-Tag für die Kauf-Conversion-Aktion und ordnen Sie Transaktions-ID, Währung und den vorgesehenen Conversion-Wert zu. ecommerce.gross_value ist der währungsgerechte Brutto-Bestellwert. Verwenden Sie ihn nur dann direkt, wenn die Ads-Conversion-Aktion diesen Bruttowert melden soll.
Wenden Sie den purchase-Trigger und Ihre Consent-Anforderungen auf jedes Ziel-Tag an.
Veröffentlichen Sie den GTM-Container erst, nachdem die Tests mit erteilter und abgelehnter Einwilligung erfolgreich waren.

Ein GA4- oder Google Ads-Basis-Tag allein wandelt das purchase-Objekt von KORONA Event nicht automatisch in eine aufgezeichnete Conversion um. Wenn Sie GTM nicht verwenden, muss Ihr eigener Code das Event verarbeiten, die für die Zielplattform erforderlichen Transformationen anwenden und die Ziel-API mit den daraus entstehenden Werten aufrufen.

Kaufwerte und Gutscheine für GA4 transformieren

Das KORONA Event-Objekt ist wie ein GA4-Event aufgebaut, aber kein direkt versandfertiger GA4-Kauf. Seine Quellwerte folgen den Commerce-Regeln von KORONA Event:

ecommerce.gross_value ist der währungsgerechte Brutto-Bestellwert. Das bisherige Feld ecommerce.value behält aus Kompatibilitätsgründen seine historische Skalierung mit zwei Nachkommastellen.
Der price einer Position ist der konfigurierte Stückpreis. Ist kein konfigurierter Stückpreis verfügbar, wird der Bruttowert der Position durch die Menge geteilt. Der Wert kann deshalb Steuern enthalten.
ecommerce.total_tax ist die währungsgerecht skalierte, separat berechnete Gesamtsteuer. Das bisherige Feld ecommerce.tax behält seine historische Skalierung mit zwei Nachkommastellen.
unit_net_value einer Position ist der abgerechnete Netto-Stückwert nach Positionsrabatten. net_value, gross_value und tax sind die zugehörigen Positionssummen.
ecommerce.items_net_value ist die Summe der abgerechneten Netto-Positionssummen ohne Versandpositionen.
ecommerce.shipping ist der abgerechnete Netto-Versandbetrag. shipping_gross_value und shipping_tax enthalten den zugehörigen Brutto- und Steuerbetrag.
Die Fiskalfelder der Vertragsversion 2 verwenden die Hauptwährungseinheit. Die bisherigen Felder value, tax und das Positionsfeld price teilen kleinste Währungseinheiten weiterhin durch 100 und sind deshalb nur bei Währungen mit zwei Nachkommastellen korrekt skaliert. tax_rate ist ein numerischer Prozentsatz; 19 bedeutet also 19 %. included gibt an, ob diese Steuerkomponente im konfigurierten Preis enthalten war.

GA4 verlangt, dass der value eines Kaufs der Summe aus price * quantity aller übergebenen Positionen entspricht und weder Steuern noch Versand enthält. Ordnen Sie bei einem KORONA Event-Kauf der Vertragsversion 2 items_net_value dem GA4-Feld value, shipping dem GA4-Feld shipping und total_tax dem GA4-Feld tax zu. Entfernen Sie Positionen mit is_shipping: true aus dem GA4-Array items, da deren Wert bereits in shipping enthalten ist. Ordnen Sie bei jeder verbleibenden Position mit einer settled_quantity größer als null unit_net_value dem GA4-Artikelpreis und settled_quantity der GA4-Artikelmenge zu. Eine Warenposition, die ausschließlich Unterprodukt-Komponenten enthält, hat settled_quantity: 0, unit_net_value: null und einen net_value größer als null. Ordnen Sie deren vollständigen net_value dem GA4-Artikelpreis zu und verwenden Sie 1 als GA4-Artikelmenge. Diese synthetische Menge existiert nur im Adapter der Zielplattform und ändert nicht die maßgebliche settled_quantity von KORONA Event. Ordnen Sie die bisherigen Felder value, tax, price oder quantity nicht direkt GA4 zu, es sei denn, Ihre Zielplattform soll bewusst genau diese Werte erhalten.

ecommerce.coupon enthält die Nummer jedes verwendeten oder eingelösten Gutscheins. Bei mehreren Gutscheinen werden die Nummern durch Kommas verbunden. Hat ein Gutschein keine Nummer, kann sein Name als Ersatz erscheinen. Verwendete Aktions- oder Rabattcodes werden in dieser Payload nicht bereitgestellt. Ordnen Sie diesen Wert nur dann dem GA4-Feld coupon zu, wenn Ihre Organisation die Gutscheineinlösung bewusst als Werbeaktion auswertet. Lassen Sie ihn andernfalls weg oder transformieren Sie ihn.

Diese GA4-Regeln bestimmen nicht den Wert, der an eine Google Ads-Conversion-Aktion gesendet wird. Konfigurieren Sie den Ads-Wert getrennt gemäß den Anforderungen Ihrer Werbeauswertung und Gebotsstrategie.

Die offizielle Google-Spezifikation beschreibt die GA4-Parameter für das purchase-Event.

Google Ads-Klickzuordnung erhalten

Bei einer standardmäßigen Google Ads-Website-Conversion verwendet das Conversion-Tag die Klickinformationen, die das Google-Tag oder der Conversion Linker gespeichert hat. Richten Sie diese Zuordnung zusätzlich zum purchase-Trigger ein:

Führen Sie das Google-Tag gemäß dem gewählten Consent Mode auf allen relevanten Landing- und Conversion-Seiten aus. Wenn Ihr GTM-Container bereits auf jeder Seite ein Google-Tag lädt, ist normalerweise kein separater Conversion Linker erforderlich.
Wenn Ihre Einrichtung dieses websiteweite Google-Tag-Verhalten nicht bereitstellt, erstellen Sie ein Conversion Linker-Tag und lösen Sie es mit All Pages oder den passenden Triggern für Landing- und Conversion-Seiten aus. Beachten Sie dabei dieselben Consent-Anforderungen.
Wenn Marketingwebsite und Online-Shop unterschiedliche Domains verwenden, konfigurieren Sie die domainübergreifende Verknüpfung für beide Domains. Die Quellseite muss Links zum Shop kennzeichnen und die Zielseite muss den Linker-Parameter annehmen. Ein unveränderter gclid-Wert in der URL ersetzt diese Einrichtung nicht.
Ordnen Sie dem standardmäßigen Google Ads-Conversion-Tag weiterhin ecommerce.transaction_id, ecommerce.currency und den vorgesehenen Conversion-Wert zu. Verwenden Sie ecommerce.gross_value, wenn die Ads-Conversion-Aktion den währungsgerechten Bruttowert melden soll.

Ordnen Sie toucantix_booking_event.gclid nicht dem standardmäßigen Google Ads-Website-Conversion-Tag zu. Dieses Feld dient der Diagnose oder einer separat entwickelten eigenen beziehungsweise serverseitigen Integration. Das standardmäßige Website-Tag ordnet die Conversion über den Status des Google-Tags oder Conversion Linkers zu.

Die Google-Dokumentation zum Conversion Linker beschreibt die aktuellen Tag- und Domainoptionen.

Vertrag der Purchase-Payload

KORONA Event leert zuerst das vorherige E-Commerce-Objekt und übergibt anschließend den Kauf. Dieses vereinfachte Beispiel zeigt die derzeit für kundenseitig verwaltete Tags vorgesehenen Beta-Felder:

javascript

window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: "purchase",
  event_id: "event-id",
  ecommerce: {
    contract_version: 2,
    transaction_id: "INV-10042",
    value: 35.7,
    gross_value: 35.7,
    currency: "EUR",
    tax: 5.7,
    total_tax: 5.7,
    items_net_value: 25,
    shipping: 5,
    shipping_gross_value: 5.95,
    shipping_tax: 0.95,
    coupon: "VOUCHER-10042",
    payment_method: "card",
    items: [
      {
        item_id: "adult-ticket",
        item_name: "Adult",
        item_category: "ticket",
        item_category2: "event",
        price: 29.75,
        quantity: 1,
        settled_quantity: 1,
        unit_gross_value: 29.75,
        unit_net_value: 25,
        gross_value: 29.75,
        net_value: 25,
        tax: 4.75,
        tax_breakdown: [{ tax_rate: 19, tax_value: 4.75, included: true }],
        is_shipping: false,
      },
    ],
  },
  toucantix_booking_event: {
    event_name: "purchase",
    utm_source: "google",
    utm_medium: "cpc",
    utm_campaign: "summer-tickets",
    gclid: "example-click-id",
  },
});

Das tatsächliche Event kann weitere Felder und null-Werte enthalten. Verwenden Sie die oben dokumentierten Pfade als Integrationsvertrag der Beta-Version von KORONA Event. Übernehmen Sie weder die Beispielwerte noch die Annahme, dass sie bereits den Regeln eines anderen Anbieters entsprechen. contract_version kennzeichnet die dokumentierte Form der Kauf-Payload; während der Beta können weiterhin kompatible Felder ergänzt werden. Testen Sie Ihren Adapter nach Aktualisierungen von KORONA Event erneut.

event_id kennzeichnet eine einzelne Ausgabe eines Events. Der Wert wird jeweils neu erzeugt und ist kein stabiler Schlüssel zur Deduplizierung von Käufen. Verwenden Sie dafür transaction_id.
transaction_id verwendet die Rechnungsnummer, wenn sie verfügbar ist, und sonst die Bestellnummer.
contract_version: 2 kennzeichnet den additiv erweiterten Vertrag mit Fiskalfeldern. Die bisherigen Bedeutungen von value, dem Positionsfeld price und quantity bleiben erhalten. Bestehende Empfänger können die neuen Felder ignorieren.
gross_value und total_tax sind die währungsgerechten Brutto- und Steuer-Gesamtsummen der Vertragsversion 2. Die bisherigen Felder value und tax behalten aus Kompatibilitätsgründen ihre historische Skalierung „kleinste Währungseinheit geteilt durch 100“. Verwenden Sie diese Felder nur, wenn diese bisherige Skalierung beabsichtigt ist.
payment_method beschreibt die Zahlungsart in KORONA Event, wenn sie verfügbar ist.
items enthält gekaufte Ticket-, Produkt- und Versandpositionen. Wenn eine zusammengesetzte Preiszeile sowohl abgerechnete Versand- als auch Nicht-Versandpositionen enthält, erzeugt sie für jede Klassifizierung eine eigene Artikelzeile. Diese Zeilen behalten dieselbe bisherige Artikelidentität. Eine Zeile, vorzugsweise die Nicht-Versandposition, enthält den bisherigen price und die aktuelle quantity der Preiszeile in der Bestellung. Zusätzliche Zeilen verwenden price: null und quantity: 0, damit Systeme, die die Felder der Vertragsversion 2 ignorieren, den bisherigen Artikelwert nicht duplizieren. Eine abgerechnete Rechnungsposition, die keiner Preiszeile des Kaufs zugeordnet werden kann, wird als eigenständige Fiskalposition ausgegeben. Sie verwendet nach Möglichkeit die ID der Rechnungsposition und deren übersetzten Namen, hat die bisherigen Felder price: null und quantity: 0 und behält ihre maßgeblichen Fiskalfelder der Vertragsversion 2. Nehmen Sie diese eigenständigen Positionen in die Artikelzuordnung der Zielplattform auf, damit ihre Positionssummen mit items_net_value oder den Versand-Gesamtsummen übereinstimmen. Verwenden Sie is_shipping und die Fiskalfelder der Vertragsversion 2, statt davon auszugehen, dass item_id innerhalb des Arrays eindeutig ist. Das bisherige Feld price bleibt der konfigurierte Stückpreis oder ein aus dem Bruttowert abgeleiteter Ersatzwert. Es kann deshalb vom abgerechneten Fiskalwert nach Rabatten abweichen. item_category ist eine feste Angebotsklassifizierung von KORONA Event, zum Beispiel ticket, product, voucher, membership, donation, fee oder service. item_category2 ist der normalisierte Angebotstyp, zum Beispiel event, admission oder die entsprechende Klassifizierung eines anderen Angebots. Dies sind keine kundenseitig konfigurierten Katalogkategorien.
settled_quantity ist die Summe der zugeordneten Mengen abgerechneter Rechnungspositionen für die gekaufte Preiszeile. Separat abgerechnete Unterprodukt-Komponenten fließen in die passenden Fiskalsummen ein, erhöhen diese Menge aber nicht. Das bisherige Feld quantity bleibt die aktuelle Menge der Preiszeile in der Bestellung. unit_gross_value und unit_net_value sind die abgerechneten Positionssummen geteilt durch settled_quantity. Eine Versand- oder Nicht-Versandgruppe, die ausschließlich Komponenten enthält, hat settled_quantity: 0 und Stückwerte mit null. Wenn eine Zielplattform einen Stückpreis multipliziert mit einer Menge verlangt, stellen Sie eine reine Komponenten-Warenposition mit ihrem vollständigen net_value als Zielpreis und der synthetischen Zielmenge 1 dar. Ändern Sie nicht die settled_quantity von KORONA Event. gross_value, net_value und das Positionsfeld tax bleiben die maßgeblichen abgerechneten Positionssummen nach Positionsrabatten. Netto schließt enthaltene und zusätzlich berechnete Steuern aus; Brutto schließt beide ein.
Ein Browser-Stückwert kann kleinere Bruchteile als die übliche kleinste Währungseinheit enthalten, wenn sich eine Positionssumme nicht ohne Rest durch die Menge teilen lässt. Verwenden Sie für einen exakten Abgleich die Positionssummen.
tax_breakdown gruppiert die abgerechneten Steuerwerte jeder Kaufposition nach genauem Steuersatz und included-Status. Gehören mehrere abgerechnete Rechnungspositionen zur selben Kaufposition, werden ihre Werte zusammengefasst, ohne die kleinsten Währungseinheiten der Rechnung wegzurunden. Berechnen Sie bei gemischten Steuersätzen von 7 % und 19 % keine Steuer aus einem Durchschnittssatz neu.
is_shipping kennzeichnet Positionen, die beim Erstellen der abgerechneten Position den konfigurierten Versandartikel verwendet haben. Spätere Änderungen an der Versandartikel-Konfiguration klassifizieren diese gespeicherte Zuordnung nicht neu. Positionen, die bereits vor Einführung dieses Felds bestanden, wurden anhand des beim Upgrade konfigurierten Versandartikels klassifiziert. Ihre Zuordnung entspricht daher möglicherweise nicht einer früheren Konfiguration. items_net_value schließt Versandpositionen aus; shipping, shipping_gross_value und shipping_tax fassen sie getrennt zusammen.
Gutscheine, Kontotransaktionen und Anpassungen auf Bestellungsebene werden nicht auf die Fiskalfelder der Positionen verteilt. Identifizieren Sie verwendete Gutscheine über coupon und verwenden Sie den währungsgerechten Brutto-Bestellwert gross_value, um die gesamte Bestellung abzugleichen.
Fiskalfelder können fehlen oder null sein, wenn keine abgerechneten Rechnungsdaten verfügbar sind. Verzweigen Sie während einer schrittweisen Einführung anhand von contract_version oder akzeptieren Sie fehlende Felder.
coupon enthält Nummern verwendeter Gutscheine, keine verwendeten Aktions- oder Rabattcodes. Mehrere Gutscheine sind durch Kommas getrennt.
toucantix_booking_event kann alle erfassten Kampagnenfelder bereitstellen: utm_source, utm_medium, utm_campaign, utm_term, utm_content, gclid, fbclid, campaign_id und placement_id. Ein Feld kann null sein, wenn es nicht erfasst wurde.
KORONA Event erzeugt den Browser-Kauf, wenn eine bezahlte Bestellung mit aktiver Analytics-Einwilligung die Erfolgsseite erreicht.
Wiederholte einwilligungsbasierte Käufe werden anhand von transaction_id im Arbeitsspeicher und nach Möglichkeit im Local-Storage-Ledger toucantix.booking_analytics.purchase_ledger des Besuchers dedupliziert. Wenn der Browserspeicher gelesen und beschrieben werden kann, hat der Ledger kein zeitbasiertes Ablaufdatum und enthält die 100 letzten Transaktions-IDs. Blockierter Speicher, ein Speicherlimit oder fehlerhafter Ledger, gelöschte Websitedaten, das Überschreiten des Limits, ein anderer Browser oder ein anderes Gerät sowie ein doppelter Ziel-Trigger können trotzdem Duplikate erzeugen. Ohne nutzbaren Analytics-Speicher steht nur die Deduplizierung im Arbeitsspeicher der Seitenlaufzeit zur Verfügung.
Bei ausstehenden oder fehlgeschlagenen Zahlungen wird kein purchase erzeugt. Rückerstattungen und Stornierungen erzeugen kein ausgleichendes E-Commerce-Event in der kundenseitigen Datenschicht.

4. Kampagnenzuordnung erhalten

Der Online-Shop liest bei aktiver Analytics-Einwilligung folgende Werte aus der Adresse der Landingpage:

utm_source, utm_medium, utm_campaign, utm_term und utm_content
gclid und fbclid
campaign_id und placement_id

Lassen Sie für einen direkten Google Ads-Link in den Shop das Google Ads Auto-Tagging aktiviert, wenn Ihr freigegebenes Konzept gclid verwendet. Alternativ ergänzen Sie die für Ihr Reporting benötigten UTM-Parameter. Wenn eine Kampagne zuerst auf einer anderen Website landet, muss diese Website die benötigten Parameter beim Link oder bei der Weiterleitung in den Shop erhalten. KORONA Event kann keine Klick-ID wiederherstellen, die entfernt wurde, bevor der Besucher den Shop erreicht.

Der Kampagnenkontext wird erst gespeichert und den vollständigen Buchungs-Events hinzugefügt, nachdem der Besucher die Analytics-Einwilligung erteilt hat. Verlässt der Besucher die ursprüngliche Kampagnen-URL vorher, stehen die ursprünglichen Parameter für den späteren Kauf möglicherweise nicht mehr zur Verfügung.

Eine freundliche Kampagnen-URL oder einen direkten Angebotslink richten Sie mit Deep-Links von einer Marketingseite ein.

5. Vollständige Einrichtung testen

Verwenden Sie eine Test-Conversion-Aktion oder Test-Property, wenn Ihr Anbieter diese bereitstellt.

Öffnen Sie den genauen Kampagnenlink in einer neuen Browsersitzung.
Prüfen Sie in der GTM-Vorschau oder einer gleichwertigen Debug-Ansicht, ob der Consent-Manager die Google-Consent-Standardwerte vor der Messung festlegt und die KORONA Event Consent-Brücke die aktuelle Auswahl vor den Checkout-Events meldet.
Lehnen Sie optionale Einwilligungen ab. Schließen Sie mit Ihrem freigegebenen Testzahlungsverfahren einen bezahlten Checkout ab. Prüfen Sie, dass kein von KORONA Event erzeugtes purchase-Event in window.dataLayer erscheint. Prüfen Sie außerdem, dass die Google-Tags dem gewählten einfachen oder erweiterten Consent-Verhalten folgen und keine einwilligungsabhängige Speicherung oder Werbefunktion verwenden, solange die zugehörigen Statuswerte abgelehnt sind.
Starten Sie eine neue Browsersitzung, erteilen Sie die freigegebenen Analytics- und Marketing-Einwilligungen und schließen Sie einen bezahlten Test-Checkout ab.
Prüfen Sie auf der Erfolgsseite genau ein purchase-Event mit der erwarteten Transaktions-ID, dem Bruttowert, der Währung, den Fiskalfeldern der Positionen und den Versandwerten. Prüfen Sie bei gemischten Steuersätzen das tax_breakdown jeder Position einzeln.
Prüfen Sie, ob die GA4- und Google Ads-Tags genau einmal ausgelöst werden und die Diagnoseansicht der Zielplattform das Test-Event empfängt. Prüfen Sie, ob GA4 items_net_value als Kaufwert, den transformierten Preis und die transformierte Menge jeder Warenposition – einschließlich des Ersatzwerts aus net_value und der synthetischen Menge 1 für reine Komponenten-Warenpositionen –, shipping als GA4-Feld shipping und total_tax als GA4-Feld tax erhält. Google Ads muss den separat konfigurierten Conversion-Wert erhalten.
Prüfen Sie mit Tag Assistant oder einer gleichwertigen Vorschau, ob das Google-Tag oder der erforderliche Conversion Linker auf der Kampagnen-Landingpage und der Erfolgsseite aktiv ist. Wenn sich die Domains unterscheiden, prüfen Sie, ob domainübergreifende Links den Linker-Parameter enthalten und der Shop ihn annimmt.
Wiederholen Sie den Test mit erteilter Einwilligung in einer mobilen Ansicht und nach einer Weiterleitung zum Zahlungsanbieter, wenn dieser den Shop verlässt und anschließend zurückkehrt.

Die bezahlte Bestellung in KORONA Event und das Ziel-Event sollten dieselbe Rechnungsnummer als transaction_id verwenden, wenn eine Rechnungsnummer verfügbar ist. Andernfalls verwendet die Payload die Bestellnummer. Richten Sie keine zusätzliche Seitenaufruf-Conversion für die Erfolgs-URL ein. Sie kann Aktualisierungen ohne E-Commerce-Payload zählen.

Serverseitige Alternative

Verwenden Sie den Webhook Bestellung abgerechnet, wenn ein externes System eine verbindliche Benachrichtigung über eine abgerechnete Bestellung benötigt. Die Payload enthält Bestellnummer, Zahlungsstatus und Zahlungsart, Währung sowie Brutto-, Netto-, Steuer-, Versand-, Gutschein- und Fiskalwerte der Positionen.

Der Webhook ist keine fertige Google Ads- oder GA4-Integration. Er enthält keine Browser-UTM-Parameter sowie keine Werte für gclid oder fbclid. Deshalb kann er allein weder Käufe aus Werbekampagnen unterscheiden noch Google Offline-Conversions hochladen. Eine kundenseitig betriebene serverseitige Integration muss alle rechtlich zulässigen Klick- oder Sitzungskennungen getrennt beziehen, mit der abgerechneten Bestellung verbinden, die dokumentierten Fiskalfelder für ihre Zielplattform transformieren, Lieferungen deduplizieren und die Anfrage an die Zielplattform senden.

Fehlerbehebung

Problem	Was Sie prüfen sollten
Kein `purchase` in `window.dataLayer`	Modus ist Einwilligungsbasiert, auf der Erfolgsseite liegt eine bezahlte Bestellung vor und die Consent-Brücke hat `analytics: true` vor dem Kauf-Event gemeldet.
Die Brücke meldet Consent, aber der Controller erscheint nicht	Prüfen Sie die Browserkonsole auf die 10-Sekunden-Warnung der Brücke. Stellen Sie sicher, dass die Brücke auf einer Shop-Seite von KORONA Event und nicht auf der Seite eines externen Zahlungsanbieters läuft. Prüfen Sie außerdem, ob ein Content-Security- oder JavaScript-Fehler die Shop-Initialisierung beendet hat.
`purchase` ist vorhanden, aber GA4 oder Google Ads erhält nichts	Veröffentlichung des GTM-Containers, exakter Trigger vom Typ Benutzerdefiniertes Ereignis für `purchase`, Ziel-Tag, Feldzuordnung, Google-Consent-Status und Consent-Anforderungen der Zielplattform.
Der GA4-Umsatz entspricht nicht dem vorgesehenen Positionsumsatz	Prüfen Sie, ob der Adapter `contract_version: 2` erhält, `items_net_value` zuordnet, Zeilen mit `is_shipping` aus den GA4-Artikeln entfernt und Versand getrennt zuordnet. Prüfen Sie bei einer reinen Komponenten-Warenposition mit `settled_quantity: 0`, ob der Adapter den vollständigen `net_value` als Preis und die synthetische Menge `1` verwendet. Prüfen Sie außerdem, ob Gutscheinnummern unbeabsichtigt als GA4-Aktionscodes behandelt wurden.
GTM lädt vor der Einwilligung	Blockierungsregeln des Consent-Managers, Reihenfolge der Schnipsel und Consent-Prüfungen des GTM-Tags. Der Analytics-Modus allein blockiert den GTM-Schnipsel nicht.
Kampagne oder `gclid` fehlt	Der Parameter hat die Shop-Landingpage erreicht und die Analytics-Einwilligung war aktiv, bevor der Kampagnenkontext gespeichert werden musste.
Google Ads zeichnet eine Conversion ohne Kampagnenzuordnung auf	Das websiteweite Google-Tag oder der erforderliche Conversion Linker wird auf Landing- und Conversion-Seiten mit der erforderlichen Einwilligung ausgeführt. Bei unterschiedlichen Domains ist die domainübergreifende Verknüpfung eingerichtet. Übergeben Sie das Diagnosefeld `toucantix_booking_event.gclid` nicht an das standardmäßige Website-Conversion-Tag.
Conversion wird doppelt ausgelöst	Zweiter Seitenaufruf-Trigger, mehrere Ziel-Tags, mehrfach eingebundene GTM-Container, gelöschter Browserspeicher oder ein Test mit anderem Browser oder Gerät.
Tracking funktioniert im Shop, aber nicht nach der Zahlung	Der Consent-Manager hat seine gespeicherte Entscheidung auf der Zahlungs- oder Erfolgsseite wiederhergestellt und vor `purchase` durch die Consent-Brücke gemeldet.
Consent-Banner verdeckt Checkout-Elemente	Passen Sie das Layout des Consent-Managers für kleine Bildschirme an, ohne Checkout-Aktionen durch eigenes CSS auszublenden.

Externe Analytics und Consent einrichten

Was wird unterstützt?

Bevor Sie beginnen

1. Analytics-Modus auswählen

2. Consent-Manager und Tags hinzufügen

Consent-Manager mit KORONA Event verbinden

Google-Beispiel: Consent Mode separat konfigurieren

3. Externe Zielplattform verbinden

Anwendungsbeispiel: GTM, GA4 und Google Ads

Kaufwerte und Gutscheine für GA4 transformieren

Google Ads-Klickzuordnung erhalten

Vertrag der Purchase-Payload

4. Kampagnenzuordnung erhalten

5. Vollständige Einrichtung testen

Serverseitige Alternative

Fehlerbehebung

Verwandte Artikel