トレントギア

トラッキングとポストバックS2Sどのように機能するか

1）何がS2Sであり、なぜそれが必要であるか

S2S（サーバ間）トラッキングとは、トラフィックソース（リダイレクタ/トラッカー/ネットワーク）のサーバーとオペレータ（カジノ）のサーバー間のイベントの交換であり、ブラウザのクッキーとロックに依存しません。

ポストバック-送信者のバックエンドから受信者のURLへのイベント（reg/KYC/FTD/2nd_dep/...）を含む送信HTTPリクエスト。

利点：

adblock/ITP/プライベートモードによりデータが失われることはありません。
アトリビューションの高精度と請求の品質。
金額や通貨、サービスフラグを安全に転送できます。

2）基本的なチェーンと役割

1.クリック：ユーザーが広告→リダイレクタをクリックすると'click_id'が作成され、パラメータ（utm、 geo、 device、 sub_id)がログされます。

2.リダイレクト：ユーザーはオペレータの着陸に進み、'click_id'はURLにプッシュされるか暗号化されます。

3.登録/CCM/預金はオペレータで発生します。

4.ポストバック：オペレータのサーバーは'registration'、 'kyc_approved'、 'deposit_success'などのイベントをトラッカーに送信し、元の'click_id'にバインドします。

5.BI/Reporting： UTM/creative/geo/deviceセクションでイベントを集計し、CPA/ROAS/LTVを検討します。

テキストスキーム：


広告→クリック→［リダイレクタがclick_idを生成］→LP/App→
↑             │
└────────ポストバック（S2S） ─┘

3）イベント識別子とリンク

click_id（必須）-最初のタッチの一意のID。アトリビューションキー。

event_id（黄色）-各イベントの一意のID （idempotency用）。

user_id/ account_id（卸売）-オペレータ側のプレーヤーID （S2Sのみに送信）。

session_id（卸売）-UX/速度を解析するための。

aff_sub/campaign/ creative_id-分析のセクション。

ルール：click_idはあなたによって作成されます。その側の演算子は、マッピング'click_id ↔ user/account'を格納します。

4）イベントフィールド： 最小構成

4.1.お申込み方法

json
{
"event"： "registration"、 " ："  " "： " "  "geo"： "BR"、 "device"： "android"、 " ："  "ip"： "203。0.113.7」、 「ua」： 「Mozilla/5。0"、 "signature"： "hmac_sha256（ペイロード）"
}

4.2.KYC承認済み

json
{
「event」： 「 」 「 ：」 「 ：」 「」 ： 「 」 「 ：」基本    full"、 "signature"："……"
}

4.3.デポジット（FTD/リピート）

json
{
「イベント」：「 」 「 ：」 「」 ： 「 」 「金額」：100。00、 「currency」： 「USD」、 「is_ftd"： true」、 「payment_method"：」カード    pix（ピックス）    crypto（暗号）    wallet」、 「ts_event"： 「2025-10-21T15:12:31Z,」 「signature」：「……」
}

必須フィールドは'event'、 'event_id'、 'click_id'、 'ts_event' （UTC）、 'signature'です。

通貨フィールドは常に'currency' （ISO-4217）と一緒にあり、文字列ではなく数値として表示されます。

5）セキュリティ： 署名とアクセス

Подпись （HMAC-SHA256）： 'signature=HMAC （secret、 canonical_payload）'；canonizeフィールド順序→安定した検証。

認可レベルでの短命トークン（JWT/不透明）： TTL 5-15分。

Idempotence：同じ'event_id'でPOSTを繰り返すと、二重なしで'200 OK'が得られます。

prodのIP allow-listとmTLS（可能であれば）。

レート制限：「バースト」やボットからエンドポイントを保護します。

postbeckエンドポイントからのHTTPリダイレクトの禁止;直接回答のみ。

6）信頼性： Retrays、キューおよび順序

イベント受信とレポート処理の間のキュー（Kafka/RabbitMQ/SQS）-ピーク時にデータを失わないように。

指数的な一時停止とバックオフジッタを備えたレトライ。試行回数とDLQ（デッドレターキュー）の制限。

注文は任意ですが、BIでソートするには'ts_event'が必要です。

リクエスト/レスポンスログ（機密データなし）、'event_id'による相関。

7）時間帯、通貨および一貫性

UTCのすべてのタイムスタンプ（'2025-10-21T15： 12： 31Z'）。

レポートでは、プロジェクトのタイムゾーンを指定しますが、イベントはUTCに保存します。

トランザクション通貨に金額を保存し、信頼できるレート（日時ベースのFX）を通じてレポート通貨に複製します。

8）重複除外およびビジネスルール

event_id idempotency：繰り返し→「既に処理されている」。

フォールバック機構として（click_id+イベントタイプ+ts-window）による重複除外。

FTDの有効性の規則：最低の沈殿物、ボーナス「ゼロ」の補充無し；契約の修正。

チャージバック/払い戻しは、正直なNGRのための別個の「負の収入」イベントです。

9）機密性とコンプライアンス

URLとフロントにPIIを渡さないでください。S2Sは敏感な分野のための場所です。

同意（分析/広告）を保存し、それらをバージョンアップします。

フィールドの最小化：アトリビューションと請求に必要なものだけ。

保持ログポリシーを定期的に確認します。

10） Web2Appとモバイルの現実

アプリケーションの場合は、MMP/SDK側で'click_id' ↔ 'install_id'をバインドします。

決定論的ID （iOSプライバシー）がない場合-確率的マッチ+サーバールールを使用し、S2Sは請求のための「真実」のままです。

11）モニタリングとSLA

メトリクス：

成功/誤ったポストバック（％/min）、 p95レイテンシ、リトレイの割合、重複の割合。
当事者間のイベントの不一致（オペレータvsトラッカー）日ごとに。
配達遅延（摂取遅延）と「失敗」時間。

SLA（例）：

ポストバック受信の可用性≥ 99。5％/月
DWHに書き込む前の平均遅延≤ 60秒です。p95 API応答≤ 500ms。
データの非同期>3％→5営業日以内の生のログの必須の調整。

12）チェックリスト

12.1.ローンチ前の技術チェック

click_id生成とログを持つリダイレクタ。
ポストバックエンドポイント：TLS、 HMAC、 JWT、 IP allow-list、 idempotency。
ペイロードスキームと正規フィールド順序が文書化されています。
キュー+DLQ、リトレイ、エラー/遅延アラート。
UTC時間、ISO通貨、FTD/払い戻し/チャージバック規則。
参照ログを修正してサンドボックスで実行します。

12.2.営業確認（毎週）

イベントと金額の量による「オペレータ↔トラッカー」の調整。
重複と「失われた」イベントの分析；レトレイの監査。
キー/トークン、寿命、回転をチェックします。
インシデントを表示し、ルールを調整します。

13）頻繁な間違いとそれらを回避する方法

1.Retraysではidempotency→FTDの重複はありません。→「event_id」と入力して「seen」を保存します。

2.異なるタイムゾーン→「floated」 D0/D1。→イベントログ内の常にUTC。

3.文字列の合計/カンマ→エラーの解析。→ピリオドとISO通貨で数字を渡します。

4.「raw」 JSON→の署名はキーの順序から切り離されます。→正規化を行います。

5.DLQ/リトレイがない→Microsobesでイベントが失われる→Queue+backoff+Alerts。

6.弱い認証→偽のポストバック。→HMAC+JWT+mTLS/IPリスト。

7.FTDルールの欠如→請求紛争。→契約の定義を修正。

14）サンプル要求および応答

14.1.POST/postback（オペレータ→トラッカー）


POST/postback HTTP/1。1
Content-Type： application/json
認可：Bearer eyJhbGciOi……
X署名：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」}

答え：


200 OK
{「status」：」 ok」、 「idempotent」： false}

同じ'event_id'で再送する：


200 OK
{「status」：」 ok」、 「idempotent」： true}

14.2.シグネチャーエラー


403禁じられた
{「error「：「signature_invalid」、 「hint「：」check canonical order」}

15）インシデントと解析

症状：オペレータはFTD=120を持っています、あなたは117を持っています。

プラン：

1.時間範囲（UTC）と通貨の調整。

2.'event_id'/'click_id'でログをアンロードします。

3.署名/TTLによる拒否されたトークン/idempotencyを検索します。

4.DLQからの「立ち往生」イベントの追加配信、和解行為。

16） 30-60-90実施計画

0-30日-回路MVP

'click_id'とログでリダイレクタを起動します。

ポストバックの受信を実装する：HMAC、 JWT、 idempotency、キュー、DLQ、アラート。

サンドボックスを上げ、テスト量でエンドツーエンドのreg/FTDスクリプトを実行します。

ドキュメントフィールドの回路図と正規化。

31-60日-質およびスケール

通貨イベントとデュアル通貨会計（txn&レポート）を含める。

p95レイテンシ、不一致、リトレイの監視を設定します。

SLA/インシデント手順に署名する。チャージバック/払い戻しイベントを追加します。

BIでは、ショーケースを収集します：FTD、ペイバック、D7/D30 ARPUコホート。

61-90日-サステナビリティと監査

秘密/証明書、フォールトトレランステストの回転を入力します。

負荷テストと「緊急ドリル」（キュードロップ/DB）を実行します。

調整のプレイブックとFTDスキーム/ルールの四半期ごとの監査を形式化します。

17）ボトムライン

S2S追跡は、正直な帰属と請求の「バックボーン」です。主キーとしてclick_id、保護されたポストバック、idempotency、リトレイ、厳格な時間/通貨衛生。この透明なFTD有効性ルール、チャージバックイベント、成熟した監視に追加すると、各変換がサーバーによって確認され、レポートで1セントに収束する信頼性の高いシステムが得られます。