Das refund Event in Google Analytics 4 (GA4)

Das refund Event in Google Analytics 4 (GA4) wird genutzt, um Rückerstattungen zu tracken, also wenn ein Kauf ganz oder teilweise wieder rückgängig gemacht wird.

Das ist besonders wichtig, wenn du GA4-Daten (oder daraus abgeleitete Conversions) zur Bewertung von Kampagnen nutzt: Umsatz ist nur dann ein sinnvolles Optimierungsziel, wenn er auch real bleibt. Ohne Rückerstattungen sehen manche Kanäle plötzlich deutlich besser aus, als sie tatsächlich sind.

Screenshot einer Retouren-/Refund-Ansicht im Backend eines Shopsystems — Refunds werden typischerweise nicht vom Nutzer im Browser ausgelöst, sondern später im Shop-Backend (oder ERP) verarbeitet.

Das refund Event gehört zu den E-Commerce Events in GA4. Du kannst (und solltest) es daher – genau wie purchase – mit Parametern wie transaction_id, value und items versehen, um Rückerstattungen sauber der ursprünglichen Bestellung und den betroffenen Produkten zuordnen zu können.

Implementierung

Der beste Ort für refund ist meistens nicht der Browser, sondern dein Backend bzw. dein Shop-System: Rückerstattungen passieren häufig Tage später, ohne dass der Nutzer gerade auf deiner Website ist. Server-Side Tagging ist hier ideal, weil du Refunds zuverlässig, vollständig und ohne Timing-Probleme senden kannst.

Screenshot eines Rücksende-/Refund-Formulars — Auch Rücksende-Formulare oder Self-Service-Retourenstrecken können ein Signal liefern – entscheidend ist aber, dass das refund Event am Ende nur bei tatsächlicher Rückerstattung gesendet wird.

Pflichtfelder

Für refund ist transaction_id entscheidend: Die ID muss exakt zur ursprünglichen Bestellung passen (also zur purchase transaction_id).
Wenn du einen Betrag (value) sendest, setze auch currency.

Ganze vs. Teil-Rückerstattungen

Vollrefund: Du übermittelst den Gesamtbetrag der Rückerstattung als value und optional alle items.
Teilrefund: Du übermittelst nur die tatsächlich erstatteten Artikel in items und setzt value auf die Summe der erstatteten Positionen (plus ggf. anteilige Versand-/Steuerkorrekturen, wenn du das so abbildest).

Wichtig ist vor allem: transaction_id muss zur ursprünglichen purchase Transaktion passen. Nur dann sind die Daten später sauber verknüpfbar.

Noch ein Detail aus der Praxis: value wird bei refund üblicherweise positiv gesendet (also z. B. 29.90), weil schon das Event selbst die Bedeutung „Rückerstattung“ trägt. Negative Werte sorgen in vielen Setups eher für Verwirrung.

dataLayer

Wenn du Refunds doch browserseitig oder über eine Bestellbestätigungs-/Self-Service-Seite tracken musst, kann das Event so aussehen:

javascript

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
    event: "refund",
    ecommerce: {
        currency: "EUR",
        value: 29.90,
        transaction_id: "T12345",
        items: [{
            item_id: "SKU12345",
            item_name: "Superfood Pulver",
            item_category: "Superfoods",
            item_variant: "500g",
            item_brand: "MySupplements",
            price: 29.90,
            quantity: 1
        }]
    }
});

Kompletten Code anzeigen

Häufige Probleme

Refund ohne transaction_id: Dann kannst du Rückerstattungen später kaum sinnvoll zuordnen.
Teilrefund ohne Items: Wenn du nur einen Teil einer Bestellung erstattest, ist das items Array besonders relevant – sonst ist später nicht nachvollziehbar, welche Produkte betroffen waren.
Brutto vs. Netto: Bleib konsistent zu deinem purchase Setup (z. B. Nettoumsatz in value und Steuern separat). Mischformen machen Auswertungen schnell unbrauchbar.