Postbacks für eine TDS: wie eine fremde Conversion zu ihrem Klick zurückfindet

Der Leitfaden zur TDS auf Cloudflare Workers endet beim Redirect. Der Worker antwortet dem Browser mit einem 302, der Browser öffnet das Offer, und ab diesem Moment sieht der Worker nichts mehr. Die Registrierung oder die Einzahlung passiert auf der Seite des Netzwerks, auf einer Domain, die Ihnen nicht gehört und auf der Sie kein Pixel setzen können.

Dieses Ereignis bringt ein Postback zurück. Das ist ein Request von Server zu Server (S2S): Wenn der Besucher konvertiert, ruft das Netzwerk eine URL auf, die Sie ihm gegeben haben, und schreibt die Daten der Conversion in den Query-String. Damit dieser Aufruf etwas bedeutet, muss er sagen, zu welchem Klick er gehört. Den Klick in die Hände des Netzwerks zu bringen, ist Aufgabe des Redirects.

Dieser Artikel zeigt, wie die TDS in 301.st beide Hälften erledigt: was sie an den Offer-Link hängt, was das Netzwerk zurückschicken muss, was eine Conversion in der Plattform ändert und wie sie zu dem Werbenetzwerk zurückkommt, das Ihnen den Klick verkauft hat. Der Tracker ist hier die TDS selbst: Klick, Regel und Conversion treffen sich an einer Stelle, ohne Zwischenstation. Alles hier wurde am 6. Oktober 2026 im Quellcode der Plattform nachgelesen. Die allgemeine Fassung dieser Schleife, von Hand auf einem Worker gebaut, steht im Artikel über die Zuordnung, wenn die Conversion-Seite nicht Ihre ist.

Die Schleife

Zwei Dinge müssen stimmen. Der Redirect muss eine Kennung in einen Parameter legen, den das Netzwerk aufbewahrt, und das Netzwerk muss diesen Parameter unverändert im Postback zurückgeben. Wie Sie dafür die Postback-Quelle einrichten, steht unten.

Was mit dem Klick mitreist

Für jeden Request erzeugt der Worker eine Click-ID: 32 Hexadezimalzeichen, deren erster Teil die Zeit des Klicks ist. Bei einem Redirect baut er um diese ID zusätzlich ein Klick-Token. Das Token enthält die Regel, die gegriffen hat, Land und Gerät des Besuchers und bei einem Split die gewählte Seitenvariante. Es ist mit HMAC signiert, und die Signatur wird geprüft, wenn das Token zurückkommt. Ein bearbeitetes oder erfundenes Token fällt dabei durch.

Eine Tabelle der Klicks führt die Plattform nicht. Das Token ist der Datensatz des Klicks, und deshalb ist es signiert: Alles, was die Plattform über eine Conversion erfährt, liest sie aus dem Token, das das Netzwerk zurückgegeben hat. Ein Token ist 44 Zeichen lang, bei einer Split-Regel 58, und 90 Tage nach dem Klick nimmt die Plattform es nicht mehr an.

Ob eine Regel das Token anhängt, entscheidet ihre Einstellung Click key in the URL:

Auswahl	Was der Offer-Link bekommt
Don’t add	nichts; der Link geht so raus, wie Sie ihn geschrieben haben
301 key (_cid)	das Token in einem Parameter namens _cid
Source parameter	das Token in dem Parameter, den Ihre Postback-Quelle nennt, etwa sub1

„Don’t add“ passt für eine White Page, einen Bot-Filter oder jeden Link, der nicht zu einem Affiliate-Netzwerk führt. Die anderen beiden sind für Conversions, die als Postbacks zu 301.st zurückkommen. Die dritte braucht eine Postback-Quelle, die in der Regel ausgewählt ist, denn der Parametername kommt von dort.

Der Worker schreibt das Token über jeden gleichnamigen Parameter, der schon im Link steht. Enthält Ihre Offer-URL sub1=irgendwas und heißt der Parameter der Quelle sub1, bekommt das Netzwerk das Token. Der Regel-Editor warnt beim Speichern davor.

Das Token kommt an einen HTTP-Redirect und an einen Split. Eine Regel, die Besucher per Meta Refresh, JavaScript oder iframe weiterschickt, bekommt kein Token, und ihre Conversions lassen sich nicht zuordnen.

{clickid} ist nicht der Schlüssel

Ziel-URLs verstehen Makros, und zwei davon zählen fürs Tracking.

{clickid} setzt die rohe Click-ID mit 32 Zeichen in den Link. Es ist dieselbe ID, die im Token steckt, aber sie ist nicht signiert und trägt sonst nichts. Ein Netzwerk, das sie im Postback zurückgibt, gibt einen Wert zurück, den die Plattform nicht zuordnen kann: Die Conversion wird als nicht zugeordnet erfasst. Nehmen Sie {clickid}, wenn ein Netzwerk Ihre ID in einem eigenen Feld haben will, und lassen Sie das Token in den Parameter gehen, den das Postback liest.

{q.name} setzt einen Parameter des eingehenden Requests in den Link. Ein Besucher, der als go.example.com/promo?cid=AD123 ankommt, kann als https://network.example/offer?sub2={q.cid} weitergeschickt werden, und das Netzwerk bekommt sub2=AD123. Der Wert wird URL-kodiert und bei 256 Zeichen abgeschnitten; ein fehlender Parameter wird zum leeren String. So reist die eigene Click-ID des Werbenetzwerks oder die gclid aus Google Ads zum Affiliate-Netzwerk und kommt im Postback zurück. {q.name} funktioniert heute in jeder Ziel-URL, steht aber noch nicht in der Makroliste des Editors; tippen Sie es von Hand.

Die Postback-Quelle

Eine Postback-Quelle ist ein Netzwerk oder eine Kampagne eines Netzwerks, so wie 301.st sie sieht. Die Liste finden Sie unter Postbacks, Postback sources. Beim Anlegen kann die Plattform das meiste auf zwei Wegen selbst ausfüllen. Sie können eine Postback-URL einfügen, die Ihnen das Netzwerk gegeben hat, samt seinen Makros, und die Plattform versucht, das Netzwerk zu erkennen. Oder Sie speichern die Quelle als Entwurf, bitten das Netzwerk, ein Test-Postback an die angezeigte Adresse zu schicken, und die Plattform lernt die Feldnamen aus diesem Request.

Diese Einstellungen entscheiden, ob Conversions zugeordnet werden:

Click parameter. Der Name des Parameters, der das Token trägt; leer bedeutet _cid. Setzen Sie ihn, wenn das Netzwerk einen eigenen Namen vorgibt, wie es die meisten tun: sub1, subid, data1, btag.

Macro syntax. Wie das Netzwerk seine Makros in Postback-URLs schreibt: {sub1}, [SUB1], ${sub1} und so weiter. Daraus baut die Plattform die URL, die Sie zurück einfügen.

Field mapping. Für jedes Feld, das die Plattform versteht, der Name des Parameters, den das Netzwerk schickt: Click ID, Event type, Transaction ID, Bruttobetrag und Währung (Gross), Auszahlung und Währung (Payout), External user ID. Eine Quelle ohne Zuordnung für Click ID erfasst jede Conversion als nicht zugeordnet, und der Editor zeigt einen Hinweis, bis Sie das Feld setzen.

Event mapping. Netzwerke benennen ihre Ereignisse unterschiedlich. Diese Tabelle übersetzt die Namen des Netzwerks in die, nach denen 301.st berichtet, etwa registration und ftd. Ein Ereignis, das die Tabelle nicht kennt, wird als unbekannt erfasst und landet nicht in Ihren Zahlen. Ein Netzwerk, das den Ereignisnamen gar nicht schicken kann, bekommt stattdessen eine Postback-URL je Ereignis, in die das Ereignis als event_type=ftd eingetragen ist, wie im Beispiel unten.

Dann geht es darum, wie das Netzwerk beweist, dass es das Netzwerk ist. Standard ist ein geheimes Token in jeder Postback-URL, das für die Quelle erzeugt wird. Die Alternativen sind eine Liste der IP-Adressen des Netzwerks, eine HMAC-Signatur in einem Header oder gar keine Prüfung. Eine zusätzliche IP-Prüfung lässt sich über das Token legen.

Drei weitere Einstellungen bestimmen, was gezählt wird. Das Attributionsfenster in Tagen, standardmäßig 90: Eine Conversion, die später nach dem Klick eintrifft, wird als abgelaufen erfasst. Die Auszahlungswährung: Ein Postback mit einer anderen Währung wird beiseitegelegt statt zu Ihren Summen addiert. Und der Program key: Geben Sie mehreren Quellen denselben Schlüssel, wenn sie Kampagnen eines Partnerprogramms sind, dann wird dieselbe Transaktion, die über zwei von ihnen eintrifft, einmal gezählt.

Ist die Quelle gespeichert, baut die Plattform die Postback-URLs, eine je Ereignis:

https://api.301.st/tds/postback/<source_id>?token=<secret>&sub1={sub1}&event_id={event_id}&user_id={user_id}&amount={amount}&event_type=ftd

Fügen Sie jede in das passende Feld des Postback-Formulars beim Netzwerk ein. Die Teile in geschweiften Klammern sind die Makros des Netzwerks, die es beim Aufruf selbst ausfüllt.

Was passiert, wenn ein Postback eintrifft

Die Plattform antwortet dem Netzwerk sofort und speichert den Request. Die Verarbeitung beginnt gleich; was liegen bleibt, holt ein stündlicher Job nach. Dann der Reihe nach:

1. Die Felder werden über das Mapping gelesen. Ein Makro, das das Netzwerk nicht ausgefüllt hat, etwa ein wörtliches {sub1}, zählt als leeres Feld, nicht als Wert.
2. Das Token wird geprüft. Ein gültiges liefert Regel, Land, Gerät und Split-Variante des ursprünglichen Klicks.
3. Die Conversion wird dedupliziert. Mit einer Transaction ID wird dieselbe Transaktion mit demselben Ereignis einmal gezählt, wie oft das Netzwerk auch wiederholt. Ohne sie vergleicht die Plattform Klick, Ereignis, Betrag und Minute.
4. Die Conversion wird als zugeordnet, nicht zugeordnet oder abgelaufen erfasst.

Eine zugeordnete Conversion geht in stündliche Summen je Regel, Variante, Land, Gerät, Ereignis und Währung. Eine Erstattung oder ein Chargeback kommt mit negativem Betrag und wird an die Conversion gehängt, die sie aufhebt.

Nicht jedes Ereignis lehrt einen Split etwas. Der Split vergleicht Akquise-Ereignisse, etwa eine Registrierung oder eine erste Einzahlung, mit den Klicks, die jede Seite bekommen hat. Spätere Geld-Ereignisse, deposit, revshare und ngr, bringen der Regel Umsatz, bewegen den Split aber nicht, denn sie kommen von einem Spieler, den die Seite schon gebracht hat. Der Worker holt die neuen Split-Zahlen mit seiner nächsten Synchronisierung. Klickzähler reisen in die andere Richtung: Ihr Worker schickt sie einmal pro Stunde an die Plattform, für jede abgelaufene Stunde, so dass die Klickzahlen einer Regel ihren Conversions ein bis zwei Stunden hinterherlaufen.

Revenue Share lebt länger als das Token. Ein Netzwerk, das Revshare zahlt, schickt Zahlungen über Monate, lange nach den 90 Tagen. Schickt das Netzwerk eine feste ID für den Spieler, zugeordnet als External user ID, verknüpft die erste zugeordnete Conversion diesen Spieler mit dem Klick. In den nächsten 365 Tagen werden Zahlungen für denselben Spieler auch ohne gültiges Token derselben Regel zugeschrieben. Sie zählen zum Umsatz der Regel und lassen, wie andere Geld-Ereignisse, den Split in Ruhe.

Die Conversion weitergeben

301.st kann jede Conversion an drei Stellen weitergeben, eingestellt je Postback-Quelle.

Ein GET an die Traffic-Quelle, das Werbenetzwerk, das Ihnen den Klick verkauft hat. Es optimiert Ihre Kampagne auf die Conversions, die man ihm meldet, gegen seine eigene Click-ID. Sie geben eine URL-Vorlage mit den Makros {source_click_id}, {event}, {payout}, {currency} und {txid} an. Der Aufruf geht nur für die Ereignisse raus, die Sie auflisten, nie für negative, und nur, wenn die Conversion die Click-ID des Netzwerks trägt.

Ein signierter POST an Ihren eigenen Endpunkt. Das Feld Outbound target URL an der Quelle. Jede Conversion geht als JSON mit einem Header X-301-Signature raus, so dass der Empfänger prüfen kann, dass sie von der Plattform kommt. So kommen Conversions in Ihre eigenen Berichte oder Ihr CRM.

Ein GET an jede andere URL, die ein Postback annimmt. Sie geben eine Vorlage an, und die Plattform füllt diese Makros: {click_id}, {source_click_id}, {event}, {payout}, {gross}, {currency}, {txid}, {conversion_id}, {rule_id}, {country}, {device}.

Für die beiden GETs gibt es in der Oberfläche von 301.st noch keinen Screen; sie werden über die API gesetzt, mit PATCH https://api.301.st/tds/postback-sources/<id>, als source_postback_url, source_postback_events und outbound_get_url. Dasselbe gilt für die Zuordnung der Click-ID der Quelle, source_click_id in field_map, die das nächste Beispiel braucht. Ein Screen dafür ist in Arbeit.

Vorlagen müssen https und einen Hostnamen verwenden, keine IP-Adresse. Werte werden URL-kodiert, und ein Wert, den die Conversion nicht hat, bleibt leer. Eine gescheiterte Zustellung wird bei einem Serverfehler, einem Timeout oder einer Rate-Limit-Antwort wiederholt: sechs Versuche insgesamt, mit Pausen von 30 Sekunden, 2 Minuten, 10 Minuten, einer Stunde und 6 Stunden. Jede andere 4xx-Antwort beendet die Wiederholungen, denn derselbe Request noch einmal ändert nichts daran.

Ein Klick von Anfang bis Ende

So sieht die ganze Schleife als ein Setup aus: Ein Werbenetzwerk liefert den Klick, ein Affiliate-Netzwerk zahlt für die Einzahlung, und das Werbenetzwerk erfährt, welcher seiner Klicks sich gelohnt hat.

Das Werbenetzwerk schreibt seine eigene Click-ID als cid in den Link der Anzeige. Die Postback-Quelle für das Affiliate-Netzwerk hat den Click parameter sub1. Über die API ordnet die Quelle source_click_id dem Parameter sub2 zu, führt ftd in source_postback_events und hat diese Vorlage für das Werbenetzwerk:

https://ads.example/conversion?click_id={source_click_id}&event={event}&payout={payout}&currency={currency}

Die Regel leitet mit dem Klick-Schlüssel im Parameter der Quelle auf dieses Ziel weiter:

https://network.example/offer?sub2={q.cid}&geo={country}

1. Die Anzeige wird geklickt, und der Besucher landet auf https://go.example.com/promo?cid=AD123.
2. Die TDS-Regel greift, und der Worker antwortet 302 mit Location: https://network.example/offer?sub2=AD123&geo=DE&sub1=<token>.
3. Der Besucher registriert sich und zahlt ein. Das Affiliate-Netzwerk ruft die Postback-URL für ftd auf, mit ausgefüllten sub1=<token> und sub2=AD123. Beide muss es zurückgeben.
4. 301.st prüft das Token, erfasst einen ftd für die Regel in Deutschland und füllt die Vorlage: https://ads.example/conversion?click_id=AD123&event=ftd&payout=....

Das Werbenetzwerk sieht jetzt eine Einzahlung auf seinen eigenen Klick AD123 und kann darauf bieten. Eines bleibt bei Ihnen: Das Ereignis kommt unter dem Namen aus 301.st an, hier ftd. Erwartet das Werbenetzwerk einen eigenen Namen, schreiben Sie ihn statt {event} in die Vorlage; mit nur ftd in der Liste wird die Vorlage für nichts anderes verwendet.

Wo es nicht hinreicht

• Eine Conversion wird nur über das Token zugeordnet. Ein Netzwerk, das einen Parameter nicht wörtlich zurückgeben kann, lässt sich nicht zuordnen, was es sonst auch schickt.
• Regeln, die per Meta Refresh, JavaScript oder iframe weiterleiten, schicken kein Token.
• Ein Token, das älter als 90 Tage ist, wird nicht gelesen, und das Attributionsfenster der Quelle kann diese Frist verkürzen. Revenue Share deckt die Spieler-Verknüpfung ab, wenn das Netzwerk eine Spieler-ID schickt.
• Postbacks werden in der eigenen Datenbank der Plattform gespeichert und verarbeitet, sie zählen also nicht gegen Ihr Cloudflare-D1-Kontingent. Die Klickzähler schon: Jeder Klick auf eine Regel schreibt in Ihre D1, was der TDS-Leitfaden in seinem Abschnitt über den Free-Plan durchrechnet.

Werden Conversions nicht zugeordnet, prüfen Sie zuerst den Redirect. Öffnen Sie den Link der Regel im Browser und sehen Sie sich die Adresse an, mit der das Offer öffnet: Das Token muss dort stehen, in dem Parameter, den das Netzwerk aufbewahrt. Prüfen Sie dann, ob die Postback-URL des Netzwerks diesen Parameter zurückgibt.