短縮リンクのコンバージョン計測：クリック識別子、有効期間、サーバーイベント

リンクのレポートには自然な止まり方があり、ほとんどのチームにとって、それはクリックです。ダッシュボードは、あるリンクが先月4,000回開かれたと告げ、それを国、デバイス、ブラウザー、参照元で分解して見せてくれます。そして分析はそこで終わります。しかし4,000クリックが語っているのは、いくら使ったかであって、いくら稼いだかではありません。それはファネルの安いほうの半分であり、スクリーンショットで最も見栄えのする半分でもあります。

コンバージョン計測は、リダイレクトの瞬間から、最終的に注文を記録することになる仕組みへ識別子を運び、それを送り返すことで、この隙間を埋めます。考え方の説明は簡単で、間違え方もまた簡単です。しかもその間違いは数か月後になって、請求書と突き合わない売上レポートという形で、ようやく表に出てきます。この記事で扱うのは、識別子、計測の有効期間がなぜ事業上の判断なのか、サーバー側のイベントとブラウザー側のイベントの違い、お金がなぜ整数なのか、重複がどう扱われるのか、そして自分が管理していない仕組みでコンバージョンが起きるときにどうするか、です。

クリックは費用であって、結果ではない

クリックだけのレポートが残り続けるのは、クリックが簡単な計測だからです。リダイレクトはあなたが管理するインフラの上で起きるので、数えるのに誰の協力も要りません。一方、その先で起きることはすべて、どこか別の場所で起きます。1つのクリックイベントに何が含まれ得るかはリンクのクリックが実際にどう計測されるかで扱っていますが、要点は、クリックが起きたことは分かっても、その後に何が続いたかは何も分からない、ということです。

この制約には、実際の帰結があります。2つの配信先がまったく同じクリック数を出しながら、片方は購入者を送り、もう片方は3秒で離脱する人を送っていることがあります。クリックで見ると立派な国別の内訳が、売上で見ると逆転することもあります。クリック率で決めた分割テストは、見出しがより煽情的で決済の完了率がより低いバリアントを、日常的に選び取ります。同じディメンションに売上が紐づくまで、こうした判断はどれも、指標の衣をまとった推測にすぎません。

紐づけるために必要なものは、1つだけです。リダイレクトから注文までの道のりを生き延びる値です。

設計のすべては識別子にある

リダイレクトのたびに、ワーカーはトークンを発行し、それを2つの場所に置きます。あなたが選んだパラメータ名——既定ではlp_cid——でリンク先のアドレスに付与し、同じ値をあなたのリダイレクトドメイン上のファーストパーティCookieに、90日間有効な形で書き込みます。

写しが2つあるのは、どちらも失われうるからです。リンク先はクエリパラメータを削ります。URLをきれいに保つために意図的に削ることもあれば、向こう側のリダイレクトの副作用として落ちることもあります。一方で、今日クリックして3日後にアドレスを直接入力して戻ってくる訪問者には、パラメータはもう残っていませんが、Cookieは持ったままです。どちらの写しも、単独では当てになりません。2つ合わせて初めて、購入に至る現実的な経路の大半を覆えます。

Cookieがファーストパーティであることは、細かい形式の話ではありません。それを設定するのは、訪問者が実際に移動した先である、あなた自身のリダイレクトドメインであり、それこそがブラウザーが取り除いてこなかった種類のCookieです。独自ドメインがブランディングの好みであることをやめ、計測のインフラになるのは、このためです。ベンダー共用のドメインでは、Cookieはベンダーのものになります。

トークンが運ぶもの

トークンは署名されており、署名の対象はクリックだけではありません。ワークスペースとパートナーの識別子が署名対象のペイロードに入っているので、あるクライアントのリンクで発行されたトークンは、別のクライアントのワークスペースでは偽造とまったく同じように拒否されます。複数のクライアントのリンクを運用している人にとって、これは、誰かが忘れずに適用したフィルターによってではなく構造として、あるクライアントの売上を別のクライアントのレポートから締め出してくれます。

トークンに含まれるものは、意図的に絞られています。クリックの時刻、リンク、分割テストのバリアント、国、デバイスの分類、トラフィックの参照元、そして疑わしいトラフィックかどうかのフラグです。個人データはありません。この一覧は、売上の列を役に立つものにしている理由でもあります。それぞれの項目が、分析で売上を分解できるディメンションになり、しかも何かと2度目の結合をする必要がないからです。

パラメータ名と有効・無効の切り替えはワークスペースの設定にあり、どちらを変えても、すべてのリンクのキャッシュされた設定が即座に書き換わります。計画に入れておく価値のある帰結が1つあります。プランにコンバージョンが含まれていない場合、リダイレクターは識別子の発行そのものを止めます。そして後から有効にしても、すでに起きたクリックについて識別子がさかのぼって作られることはありません。

計測の有効期間は事業上の判断

有効期間とは、コンバージョンの功績を認めてもらえるクリックの、最大の古さのことです。ワークスペースごとの設定であり、ここに出てくる数字のなかで唯一、既定値として受け入れるのではなく、議論すべきものです。

短すぎれば、自分が本当に生み出した売上を捨てることになります。長すぎれば、どのみち起きていた購入までリンクの功績にしてしまい、これは役に立たないどころか有害です。自信を持って間違えるからです。選び方は、すでに追跡できている注文について、最初の接触から購入までの間隔を測ることです。衝動買いは数分で終わり、検討を伴う消費者の購入は数日、承認の手順が入る法人の購入は数週間かかります。

この設計が避けている失敗の形は、黙って拒否することです。有効期間を過ぎて届いたコンバージョンはattribution_expiredで拒否され、これはinvalid_click_idとは別のコードです。この2つの状態は、まったく違う直し方を必要とします。両方に同じ汎用のエラーが返る連携は、間違ったところの調査に1週間を使うことになります。コードを記録し、両方を別々に数え、attribution_expiredの割合が増えていることは、有効期間がもう販売サイクルに合っていない兆候として扱ってください。

2つの受け口には、上限の違いもあります。Cookieの寿命は90日なので、それに頼るブラウザー側からの報告は、それより長くは生きられません。サーバー側からの報告は識別子そのものを保存しているので、上限はワークスペースの有効期間だけです。

入口は2つ、ルールは1つ

どちらの経路も同じサービスを通るので、有効期間、重複排除、外部への送信は同一に振る舞います。違うのは、それぞれの経路が何を生き延びるか、そしてあなたに何を求めるかです。

サーバー側のイベント

あなたのバックエンドが、識別子に目標、注文の識別子、金額、通貨を添えて送信します。

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のスコープが必要で、つまりこの経路には、ブラウザー経由にはない負担があります。発行し、保管し、定期的に入れ替える認証情報です。スコープ付きのキーをどう管理するかはAPIの認証をご覧ください。そしてこのキーはサーバーに置いてください——売上データへの書き込み権限を持つキーは、ページに置くものではありません。

その代わりに手に入るのは、広告ブロッカーにも、スクリプトブロッカーにも、トラッキング防止の設定にも、JavaScriptのエラーにも潰されない報告です。あなた自身のインフラから、あなた自身のシステムが注文の存在を認めた瞬間に発火するので、ボタンが押された楽観的な瞬間ではなく、不正チェックを通った後の事実を映します。

ブラウザー側のイベント

ワーカーがあなた自身のリダイレクトドメインから小さなスクリプトを配信し、サンクスページがそれを呼び出します。

<script src="https://go.example.com/cv.js" defer></script>
<script>
  window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>

スクリプトはURLかファーストパーティCookieから識別子を読み取るので、手で何かを渡す必要はありません。経路のどこにもサードパーティのホストが存在せず、これは2つの意味で効いてきます。プライバシー上の性質であると同時に、ホワイトラベル上の性質でもあるからです。クライアントのページは、その下にあるプラットフォームの名前を出すものを、何一つ読み込みません。

代償は、クライアント側の計測につきものの代償です。ブロッカー、プライバシーモード、スクリプトの読み込み失敗、そして訪問者が0.5秒早くタブを閉じること——どれもイベントを取り去りますし、その欠落は均一ではありません。技術者層やプライバシー意識の高いオーディエンスは、一般消費者層よりもはるかに多くを遮断します。つまりブラウザー経由だけの構成は、単に少なく数えるのではなく、セグメントごとに偏った少なさで数えるということです。

どちらを選ぶか

サーバーが注文を知っている場所では、サーバー経由を使ってください。お金が動く場面のほとんどが、それに当たります。ブラウザー経由は、ブラウザーの中にしか存在しない成果や、サーバー側にコードを足せない場合のためのものです。タグマネージャー経由でしか編集できないページ、ホスティング型プラットフォーム上の登録、自分の所有ではないクライアントのランディングページなどです。

1つの成果に両方を走らせても、重複排除があるので安全です。ただしそれは、両方の経路が同じorder_idを送っている場合に限ります。そうでなければ、カバー範囲を広げているのではなく、売上を二重に数えているだけです。

目標そのものは軽い仕組みです。目標とはpurchase、signup、trialのように名前の付いた成果で、金額なしで届いたコンバージョンのために既定の金額と通貨を持つことができ、存在しない目標が参照された場合は、最初の利用時に作られます。

お金は整数

金額は整数の最小単位です。小数点以下2桁の通貨では4999が49.99を意味し、49.99という金額は、黙って丸められるのではなく、該当する項目名を示して拒否されます。

これは1日ほど人を苛立たせ、その後は何年も人を救います。二進の浮動小数点は、ほとんどの小数を正確に表せません。2つの金額を足すと予想外の末尾の桁が付いた3つ目の値が出てくる、あの古典的な実演は珍しい見世物ではなく、規模が大きくなったときに売上の列のあらゆる合計に起きることです。小数点以下を持たない通貨もあるので、100で割れば常に正しい、という前提も成り立ちません。

境界で小数を拒むことは、人が読める価格から最小単位へという唯一の正直な変換を、たった1か所に押し込めます。あなたのコードの中の1か所、テストできる場所です。

重複はデータベースの仕事

重複排除は、読み取ってから書き込むのではなく、1回のアトミックな挿入として行われます。同じorder_idが繰り返し届いても、作られるコンバージョンは1件で、それが重複の印付きで返されます。

この区別は机上の話に聞こえますが、そうではありません。確認してから挿入する方式には、2つの操作のあいだに隙間があり、待ちきれない送信側が再送したWebhookは、その隙間に2件の呼び出しを落とし込みます。どちらも既存のレコードを見つけられず、どちらも1件書き込みます。こうして売上レポートには、後から誰にも見つけられない幻の10%が育ちます。個々のレコードは、どれも完全に正当に見えるからです。

実務上の原則は、自社のシステムのなかで安定していて一意な注文の識別子を選び、その導き方を二度と変えないことです。自社の注文番号はたいてい正解で、タイムスタンプや、再試行のたびに作り直される値は完全に不正解です。上のリクエストのようにIdempotency-Keyヘッダーを添えれば、失敗した呼び出しは、調査するものではなく、もう一度送ればよいものになります。

疑わしいトラフィックは、隠されるのではなく印を付けられます。分類器の判定はトークンの中を一緒に運ばれるので、データセンターやプロキシに紐づいたコンバージョンは、記録される瞬間に疑わしいものとして印が付き、レポートには独立したセグメントとして現れます。コンバージョンが200件あったという事実と、コンバージョンが200件あってそのうち40件は1時間のあいだに1つのホスティング事業者のアドレス範囲から来たという事実は別物であり、お金を払う価値があるのは一方だけです。コンバージョンのデータとトラフィックのフィルタリングが別々の機能であることをやめるのは、まさにこの地点です。

コンバージョンが別の場所で起きるとき

実務での難しさの大半は、APIにはありません。計測する価値のある瞬間が、ホスティング型のストアやCRM、請求サービスの内側で起きることにあります。あなたの仕事は、文字列を1つ、クリックからその仕組みへ運び入れ、もう一度取り出してくることです。

ホスティング型のストア。 そのプラットフォームが注文のカスタム属性やメタデータを許すなら、それがきれいな経路です。訪問者が着地した時点で識別子を読み取り、隠し項目として決済フローを通して運び、注文に保存し、ボタンが押されたときではなく注文が確定したときに、あなたのサーバーからコンバージョンを送ります。カスタム項目をまったく許さない一方で、確認ページへのスクリプトは許すプラットフォームなら、代わりにブラウザー経由を使ってください。こうした選び方はECの導入例で、より詳しく扱っています。

CRMと営業が介在する商談。 リードフォームの隠し項目として識別子を取得してレコードに保存し、商談が受注になった時点でコンバージョンを送ります。ここでの罠は時間です。7週間で決まる商談には、7週間を収められる有効期間が必要ですし、識別子を知っているのがCRMだけなら、その保持期間とエクスポートの挙動が、あなたの計測アーキテクチャの一部になります。リード獲得の時点でsignupの目標を、受注の時点でpurchaseの目標を送ることも検討してください。そうすれば、ファネルの底に四半期かかる場合でも、上のほうは計測できます。

請求とサブスクリプション。 引き金は、請求サービスのWebhookに任せます。請求書が支払われたら、あなたのサーバーが、その顧客に紐づけて保存しておいた識別子を引き、請求書の識別子を注文の識別子としてコンバージョンを送ります。継続課金はそれぞれ別のコンバージョンとして自然に届き、初回の支払いは目標によって、更新と区別できるままになります。

3つのどの形でも、型は同じです。外部の仕組みは、リンクについて何も知る必要がありません。中身の分からない文字列を1つ持っていて、それをあなたに返すだけです。

その数字がこの後どこへ行くかは、意図的にありふれた作りです。署名付きのconversion.createdイベントが、通常のWebhookの仕組みを通じて発行され、設定済みの広告連携は、文書化されたバックオフと、無限の再試行ではなく打ち切りの印を備えた送信キューを通じて、コンバージョンを受け取ります。プランは、UTCで数える暦月あたりの受け入れコンバージョン数に上限を設けることもでき、その上限を超えるとプランの制限ではなくquota_exceededが返るので、「プランに入っていない」と「今月分を使い切った」は、サポートに問い合わせなくても区別できます。

一度で正しく組むために

1. コンバージョンはキャンペーンの後ではなく、前に有効にします。識別子はリダイレクトの時点で発行されるもので、さかのぼって作ることはできません。
2. リンクは自社のドメインで運用し、ファーストパーティCookieが自分のものになるようにします。
3. 有効期間は実測した購買サイクルから決め、attribution_expiredの割合が動いたら見直します。
4. サーバーが注文を知っている場所では、サーバー経由を優先します。
5. 価格から整数の最小単位への変換は、コードのなかのちょうど1か所で行います。
6. 注文の識別子には実際の注文番号を使い、どの経路からも同じ値を送ります。
7. 拒否のコードは別々に記録し、期ごとに1回は請求と突き合わせ、差は平均でならすのではなく調査します。

項目の完全なリファレンスはコンバージョンのドキュメントに、売上の列が、すでに読んでいるレポートのなかでどう振る舞うかはコンバージョン計測の機能ページにあります。これは経理を置き換えるものではありません。答えるのは、経理には答えられない、もっと狭い問いです。どのリンク、どの国、どのリンク先、どのトラフィックの参照元がお金を生んだのか。