Postbacks, Pixel und Image-Tags: Nur eines davon taugt zur Abrechnung
Drei Mechanismen, um eine Conversion zu melden, so beschrieben, dass auch Nicht-Techniker sie behalten, dazu die sechs Arten, wie Integrationen tatsächlich kaputtgehen. Geschrieben für Betreiber und technische Affiliate Manager, die das schon einmal um elf Uhr nachts debuggt haben.
Eine Conversion lässt sich auf drei Wegen melden: über ein Image-Tag, über ein JavaScript-Pixel oder über ein Server-zu-Server-Postback. Nur das Postback hält gut genug, um Provision dagegen abzurechnen, weil es nicht auf die Mitarbeit des Spielerbrowsers angewiesen ist. Die meisten Integrationen, die "nicht tracken", sind gar keine kaputten Postbacks, sondern fehlende Klick-Identifikatoren auf dem Spielerdatensatz.
Der Anruf kommt immer zur Unzeit. Ein Affiliate Manager hat einen Partner, der droht, den Traffic abzuziehen, der Betreiber schwört, die Integration sei live, und das Dashboard zeigt null. Jemand schickt einen Screenshot von einem Tag im Footer der Einzahlungsbestätigungsseite und fragt, warum es nicht funktioniert.
Es funktioniert nicht, weil es ein Tag im Footer einer Seite ist.
Eine Conversion zu melden ist ein kleines Problem mit vielen Möglichkeiten, es falsch zu machen, und diese Möglichkeiten haben sich in zehn Jahren kaum verändert. Verändert hat sich, dass zwei der drei Mechanismen still und leise unzuverlässig wurden, während alle sie weiter ausgeliefert haben. Dieser Text ist der, den Sie Ihrem Entwickler vor der Integration geben, nicht danach.
Drei Wege zu sagen, dass ein Spieler eingezahlt hat
Das Image-Tag. Der älteste. Ihre Seite bindet ein Ein-Pixel-Bild ein, dessen Quelle eine URL der Tracking-Plattform ist. Der Browser versucht das Bild zu laden, dieser Request trifft die Plattform, und der Request selbst ist die Nachricht. Ein Bild wird gar nicht gebraucht, der Abruf ist der Punkt. Es braucht nichts außer HTML, weshalb es so lange in Template-Systemen überlebt hat, in denen niemand JavaScript anfassen wollte.
Das JavaScript-Pixel. Dieselbe Idee mit einem Skript statt einem Bild. Ein Snippet läuft in der Seite, sammelt etwas Kontext und schickt den Aufruf. Es ist flexibler: Es kann einen Wert lesen, den die Seite in eine Variable gelegt hat, es kann auf das Rendern einer Bestätigung warten, es kann einen Einzahlungsbetrag übergeben, der erst zur Laufzeit bekannt war. Es ist auch fragiler, weil es davon abhängt, dass das Skript lädt, die Variable existiert und die Seite darüber keinen Fehler geworfen hat.
Das Server-zu-Server-Postback. Gar kein Browser. Wenn Ihr Backend das relevante Ereignis erfasst, sendet es einen HTTP-Request an eine URL und trägt darin den Identifikator, den es bei der Ankunft des Spielers erhalten hat. Ihr Zahlungsdienst bestätigt eine Einzahlung, Ihr System schreibt die Transaktion, und irgendwo auf demselben Weg geht ein Request hinaus, der sagt: dieser Spieler, dieses Ereignis, dieser Betrag, diese Währung.
Das ist die ganze Idee. Sie klingt weniger raffiniert als die anderen beiden, und genau deshalb hält sie.
Warum zwei der drei nicht mehr verlässlich sind
Es gibt keine einzelne Ursache. Es gibt einen Stapel davon, und jede für sich wäre überlebbar.
Safari und Firefox blockieren Third-Party-Cookies standardmäßig, und Firefox blockiert zusätzlich Requests an Domains auf seiner Tracker-Liste. Chrome erlaubt Third-Party-Cookies weiterhin, dort kommt die Blockade also vom Adblocker statt vom Browser. Safari begrenzt zudem, wie lange per Skript geschriebener Speicher überlebt, teils auf wenige Tage, womit alles, was auf beim Klick geschriebenem Zustand beruht und ihn bei der Einzahlung liest, ein Verfallsdatum von einem Bruchteil eines normalen Entscheidungsfensters hat. Adblocker liegen über all dem und sind genau in dem Publikum verbreitet, das vor der Anmeldung Vergleichsinhalte liest. Nichts davon kündigt sich an. Ihr Betreiber sieht die Seite sauber rendern und schließt daraus, die Integration funktioniere.
Dann gibt es den Teil, den keine Browsereinstellung reparieren kann. Ein Spieler klickt am Arbeitsplatz auf dem Desktop, denkt darüber nach und zahlt abends vom Handy ein. Oder er registriert sich im Web und zahlt in der nativen App ein, wo es keinen Browser, keine Seite und kein Tag zum Auslösen gibt. Gerade im Sportsbook folgt die Einzahlung dem Spielplan statt dem Klick, und sie folgt ihm in die App. Wenn Sie sehen wollen, wie unterschiedlich sich diese beiden Wege verhalten: Casino- und Sportsbook-Traffic gehen genau an diesem Punkt auseinander.
Ein Pixel kann nicht von einem Ort aus feuern, den der Browser nie besucht. Daran ist mit besserer Tag-Platzierung nichts zu reparieren.
| Worauf es Ihnen ankommt | Image-Tag | JavaScript-Pixel | Server-zu-Server-Postback |
|---|---|---|---|
| Feuert aus | Dem Browser des Spielers | Dem Browser des Spielers | Ihrem eigenen Backend |
| Übersteht Adblocker | Selten | Selten | Ja, nicht beteiligt |
| Übersteht Gerätewechsel | Nein | Nein | Ja |
| Übersteht eine Einzahlung in der App | Nein | Nein | Ja |
| Kann Seitenzustand zur Laufzeit lesen | Nein | Ja | Nicht zutreffend |
| Meldet einen abgerechneten Betrag | Nur was die Seite weiß | Nur was die Seite weiß | Ja, aus dem führenden System |
| Wann einsetzen | Altsysteme, die Sie nicht ändern können | Ein Signal innerhalb derselben Session, als Zweitquelle | Alles, was über Geld entscheidet |
Die Fehlerbilder, die man kennen sollte
Niemand macht eine Integration auf interessante Weise kaputt. Dieselben sechs Fehler erklären fast alles.
Auslösen beim Seitenaufruf statt beim Ereignis. Das Tag sitzt auf der Einzahlungsbestätigungsseite und feuert also jedes Mal, wenn diese Seite geöffnet wird. Ein Spieler lädt neu, kommt über den Verlauf zurück oder landet dort nach einem fehlgeschlagenen Versuch, und jedes Mal steht eine Conversion in Ihrem Reporting. Das bläht die Zahlen in die Richtung auf, die gut aussieht, weshalb es so lange überlebt, bevor jemand es hinterfragt.
Ist es wirklich serverseitig? Ein Backend-Framework, das ein Template rendert, gibt immer noch ein Tag aus, das der Browser ausführen muss. Wenn der Request vom Gerät des Spielers ausgeht, ist er browserseitig, egal in welcher Datei er geschrieben wurde. Der Test dauert eine Minute: Skripte im eigenen Browser blockieren und schauen, ob das Ereignis trotzdem ankommt.
Dann gibt es den Klick-Identifikator, der auf dem Spielerdatensatz fehlt. Das ist mit großem Abstand der häufigste Fehler, und er bekommt weiter unten einen eigenen Abschnitt.
Die Einzahlung wird gemeldet, bevor sie abgerechnet ist. Die Zahlung ist autorisiert, das Postback geht raus, die Zahlung scheitert danach oder wird zurückgebucht. Jetzt hängt eine Provision an Geld, das nie angekommen ist. Feuern Sie auf den Zustand, den Ihre Buchhaltung anerkennen würde, nicht auf den, den Ihre Checkout-Seite zeigt.
Idempotenz, oder ihr Fehlen. Netzwerke laufen in Timeouts. Ein gut gebauter Sender wiederholt, und das ist richtig. Wenn die empfangende Seite nicht erkennen kann, dass der zweite Versuch dasselbe Ereignis ist wie der erste, wird aus dem Retry eine zweite Conversion. Jedes Ereignis braucht eine stabile eindeutige Referenz von Ihrer Seite, denselben Wert bei jedem Versuch, damit ein Duplikat erkannt und verworfen statt doppelt bezahlt wird.
Ereignisse kommen außerdem in falscher Reihenfolge an. Eine Einzahlung landet vor der Registrierung, zu der sie gehört, weil zwei Dienste unabhängig gefeuert haben und einer schneller war. Ordnen Sie die Ereignisse, die voneinander abhängen, oder geben Sie jedem genug Kontext mit, um allein zu stehen.
Das eine Detail, das über alles entscheidet
Jeder Fehler oben ist an einem Nachmittag reparierbar. Dieser nicht.
Wenn ein Spieler über einen Tracking-Link ankommt, muss der Identifikator dieses Links bei der Registrierung auf dem Spielerdatensatz gespeichert werden. Nicht in einer Session. Nicht in einem Cookie. Auf der Zeile in Ihrer Datenbank, die dieses Konto darstellt, neben der E-Mail-Adresse, in derselben Transaktion, die es anlegt.
Geschieht das nicht, lässt sich nichts danach attribuieren. Der Spieler zahlt drei Wochen später ein, Ihr Backend feuert ein technisch einwandfreies Postback, und es trägt keinen Identifikator, weil es keinen zu tragen gibt. Kein Maß an Postback-Feinjustierung repariert das. Sie debuggen kein Reporting-Problem, Sie debuggen ein Registrierungsproblem, und die Lösung liegt im Anmeldeprozess.
Zwei verwandte Gewohnheiten ersparen viele Diskussionen. Behalten Sie den Identifikator auch, wenn der Wert seltsam aussieht, denn Sie speichern ein Token und validieren keines. Und behalten Sie ihn für die Lebensdauer des Kontos statt für dreißig Tage, denn eine CPA, die auf eine qualifizierende Einzahlung zahlt, braucht die Verknüpfung noch in dem Moment, in dem die Einzahlung qualifiziert, und das kann Monate nach dem Klick sein. Wenn das Vokabular rund um qualifizierende Einzahlungen und Ersteinzahlungen bei Ihnen unscharf ist, lohnt sich das Glossar zu FTD, NGR, CPA, CPL und CPR zehn Minuten vor dem Schreiben des Schemas.
Testen, bevor Traffic läuft
Ein korrekter Integrationstest ist langweilig und dauert etwa eine Stunde.
- Klicken Sie einen echten Tracking-Link und schließen Sie die Registrierung ab wie ein normaler Spieler. Schauen Sie dann in Ihrer eigenen Datenbank auf den Spielerdatensatz und bestätigen Sie, dass der Identifikator darauf steht. Steht er nicht da, hören Sie auf, denn alles Weitere ist Theater.
- Zahlen Sie echtes Geld ein. Ein kleiner Betrag genügt, 20 EUR reichen. Testzahlungen überspringen häufig genau den Codepfad, der das Ereignis auslöst, und so bestehen Integrationen im Staging und fallen am ersten Tag aus.
- Prüfen Sie, dass das Einzahlungsereignis genau einmal ankam, mit dem richtigen Betrag und der richtigen Währung, nachdem die Zahlung abgerechnet war und nicht als sie eingereicht wurde.
- Senden Sie dasselbe Ereignis absichtlich noch einmal. Es sollte als Duplikat erkannt und nicht doppelt gezählt werden.
- Wiederholen Sie das Ganze auf einem Handy und noch einmal mit einer Einzahlung in der App statt im Browser, falls Sie eine haben.
Eine Stunde Entwicklerzeit und eine Einzahlung, gegen einen Monat Abstimmung mit einem Affiliate, der bereits überzeugt ist, dass Sie seinen Traffic kürzen. Die QA-Anleitung für Tracking-Links deckt die Affiliate-Seite desselben Tests ab, und beide Enden gemeinsam durchzugehen ist der Weg, die Abweichung an einem Nachmittag statt in einem Quartal zu finden.
Was AFFILIFY von einem Betreiber erwartet
Die Integrationsreferenz liegt unter affilify.partners/docs, mit Endpunkt, Parameternamen und akzeptierten Ereignistypen. Lesen Sie sie dort und nicht in einem Blogbeitrag, denn diese Seite ist die, die wir aktuell halten.
Der Umfang ist klein. Ein Ereignisname, der Identifikator, den Sie beim Klick erhalten haben, ein Betrag und eine Währung, dazu Ihr Key. Registrierung, Ersteinzahlung, Folgeeinzahlungen und Umsatzereignisse sind getrennte Nachrichten, denn das Provisionsmodell eines Deals entscheidet, welche davon zählen, und ein Programm kann keinen RevShare auf Daten zahlen, die es nie bekommen hat. Wenn Sie noch zwischen Modellen wählen, legt CPA, RevShare und Hybrid dar, was jedes von Ihrer Seite braucht.
Zwei Dinge sollten klar gesagt sein. Die Attribution hat bei uns mehrere Rückfallebenen. Sie sind eine Versicherung, kein Plan. Der bei der Registrierung gespeicherte Identifikator ist der Teil, den Sie kontrollieren, also senden Sie ihn. Und die Traffic-Qualität wird laufend bewertet, was bedeutet, dass manche Conversions während der Prüfung gehalten statt sofort gutgeschrieben werden. Das ist keine Ablehnung, und der Affiliate sieht den Status statt einer stillen Lücke.
Ein Betreiber, der den Identifikator zurückgibt, abgerechnete Ereignisse genau einmal meldet und sich in einer Stunde mit einer echten Einzahlung testen lässt, wird das Gespräch um elf Uhr nachts nie führen. Mehr ist hier nicht der Anspruch.
Häufige Fragen
Was ist der Unterschied zwischen einem Postback und einem Pixel?
Ein Pixel wird vom Browser des Spielers ausgelöst, während eine Seite offen ist. Ein Postback wird von Ihrem eigenen Backend ausgelöst, wenn das Ereignis erfasst wird, ganz ohne Browser. Dieser eine Unterschied entscheidet alles Weitere: Das Postback ist von Adblockern und der Cookie-Politik des Browsers unbeeindruckt, es funktioniert auch, wenn sich der Spieler am Laptop registriert und vom Handy einzahlt, und es funktioniert, wenn die Einzahlung in einer nativen App passiert, wo nie eine Seite lädt. Außerdem meldet es den Betrag, den Ihr führendes System hält, und nicht den, den eine Seite zufällig kannte.
Können wir ein Pixel als Backup neben dem Postback behalten?
Können Sie, aber seien Sie klar darüber, was es wert ist. Ein Pixel bestätigt immer nur Ereignisse, die es sehen kann, und das ist eine Teilmenge der tatsächlich eingetretenen Ereignisse, deren Größe für Sie unsichtbar bleibt. Behandeln Sie es während der Entwicklung als Plausibilitätsprüfung innerhalb derselben Session und nicht als zweite Wahrheitsquelle, und stimmen Sie niemals Zahlungen dagegen ab. Wenn beide für dasselbe Ereignis feuern, braucht Ihre Plattform eine stabile eindeutige Referenz von Ihrer Seite, damit das Paar als eine Conversion erkannt wird und nicht als zwei.
Unsere Postbacks feuern, aber nichts wird attribuiert. Warum?
Fast immer, weil der Klick-Identifikator bei der Registrierung nie auf dem Spielerdatensatz gespeichert wurde. Das Postback geht korrekt, pünktlich und mit gültigem Key hinaus und trägt nichts, worauf sich matchen ließe. Prüfen Sie zuerst eine echte Spielerzeile in Ihrer Datenbank. Fehlt der Identifikator dort, liegt der Fehler in Ihrem Anmeldeprozess und nicht im Postback-Code, und keine Retry-Logik und keine Endpunkt-Feinjustierung ändert das Ergebnis.
Wie sollten wir eine Postback-Integration testen, bevor Traffic läuft?
Klicken Sie einen echten Tracking-Link, registrieren Sie sich als Spieler und bestätigen Sie, dass der Identifikator auf der Kontozeile gelandet ist. Zahlen Sie dann echtes Geld ein, denn Testzahlungen überspringen oft genau den Codepfad, der das Ereignis auslöst. Bestätigen Sie, dass die Einzahlung genau einmal ankam, mit richtigem Betrag und richtiger Währung, nachdem die Zahlung abgerechnet war. Senden Sie dasselbe Ereignis absichtlich erneut und bestätigen Sie, dass es als Duplikat verworfen wird. Wiederholen Sie es dann auf einem Handy und in der App, falls vorhanden. Eine Stunde und eine kleine Einzahlung.
