外部プラットフォームでのコンテンツ販売、流入経路の計測が難しい理由

購入完了は自社の解析の外で起きる

外部の販売プラットフォームで商品を売る場合、決済が完了するページは自社ドメインの外にあります。自前のアクセス解析タグを置けるのは、記事やSNSから自社サイトを経由するところまでで、その先の購入完了ページには置けません。

「リンクにUTMを付ける」「販売プラットフォームの管理画面を確認する」という対策は必要です。ただ、これだけでは埋まらない分断があります。クリックと購入が、別々のシステムの上で起きているためです。

販売ページは集客装置ではなく決済ページとして機能している

2026年6〜7月の時点で、販売プラットフォームの販売履歴に並ぶ購入は、すべて「紹介者：なし」でした。2026-09-12に改めて確認した時点でも、累計11件すべてが「紹介者：なし」のままです。

プラットフォーム内のおすすめ経由の購入がゼロということは、そのページ自体は集客を担っていないということです。買い手を商品ページまで連れてくる工程は、すべて自社側（記事・SNS）で終わっていて、プラットフォームは決済だけを担当しています。

そうであれば、計測すべき対象は「販売ページで何が起きたか」ではありません。「販売ページの手前で、誰がどこから来たか」です。

計測を後回しにした結果、実際に起きたこと

直接リンクだった頃は、クリックが一切残らなかった

以前は、記事から販売ページへ直接リンクしていました。この構成では、クリックが自社の解析にまったく残りません。そのため、最初の売上が発生したときも「何が売らせたか」に答えられませんでした。

2026-06-20から、すべてのリンクを自社ドメインの中継ページ（/go/<商品>）経由に統一しています。

リンクそのものが死んでいた記事があった

2026-07-12に点検したところ、販売ページへのリンクを持つ自社記事6本のうち4本（5月公開分）は、リンク部分が差し替え前の仮置き文字列のままで、リンクとして機能していませんでした。

つまり、その時点までの売上は、実質2記事の成果だったことになります。計測が無い状態では、この「4本が死んでいる」という事実にも気づけませんでした。

ここから言えるのは、計測の仕組みを作ることと、その仕組みが実装どおりに動いていることを確認することは、別の工程だということです。リンクを貼った直後・差し替えた直後の点検を、作業の一部として組み込んでおく必要があります。

測れる範囲と測れない範囲を先に線引きする

購入完了は外部プラットフォーム側で起きるため、1件のクリックと1件の購入を結ぶことはできません。ここは推測で埋めません。

測れるのは、次の2つを並べて見るところまでです。

  • 送客クリックの記事単位の実数（自社の中継ページを経由した回数）
  • 販売履歴の日付（外部プラットフォームの管理画面に出る購入日）

「どのクリックがどの購入になったか」は分かりません。それでも「どの時期に、どの記事群からの送客が多かったか」と「どの時期に売れたか」を並べることはできます。

計測設計の最初にやるべきなのは、この境界線を引くことです。境界線を引かずに「完全に結びつける」という目標を立てると、構造上届かない目標を追いかけることになります。

送客クリックを記事単位で取るための中継ページの設計

自社の記事やSNSから外部の販売ページへ送る前に、自社ドメインの中継ページ（/go/<商品>）を必ず経由させます。実装は次のとおりです。

  • 静的ホスティングの書き換えルールで、/go/<商品> へのアクセスを中継用HTMLへ「200（URL書き換え）」で渡す。これにより、クエリ文字列（utm_*）がそのまま残る
  • 中継HTMLに自前の解析タグを置き、ページビューが記録されるよう約0.8秒待ってから、販売ページへ location.replace で移動する
  • JavaScriptが無効な環境では、meta refresh で即時に移動する
  • 自動で移動しない場合に備えて、「自動で移動しない場合はこちら」という手動リンクも置く
  • 中継ページ自体が検索結果に載らないよう、noindex,nofollow を指定する
  • OGP（タイトル・説明・画像）を持たせ、記事やSNSにURLを貼ったときにリンクカードが商品の画像付きで出るようにする

この設計には、計測以外の利点もあります。販売ページのURLが変わっても、直すのは中継ページ1か所で済みます。記事やSNSに貼った既存のリンクを1本ずつ直す必要がありません。

別ドメインの決済ページ（自社の解析の外にあるページ）へ送る場合も、同じく /go を経由させます。送り先がどこであっても、計測の入口は自社の中継ページに統一しています。

UTMの設計：記事を一意に識別する

リファラでは記事まで分からない

中継ページを置いても、パラメータの設計が甘いと「どの記事が送客したか」までは分かりません。実際、解析上のリファラは送客元サイトのドメイン止まりで、記事のパスが落ちていました。既存のパラメータにも記事を識別する値が無く、記事単位の識別は構造的にできない状態でした。

そこで2026-08-08に utm_term を追加し、記事を一意に指す文字列を必ず入れる運用にしました。現在の規約は次の5つです。

  • utm_source：送客元のアカウント
  • utm_medium：媒体
  • utm_campaign：cta で固定（商品ごとに変えない）
  • utm_content：着地先（商品）の識別
  • utm_term：記事を一意に指す文字列（記事管理シートのslug列と完全一致）

utm_term の値は記事管理シートのslug列と一致させています。スクリプトが解析ツールからこの値を回収し、記事管理シートへ「送客クリック」「取得日」として書き戻します。突合は値の完全一致だけで成立するので、人が記事名を目で照らし合わせる工程はありません。

SNSのプロフィール欄は短いURLにする

SNSのプロフィール欄には別の制約があります。文字数の上限で長いURLが切れる媒体や、「?」以降を落とす媒体があります。そのため2026-09-20から、プロフィール欄には短い /go/<媒体>-<軸> を置き、UTMは転送先（302リダイレクト）の側に持たせています。プロフィール欄に剥き出しのUTM付きURLは出しません。

母数が少ない前提での集計方法

中継ページとUTMを整えても、母数そのものが小さいという現実は残ります。2026-08-08時点の実測では、記事から自社サイトへの送客は過去28日で約50クリック（アカウント別に35と7）でした。

これを記事本数で割ると、記事1本あたり0〜1クリックにしかなりません。この密度では、記事1本ずつの優劣は判断できません。

そこで、集計の主役を「記事別」から「記事の型（テンプレート）別・アカウント別の合算」に変えました。型で束ねると、1つの型あたり13本前後の母数が立ちます。母数が3本に満たない型は「参考値」として別枠に置き、効く型とは呼びません。

記事単位のクリック数は、それ単体で意思決定に使う数字ではありません。型ごとの合算に積み上げるための最小単位として取っておくものです。

外部プラットフォームでのコンテンツ販売は、決済までのどこかで必ず自社の解析の外に出ます。そこを無理に埋めようとせず、埋まらない境界線を先に引き、境界線の内側（記事から自社ドメインまでの送客）を記事単位で確実に取る。relmeaではこの形で運用しています。