ECサイトの売上・利益を中長期的に拡大させる上で、Web広告、自然検索、SNS、ダイレクト（Direct）、メールやLINEなどのCRM施策といった集客チャネルの多角的な評価は避けて通れません。昨今はAI経由での購入が増えていますが、依然としてAI以外での流入は健在です。
「今月はSEOからのセッション数が伸びているから好調だ」
「ディスプレイ広告の初回CVRが低いから予算を削ろう」
「Directからの購入が多いから、ブランド認知は十分に上がっている」
現場のマーケティング会議で日常的に交わされるこのような会話ですが、LTVの側面からみると評価はそう単純なものではありません。
本記事では、GA4（Googleアナリティクス4）のアクセスログとECカートの購買データをDWH上で結合し、「流入元別の真の顧客価値（LTV）」を可視化する実践アプローチを紹介します。また、これらのデータを統合する際に頻発する「データの地雷」も公開していきます。
なぜ流入元ごとのユーザー行動を知ることが「利益拡大」に直結するのか？
主な流入チャネルごとの顧客特性とLTV構造の差を整理すると、以下のようになります。
有料広告（Paid Media / 検索・ディスプレイ広告）: キャンペーンや初回割引クーポンなどで即効性高く新規ユーザーを獲得できるが、価格感度の高い「一見客」も混ざりやすく、初回購入後の離脱率（F2転換の壁）が高い傾向がある。
自然検索（Organic Search / SEO）: 特定の深い悩みや明確な目的（ブランド名や成分・用途など）を持って自ら検索して訪れるため、初回購入時の納得感が高く、製品体験がハマれば高いF2転換率（2回目購入率）やLTVを示す「ブランドファン」へ育ちやすい。
SNS / 口コミ（Social / Referral）: 世界観への共感や第三者の推奨（UGC）をきっかけに流入するため、特定カテゴリーの併売（クロスセル）や、自らもSNSで発信・拡散してくれるアンバサダー化のポテンシャルが高い。
ダイレクト / メール・LINE（Direct / CRM）: すでにブランドを深く認識している既存顧客や熱量の高いリピーター層が中心であり、CVRおよび再購入率が最も高く、事業のベースライン（手残り利益）を支える基盤となる。
このように、流入経路によって「顧客の質」が根本的に異なるにもかかわらず、GA4の標準画面で「今月のセッション数」や「初回の購入数」という単一の定規だけで評価してしまうと、例えば「初回のCVRは低いが、1年後のLTVが広告流入の2倍以上に育つSEOコンテンツ」を誤って評価下げして更新を止めてしまったり、逆に「初回のCV数は多いが、2回目以降まったく買われない値引き広告」に予算を注ぎ込み続けるといった本末転倒な意思決定に陥ってしまいます。
流入元の「量（セッション数・初回CV数）」だけでなく、そのチャネルから来た顧客が、最終的にどれだけのLTVや粗利をもたらしているかという「質」を紐づけて評価することこそが、ROI（投資利益率）を最大化させる方法です。
従来手法（GA4単体）の限界とデータサイロ問題
GA4単体のレポートには、構造的な「分断の壁（データサイロ問題）」が存在します。
1. GA4は「購入完了（purchaseイベント）」までしか追えない
GA4が追跡できるのは、ブラウザ上で発生した purchaseイベントの段階までです。その後に発生する「注文・配送のキャンセル」「2回目以降のリピート購入や定期購入」といった情報はGA4内には存在せず、ECカート（Shopify、futureshop、makeshop等）や基幹CRMシステム側に閉じ込められています。
2. クッキーベースのユーザー識別（user_pseudo_id）の限界
GA4は端末・ブラウザごとのCookie（user_pseudo_id）でユーザーを識別しています。同一人物であっても、初回はスマホのInstagram広告から購入し、2回目はPCのGoogle検索から購入した場合、GA4単体ではそれぞれ別のユーザーとしてカウントされてしまい、正しい顧客単位のリピート軌跡やLTVを合算できません。
結果として、Web上の行動データ（GA4）と、バックオフィスにある確定売上・顧客データ（ECカート）が分断され、お互いのデータを活かしきれない状態に陥ってしまいます。
「流入×購買」の分析手法の実践
このデータサイロを越えて「どの流入元が最高のLTVを生み出しているか」を解き明かすために、私たちはDWH（BigQueryやAmazon Athena等）上で以下のデータモデリングを実行しています。
ステップ1：データの圧縮と一元化
GA4のデータは100万イベント/日まで無料でBigQueryにエクスポートすることができます。分析でこの100万行のログをすべて使うことは無いので、カートシステムと結合するデータのみ整形・圧縮します。この圧縮されたデータをECカートデータが格納されているDBまで持っていくところが第一段階です。弊社ではAPIで取得したカートシステムのデータをs3に格納しているため、整形されたGA4データをAmazon AppflowでBigQuery→s3に転送しています。
ステップ2：GA4 transaction_id × ECカート 注文ID のキー結合（JOIN）
整形したGA4データのecommerce.transaction_id をキーにして、ECカートの確定受注データ（order_id）とDWH上でLEFT JOIN（結合）を行います。
クエリ例（両方BigQueryに揃っている場合）
WITH ga4_data AS (
SELECT DISTINCT
user_pseudo_id,
ecommerce.transaction_id,
session_traffic_source_last_click.cross_channel_campaign.source AS utm_sources,
session_traffic_source_last_click.cross_channel_campaign.medium AS utm_media,
session_traffic_source_last_click.cross_channel_campaign.campaign_name AS utm_campaign,
FROM
`your-project.analytics_XXXXXXXXX.events_*`
WHERE
ga.event_name = 'purchase'
AND _TABLE_SUFFIX BETWEEN '20260101' AND '20260831'
),
SELECT
ord.customer_id, -- ECカート側の顧客ID
ord.order_id, -- ECカート側の注文ID
ord.total_revenue, -- 確定売上（キャンセル控除後）
ord.margin_amount, -- 粗利益額
ga.utm_source,
ga.utm_medium,
ga.utm_campaign,
ga.user_pseudo_id
FROM
cart_orders ord
LEFT JOIN -- GA4のtransaction_idとECカートの注文IDを突合
ga_data ga ON transaction_id = ord.order_id
ステップ3：流入元別のコホートLTV・アトリビューション分析
顧客ID（customer_id）が紐づいたことで、特定チャネル（例：2026年1月にSEO経由やGoogleリスティング広告から初回流入・購入した顧客群）をコホートとして固定し、その後の2ヶ月後、3か月後、6ヶ月後の累積LTV推移を時系列で分析することが可能になります。
初回接触（First-click）のアトリビューションモデルによって、「認知に効いているチャネル（SEOやSNS）」と「獲得・リピートに繋がるチャネル」の役割分担を明確にします。
分析時にハマる「地雷」と解決策
結びとして、GA4とECカートのデータ統合基盤を構築するにあたり、現場で直面した「地雷」とその解決策をご紹介します。
地雷1：決済代行システム遷移時のセッション断絶
クレジットカード決済の3Dセキュア認証や、PayPayなどの外部決済画面へ遷移した際、決済完了後にECサイトのサンクスページへ戻って来ます。しかし、そのタイミングでGA4のセッションが切れ、purchase以降のデータが欠損してしまいました。これにより各チャネルのコンバージョン貢献度が著しく過小評価される事態に陥りました。
【現場での解決策】
決済開始画面で発火するbegin_checkoutイベントを使います。セッションが切れない決済方法から「決済開始画面→サンクスページまで完遂する確率」を計算し、セッションが切れる決済方法の決済開始数に掛け合わせることでコンバージョンを算出します。transaction_idの欠損が起きた場合でも、カート内商品と決済開始時刻の情報があれば、類似するECカートデータの明細と理論上は結合可能です。
地雷2：Safari ITP（Intelligent Tracking Prevention）による同一性の破綻
Safari（iOS/macOS）のITP規制により、JavaScriptで発行されたファーストパーティCookie（GA4の _ga / user_pseudo_id）の保持期間が最長7日間（または24時間）に制限されます。これにより、初回購入から2回目の購入（F2転換）までに30日〜60日の間隔が空く商材（アパレルやコスメ等）において、同一のブラウザであってもGA4上では「新規ユーザー（別ID）」として別カウントされ、リピート購入がすべて (direct) / (none) へ分類されてしまう地雷を踏みました。
【現場での解決策】
transaction_idと注文idの結合さえできれば ECカート側のユニークな customer_id（会員ID）を軸とすることで回避できる問題です。GA4上での新規ユーザー訪問率を集計する際は「device.web_info.browser」という項目にSafariが含まれているものを除外します。
■ECのためのダッシュボード「ECコネクター® DashBoard」についてはこちら
〈筆者プロフィール〉
データサイエンティスト J
ECコネクター® DashBoard 開発・データ分析担当。
大学・大学院にてコンピューターサイエンスおよびデータ解析を専攻し、修士課程を修了。
現在は「ECコネクター® DashBoard」の開発エンジニア／データサイエンティストとして、サービス全体のアルゴリズム設計からダッシュボード開発までを担当。 Amazon AthenaやBigQueryを用いた大規模データのクエリ処理、Pythonによるデータパイプライン構築、各種API連携の自動化を得意とし、データの集計・加工からビジネスに直結する可視化までを一貫して手がけている。
