しきい値で行が消える
少数のユーザーに関する行は表示されません。属性別・商品別に細かく見るほど、答えに必要な行から先に消えます。
テーマ6 支える層
6
GA4 の画面では、答えが出ない。
BigQuery にイベント単位で出し、受注・広告費とつなぐ
GA4 は、画面で見る限り集計済みの数字しか返しません。BigQuery にイベント単位で出すと、受注・広告費・商品マスタと同じテーブルで扱えるようになり、初めて「なぜ」に答えられます。
初期診断について相談するなぜ画面では足りないのか
サンプリングと「(other)」
期間を伸ばす、項目を細かくすると、推計値や「(other)」への丸めが起きます。検索語やランディングページの長い尾は画面に出ません。
他のデータと結合できない
受注ステータス、原価、送料実費、広告費、在庫、商品マスタ。売上・粗利の問いは、これらと GA4 を同じ行で見る必要があります。
セッション・ユーザーの定義が固定
ログイン ID を主キーにする、複数日の検討期間を1つの単位で扱う、といった自社の定義で見直せません。
保持期間
イベント単位のデータは画面から一定期間で消えます。前年同期との比較、季節性の分解、長い購入間隔の分析ができません。
BigQuery で初めて出せる答え
| 観点 | 画面で止まる理由 | BigQuery で出せる答え |
|---|---|---|
| 05 計測欠損 | 注文 ID 単位で受注と突合できない | 落ちている注文の属性別の割合 |
| 11 取りこぼしの切り分け | イベントの並び順を条件にできない | 再試行・決済手段変更のパターン件数 |
| 12 サイト内検索 | 検索語の尾が (other) に丸まる | ゼロ件語の全件と表記ゆれの統合 |
| 01 増分売上 | 広告費・地域と結合できない | 実験群・対照群の差 |
| 07 クーポン | 顧客単位の履歴と結合できない | 類似顧客比較による効果推定 |
| 03 チャネル別コホート | 獲得月×以後の購買を追えない | 粗利回収までの期間 |
| 04 既存顧客への無駄撃ち | 会員 ID と計測 ID を結合できない | 既存顧客に当たっている新規獲得広告の割合 |
| 16 ベースライン分解 | 保持期間を超える | 季節性・キャンペーンを除いた素の推移 |
この層で初めて立てられる問い
21 売上が落ちた日の原因切り分け
- 問い
- 先週、売上が急に落ちた。計測の問題か、在庫か、広告か、外部要因か。
- なぜ見落とされるか
- それぞれ別の担当者・別の画面にあり、同じ日付軸で並ぶことがない。原因不明のまま「様子を見る」で終わる。
- 何が分かるか
- GA4 のイベント・受注・広告費・在庫・リリース履歴を日付で結合した1つの表。落ちたのがセッションか、購入率か、客単価か、特定デバイスか、特定商品か、を同じ日で切り分ける。
- 必要なデータ
- 既存＝GA4 エクスポート・受注／追加＝広告費・在庫・リリース記録。
- 打ち手の例
- 原因に応じた対応。計測障害なら実装修正、リリース起因なら差し戻し、在庫なら補充・広告抑制。
22 検討期間の実態と、広告評価の窓の見直し
- 問い
- 初回訪問から購入まで、実際に何日かかっているのか。媒体のコンバージョン窓はそれに合っているのか。
- なぜ見落とされるか
- 画面のアトリビューションは媒体側の窓と定義で集計され、自社の顧客の検討期間を測る前提になっていない。
- 何が分かるか
- セッションを横断した購入までの経路と日数の分布（商品カテゴリ・新規/既存別）、最初の接点と最後の接点の乖離、指名検索の広告が自然流入を置き換えている割合。
- 必要なデータ
- 既存＝GA4 エクスポート・受注／追加＝媒体費用。
- 打ち手の例
- 評価窓の変更、上流の接点への予算配分、指名検索の入札見直し。
23 計測異常の自動検知 ★
- 問い
- 計測が壊れていたことに、何日後に気づいているか。
- なぜ見落とされるか
- 計測障害は売上ではなくレポートに現れ、レポートは月次で見られる。壊れている期間は媒体の学習も壊れている。
- 何が分かるか
- GA4 の購入イベントと受注件数の日次乖離、イベント数の急変、パラメータの欠落を、しきい値を超えた日に通知する。
- 必要なデータ
- 既存＝GA4 エクスポート・受注の日次件数。
- 打ち手の例
- 検知当日の実装確認。継続支援の定型項目にする。
24 自社の定義でセッション・顧客を組み直す
- 問い
- ログイン前後、アプリと Web、複数の端末。「同じ顧客」を自社の基準で数えられているか。
- なぜ見落とされるか
- 画面の定義は変えられず、変えられないことに慣れてしまう。
- 何が分かるか
- ログイン ID を主キーにしたユーザー単位の行動、複数日の検討期間を1単位とした購入経路、既存顧客と新規の正確な分離。
- 必要なデータ
- 既存＝GA4 エクスポート・会員 ID の計測設定／追加＝CRM の顧客マスタ。
- 打ち手の例
- 04（無駄撃ちの除外）、17（離反予兆）、02（予測 LTV）の前提になる。
問題分析の型
売上改善だけでなく、起きた問題の切り分けも同じテーブルで行います。
| 症状 | 切り分ける候補 | 使うデータ |
|---|---|---|
| 売上が落ちた | 計測／流入／購入率／客単価／在庫／リリース | 観点 21 の結合表 |
| 特定デバイスだけ購入率が低い | 実装差／決済リダイレクト／表示崩れ | 観点 11・05 |
| 媒体の CV と受注が合わない | 二重計上／欠損／窓の違い／定義の違い | 観点 05・22 |
| 前年比が説明できない | 季節性／キャンペーン／計測変更／保持期間切れ | 観点 16 |
| 検索からの購入が減った | ゼロ件増加／表記ゆれ／カテゴリ変更 | 観点 12 |
画面では、答えに必要な行から消える。必要なもの
- GA4 から BigQuery へのエクスポート設定。未設定なら設定から支援します。設定以前のデータは遡れないため、早期の設定を勧めます。
- 受注データの取り出し方法（CSV／DB／API）。受注側に GA4 の識別子（client_id・session_id）を保存する列があると、購入に至らなかった注文も行動と結べます。
- 必要に応じて広告費・在庫・商品マスタ。
- 参照元除外リストに決済・認証ドメインを登録すること。タイムゾーンと日付境界、二重計上、計測対象外の注文の除外を初回に確認します。
- BigQuery の費用は取り込む量と集計の頻度に比例するため、初回に見積もります。
受け取るもの
- 結合テーブルの設計と集計クエリ
- 定期実行の設定
- 設計意図と運用手順の記録
- ダッシュボードは「見る人が決まっている表」に限って作ります
手順を公開しています
- 計測から落ちている注文を、注文 ID 単位で特定し、日次監視に展開する（観点 05・23）
- 決済で消えている注文を、再試行・手段変更・認証からの戻りのパターンで切り分け、受注ステータスと突合する（観点 11）
- 売上が落ちた日を、セッション×購入率×客単価の分解と、広告費・在庫・リリース履歴の同一日付軸で切り分ける（観点 21・16）
示せるのは手順と実装で、顧客案件での結果ではありません（3事例は生成データで検証し、技術記事と公開コードとして公開します）。
ec_demo n8n_autoupdate_caddy相談
「データが揃っているか分からない」段階から、ご相談ください。
別々の画面やデータでは答えられない問いを、何をつなげば確かめられるかから整理します。