- マーケティング
GoogleアナリティクスとBigQueryで「売れる道」を見つける方法
この記事で分かること
前回の記事「GoogleアナリティクスとBigQueryの決定的な違い」では、GA4が「見やすいレポート」、BigQueryが「生データを自由に集計できる場所」という違いを整理しました。
今回は実践編です。BigQueryのSQL（データベースへの質問文）を使って、「購入する人がよく通る道」と「購入しない人がよく通る道」の違いを数値化する方法を、具体例中心で解説します。
この記事はこんな方におすすめです：
- EC担当者やマーケティング担当者で、「広告費を増やしていいのか根拠がない」と悩んでいる
- サイト改善の優先順位が決められず、「どこから直すべきか」迷っている
- 数字を見ても「次に何をするか」が言葉にできない
目次
GoogleアナリティクスとBigQueryで「売れる道」を見つける方法―続編：SQLで購入者の行動パターンを可視化する
BigQueryのSQL（データベースへの質問文）を使って、「購入する人がよく通る道」と「購入しない人がよく通る道」の違いを数値化する方法を、具体例中心で解説しますが、そもそも、なぜ「購入者の通る道」を見るのでしょうか？それは、売上を伸ばすには「売れる道」を増やすのが近道だからです。
結論から言うと、売れた人がよく通る道と、売れなかった人がよく通る道は、だいたい違います。その差を見つけて「売れる道」を太くするのが、遠回りせずに成果を出す近道です。
たとえば、こんな状況を想像してください。
あなたのECサイトで昨日100人が商品を購入しました。
- 購入した人は、購入前にどのページを見ていたのか?
- どんな順番でページを回遊し、最終的に購入に至ったのか?
- 逆に、購入しなかった人はどこで離脱したのか?
この行動の違いが分かれば、次のような具体的な改善策が見えてきます。
具体例で理解する：2つのサイトで「道の違い」を見つける
具体例A：物販EC（ねじ部品を売るサイト）
あなたのサイトには次のようなページがあるとします。
/landing– 広告から入るページ/category– 商品一覧/product– 商品詳細/shipping– 送料や配送の案内/cart– カート/checkout– 購入手続き/thanks– 購入完了
ここで重要なのは、「どのページが見られたか」だけでなく、どんな順番で見られたかです。
分析結果の例
BigQueryで分析すると、次のような違いが見えてきます。
購入する人によく見られる並び（2ページ連続）：
- 商品詳細 → 送料案内（18%の人が通る）
- 送料案内 → カート（15%の人が通る）
購入しない人によく見られる並び：
- 商品一覧 → 送料案内
- 送料案内 → 商品一覧（12%の人が戻る）
- 商品詳細 → 検索（10%の人が再検索する）
この結果から分かること
「送料案内」が分岐点になっています。
- 購入する人は送料を確認後、カートへ進む
- 購入しない人は送料を見て、商品一覧に戻る（=送料に納得していない？）
次のアクション
- 商品詳細ページに送料の要点を先出し（例：「5,000円以上で送料無料」）
- 広告の誘導先を、送料が安いカテゴリ（大口注文商品など）に変更
具体例B：問い合わせ型サイト（不動産の査定フォーム）
ドコドアが支援する案件では、ECだけでなく「問い合わせ」や「資料請求」が成果のサイトも多くあります。
たとえば、不動産査定サイトの場合：
/assessment– 査定フォーム入力ページ/area– 対応エリアの説明/fee– 料金の説明/result– 実績・事例/thanks– 完了ページ
分析結果の例
問い合わせする人によく見られる並び：
- 料金 → 実績 → フォーム（20%）
- エリア → 実績 → フォーム（15%）
問い合わせしない人によく見られる並び：
- フォーム → 料金 → 離脱（12%）
この結果から分かること
「料金ページ」を見た後に離脱する人が多い。つまり、料金に不安を感じている可能性が高いです。しかし、料金の後に実績を見るユーザーがフォームに遷移している率が多い 。
次のアクション
- 料金ページに実績ページへの導線を強化（「安心して任せられる」を訴求）
- フォーム入力前に、料金の安心感を伝える一文を追加
SQL実行結果例
データ分析の3つのポイント
ポイント1：「購入後」のページを混ぜない―道がぼやける原因
結論：ゴールした後の足あとを混ぜると、道がぼやけます。
購入した人は、購入後に「マイページ」「返品ポリシー」「問い合わせ」なども見ます。でもそれは「買ったから見た」のであって、「買うために見た」わけではありません。
もし購入後の閲覧まで混ぜると、「返品ポリシーが購入を増やしている」と誤解することがあります（実際は購入後に読まれているだけ）。
SQL側の対応
添付のSQLでは、PRE_CONV_ONLY（成果前だけを見るスイッチ）をTRUEにして、最初のコンバージョン時刻より後のページ閲覧を除外しています。
-- 設定例
PRE_CONV_ONLY = TRUE -- CV前のみ見るさらに、コンバージョン判定も2系統で対応：
- サンクス系パス：
/thanksや/completeを含むか - イベント名：
purchaseやtell_tap（電話タップなど）に一致するか
これにより、「サンクスページがないサイト」や「イベントでしか成果が取れないサイト」でも対応できます。
💡 ワンポイント
「購入前」だけに絞ることで、本当に購入を促したページが明確になります。
ポイント2：「3つ並び」で改善点が具体化する
結論：「どのページが見られたか」だけだと点です。「どんな順番で見られたか」だと道になります。
道になると、コンバージョンに寄与しているポイントが分かります。
3つ並び（3ページ連続）で見えること
3つ並びにすると、次のようなコンバージョンの型が見えます：
- 料金ページ → 実績ページ → フォーム（安心して進む）
SQL側の処理
SQLでは次の順でノイズを減らしています：
- URLを整える（
index.htmlを/に、小文字に統一） - 末尾のページ名（
leaf）だけを取り出す - 同じページの連続を圧縮する
LEAD（次の行を見る仕組み）で2つ並び・3つ並びを作成
-- 3つ並びの例
CONCAT(leaf1, ' -> ', leaf2, ' -> ', leaf3) AS sequence失敗しないためのチェックポイント
データ分析でよくある失敗と、その対策をまとめます。
チェック1：テストアクセスが混ざって社内導線が上位になる
理由： 改善の矢印がユーザーではなく社内に向くからです。
対策：
- テストドメイン（例：
https://testsite-dummy.site/）を除外 previewを含むURLを除外- Tag Assistant（計測確認ツール）由来の参照を除外
SQLではExcludedUsers（除外ユーザー集合）として処理しています。
チェック2：コンバージョンの定義が1種類で取りこぼす
理由： 成果があるのに「成果なし」に分類されます。
対策：
- サンクス系パス（
/thanks,/complete）とイベント名（purchase,tell_tap）の両方で判定 - 設定値（キーワード配列）で育てる
チェック3：URLの表記ゆれで同じページが別物になる
理由： 並びが分裂して差が見えなくなります。
対策：
index.html等を/に寄せる- 小文字化
- 末尾スラッシュ統一
- 必要ならクエリパラメータ除去も検討
チェック4：母数が小さい並びを信じすぎる
理由： 再現しない改善に時間が溶けます。
対策：
occurrences（回数）と信頼区間（弊社では、母数が少ない時はWilson信頼区間を使用します。）をセットで見る- 回数が10回未満は参考程度にする
チェック5：期間が長すぎて、昔のサイト構造が混ざる
理由： いまの改善判断がずれます。
対策：
_TABLE_SUFFIXで直近30日、改修前後など目的別に切る
自社運用とプロへの依頼、どう考えるべきか
自社で運用する場合
自社で運用することは時間はかかるものの可能です。とくに今回のSQLのように、設定（コンバージョンの定義、上位件数など）をまとめておくと、社内でも回しやすくなります。
ただ、現場では次のような地味な整備が増えます：
- 除外条件の追加（新しいテストドメインなど）
- イベント名の増減（新しい成果イベントの追加）
- 見やすい表にする（ビュー化）
日々の運用と並行すると、分析が止まりがちです。
プロに任せる価値
プロに任せる価値は、丸投げではなく「目的の言語化は社内、設計と検証は伴走」にできる点です。
たとえば、上位の並びを見て、次のような改善を一気通貫で進められます：
- 広告の誘導先（ランディングページ）を変える
- ページ内のボタン位置を変える
- 説明文を変える
さらに、結果をLooker Studio（可視化ツール）で共有すると、社内説明が一気に楽になります。
💡 ワンポイント
Looker StudioはBigQueryのデータをコネクタで接続して可視化できます。Googleヘルプ
弊社ではこのLooker StudioでBigQueryのデータを可視化することにより、クライアントと定期的なミーティングを開催し、現場の意見を吸い上げたコンバージョンレート向上施策を行っています。
もし、BigQueryを活用したデータ分析にお悩みの場合、ぜひ弊社にご相談ください。弊社では、企業様のニーズに合わせたカスタマイズ分析や、ツールの導入サポートを行っております。
▼ホームページ
https://docodoor.co.jp/lp_marketing/
▼お問い合わせ・ご相談はこちら
https://docodoor.co.jp/lp_marketing/#contact
よくある質問
質問1：広告が少ないサイトでも意味がありますか？
回答： 意味があります。広告が少なくても、自然検索やリピーターの導線にも同じ考え方で使えます。まずは直近期間で、成果ありの並びと成果なしの並びの差を見るのがおすすめです。
質問2：2つ並びだけで十分ですか？
回答： 最初は2つ並びで十分です。3つ並びは情報が増える分、回数が減って不安定になりやすいので、慣れてから追加すると失敗しにくいです。
質問3：結果が出たら、次に何をすればいいですか？
回答： 差が大きい並びが通るページから改善します。送料案内が分岐点なら、送料の見せ方、ボタンの位置、商品詳細への要点の移植など、迷いを減らす施策から着手します。
質問4：Looker Studioで社内共有するとき、まず何を見せればいいですか？
回答： 「並び（sequence）・差（diff_pp）・回数（occurrences）の3つ」をセットで見せるのが分かりやすいです。数字が大きくても回数が少ない場合は判断を保留にし、改善の優先順位を誤らないようにします。
用語集
以下、記事で使用した専門用語を、やさしい言いかえとともにまとめます。
| 専門用語 | やさしい言いかえ | 詳細な定義 |
|---|---|---|
| BigQuery | とても大きいデータを速く数えられる場所 | 大量データを高速に集計できるデータ分析基盤 |
| SQL | データに質問するための言葉 | データベースに対して集計や抽出を指示する言語 |
| イベント | サイトで起きた出来事のメモ | ページ表示やクリックなど、ユーザー行動の記録単位 |
| event_params | 出来事に付ける「メモのメモ」 | イベントにひもづく追加情報（ページURL、参照元など） |
| セッション | 1回の訪問のひとかたまり | 一定時間内の訪問のまとまり |
| 2つ並び／3つ並び | よく通る道の並びを数えるやり方 | 連続する2ページ、3ページの並びを特徴として数える方法 |
| Wilson信頼区間 | その数字が「たまたま」じゃないか確認する安全帯 | 割合の推定に対して、ばらつきを考慮した区間推定の一つ |
| LEAD | 次の行を見る仕組み | SQLで次の行のデータを取得する関数 |
| SAFE_DIVIDE | ゼロ割りを安全に避ける | 分母がゼロの場合にエラーを出さずにNULLを返す関数 |
ドコドア マーケティング部
有資格：Google広告認定資格、Googleアナリティクス個人認定資格など
