Wie S2S-Tracking und Postbacks funktionieren

1) Was ist S2S und warum wird es benötigt?

S2S (Server-to-Server) -Tracking ist der Austausch von Ereignissen zwischen den Servern der Verkehrsquelle (Ihrem Redirector/Tracker/Netzwerk) und den Servern des Betreibers (Casino), ohne Abhängigkeit von Browser-Cookies und Sperren.

Postback ist eine ausgehende HTTP-Anforderung mit einem Ereignis (reg/KYC/FTD/2nd_dep/...) aus dem Backend des Absenders an die URL des Empfängers.

Vorteile:

Daten gehen nicht durch Adblock/ITP/private Modi verloren.
Die Attributionsgenauigkeit und die Abrechnungsqualität werden verbessert.
Sie können den Betrag/die Währung und die Dienstflaggen sicher übertragen.

2) Grundlegende Kette und Rollen

1. Klick: Der Benutzer klickt auf die Anzeige → Ihr Redirector erstellt „click _ id“ und protokolliert die Parameter (utm, geo, device, sub_id).

2. Umleitung: Der Benutzer geht zum Landing Operator, 'click _ id' wird in die URL eingeblendet oder verschlüsselt.

3. Die Registrierung/KUS/Einzahlungen erfolgen beim Betreiber.

4. Postbacks: Der Server des Operators sendet die Ereignisse' registration', 'kyc _ approved', 'deposit _ success' usw. an Ihren Tracker und bindet sie an die ursprüngliche' click _ id'.

5. BI/Reporting: Sie aggregieren Ereignisse nach UTM/Creative/Geo/Device-Abschnitten, zählen CPA/ROAS/LTV.

Textschema:


Ad → Click → [Ihr Redirector: generiert click_id] → LP/App → (Reg/KYC/FTD auf Betreiberseite)
↑             │
└──────── Postback (S2S) ─┘

3) IDs und Ereignisverknüpfung

click_id (objas.) - eindeutige ID der ersten Berührung; Attributionsschlüssel.

event_id (Gelee) - eindeutige ID jedes Ereignisses (für Idempotenz).

user_id/ account_id (Opz.) - Spieler-ID auf Betreiberseite (wird nur an S2S übertragen).

session_id (opz.) - für UX/Geschwindigkeitsanalyse.

aff_sub/campaign/ creative_id - Schnitte für die Analytik.

Regel: click_id wird von Ihnen erstellt. Der Operator auf seiner Seite speichert das Mupping „click _ id ↔ user/account“.

4) Ereignisfelder: minimale Zusammensetzung

4. 1. Registration

json
{
"event": "registration",  "event_id": "reg_8f9...",  "click_id": "clk_123...",  "account_id": "u_456...",  "geo": "BR",  "device": "android",  "ts_event": "2025-10-21T14:54:12Z",  "ip": "203. 0. 113. 7",  "ua": "Mozilla/5. 0",  "signature": "hmac_sha256(payload)"
}

4. 2. KYC Approved

json
{
"event": "kyc_approved",  "event_id": "kyc_b21...",  "click_id": "clk_123...",  "account_id": "u_456...",  "ts_event": "2025-10-21T15:10:05Z",  "kyc_level": "basic    full",  "signature": "..."
}

4. 3. Deposit (FTD/Repeat)

json
{
"event": "deposit_success",  "event_id": "dep_9aa...",  "click_id": "clk_123...",  "account_id": "u_456...",  "amount": 100. 00,  "currency": "USD",  "is_ftd": true,  "payment_method": "card    pix    crypto    wallet",  "ts_event": "2025-10-21T15:12:31Z",  "signature": "..."
}

Erforderliche Felder: 'event', 'event _ id', 'click _ id', 'ts _ event' (UTC), 'signature'.

Geldfelder sind immer zusammen mit 'currency' (ISO-4217) und als zahlen, nicht strings.

5) Sicherheit: Unterschriften und Zugang

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; kanonisieren die Reihenfolge der Felder → eine stabile Überprüfung.

Kurzlebige Token (JWT/opaque) auf Autorisierungsebene: TTL 5-15 Minuten.

Idempotenz: Ein wiederholter POST mit der gleichen 'event _ id' sollte' 200 OK 'ohne Take ergeben.

IP allow-list und mTLS (wenn möglich) auf dem Produkt.

Rate limiting: Schützen Sie Endpoint vor „Bursts“ und Bots.

Verbot von HTTP-Weiterleitungen vom Post-Back-Endpoint; Nur direkte Antworten.

6) Zuverlässigkeit: Retrays, Warteschlangen und Ordnung

Warteschlange (Kafka/RabbitMQ/SQS) zwischen Ereignisempfang und Berichtsverarbeitung - um bei Peaks keine Daten zu verlieren.

Retrays mit exponentieller Pause und Backoff-Jitter; Grenze der Versuche und DLQ (dead-letter queue).

Die Reihenfolge ist nicht erforderlich, aber es ist wünschenswert, ein 'ts _ event' zu haben, um in BI zu sortieren.

Request/Response-Protokolle (keine sensiblen Daten), Korrelation nach 'event _ id'.

7) Zeitzonen, Währung und Konsistenz

Alle Zeitstempel in UTC ('2025-10-21T15: 12: 31Z').

Geben Sie in den Berichten die Zeitzone des Projekts an, speichern Sie jedoch die Ereignisse in UTC.

Speichern Sie die Beträge in der Transaktionswährung und duplizieren Sie sie in der Berichtswährung über einen zuverlässigen Wechselkurs (Data-Time-Based FX).

8) Deduplizierung und Geschäftsregeln

Idempotenz nach event_id: Die Wiederholung → „bereits verarbeitet“.

Deduplizierung nach (click_id + Ereignistyp + ts-Fenster) als Ersatzmechanismus.

FTD Validitätsregeln: Mindesteinlage, keine Bonus „Null“ Auffüllungen; im Vertrag zu fixieren.

Chargeback/Refund - ausgewählte „Negative Income“ -Ereignisse für einen ehrlichen NGR.

9) Vertraulichkeit und Compliance

Übergeben Sie die PII nicht an die URL und Front; S2S ist ein Ort für sensible Felder.

Speichern Sie consent/consents (analytics/ads) und versionieren Sie diese.

Minimieren Sie die Felder: nur das, was Sie für die Zuordnung und Abrechnung benötigen.

Überprüfen Sie regelmäßig die Retention-Richtlinien der Protokolle.

10) Web2App und mobile Realitäten

Für Anwendungen verknüpfen Sie' click _ id '↔' install _ id 'auf der MMP/SDK-Seite.

Wenn es keine deterministische ID (iOS-Privatsphäre) gibt, verwenden Sie probabilistische Match + Server-Regeln, und S2S bleibt die „Wahrheit“ für die Abrechnung.

11) Überwachung und SLA

Metriken:

Erfolgreiche/fehlerhafte Postbacks (%/min), p95 Latenz, Anteil der Retrays, Anteil der Duplikate.
Die Diskrepanz der Ereignisse zwischen den Parteien (Operator vs Tracker) für Tage.
Lieferverzögerung (ingestion lag) und „dips“ stundenweise.

SLA (Beispiel):

Verfügbarkeit von Postbacks ≥ 99. 5 %/Monat.
Die durchschnittliche Verzögerung bis zum Schreiben in DWH ≤ 60 Sekunden; p95 API-Antwort ≤ 500ms.
Daten> 3% → obligatorischer Abgleich der Rohprotokolle innerhalb von 5 Werktagen.

12) Checklisten

12. 1. Tech-Check vor dem Start

Redirector mit Generierung von click_id und Protokollen.
Endpoint der Postbacks: TLS, HMAC, JWT, IP allow-list, idempotency.
Die Payload-Schemata und die kanonische Reihenfolge der Felder sind dokumentiert.
Warteschlangen + DLQ, Retrays, Fehler/Latenz Alerts.
UTC-Zeit, ISO-Währung, FTD/Refund/Chargeback-Regeln.
Durchläufe in der Sandbox mit Fixierung der Referenzprotokolle.

12. 2. Betriebscheck (jede Woche)

Überleitung „Operator ↔ Tracker“ nach Ereignisvolumen und Summen.
Analyse von Duplikaten und „verlorenen“ Ereignissen; Audit von Retrays.
Überprüfung von Schlüsseln/Token, Lebensdauer und Rotation.
Anzeige von Vorfällen und Regelanpassungen.

13) Häufige Fehler und wie man sie vermeidet

1. Keine idempotency → FTD-Takes bei Retrays. → Geben Sie' event _ id 'und den Speicher' gesehen 'ein.

2. Verschiedene Zeitzonen → „geschwommen“ D0/D1. → Immer UTC im Ereignisprotokoll.

3. Stringsummen/Kommas → Parsingfehler. → Übergeben Sie Zahlen mit Punkt und ISO-Währung.

4. Die Unterschrift auf dem „rohen“ JSON bricht → mit der Reihenfolge der Schlüssel. → Machen Sie Kanonisierung.

5. Keine DLQ/Retrays → Verlust von Ereignissen bei Microboys. → Warteschlange + Backoff + Alerts.

6. Schwache Authentifizierung → gefälschte Postbacks. → HMAC + JWT + mTLS/IP-Blatt.

7. Das Fehlen von FTD-Regeln → Abrechnungsstreitigkeiten. → Konsolidieren Sie die Definitionen im Vertrag.

14) Beispiele für Anfragen und Antworten

14. 1. POST/Postback (Operator → Tracker)


POST /postback HTTP/1. 1
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
X-Signature: sha256=ab12...

{ "event":"deposit_success","event_id":"dep_9aa",  "click_id":"clk_123","account_id":"u_456",  "amount":100. 00,"currency":"USD","is_ftd":true,  "ts_event":"2025-10-21T15:12:31Z" }

Die Antwort lautet:


200 OK
{ "status":"ok", "idempotent": false }

Re-Upload mit der gleichen 'event _ id':


200 OK
{ "status":"ok", "idempotent": true }

14. 2. Signaturfehler


403 Forbidden
{ "error":"signature_invalid", "hint":"check canonical order" }

15) Vorfälle und Analysen

Symptom: FTD Operator = 120, Sie haben 117.

Der Plan:

1. Überleitung des Zeitbereichs (UTC) und der Währungen.

2. Rohprotokolle mit 'event _ id '/' click _ id' entladen.

3. Suche nach abgelehnten wegen Signatur/TTL-Token/Idempotenz.

4. Zusätzliche Lieferung von „gestrandeten“ Ereignissen aus dem DLQ, Abstimmungshandlungen.

16) 30-60-90 Umsetzungsplan

0-30 Tage - Kontur MVP

Führen Sie den Redirector mit 'click _ id' und den Protokollen aus.

Implementieren Sie den Empfang von Postbacks: HMAC, JWT, idempotency, Warteschlangen, DLQ, Alerts.

Sandbox anheben, End-to-End-Reg/FTD-Skript mit Testsummen fahren.

Dokumentieren Sie die Schemata und die Kanonisierung der Felder.

31-60 Tage - Qualität und Maßstab

Schließen Sie Geldereignisse und Zwei-Währung-Konten (txn & report) ein.

Konfigurieren Sie die Überwachung von p95 Latenz, Diskrepanzen und Retrains.

SLA/Incident Procedures unterzeichnen; hinzufügen chargeback/refund Ereignisse.

In BI, um Schaufenster zu sammeln: Kohorten FTD, Payback, D7/D30 ARPU.

61-90 Tage - Nachhaltigkeit und Audit

Einführung der Rotation von Geheimnissen/Zertifikaten, Fehlertoleranztests.

Führen Sie Belastungstests und „Notfallübungen“ durch (Warteschlangenausfall/OBD).

Formalisieren Sie die Abgleich-Playbooks und die vierteljährliche Prüfung der FTD-Regelungen/Regeln.

17) Das Ergebnis

S2S-Tracking ist das Rückgrat der ehrlichen Zuschreibung und Abrechnung: click_id als Primärschlüssel, geschützte Postbecks, Idempotenz, Retrays und strenge Zeit-/Währungshygiene. Hinzu kommen transparente FTD-Gültigkeitsregeln, Chargeback-Ereignisse und ausgereifte Überwachung - und Sie erhalten ein zuverlässiges System, bei dem jede Conversion vom Server bestätigt wird und in Berichten auf den Cent konvergiert.