コンバージョンと売上
注文を、それを生んだクリックに紐づけます。署名付きのクリック識別子、アトリビューション期間、目標、サーバーAPI、ブラウザー用スクリプト、そして外部への転送を説明します。
2026年8月14日更新
コンバージョン計測は、クリックと、そこから生まれたお金との間の輪を閉じます。リダイレクタはリダイレクトのたびに署名付きの識別子を発行し、あなたのサーバーかサンクスページが、それを注文とともに送り返します。すると、いつも読んでいるすべての内訳に、売上の列が加わります。
コンバージョンは有料の機能です。プランに含まれていない場合、リダイレクタは識別子の発行そのものを行わなくなり、2つの受け口はどちらも、プランの制限としてコンバージョンを受け付けません。
クリックの識別子
リダイレクトのたびに、ワーカーはトークンを発行し、次のことを行います。
- リンク先のアドレスに、ご自身で選んだ名前のパラメータ(既定では
lp_cid)として付与します。 - リダイレクト用ドメインのファーストパーティCookieに、有効期間90日で書き込みます。
サードパーティのものを一切受け付けなくなったブラウザーでも紐づけが生き残るのは、このCookieのおかげです。設定しているのが当社のドメインではなく、あなた自身のドメインだからです。
トークンには署名があり、テナントに結び付けられています。ワークスペースとパートナーの識別子が署名対象に含まれているため、あるクライアントのリンクで発行されたトークンは、別のクライアントのワークスペースでは偽造とまったく同じように拒否されます。個人データは含まれません。含まれるのは、クリックの時刻、リンク、分割のバリアント、国、デバイスの種別、流入元、そして疑わしいトラフィックであることを示すフラグです。
パラメータの名前も、発行の有効・無効も、コンバージョン → 設定にあります。どちらを変更しても、すべてのリンクのキャッシュ済み設定がただちに書き換えられます。
アトリビューション期間
期間を過ぎて届いたコンバージョンは、attribution_expiredとして拒否されます。これはinvalid_click_idとは別のコードなので、連携側は「遅すぎた」のか「識別子が壊れている」のかを、推測せずに見分けられます。期間はワークスペースごとの設定です。
目標
目標とは、名前を付けた成果です。purchase、signup、trialといったものです。目標には既定の金額と通貨を持たせられ、金額のないコンバージョンが届いたときに使われます。まだ存在しない目標がコンバージョンから参照された場合は、最初に使われた時点で作成されるので、連携を2か所で設定する必要はありません。
コンバージョンを送る
サーバーから
curl -X POST https://api.linkprofit.com/v1/conversions \
-H "Authorization: Bearer lp_live_..." \
-H "Content-Type: application/json" \
-H "Idempotency-Key: order-10241" \
-d '{
"click_id": "1.eyJ1aWQiOiJ...",
"goal": "purchase",
"order_id": "10241",
"amount_cents": 4999,
"currency": "usd"
}'
キーにはconversions:writeのスコープが必要です。金額は最小通貨単位の整数——セント、ペンス、コペイカです。49.99のような金額は、黙って丸められるのではなく、該当する項目名を添えて拒否されます。支払いの経路の途中で勝手に決めた丸めの規則こそが、売上レポートと請求書が静かに食い違いはじめる原因だからです。
ブラウザーから
ワーカーは、あなた自身のリダイレクト用ドメインから小さなスクリプトを配信します。
<script src="https://go.example.com/cv.js" defer></script>
<script>
window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>
スクリプトは、URLかファーストパーティCookieから識別子を読み取ります。この経路のどこにも、サードパーティのホストは登場しません。これはプライバシー上の性質であると同時に、ホワイトラベル上の性質でもあります。クライアントのページが、プラットフォームに言及するものを読み込むことはいっさいありません。
重複
重複の排除は、読み取ってから書き込むのではなく、1回のアトミックな挿入で行われます。同じorder_idが繰り返し届いても、作られるコンバージョンは1件だけで、応答には重複である旨の印が付きます。だからこそ、失敗したウェブフックの再試行は、危険ではなく安全なのです。
疑わしいコンバージョン
分類の判定はトークンの中に同梱されているため、データセンターやプロキシに紐づいたコンバージョンは、記録される時点で疑わしいものとして印が付きます。削除されるわけでも、黙って混ぜられるわけでもなく、レポートには独立したセグメントとして現れます。「コンバージョン200件」と「コンバージョン200件、うち40件は1時間以内に同じホスティングのアドレス範囲から」は、別の事実です。
コンバージョンのその後
- 署名付きの
conversion.createdウェブフックイベントが、通常のウェブフックの仕組み——キュー、署名、再試行のスケジュール、取りこぼしを拾うcron——を通じて送出されます。 - 設定済みの広告連携には、配送キューを通じてコンバージョンが届きます。試行回数のカウンターは外部への呼び出しの前に加算され、待ち時間の増やし方は文書化されており、無限に再試行するのではなく打ち切りの印が付きます。
月間の上限
プランによって、暦月あたりに受け付けるコンバージョン数に上限が設けられることがあります。集計はUTCです。上限を超えると、受け口はquota_exceededを返します。これはプランの制限とは別のコードなので、「プランに含まれていない」のか「今月分を使い切った」のかの違いが、サポートへ問い合わせなくても分かります。