Dubの紹介リンクを日英で計測する：UTM生成で紹介IDを壊さない実装と検証

日英の記事から同じ紹介リンクへ送ると、どちらの記事が読者の判断につながったかをリンクだけでは区別できない。記事の言語と掲載位置をUTMに入れる方法を、URL生成コードで試した。発行済みリンクのパスと既存の紹介パラメータを保ち、分類に使う値だけを追加する。

検証日は2026年9月30日。今回確かめたのは、ローカルで作ったURLの構造だ。Dub APIでのリンク発行、リダイレクト後のパラメータ保持、購入と報酬の帰属は検証していない。入力には example.com の試験用URLを使い、テストのために紹介クリックや登録を発生させることはしていない。

#クリックと紹介料を別々に確認する

記事から公式サイトへ移動した回数と、紹介料が確定した件数は別の数字になる。読者がリンクを開いても、登録せずに離脱することがある。登録後に無料のまま利用する場合もある。返金やキャンセルの扱いは案件ごとに異なるため、購入の表示だけで入金を見込むのも早い。

このメディアでは、記事の閲覧、リンクのクリック、lead、sale、確定報酬を順に見る。クリック率は「対象リンクのクリック数／対象記事の閲覧数」、lead率は「登録などのlead数／対象リンクのクリック数」と定義する。計測対象と期間をそろえたうえで確認する数字であり、UTMを追加するだけで自動的に計算できるものではない。

Dubの公式説明では、UTM別にリンクの分析を絞り込め、Conversionsと組み合わせると登録や売上を確認できる。ただし、事業者側が計測するconversionを、自分のUTM生成コードだけで追加することはできない。DubのUTM分析機能

#紹介URLを正本にする

まず案件へ参加し、事業者が発行した紹介URLを保存する。紹介先の製品サイトを開いて、そのURLを手作業で短縮リンクへ作り直すと、発行済みの紹介識別子を失う可能性がある。記事ごとの分類は発行済みURLに対して行う。

この記事の実験では、https://example.com/ref/demo?ref=keep#pricing を発行済みURLに見立てた。/ref/demo、ref=keep、#pricing を保つことを期待値に置いた。試験用URLで確認できるのは、こちらのコードがそれらを書き換えないことまでで、事業者の帰属処理がどう動くかは分からない。

実際の運用では、Circlebackは参加済みの紹介リンクを使い、未参加のDubには通常の公式リンクを使う。未参加の案件に紹介IDを推測して付ける運用は取らない。Dubの募集ページに掲載された条件は売上の30%、1年間だが、これはこのサイトに報酬が発生するという意味ではない。Dubの公式募集ページ

#日英で共通のUTM命名を決める

命名は両言語で同じ形式にした。記事のURLに使うslugをキャンペーン名とし、言語と掲載位置は utm_content に置く。翻訳タイトルを値にすると、タイトルを変更しただけで計測上の別キャンペーンになるためだ。

本文中なら body、末尾のサービス案内なら footer を使う。最初から値を限定しておくと、JA、jp、Japanese が同じ意味で混在することを避けられる。閲覧者のメールや顧客名を入れる必要はない。URLはブラウザ履歴やアクセスログなどにも残るため、記事の分類に必要な値だけで足りる。

#文字列連結を使わないURL生成

既存URLにはすでにクエリが付いていることがある。末尾に ?utm_source=... をつなぐ方式では、二つ目の ? が値に混ざるなど、想定していないURLを作りやすい。URL と URLSearchParams を使ってパラメータ単位で編集した。

import { buildReferralUrl } from './referral-utm.mjs'

const url = buildReferralUrl(
  'https://example.com/ref/demo?ref=keep#pricing',
  {
    locale: 'ja',
    slug: 'circleback-webhook-action-items',
    placement: 'footer',
  },
)
console.log(url)

出力は次のURLになる。

https://example.com/ref/demo?ref=keep&utm_source=sakimyto.com&utm_medium=affiliate&utm_campaign=circleback-webhook-action-items&utm_content=ja-footer#pricing

既存のUTMがある場合は、今回の命名で上書きする。searchParams.set を使うため、同じ utm_content を二つ残さない。UTM以外の ref=keep とフラグメントは維持する。関数はHTTPSと、資格情報を含まないURLだけを受け付ける。言語はja/en、掲載位置はbody/footer、slugは小文字英数字とハイフンに限定した。

#ローカルで確認できた範囲

日本語と英語のURLを同じ入力から生成すると、utm_content だけが ja-footer と en-footer で分かれた。パス、ref、フラグメント、キャンペーン名は一致した。既存UTMを含む入力でも、同じキーが重複しないことをテストした。

不正なURLも試した。相対パス、HTTP、javascript:、資格情報を含むURLは拒否する。frという未対応言語、未知の掲載位置、../private というslugも受け付けない。これは公開記事から渡す値を一定に保つための入力検証であり、任意のリンクを安全な紹介リンクに変える機能ではない。

再現用のコードはCirclebackの記事と共通である。3ファイルを同じフォルダに保存し、bun demo.mjs またはNode.js 22以降の node demo.mjs で実行できる。

• UTM生成関数
• 実行デモ
• デモから読み込むタスク変換関数

デモのURLはフラグメントなしの試験用入力で、ja-footer と en-footer の両方を出力する。フラグメント付きの結果を試すなら、入力URLへ #pricing を加える。

#実際の紹介リンクへ適用するとき

Dubは短縮リンクに付けたパラメータを遷移先へ渡せると説明している。また、同じパラメータが遷移先にもある場合は短縮リンク側の値が優先される。このため、紹介プログラムが使うパラメータをこちらで上書きしない運用が必要だ。Dubのパラメータ引き継ぎの説明

適用前には案件の条件を確認し、発行済みリンクへUTMを足してよいかを判断する。許可されたテスト方法があれば、最終URLの紹介識別子、UTM、該当リンクのクリック表示を確認する。購入や登録を自分で行って報酬テストをする手順は含めない。自己紹介や広告利用の制限は、案件ごとの条件に従う。

今回のサイト実装では、Circlebackの紹介リンクは確認できた元のURLで掲載している。UTMの追加は、このローカル生成実験と事業者側での帰属確認を別々に扱う。コードが正しいURLを作ったことを、紹介料が正しく計測されたことの証拠にはしない。

#何を見て次の記事を決めるか

計測にも、AIに仕事の続きを渡すための情報が要る。「この記事は好調」とだけ記録するより、記事slug、言語、対象期間、閲覧、クリック、確定報酬をそれぞれ残す。公開後にAIへ改善案を頼むとき、露出の問題か、導入判断の問題かを、同じ数字から検討できるようにする。今回のURL生成実験だけでは、その実績値は得られない。

公開後に記事を評価するときは、日英それぞれで対象の課題を検索する読者が来ているかを見る。閲覧はあるがクリックが少ない場合、サービスを導入する理由が本文で判断できるかを見直す。クリック後にleadやsaleが増えない場合は、記事と製品の適合、料金、設定の手間などを調べる。少数のクリックだけで、言語別の成約率に差があると結論づけることはできない。

高い報酬率を見つけるだけでは、読者の作業は進まない。CirclebackのWebhook実験では、担当者なしや再送をどう扱うかまで試した。実装を読んだ読者が、自分の運用で必要かを判断できることを、次のSaaS記事でも基準にする。