会社情報
採用情報
お問い合わせ
Article

サイトリニューアル後の効果測定：KPI設定と分析方法

高田晃太郎
サイトリニューアル後の効果測定：KPI設定と分析方法

Googleの公開データでは、モバイルのページ読み込みが1秒から3秒に延びると「バウンスの確率（直帰率）」が32%上昇するとされ¹、McKinseyの分析ではデザイン主導企業が収益成長と株主総利回りでほぼ2倍の差を生むと報告されています²。にもかかわらず、サイトリニューアルの効果測定は見た目や主観に寄りがちで、数週間で熱が冷め、数字の検証（KPIやROIの確認、GA4での計測）がおざなりになる現場は少なくありません。プロダクトとグロースの改修現場では、成果を分けるのは、事前のKPI設計と、同等性（前後で同じ定義・条件で計測できること）を担保した計測・分析運用です。移行期はトラフィックの季節性、計測のスキーマ差、SEOの揺り戻し³、同意管理（Consent Mode）に伴う観測母集団の変化¹¹など複数のノイズが重なります。だからこそ、「サイトリニューアル 効果測定」「KPI 設定」「GA4 分析」「BigQuery 比較」「準実験（差の差）」という観点を最初から束ね、KPIツリーで目的を明確にし、GA4/BigQueryと準実験の視点で変化を推定し、ROIの言葉で経営に返す筋道を設計しておく必要があります。

KPI設計の原則：North Star、入力、ガードレール

効果測定の起点は、ビジネスに接続したNorth Star Metric（北極星指標）の定義です。ECなら粗利ベースのウェブ売上や購買回数、B2Bなら商談化率やパイプライン価値の創出といった、価値に直結する量を据えます。そのうえでNorth Starを動かす入力指標（ユーザー行動の中間KPI）を階層化していきます。例えば商品詳細閲覧率、カート投入率、チェックアウト完了率、平均注文額（AOV）、検索回遊の成功率、ナビゲーションの自己解決率などが該当します。さらに、結果を歪めないためのガードレール指標（品質・安全側のKPI）を明示します。代表的にはLCPやCLSなどのパフォーマンス指標⁴（Core Web Vitals）、可用性とエラーレート、404やリダイレクトの比率、ブランド検索のシェア、そしてコンプライアンスに関わる同意取得率です。これらをKPIツリーとして文章で描けば、なぜ今この数値を上げたいのか、どの入力に手を打つのか、どの副作用を許容しないのかが、チーム間で共有可能な言語になります。

リニューアルでは計測の同等性が最大のリスクになります。イベント名やパラメータの変更、同意フローの導入、サイトマップやURL構造の変更、スキーママークアップの改修など、どれか一つでもズレると前後比較が成立しません。対策として、旧環境と新環境でイベントの二重送信期間を設け、GA4（Google Analytics 4）のイベントモデルを揃え、BigQueryの生データで差分を確認する段取りをプロジェクト計画に含めておきます⁵。季節性に関しては同週同曜日比較で短期の目線合わせをし、最終的にはコントロールを用いた準実験（後述の差の差など）で因果の推定に踏み込みます¹⁰。

KPIツリーの具体例（ECとB2B）

ECのケースではNorth Starをウェブ経由粗利に置き、入力としてセッションあたり商品詳細閲覧数、在庫可視化による入荷通知登録率、カート投入率、クーポン適用率、そしてチェックアウトのタイムトゥコンプリートを配置します。ガードレールにはLCPのp75（上位75%が達する代表値）、決済エラー率、配送費用の高騰による利益圧迫などを置きます⁴。B2BではNorth Starを商談化価値にして、入力はウェビナー申込からのMQL化率（Marketing Qualified Lead）、フォーム到達率と完了率、コンテンツのスクロール深度や滞在時間による高意図セグメント比率を置き、ガードレールに問い合わせ応答SLAや同意取得率を配します¹¹。いずれも、イベントの定義とスキーマを先に文書化し、GTMやサーバーサイドタグで反映することが、後段の分析精度を決めます¹³。

リニューアル特有の落とし穴と回避

トラフィックソースの配分が短期間に変わると、集客由来のミックス効果でコンバージョン率（CVR）が動きます。SEOはリダイレクトや内部リンク構造の変更から一時的に落ち込みが起きやすく³、同意管理（Consent Mode）の実装で広告計測が減衰することもあります¹¹。GA4の自動収集イベントに頼りすぎると、フォームの分岐やSPA（Single Page Application）の仮想ページ遷移が抜けることがあります⁵。これらを前提に、比較の単位はチャネル、デバイス、国、重要テンプレートごとに分解して捉え、同時期に広告配信やキャンペーンを変更しない運用上の配慮を合意しておくと、分析のノイズが大きく減ります。

GA4/BigQueryで実装する計測と前後比較

計測はイベントの同等性を軸に設計し、ウェブの主要アクションをサーバーサイド経由で冪等（同じ事象は一度だけ記録）に送信しておくと、広告ブロッカーやネットワークエラーの影響を最小化できます¹³。クライアント側はシンプルに保ち、GTMではイベント名とビジネスパラメータを明示します。例えばB2Bのリード送信を次のように実装します。

<script>
window.dataLayer = window.dataLayer || [];
function trackLeadSubmitted(payload){
  try {
    window.dataLayer.push({
      event: 'lead_submit',
      lead_id: payload.id,
      plan_tier: payload.planTier,
      annual_value: payload.annualValue,
      funnel_stage: 'MQL',
      timestamp_ms: Date.now()
    });
  } catch (e) {
    console.error('tracking failed', e);
  }
}
// 送信完了時に呼び出し
// trackLeadSubmitted({id:'L-12345', planTier:'Pro', annualValue:120000});
</script>

GA4のBigQueryエクスポートでは、eventsテーブルから前後期間のコンバージョン率と平均注文額（AOV）を比較します⁵。テーブルサフィックスで日付を絞りスキャン量とコストを抑え、パーティションやクラスタリング（クエリ最適化）のベストプラクティスを適用します⁶¹⁴。一般的な中規模サイトで日次数GBの出力があり得ますが、_TABLE_SUFFIXで期間を絞れば1回の比較で数十GB程度に抑えられ、BigQueryのオンデマンド課金でも数十セントの目安に収まるケースが多いです⁷。

-- GA4 BigQuery: 前後比較（セッションCVRとAOV）
DECLARE redesign_date DATE DEFAULT DATE("2025-05-15");
WITH sessions AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS d,
    user_pseudo_id,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key='session_id') AS sid,
    geo.country AS country,
    device.category AS device
  FROM `project.dataset.events_*`
  WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(redesign_date, INTERVAL 28 DAY))
                          AND FORMAT_DATE('%Y%m%d', DATE_ADD(redesign_date, INTERVAL 28 DAY))
  AND event_name = 'session_start'
), conv AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS d,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key='session_id') AS sid,
    COUNTIF(event_name IN ('purchase','lead_submit')) > 0 AS converted,
    AVG((SELECT value.int_value FROM UNNEST(event_params) WHERE key='value')) AS value
  FROM `project.dataset.events_*`
  WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(redesign_date, INTERVAL 28 DAY))
                          AND FORMAT_DATE('%Y%m%d', DATE_ADD(redesign_date, INTERVAL 28 DAY))
  GROUP BY d, sid
), joined AS (
  SELECT s.d, s.device, s.country,
         COUNT(DISTINCT s.sid) AS sessions,
         SUM(CASE WHEN c.converted THEN 1 ELSE 0 END) AS conversions,
         AVG(c.value) AS aov,
         CASE WHEN s.d < redesign_date THEN 'pre' ELSE 'post' END AS phase
  FROM sessions s
  LEFT JOIN conv c USING(d, sid)
  GROUP BY s.d, s.device, s.country, phase
)
SELECT phase, device, country,
       SUM(conversions)/SUM(sessions) AS cvr,
       AVG(aov) AS aov,
       SUM(conversions) AS convs,
       SUM(sessions) AS sess
FROM joined
GROUP BY phase, device, country
ORDER BY device, country, phase;

定着やリピートを狙ったリニューアルでは、初回からの再訪までの時間や30日内のリテンションが重要になります。コホートで日次の戻り率を見れば、UI変更の効果が一次CVでは見えなくても、二次効果として現れているかを把握できます。

-- コホート：初回訪問から30日内のリテンション
WITH first_visit AS (
  SELECT user_pseudo_id, MIN(PARSE_DATE('%Y%m%d', event_date)) AS first_d
  FROM `project.dataset.events_*`
  WHERE event_name='session_start'
  GROUP BY user_pseudo_id
), visits AS (
  SELECT fv.user_pseudo_id, fv.first_d,
         PARSE_DATE('%Y%m%d', e.event_date) AS d
  FROM first_visit fv
  JOIN `project.dataset.events_*` e
    ON e.user_pseudo_id=fv.user_pseudo_id AND e.event_name='session_start'
  WHERE PARSE_DATE('%Y%m%d', e.event_date) BETWEEN fv.first_d AND DATE_ADD(fv.first_d, INTERVAL 30 DAY)
)
SELECT first_d,
       DATE_DIFF(d, first_d, DAY) AS day_offset,
       COUNT(DISTINCT user_pseudo_id) AS users
FROM visits
GROUP BY first_d, day_offset
ORDER BY first_d, day_offset;

APIでの集計が適切な現場もあります。GA4 Data APIは細粒度のディメンションで日次を引き、Pandas（Pythonのデータ分析ライブラリ）側で前後差を整形して差分を見ると、可視化までが速いです¹²。エラーハンドリングとタイムアウトを入れ、再試行の制御を組み込みます。

import os
import time
from typing import List
from google.analytics.data_v1beta import BetaAnalyticsDataClient, RunReportRequest, DateRange, Dimension, Metric
from google.api_core.retry import Retry

PROPERTY_ID = os.environ.get("GA4_PROPERTY_ID")
client = BetaAnalyticsDataClient()

def run_report(start: str, end: str):
    request = RunReportRequest(
        property=f"properties/{PROPERTY_ID}",
        date_ranges=[DateRange(start_date=start, end_date=end)],
        dimensions=[Dimension(name="date"), Dimension(name="deviceCategory")],
        metrics=[Metric(name="sessions"), Metric(name="conversions"), Metric(name="totalRevenue")]
    )
    return client.run_report(request, retry=Retry(deadline=30.0))

try:
    pre = run_report("2025-04-17", "2025-05-14")
    post = run_report("2025-05-15", "2025-06-12")
except Exception as e:
    raise RuntimeError(f"GA4 API failed: {e}")

# 必要に応じてpre/postをDataFrame化してCVRやAOVの差分を算出

パフォーマンスの改善はコンバージョンへの弾性を持つため、p75のLCPやCLSといったフィールド指標はCrUXや自前RUM（Real User Monitoring）で監視し⁴、ラボ環境ではLighthouse CIでテンプレート別のパフォーマンスバジェットを検証して回帰を検知する運用が有効です⁸⁹。Nodeでバジェットを検証してビルドを落とす設定にしておくと、リニューアル後の劣化も早期検知できます。

import lighthouse from 'lighthouse';
import chromeLauncher from 'chrome-launcher';

async function run(url) {
  const chrome = await chromeLauncher.launch({chromeFlags: ['--headless']});
  const opts = {logLevel: 'error', output: 'json', onlyCategories: ['performance'], port: chrome.port};
  const runnerResult = await lighthouse(url, opts);
  const lcp = runnerResult.lhr.audits['largest-contentful-paint'].numericValue;
  if (lcp > 2500) {
    throw new Error(`LCP budget exceeded: ${lcp}ms`);
  }
  await chrome.kill();
}

run(process.argv[2]).catch(e => { console.error(e); process.exit(1); });

最後に、テンプレートごとの影響を識別するため、コントロールとなる旧テンプレート群と新テンプレート群をページパスやテンプレートIDで分け、差の差（Difference-in-Differences）で効果を推定します¹⁰。広告や外的要因の影響を均すため、同期間のニュースページなど意図的に変更していないセクションをコントロールに採用するのが実践的です。

-- 差の差：テンプレート別日次CVRの差分推定（骨子）
WITH daily AS (
  SELECT PARSE_DATE('%Y%m%d', event_date) AS d,
         (SELECT value.string_value FROM UNNEST(event_params) WHERE key='template_id') AS tpl,
         (SELECT value.string_value FROM UNNEST(event_params) WHERE key='session_id') AS sid,
         ANY_VALUE(geo.country) AS country
  FROM `project.dataset.events_*`
  WHERE event_name IN ('session_start','purchase','lead_submit')
    AND _TABLE_SUFFIX BETWEEN '20250401' AND '20250630'
  GROUP BY d, tpl, sid
)
-- 実務ではtplを新旧でラベル化し、前後×新旧の相互作用項を回帰で推定
SELECT * FROM daily LIMIT 100;

準実験で因果に近づく：A/Bができない現実への処方

フルリニューアルでA/Bテストが難しい現場は多く、そこでは準実験の設計が鍵になります。差の差（Difference-in-Differences）は、変更対象群と非対象群の前後差をさらに差し引くことで、共通ショックを除いた効果を推定します¹⁰。対象群をテンプレートやURL群で構成し、公開日を境に前後を取り、同期間の非対象群をコントロールに置きます。季節性の影響を減らすため、週と曜日を固定効果として扱うか、同週比較で短期の揺れを均します。ステップリリースやフィーチャーフラグが使えるなら、地域やデバイスを段階導入して自然実験に近づけます。

計測上の注意は二点あります。第一に、イベントの二重送信期間を設け、旧定義と新定義が同じ意味を持つかを生データでクロスチェックすること⁵。第二に、同意管理の変更で観測可能な母集団が縮む場合、同意ありユーザーに限定した比較と、全体比率に基づく重み付けを併記して、経営の意思決定に誤差の幅を明示することです¹¹。信頼区間は意思決定の境界線を与え、導入の是非を感情論から切り離す助けになります。

ROIモデルとダッシュボード：経営に返す言葉

意思決定の最終形は、効果の推定値と不確実性を、コストと時間軸に乗せたROIで表現することです。例えば、基準期間のセッションが月間100万、CVRが2.0%、平均粗利が2,000円なら、月次粗利はおよそ4,000万円です。リニューアルでCVRが相対10%上昇し、平均注文額が変わらないと仮定すれば、粗利は月400万円の上振れになります。ここから移行と開発の総コスト、パフォーマンス改善に伴うインフラ費用の増減、サポートコストの変動を見積もり、回収期間とIRRのレンジを作ります。信頼区間の下限で回収できるかを真剣に問うと、経営は落ち着いて次の投資判断ができるようになります。

運用面では、BigQueryに前後比較のビューを用意し、Looker StudioやMetabaseでテンプレート別のCVR、AOV、パフォーマンス、エラーレート、404比率、同意取得率をひとつの画面に収めます。テーブルは日付でパーティション、テンプレートIDやデバイスでクラスタリングし、ダッシュボードの更新が秒単位で返る感覚を作ると、現場の意思決定速度が上がります¹⁴⁶。BigQueryのスキャンコストは圧縮後のデータ量に依存するため、イベントパラメータの列化や不要フィールドの除外でテーブル設計を見直す価値も大きいです。一般的な運用では、90日×主要ディメンションでの日次比較は、適切なパーティションとサフィックス指定があれば、短時間（秒以内）で返るように最適化できます⁶。

ミニケース：B2B SaaSの情報設計刷新（例示）

B2B SaaSで、情報設計とナビゲーションの刷新、フォーム簡素化、ヘルプセンター統合を同時に行うケースを想定します。イベントは旧新で二重送信し、同意管理の導入に合わせてサーバーサイド計測に移行。公開後4週時点で、ブランド検索の占有は横ばい、オーガニックは一時的に数％の減少、広告流入は意図的に固定するといった前提を置きます。差の差でMQL化率が相対でおよそ10〜20%上昇、フォーム完了のタイムトゥコンプリートが約30〜40%短縮、LCPのp75が3,000ms前後から2,200ms程度まで改善といった傾向が観測されることがあります。反面、ヘルプの自己解決率が当初低下することもあり、FAQの見出し改善とサイト内検索の同義語辞書追加で数週間〜数ヶ月で復帰する、といった進行表が現実的です。粗利換算の上振れ試算から、実コストの回収は数ヶ月で見込めると評価できるケースもあります。こうした枠組みは、プロダクトへの改善提案や次スプリントの優先順位付けにも接続しやすいのが利点です。

まとめ：綺麗さより、測れる強さを

リニューアルのインパクトは、設計されたKPIツリー、同等性を担保する計測、GA4/BigQueryでの分解、準実験での因果推定（差の差）、そしてROIという経営の言語に翻訳する一連の流れがあってこそ、初めて説明可能になります。アートとしての刷新は魅力的ですが、事業としての刷新は、測れる強さが支えます。あなたの組織で次に踏み出すべきは、すでにあるデータを正しく揃え、北極星に向けて入力とガードレールを結ぶことかもしれません。公開から数日で静かな手応えを掴むために、今日、どのテンプレートから検証（GA4/BigQueryによる前後比較）を始めますか。

参考文献

  1. Think with Google. Find out how you stack up to new industry benchmarks for mobile page speed (2017). https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/
  2. McKinsey & Company. The Business Value of Design (2018). https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design
  3. Google Search Central. Site moves with URL changes. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
  4. web.dev. Core Web Vitals. https://web.dev/articles/vitals
  5. Google Analytics Help. Link Google Analytics 4 to BigQuery. https://support.google.com/analytics/answer/9823238
  6. Google Cloud Blog. Cost optimization best practices for BigQuery. https://cloud.google.com/blog/products/data-analytics/cost-optimization-best-practices-for-bigquery
  7. Google Cloud. BigQuery pricing. https://cloud.google.com/bigquery/pricing
  8. Lighthouse CI documentation (GitHub). https://github.com/GoogleChrome/lighthouse-ci
  9. web.dev. Performance budgets 101. https://web.dev/articles/performance-budgets-101
  10. Cunningham, S. Causal Inference: The Mixtape — Difference-in-Differences. https://mixtape.scunning.com/06-differenceindifferences
  11. Google Developers. Consent mode. https://developers.google.com/tag-platform/consent
  12. Google Developers. Analytics Data API v1. https://developers.google.com/analytics/devguides/reporting/data/v1
  13. Google Tag Manager. Server-side tagging. https://developers.google.com/tag-platform/tag-manager/server-side
  14. Google Cloud. Partitioned tables in BigQuery. https://cloud.google.com/bigquery/docs/partitioned-tables