ブログに戻る
オペレーター向け 2026年9月23日 読了目安 5 分

冪等なポストバック:経理が二重計上を気にする理由

リトライしても安全なポストバックが、経理が署名する数字と、経理が議論する数字の差です。冪等が意味すること、オペレーターが同じイベントを一度より多く送る理由、そのときにアフィリエイトがウォレットで見るべきもの。

執筆: AFFILIFY 最終レビュー: 2026年9月23日
経理チームはポストバックを嫌っているのではありません。再現できない合計を嫌っています。リクエストがタイムアウトして再送されたせいで同じ初回入金が2回出せるなら、月は閉じられません。誰かが金曜の午後を、2つのCSVと蛍光ペンで過ごします。冪等なポストバックは、その金曜を取り消す方法です。

これは能力の記事です。AFFILIFYは、オペレーターが一度より多く送っても、コンバージョンを1回だけ数えます。重複の見分け方は公開チェックリストではありません。知る必要があるのは問題の形、線に乗せるもの、リトライが着いたときにアフィリエイトのウォレットがすべきことです。

トラッキングの広い絵が欲しいなら、ポストバック、ピクセル、イメージタグが比較です。これはS2Sの、経理向けの断面です。

ここでの冪等の意味

冪等とは、同じイベントを2回適用しても、保存された結果が変わらないことです。FTD #84102を送る。キューが200を見ていないので、もう一度送る。FTDはまだ1件です。コミッションはまだ1件です。2回目のリクエストはエラーではなく、2人目のプレイヤーでもありません。

反対は、HTTPリクエストごとに増えるカウンターです。そのカウンターはリトライのログとは一致します。オペレーターのプレイヤーデータベースとは一致せず、1人しか送っていないアフィリエイトとも一致しません。

リトライはバグではありません。ネットワークは落ちます。ロードバランサはタイムアウトします。200は失われます。まともに組むなら「届くまで送る」が成功経路であり、受け手が重複を飲み込めるときにだけ安全です。製品要件はこれで全部です。

リトライされたポストバックでも、コンバージョンは1件、コミッションは1件

オペレーターが送るべきもの

クリックIDはすでに持っています。イベントタイプもすでに持っています。登録、FTD、入金、ディールが他に求めるもの。リトライが新しい物体ではなく同じ物体になるよう、そのイベントの安定した識別子を送ってください。正確なフィールド名はここではなく、ポストバックのドキュメントにあります。

月末を救う規則は3つです。

同じペイロードをリトライする。 nonceを増やさない、新しいイベントIDを発行しない、タイムアウトを「直す」ためにFTD-2を送らない。2回目の送信は、1回目の送信をもう一度であるべきです。

HTTPの成功だけを台帳にしない。 自分の側は、リクエストの前に「FTD #84102を送るつもりだった」を記録し、あとに「FTD #84102を受け取ったと言った」を記録する。リクエストだけ記録すると、タイムアウトは穴に見え、埋めるために別のイベントを送ります。

NGRは期間であり、ピンではありません。 入金イベントは入金ごとに冪等にできます。月次のNGRの数字は、日付の範囲についての声明です。足し上がることを期待する小さな増分の流れではなく、その範囲についての声明として送ってください。NGRとネガティブキャリーオーバーが、それらの控除が安定していなければならない理由のアフィリエイト向け版です。

ピクセルはこれをうまくできません。ブラウザで2回発火するピクセルは、2回の発火です。イメージタグも同じです。S2Sが2026年の既定なのは、3つのうち経理が再現に耐えられる唯一のものだからです。それがポストバック対ピクセルの能力の主張です。

アフィリエイトが見るべきもの

1人のプレイヤー、1件のFTD、1本のCPA行。コンバージョンを開けば、ブランド、クリック、GEO、sub-id、タイムスタンプが見えるはずです。双子は見えないはずです。

入金が後から取り消されるなら、それは重複ではなく別のイベントです。チャージバック、ボーナス悪用、キャンセルされた決済。それらは調整として着き、お金を保留にでき、保留中のコミッションを引き戻せます。リトライではありません。支払いの仕組みが、保留中、利用可能、保留、審査中を扱います。支払い自体も出る側で1回だけ数えられます。入る側のポストバックが1回だけ数えられるのと同じ理由です。

二重に見えたら、ウォレットから始めないでください。リンクから始めてください。壊れたクリックIDが生むのは余分ではなく、欠けです。先にトラッキングリンクをQAする。それから、2つの着地、2つのsub-id、2つのブランドが2つの本物のクリックを作ったかを見る。1人からの2つの本物のクリックは、2つのイベントになり得ます。それは二重計上ではありません。クリックが2つです。

これがオペレーターにとっての売りになる理由

二重に数えるアフィリエイトプログラムは払いすぎ、クローバックし、関係を消耗します。リトライを落とすアフィリエイトプログラムは数え足りず、議論し、反対側から関係を消耗します。冪等なS2Sは地味な3つ目です。送り、必要ならもう一度送り、合計は動かない。

AFFILIFYがコンバージョンをバケツではなく行として見せられる理由でもあります。行がイベントです。リトライは合計をいた場所に残します。

アフィリエイト側では、同じ規則が15日を閉じられる理由です。14:58にキューが追いついたからといって変わらない合計の上で、保留中が利用可能になります。KYCはいまも出金の門です。レベルは対象入金を1回だけ数えます。FTDそのものがリトライログ相手のコイントスなら、どれも動きません。

オペレーターとしてこれをつなぐなら、ドキュメントから始め、自分のクリックパラメータを使い、「届くまで送る」を普通として扱ってください。アフィリエイトなら、考えなくてよいはずで、それが要点です。考える必要があるときは、上流が2つの違うイベントを送って1つと呼んでいます。それはリトライではなく、連携のバグです。

よくある質問

ポストバックにおける冪等とは何ですか?

同じイベントを一度より多く送れ、1回だけ数えられることです。タイムアウトとリトライは想定内です。2回目のHTTPリクエストは2件目のFTDではなく、2件目のコミッションでもありません。ペイロードが変わり、新しいイベントIDが発行されたなら、それはリトライではなく新しいイベントです。

オペレーターがリトライしたら、AFFILIFYのウォレットにFTDが二重に出ますか?

出ません。同じイベントのリトライは2本目の行を足さず、2件目のCPAも足しません。2本見えるなら、イベントが2つありました。クリックが2つ、入金が2つ、またはイベントタイプが2つ。プラットフォームが2回数えたと仮定するのではなく、ブランドとほどく価値があります。

支払いが冪等なのと同じことですか?

同じ発想で、向きが違います。入ってくるコンバージョンは、リトライされても1回だけ数えます。出ていく支払いは、支払い事業者が2回求められても1回だけ計上します。どちらもあるので、経理は蛍光ペンなしで月を閉じられます。出る側は[支払いの仕組み](/blog/how-affilify-payouts-work)です。

ピクセルにもこれは必要ですか?

ピクセルとイメージタグはブラウザで発火し、ページが読み込まれた回数だけ発火します。サーバーのポストバックのように、リトライしても安全にはできません。S2Sが既定で、ピクセルがまだサーバーイベントを送れない人の予備である理由のひとつです。S2Sを選んでください。

同じクラスターの記事