Warum Erstattungen nur an GA4 gehen

Eine Erstattung ist eine Conversion, die rückwärts gelaufen ist. GA4 hat genau dafür ein natives Event: Es verrechnet den Umsatz gegen den ursprünglichen Kauf. Keine Werbeplattform hat ein echtes Refund-Event, also bringt es nichts, ein Custom-"Refund" zu senden, und es riskiert, genau die Counts zu verschmutzen, auf denen dein Bidding läuft. Beaconry leitet Erstattungen allein an GA4. Hier ist die Begründung, das Detail auf Wire-Ebene und warum das dem "meine Erstattung ist aus Meta verschwunden"-Support-Ticket zuvorkommt.

Das Prinzip in einem Satz

Ein Conversion-Event geht nur dann an einen Kanal, wenn dieser Kanal ein echtes Konzept davon hat. Für Erstattungen qualifiziert sich genau ein Ziel: GA4. Jede Werbeplattform hat entweder gar kein Refund-Event oder einen Slot, der Schaden anrichten würde, wenn du hineinfeuerst. Die Regel lautet also nicht "schick die Erstattung überall hin, wo sie technisch akzeptiert wird", sondern "schick sie nur dorthin, wo sie etwas bedeutet". Dieses eine Prinzip entscheidet das gesamte Verhalten, und es lohnt sich zu verstehen warum, denn die verlockende Alternative (ein Custom-Refund-Event an jeden Kanal sprühen, der es nicht ablehnt) ist genau die Art gut gemeinter Entscheidung, die einen Kampagnen-Report leise korrumpiert.

Was GA4 mit einer Erstattung tatsächlich macht

GA4 behandelt refund als erstklassiges E-Commerce-Event, mit demselben Status wie purchase, add_to_cart oder view_item. Es ist kein Custom-Event, das du definieren musst. Wenn GA4 ein refund mit einer transaction_id empfängt, die zu einem früheren purchase passt, verrechnet es den erstatteten Umsatz gegen diesen Kauf in den Monetarisierungs-Reports. Die Zahlen "Total revenue" und "Purchase revenue" des Kunden sinken um den erstatteten Betrag, automatisch, ohne Custom-Report-Rechnerei.

Diese Verrechnung ist der ganze Grund, warum Erstattungen überhaupt das Senden wert sind. Ohne sie ist eine Erstattung nur eine Zahl in einer Tabelle, die sich jemand merken muss, um sie von Hand abzuziehen. Mit ihr bleiben GA4s Umsatzzahlen von selbst wahrheitsgemäß. Das ist eine Fähigkeit, die die Werbeplattformen schlicht nicht bereitstellen, und genau das macht GA4 zum einen Kanal, wo sich eine Erstattung ihren Platz auf der Leitung verdient.

Was die Werbeplattformen mit einer Erstattung machen: nichts Nützliches

Geh die Kanäle durch, an die Beaconry weiterleitet, und stell die einzig relevante Frage, "hat diese Plattform ein natives Refund-Event, das gegen den Kauf verrechnet":

• Meta CAPI: nein. Refund ist kein unterstützter Conversions-API-Event-Typ. Meta hat zwar eine Cancellation-and-Refund-API, aber das ist die Commerce-Platform-Order-Management-API zum Verwalten von Shop-Bestellungen, eine komplett andere Surface, nicht die Conversions API, auf die Pixel und CAPI optimieren. Ein Custom-Refund-Event an CAPI ist inert: Es taucht nie in der Standard-Events-Manager-Ansicht auf, und Bidding-Algorithmen handeln nicht danach.
• TikTok Events API: kein Refund- oder Return-Standard-Event. Laut TikToks eigener Doku ist Refund-Handling für das Kampagnen-Optimierungs-Event-Set "not applicable". Ein Custom-Event wäre bestenfalls ein passiver Zähler.
• Snapchat CAPI: kein natives Refund-Event. Schlimmer noch, ohne Standard-Mapping landet es auf demselben CUSTOM_EVENT_1-Slot, den Beaconry für Form-Leads reserviert. Ein Refund dort zu feuern würde mit deinen Lead-Events kollidieren und die beiden im Snap Events Manager unmöglich trennbar machen.
• Pinterest Conversions API: kein natives Refund-Event. Du könntest ein Custom-refund senden, und Pinterest würde es sogar im Manager anzeigen, aber es trägt null Smart-Bidding-Wert und macht keine Umsatz-Verrechnung. Es ist ein Zähler mit einem freundlichen Label.
• Reddit Conversions API: dieselbe Geschichte wie Pinterest. Ein Custom-Refund würde auftauchen, aber nichts optimieren und nichts verrechnen.
• Microsoft Ads: die OfflineConversions API hat von vornherein kein Refund-Conversion-Konzept, auf das man mappen könnte, also gibt es nichts zu senden.

Beachte das Muster. Bei Meta und TikTok wird ein Custom-Refund still verschluckt. Bei Snapchat ist es aktiv schädlich (Slot-Kollision). Bei Pinterest und Reddit ist es sichtbar, aber wertlos. Keiner von ihnen tut, was GA4 tut. Die ehrliche Antwort lautet also überall außer bei GA4: weglassen.

Die Falle: "aber Pinterest und Reddit würden es anzeigen"

Das ist die Entscheidung, die vernünftig aussieht und es nicht ist. Pinterest und Reddit rendern ein Custom-refund-Event tatsächlich in ihren Dashboards, also ist ein naheliegender Instinkt "na gut, schick es an die Kanäle, die es anzeigen, lass die weg, die es verschlucken". Diese Regel ist willkürlich, und willkürliche Regeln verrotten.

Sie ist willkürlich, weil der entscheidende Faktor "ist dieses Event in der Vendor-UI sichtbar" ist, nicht "bedeutet dieses Event irgendetwas". Sichtbarkeit ist ein Zufall des Dashboards jeder Plattform, kein Signal für Wert. Ein Refund-Event auf Pinterest verrechnet keinen Umsatz, passt kein Bidding an und korrigiert keine Attribution. Es erhöht nur eine Zahl, die niemand weiter unten in der Kette zu interpretieren verdrahtet ist. Es an Pinterest-weil-sichtbar zu schicken, aber nicht an Meta-weil-unsichtbar, würde eine logische Entscheidung über zwei widersprüchliche Regeln aufspalten, und die nächste Person, die den Dispatcher anfasst, müsste rückwärts herausfinden, warum.

Die prinzipientreue Regel ist sauberer und sie verallgemeinert sich: Ein Conversion-Event wird nur dann an einen Kanal dispatcht, wenn der Kanal ein echtes Konzept davon hat. Für Erstattungen läuft das allein auf GA4 hinaus, und es bleibt wahr für jeden künftigen Kanal, den Beaconry hinzufügt, ohne dass jemand es neu verhandeln muss.

Wie das Überspringen im Code durchgesetzt wird

Der Dispatcher hat eine Per-Channel-Skip-Liste, BCNR_Forwarder::SKIP_BY_CHANNEL. Der Name refund erscheint in der Skip-Liste für meta, tiktok, snapchat, pinterest und reddit. Microsoft Ads hatte von vornherein nie ein Refund-Mapping. GA4 hat keinen Skip-Eintrag für refund, also bekommt es das Event ganz normal. Der relevante Ausschnitt der Dispatch-Schleife sieht so aus:

// In BCNR_Forwarder::dispatch(), after the pre-dispatch filter:

if ( self::has_ga4() ) {
    self::dispatch_ga4( $event );          // refund lands here, nets vs purchase
    self::after_dispatch( 'ga4', $event );
}

if ( self::has_meta() && self::should_dispatch_to_channel( 'meta', $event ) ) {
    // should_dispatch_to_channel('meta', ...) returns false for 'refund'
    // because 'refund' is in SKIP_BY_CHANNEL['meta'] - so this is skipped
    self::dispatch_meta( $event );
    self::after_dispatch( 'meta', $event );
}
// ... same skip outcome for tiktok / snapchat / pinterest / reddit

Der should_dispatch_to_channel()-Check jedes Kanals liest seinen eigenen SKIP_BY_CHANNEL-Eintrag und gibt false zurück, wenn der Event-Name auf der Liste steht. Eine Erstattung erreicht also dispatch_ga4() und stoppt dort. Das Überspringen ist Daten, keine Branching-Logik, die über fünf Dispatch-Methoden verstreut ist, und genau deshalb erbt ein sechster Werbekanal das richtige Verhalten in dem Moment, in dem du 'refund' zu seinem Skip-Set hinzufügst.

Eine Feinheit ist erwähnenswert: Eine Erstattung wird NICHT als "analytics-only"-Event eingestuft, so wie es form_start und form_abandon sind. Die laufen über ein separates zentrales Gate (ANALYTICS_ONLY_EVENTS), das hart vor jedem Werbekanal stoppt. Eine Erstattung ist ein echtes Commerce-Event, es hat nur zufällig genau einen Kanal, der sie unterstützt. Die beiden Mechanismen sehen von außen ähnlich aus (beide enden GA4-only), aber sie existieren aus unterschiedlichen Gründen: analytics-only heißt "Verhaltenssignal, nie eine Conversion", refund heißt "echte Conversion, nur ein Kanal implementiert sie". Sie im Code zu vermischen wäre ein Fehler in dem Moment, in dem irgendeine künftige Werbeplattform ein echtes Refund-Event ausliefert.

Der Refund-Payload selbst

Wenn WooCommerce seinen Order-Refunded-Hook feuert, baut Beaconrys handle_refund() das Event. Drei Details sind tragend:

Der Wert ist negativ. Der Refund-Wert wird als -1 * delta gesendet, eine negative Zahl. GA4s natives Handling macht die Verrechnung von selbst, aber das negative Vorzeichen bedeutet außerdem: Wenn ein Kunde DOCH einen Custom-Report baut, der Event-Werte über die Pipeline summiert, subtrahiert die Erstattung, statt zu addieren. Es ist das korrekte Vorzeichen für den einen Kanal, der es versteht, und harmlose Arithmetik für jeden nachgelagerten Consumer:

BCNR_Forwarder::dispatch( [
    'name'      => 'refund',
    'event_id'  => 'bcnr_refund_' . $order_id . '_' . (int) ( $total_refunded * 100 ),
    'timestamp' => time(),
    'page_url'  => self::current_url(),
    'params'    => [
        'transaction_id' => (string) $order_id,
        'currency'       => $order->get_currency(),
        'value'          => -1 * $delta,   // negative: nets against the purchase
    ],
    'user_data' => self::user_data_from_order( $order ),
] );

Teil-Erstattungen werden per Delta gehandhabt. Der Handler liest get_total_refunded() (den kumulativen erstatteten Betrag der Bestellung) und vergleicht ihn mit der letzten Summe, die Beaconry bereits gemeldet hat, gespeichert in den Order-Meta. Er sendet nur die Differenz, das delta. Erstatte heute 30 einer 100er-Bestellung, und der Event-Wert ist -30. Erstatte nächste Woche weitere 20, und der nächste Event-Wert ist -20, nicht -50. GA4 verrechnet jede Korrektur der Reihe nach gegen dieselbe transaction_id, sodass die laufende Umsatzzahl bei jedem Schritt der Realität folgt, statt doppelt zu subtrahieren.

Die event_id ist idempotent. Die event_id backt die erstattete Summe in Cents in den String ein: bcnr_refund_<order_id>_<cents>. WooCommerce kann denselben Refund-Hook für eine einzelne Refund-Aktion mehr als einmal feuern, und der Vergleich der gespeicherten Summe schließt ein erneutes Feuern bereits kurz (wenn total_refunded <= prev_total, früher Return). Die cents-gestempelte event_id ist die zweite Verteidigungslinie: Derselbe Refund-Betrag erzeugt dieselbe id, sodass selbst ein Duplikat, das durch die Sicherung geschlüpft ist, dedupliziert wird, statt doppelt zu zählen. EDD und SureCart verwenden über ihre eigenen Refund-Hooks dieselbe Form (surecart/models/refund/created für SureCart, der EDD-Refund-Pfad für EDD), sodass das GA4-only-Routing und das Verrechnungs-Verhalten über alle drei Commerce-Plattformen identisch sind.

Was das zuvorkommt: "meine Erstattung ist aus Meta verschwunden"

Hier ist das Support-Ticket, dem dieses Design zuvorkommt. Ein Kunde stößt in WooCommerce eine Erstattung an, öffnet GA4 und sieht den Umsatz korrekt sinken. Dann öffnet er den Meta Events Manager, sucht nach einer passenden Erstattung und findet nichts. Der Instinkt ist "das Plugin verschluckt meine Erstattungen". Tut es nicht. Meta hat keinen Ort, eine Erstattung hinzulegen. Es gibt kein Meta-Refund-Event, in dem sie landen könnte, also ist die Abwesenheit korrektes Verhalten, kein Bug.

Das Ehrliche, und was Beaconry tut, ist, gar nicht erst ein Phantom-Event an Meta zu senden. Ein Custom-Refund-Event auf CAPI würde nur in dem Sinne "auftauchen", dass es einen Custom-Event-Zähler aufbläht, auf den niemand handelt, während es null Verrechnung und null Optimierung macht. Das würde die Verwirrung sogar verschlimmern, denn jetzt GIBT es eine Meta-Refund-Zahl, sie tut nur nichts und gleicht sich nicht gegen deinen Purchase-Count ab. Sie komplett wegzulassen ist sowohl das ehrlichere Verhalten als auch das, das die Events-Manager-Ansicht sauber hält.

Die Antwort auf das Ticket ist also kurz: Erstattungen leben in GA4, wo die Plattform sie für dich gegen den Kauf verrechnet. Die Werbekanäle optimieren weiter auf den Conversions, die sie tatsächlich unterstützen, mit Counts, die nicht durch inerte Refund-Events verschmutzt sind. Wenn du das vollständige refund-korrigierte Umsatzbild willst, es ist in der GA4-Monetarisierung, bereits verrechnet, ohne manuelles Abziehen.

Wie die Werbeplattformen Erstattungen ohne Event korrigieren

Es ist legitim zu fragen: Wenn Meta und TikTok die Erstattung nie sehen, bleiben ihre ROAS-Zahlen dauerhaft falsch? Nein, und genau deshalb ist GA4-only doku-konformes Verhalten und keine Lücke. Die Werbeplattformen handhaben Wert-Korrektur über ihre eigenen Attribution-Decay- und Conversion-Adjustment-Mechanismen, nicht über ein Echtzeit-Refund-Event. Es gibt keinen Negative-Value-Purchase, den du ihnen senden sollst; ihr Modell ist, attribuierte Conversions auf ihrer Seite zu altern und anzupassen. Zu versuchen, ein Refund-Event auf ein System zu schrauben, das nie gebaut wurde, eines zu konsumieren, verbessert seine Genauigkeit nicht, es fügt nur Rauschen hinzu. Die Arbeitsteilung ist sauber: GA4 besitzt die verrechnete, refund-korrigierte Umsatz-Wahrheit; die Werbekanäle besitzen die Optimierung auf den positiven Conversions, die sie unterstützen, und korrigieren den Wert auf ihre eigene Weise.

Fazit

Erstattungen gehen nur an GA4, weil GA4 der einzige Kanal mit einem nativen Refund-Event ist, das den Umsatz gegen den Kauf zurückverrechnet. Jede Werbeplattform hat entweder kein Refund-Event (Meta, TikTok, Microsoft) oder eines, das nur verschmutzen oder kollidieren würde (Snapchats Lead-Slot-Kollision) oder einen kosmetischen Zähler, der nichts optimiert (Pinterest, Reddit). Das Prinzip, "schick eine Conversion nur dann an einen Kanal, wenn dieser Kanal ein echtes Konzept davon hat", ist es, was das Routing ehrlich hält und was einen künftigen Kanal ohne Umdenken einfügen lässt. Der praktische Gewinn ist zweifach: GA4-Umsatz bleibt ohne manuelles Abziehen wahrheitsgemäß, und deine Ad-Channel-Conversion-Counts bleiben sauber, keine Phantom-Refund-Events, die die Zahlen aufblähen, von denen dein Bidding abhängt. Die Frage "wo ist meine Meta-Erstattung hin" beantwortet sich von selbst, sobald du weißt, dass Meta nie einen Ort hatte, sie hinzulegen.