Kurz gesagt
- Die Ad-Plattform schickt dir eine Click-ID. Du schickst den Postback zurück, wenn die Conversion passiert
- Stark genutzt im Mobile-Attribution-Umfeld (MMPs wie AppsFlyer, Adjust) und in Affiliate-Netzwerken
- „Postback“ überschneidet sich mit CAPI, ist aber älter, dieselbe Idee, oft ältere Protokolle
- Postbacks sind, wie Ad-Plattformen lernen, worauf sie optimieren sollen, wenn clientseitiges Tracking nicht praktikabel ist
Warum Postbacks existieren
Die meisten Ad-Plattformen bieten heute mindestens eins von: einem Pixel, einer CAPI-artigen API oder einer Postback-URL. Die Postback-URL ist die einfachstmögliche Schnittstelle: Wenn ein getracktes Event passiert, machst du einen HTTP-Request an eine URL, die dir die Plattform gegeben hat, mit Click-ID und Conversion-Details im Query-String.
Dieser Minimalismus ist der Grund, warum Postbacks zwei Jahrzehnte überlebt haben, während reichhaltigere Tracking-Muster kamen und gingen. Sie funktionieren über jeden HTTP-Stack, brauchen kein SDK und sind leicht zu debuggen, du kannst sie von Hand curlen.
Wie Postbacks funktionieren
Schritt für Schritt:
- Ad-Plattform hängt eine Click-ID an ausgehende URLs an (z. B.
?gclid=..oder?fbclid=..) - Deine Seite erfasst und speichert die Click-ID
- Nutzer konvertiert (Kauf, Registrierung, Install)
- Dein Server feuert einen HTTP-Request an die Postback-URL, inklusive Click-ID, Event-Typ, Wert und aller weiteren nötigen Parameter
- Die Ad-Plattform verbucht die Conversion gegen den ursprünglichen Klick und schreibt die Attribution entsprechend zu
Der vollständige Conversion-Loop passiert serverseitig nach dem initialen Klick.
Wo Postbacks dominieren
Drei Kontexte, in denen Postbacks die primäre Integration bleiben:
- Mobile Attribution. Apples SKAdNetwork nutzt Postbacks. Ebenso AppsFlyer, Adjust, Singular und andere MMPs. Die Mobile-Welt lief auf Postbacks, lange bevor Web-Tracking aufholte.
- Affiliate-Netzwerke. CJ, Rakuten, Impact, Awin, alle nutzen Postback-URLs, um Conversions an Publisher zurückzumelden.
- In-Platform-Server-zu-Server. Selbst wenn eine Plattform auch ein reichhaltigeres SDK bietet, ist die Postback-URL der reibungsärmste Fallback.
Postback vs. CAPI
Beide sind Server-zu-Server. Die Unterschiede:
- Postback ist typischerweise ein einfacher HTTP-GET mit Query-Parametern
- CAPI ist typischerweise ein reichhaltigerer HTTPS-POST mit JSON-Body und Authentifizierung
- Postback ist oft unidirektional und zustandslos
- CAPI unterstützt Event-Deduplizierung über geteilte Event-IDs und reichhaltigere First-Party-Daten-Payloads
In der Praxis überschneiden sie sich. Viele Plattformen bieten heute beides, Postback für einfache Fälle, CAPI für reichhaltigere Setups.
Häufige Fehler
- Den Postback feuern, bevor die Bestellung committet ist. Fehlgeschlagene Bestellungen lösen Phantom-Conversions aus. Warte auf den tatsächlichen Commit.
- Postbacks für erstattete Bestellungen senden. Die meisten Plattformen akzeptieren auch Refund-Postbacks, nutze sie, sonst sind deine Conversion-Daten dauerhaft aufgebläht.
- Postback-URLs im clientseitigen Code hardcoden. Untergräbt die Sicherheits- und Zuverlässigkeitsvorteile des serverseitigen Feuerns.
FAQ zu Postback
Was ist ein Postback?
Ein Postback ist ein Server-zu-Server-Signal, das ein Advertiser an eine Ad-Plattform sendet, wenn ein getracktes Event passiert. Die Plattform hängt eine Click-ID an ausgehende URLs an. Der Advertiser feuert sie per HTTP zurück, wenn die Conversion passiert.
Postback vs. CAPI, wo ist der Unterschied?
Beide sind Server-zu-Server. Postbacks sind einfacher (HTTP-GET mit Query-Parametern, zustandslos). CAPI ist reichhaltiger (HTTPS-POST mit JSON, unterstützt Event-ID-Deduplizierung). Viele Plattformen bieten heute beides.
Warum werden Postbacks in der Mobile Attribution genutzt?
Mobile Attribution lief auf Postbacks, lange bevor Web-Tracking aufholte. Apples SKAdNetwork nutzt Postbacks. Mobile-Measurement-Anbieter wie AppsFlyer und Adjust nutzen sie auch. Sie funktionieren über jeden HTTP-Stack und brauchen kein SDK.