Wie kommen Erstattungen in Metrunio an?

Eine Erstattung ist eine Korrektur am Kauf, keine neue Messung im Browser. Dein Shop-Server meldet sie über die Server Events API; eine Shop-Anbindung wie die Shopify-App tut das von selbst.

POST /v1/server/events
Authorization: Bearer <Serverschlüssel>

{
  "site_id": "site_…",
  "events": [{
    "event_id": "refund-12345-1",
    "event_type": "refund",
    "occurred_at": "2026-09-29T10:15:00Z",
    "order_id": "12345",
    "value": "10.00",
    "currency": "EUR"
  }]
}

Was „passend“ heißt

• Dieselbe Bestellnummer wie der Kauf, Zeichen für Zeichen. „#1001“ und „1001“ sind zwei Bestellungen.
• Dieselbe Umgebung: Eine Testerstattung findet keinen Kauf aus der Produktion.
• Dieselbe Währung. Eine Erstattung ohne Betrag gilt für den ganzen Kauf und braucht keine.
• Eine eigene event_id je Erstattung. Dieselbe event_id zweimal zählt einmal; das schützt vor doppelter Zustellung. Zwei Teilerstattungen über denselben Betrag brauchen deshalb zwei verschiedene event_id.

Wenn die Erstattung vor dem Kauf ankommt

Das kommt vor: Zwei Webhooks überholen sich, ein Bestandsimport läuft in beliebiger Reihenfolge, oder der Kauf steckt in einer Wiederholung. Metrunio wartet dann bis zu 24 Stunden auf den Kauf: anfangs alle halbe Minute, später einmal je Stunde. Kommt er, wird die Erstattung verbucht, als wäre sie nach ihm gekommen. Die 24 Stunden zählen ab dem ersten Verarbeitungsversuch, nicht ab dem Empfang; nach einer Störung beginnt die Frist also nicht schon abgelaufen.

Kommt in dieser Zeit kein passender Kauf, verbucht Metrunio die Erstattung nicht und löscht sie. Unter „Datenstatus“ zählt der Befund REFUND_WITHOUT_PURCHASE, wie viele Erstattungen je Website und Tag so verworfen wurden. Bestellnummern oder andere Kennungen hält Metrunio dafür nicht fest, denn oft gehört eine solche Erstattung zu einem Kauf, der nicht gespeichert werden durfte. Welche es waren, siehst du in deinem Shop anhand des Tages. Der häufigste Grund sind Bestellnummern, die Kauf und Erstattung verschieden schreiben. Kommt der Kauf später doch an, sende die Erstattung mit einer neuen event_id erneut. Dieselbe event_id gilt als schon empfangen.

Woran du siehst, dass sie verbucht ist

• Conversions: Die Bestellung steht als „erstattet“ oder „teilweise erstattet“, mit dem erstatteten Betrag.
• Übersicht: „Umsatz gemessen“ rechnet nach Erstattungen; die Erklärung der Kachel nennt den Betrag vor Erstattungen und die Summe der Erstattungen. Zugeordneter Umsatz und die Werte je Kanal und Kampagne rechnen ebenfalls nach Erstattung.
• Export und Lese-API: Die Spalte „wert“ (value) ist der ursprüngliche Kaufwert, „erstattet“ (refundedValue) die Summe der Erstattungen, „status“ sagt refunded oder partially_refunded. Abgezogen wird nicht in der Spalte, sondern daneben. So lässt sich beides gegen den Shop abgleichen.

Im Demo-Shop

Der Demo-Shop simuliert Erstattungen im mitgelieferten Demo-Mandanten, ganz oder in Teilen. Er meldet „Erstattung angenommen“, sobald der Collector sie angenommen hat; verbucht ist sie, wenn die Bestellung unter „Bestellungen & Ziele“ als erstattet erscheint. Misst der Shop in deinem eigenen Mandanten, ist der Knopf gesperrt: Dort meldet das Tracking-Skript den Kauf aus dem Browser, und Erstattungen kämen über die Server Events API deines Mandanten. Den Serverschlüssel dafür hat der Demo-Shop nicht.