AI経由でCVしたユーザー経路をBigQueryで可視化する
今回のテーマは、AI経由ユーザーの貢献度をどう測るか、だ。
GA4標準のCVR計測では、AI経由ユーザーの本当の貢献度が見えない。理由は単純で、AI経由で初めてサイトに接触し、その日は買わずに帰った人が、後日あらためて指名検索で戻ってきてCVした場合、その「後日CV」はAI経由として記録されないからだ。標準のCVRは最後に繋がったセッションの参照元（last-click）で集計するので、後日CVはまるごと指名検索やGoogleに計上され、最初にきっかけを作ったAIの貢献は0と表示される。
今回は実際にAI経由でCVした1人のユーザーをBigQueryで丸ごと追い、どのような経路でCV新至ったのかを可視化する。
なお、本記事に登場するプロジェクトID・データセット・サービス名・URL・ユーザーIDは、実際のクライアント情報を伏せるためにすべてサンプル値へ置き換えている。クライアントは仮にサンプル社（サブスク型のサービスを運営）とする。
なぜ「たった1人」を丸ごと追うのか
ある月のデータを見ると、AI経由でCVが1件ついていました。集計でAIのCV件数を眺める前に、まずその1人を丸ごと追って、どんなステップでCVに至ったかを可視化します。
理由はシンプルで、件数の集計をいきなり組むと、判定ロジック（年・どのフィールドを参照元と見るか・どのイベントをCVと見るか）が正しいかどうか検証できないからです。1人なら全イベントを時系列で並べても軽いし、目で答え合わせができます。ここで計測ロジックを確定させてから、横展開で件数を数える。順番を逆にすると、間違った定義のまま大きな数字を出してしまう可能性がある。
事前準備：AIの参照元はどのフィールドに入るのか
最初にやるべきは、AI流入が「どのフィールドに格納されているか」の確定です。GA4のBigQueryエクスポートには参照元らしき列が複数あり、ここを間違えると取りこぼします。
候補となるフィールドを横並びにして、AIっぽい値（chatgpt / gemini / perplexity / copilot）がどこに立つかを数えるクエリがこれです。
SELECT
LOWER(collected_traffic_source.manual_source) AS collected_src,
LOWER(session_traffic_source_last_click.manual_campaign.source) AS sess_manual_src,
LOWER(session_traffic_source_last_click.cross_channel_campaign.source) AS sess_cc_src,
LOWER(traffic_source.source) AS user_src,
LOWER((SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_referrer')) AS referrer,
COUNT(*) AS c
FROM `sample-project-000000.analytics_000000000.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260301' AND '20260526'
AND REGEXP_CONTAINS(
LOWER(CONCAT(
IFNULL(collected_traffic_source.manual_source, ''), '|',
IFNULL(session_traffic_source_last_click.manual_campaign.source, ''), '|',
IFNULL(session_traffic_source_last_click.cross_channel_campaign.source, ''), '|',
IFNULL(traffic_source.source, ''), '|',
IFNULL((SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_referrer'), '')
)),
r'chatgpt|gemini|perplexity|copilot')
GROUP BY 1, 2, 3, 4, 5
ORDER BY c DESC;結果を見ると、AIの参照元は sess_cc_src（session_traffic_source_last_click.cross_channel_campaign.source）にきれいに入っていました。chatgpt.com / gemini.google.com / perplexity / copilot.com が全部この列に立ちます。これがGA4でいう「セッションの参照元」とイコールです。
取りこぼしを生む落とし穴：referrerでは見えない
ここで今後の分析のために拾っておきたい発見があります。
collected_src が null なのに sess_cc_src は chatgpt.com、という行がいくつもあります。該当行のreferrerを見ると …/?utm_source=chatgpt.com になっている。これはChatGPTの引用リンクに utm_source=chatgpt.com が付いて飛んできているパターンで、HTTPリファラーではなくUTM経由でソースが判定されています。
つまり、page_referrer ベースで「AIっぽいリファラーが付いているか」を判定すると、このパターンを丸ごと取りこぼします。AI流入は referrer ではなく、セッションの参照元（cross_channel_campaign.source）で見る。これがこのプロパティでの正解でした。最初に候補を横並びにして数えておいたおかげで、ここを間違えずに済みます。
CVユーザーの行動を時系列で追うクエリ
判定ロジックが固まったので、CVユーザーの全イベントを時系列で出します。条件は「年は2026年」「参照元は cross_channel_campaign.source」「CVイベントは お問合せ」の3つ。AIに接触し、かつCVしたユーザーを抽出して、そのユーザーの全イベントを並べます。
WITH base AS (
SELECT
user_pseudo_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
event_name,
TIMESTAMP_MICROS(event_timestamp) AS event_time,
REGEXP_REPLACE(
REGEXP_EXTRACT(
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
r'(https?://[^?#]+)'),
r'^https?://[^/]+', '') AS path,
LOWER(session_traffic_source_last_click.cross_channel_campaign.source) AS session_source
FROM `sample-project-000000.analytics_000000000.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260301' AND '20260526'
),
ai_users AS (
SELECT DISTINCT user_pseudo_id
FROM base
WHERE REGEXP_CONTAINS(session_source, r'chatgpt\.com|gemini\.google\.com|perplexity|copilot\.com')
),
cv_users AS (
SELECT DISTINCT user_pseudo_id
FROM base
WHERE event_name = 'お問合せ'
),
target AS (
SELECT user_pseudo_id FROM ai_users
INTERSECT DISTINCT
SELECT user_pseudo_id FROM cv_users
)
SELECT
b.user_pseudo_id,
b.session_id,
b.event_time,
b.event_name,
b.path,
b.session_source
FROM base b
INNER JOIN target t USING (user_pseudo_id)
ORDER BY b.user_pseudo_id, b.event_time;出力されたのはユーザー1人、セッション6つ。GA4のセグメント（AI接触ユーザー）が出していた「1ユーザー / 6セッション」と完全に一致しました。年とフィールドが直って、BQとGA4が同じものを指すようになった。ここまで来れば、この計測は信用して横展開できます。
結果：10日間の動線
中身は、想定どおりでした。これはlast-clickのAI CVではなく、典型的なアシストCVです。10日間の動線をたどると、こうなっています。
最初の接点は4/17。Google経由でブログ記事（/blog/column/sample-article/）に着地しています。これがファーストタッチで、ここはAIではありません。
4/21、ここでGemini経由でトップページ（/）に再訪します。そこから /service/ → /plan/ → /campaign/ と回遊して、/plan/（料金ページ）に30分以上滞在しています。AI（Gemini）が効いたのは発見ではなく、検討フェーズの深掘りでした。同日と翌日もGeminiセッションが続き、LPや料金ページを見ています。
4/22には、比較サイト（外部の比較メディア）経由で比較検討。
そして4/27、Google経由でLPに入り、申込フォームを進めて/thanks/ で お問合せ が発火しました。クローズのセッションはGeminiでもなく、Googleでした。
動線を一行にまとめると、こうなります。
これは「AIがCVを生んだ」ではなく「AIがCVを助けた」
ここからが本題です。
このパスは「AIがCVを生んだ」のではなく「AIがCVを助けた」パスです。実際にクローズしたセッション（4/27）の参照元はGoogleで、Geminiではありません。冒頭で書いた「AI経由で接触したがその日は買わず、後日あらためて指名検索で戻ってきてCVする」が、まさにこのユーザーで起きていました。
もし同一セッションのlast-clickでCVを集計していたら、このお問合せはまるごとGoogle（指名検索）に計上され、AIの貢献は0と表示されていたはずです。GA4標準のCVRで後日CVが取りこぼされる、というのはこういうことです。
GA4が1件として可視化できたのは、セグメントが「AI接触 → のちにお問合せ」という間接ステップのシーケンスで見ていたからです。
AIをlast-clickで測ると、仕事が丸ごと消える
流入チャネルの価値は「最後にCVに繋がったか（last-click CV）」で測ります。これが王道です。
でもサンプル社のAI流入の実態は、これと逆でした。AIは最後に刈り取る役ではなく、検討の途中で深く効いている。Geminiセッションでこのユーザーが見たのはトップから /plan/ /service/ /campaign/で、料金とサービス比較に30分以上かけています。発見はGoogleのブログ記事、比較は比較サイト、クローズはGoogle。AIは「比較検討の中盤を担うアシスト」というポジションでした。
だからAIを評価するKPIは、last-click CVではなく「CV経路にAI接触が含まれるか（アシスト/シーケンス）」で持つべきです。
施策に落とす：強化すべきは「検討フェーズのページ」
この読み解きを施策に落とすと、強化すべきはトップページではありません。Geminiセッションで実際に消費された検討フェーズのページです。具体的には /plan/（料金）、/service/（サービス比較）、/campaign/。
ここを「AIが引用しやすい構造」に整えると、このアシストの本数を増やせる余地があります。引用されやすい構造とは、たとえば明確な比較表、料金のQ&A、条件別のおすすめといった、AIが切り取って提示しやすい形です。「引用される記事の構造」を、発見系の記事だけでなく、CVに効いた検討ページにも当てていくイメージです。
次の一手：アシスト基準でAI関与CVを数える
ここまでは、あくまで1本のゴールデンパスです。ここから一般化するには、次は数えることになります。
具体的には、last-click基準のAI CV（おそらくほぼ0）と、経路にAI接触が含まれるCV（このユーザーを含む数件）を並べて、その差分を出す。差分そのものが「last-clickでは見えなかったAIの本当の貢献量」になります。
さらに、そのアシストCVの母集団で、AI接触時にどのページへ着地・回遊していたかを集計すれば、検討フェーズで効いているページが面で見えてきます。今回、1人の行動を時系列で追ったことで判定ロジック（年・cross_channel_campaign.source・CVイベント名）が確定したので、あとは件数を出す形に組み替えるだけです。
また、上記をベースにして、月間お問合せ数・受注率・受注単価を出すことができれば、1問合せにおける期待受注額を算出できるので、アシストCVチャネルの隠れ貢献額（関与率）が出せるようになります。
まとめ
AI流入を正しく評価したいなら、最初にやることは2つです。1つ目は、AIの参照元がどのフィールドに入るかを確定させること。このプロパティでは session_traffic_source_last_click.cross_channel_campaign.source で、referrerでは取りこぼしました。2つ目は、評価軸をlast-clickからアシスト（経路にAI接触が含まれるか）へ切り替えること。
今回のケースでいくと、AIは最後に刈り取るチャネルではなく、検討の中盤を深く支えるチャネルでした。BigQueryを活用して初めて、その貢献が数字として見えてきます。