「先月、CVの数え方を変えました？」に慌てないために。Consent Mode一本化前後で残しておきたい確認表

「先月、何か変えました？」と聞かれたとき、すぐ答えられますか

「先月、CVの定義か計測条件、何か変えました？」

広告代理店との月次報告で、こんなふうに聞かれたことはないでしょうか。

CV数が増えた。
逆に、急に減った。
広告の成果なのか、サイト側の変更なのか、タグや同意設定の影響なのか。

数字を最後に説明する立場のWeb担当者ほど、この問いにすぐ答えられないと苦しくなります。

2026年6月15日から、GoogleアナリティクスとGoogle広告のあいだのデータの流れ方が変わります。これまで「Google Signals」と「Consent Mode」の2つのスイッチで制御していた広告データの受け渡しが、Consent Mode（ad_storage）側の一本に整理される、という内容です。

私たちがこの案内を読んで最初に確認したのは、設定画面の細かな仕様ではありませんでした。

「これ、社内で誰が確認して、どこに記録するんだっけ？」

という運用の段取りです。

タグ、CMP（同意管理ツール）、広告代理店、そして社内で数字を説明するWeb担当者。関係者が複数いるほど、設定変更そのものよりも、「変更前後をどう記録するか」が重要になります。

この記事では、Consent Mode一本化に向けて、私たちが用意した確認表と運用の残し方を、自社ブログ向けに手順として整理します。

なぜこの課題が起きるのか

背景1：計測条件の変更は、タグ担当だけでは完結しない

6月15日より前は、GoogleアナリティクスとGoogle広告をリンクした際のデータの流れは、主に2つのゲートを通っていました。

ひとつは、Googleアナリティクス側の「Google Signals」。
もうひとつは、Google広告側の「Consent Mode」です。

これまでは、この両方が関係する形で広告データの受け渡しが制御されていました。

6月15日以降は、Consent Mode（ad_storage）が唯一の制御役になります。Google Signalsは、Googleアナリティクス内でログイン済みユーザーの行動レポートに紐づく役割へと縮小されます。

ここで起きやすいのが、「設定を変えた人」と「数字を説明する人」が別になる問題です。

タグ担当者は、設定を更新する。
CMP担当者は、同意取得の連動を確認する。
広告代理店は、広告管理画面の成果を見る。
Web担当者は、月次報告でCV数の変化を説明する。

それぞれの作業は正しくても、変更日や理由が残っていなければ、後から数字の変化を説明できません。

背景2：「変更前の数字」と「変更後の数字」が分断されやすい

私たちも以前、別のタグ系の変更で同じ失敗をしました。

設定の更新そのものは、タグ担当者に任せて完了していました。ところが月末に代理店から「先月、CVの定義変えました？」と聞かれたとき、いつ、何を、なぜ変えたのかを誰もすぐに答えられませんでした。

変更は終わっている。
でも、変更の記録がどこにもない。

この状態になると、CV数のブレが「施策の成果」なのか「計測条件の変更」なのかを切り分けるのに時間がかかります。

計測条件の変更は、タグを直して完了ではありません。

少なくとも、次の4つがセットで残っている必要があります。

• 変更前の数字
• 変更日
• 変更理由
• 変更後の数字

今回のConsent Mode一本化は、この記録体制を見直すきっかけになる変更だと感じています。

解決するためのSTEP

STEP 1：現状を可視化する

まずやるべきことは、現在の設定と影響範囲を見える形にすることです。

私たちは、計測条件に関わる変更があるたびに開く確認表を用意しました。今回のConsent Mode一本化に向けて入れている項目は、たとえば次のような内容です。

1. Google広告側のConsent Mode（ad_storage）の状態を確認したか
2. CMPの同意取得が ad_storage と正しく連動しているか
3. Google Signalsを使っていた前提のレポート・オーディエンスがないか
4. 変更前のCV・主要指標のスクリーンショットを取ったか
5. EU圏のユーザーがいる場合、同意まわりの通知が必要かを確認したか

特に見落としやすいのが、5つ目の同意まわりです。

EU圏のユーザーがいるサイトでは、今回の変更が同意の取り方や通知に関係する場合があります。ここはWeb担当者だけで判断せず、法務や経営の確認も含めて項目化しておくのが安全です。

私たちはこの確認項目を、MONJI+のチェックリスト機能に登録しています。修正依頼を作る画面からそのまま呼び出せるため、「今回も全部見たよね」を毎回そろえやすくなります。

STEP 2：月次運用として記録・一覧化する

確認表を作っても、確認して終わりでは意味がありません。

大事なのは、変更作業そのものを1件の依頼として残し、担当者・期日・優先度を明確にしておくことです。

私たちの場合、Consent Mode一本化に関する作業をMONJI+上で1件の修正依頼として登録しました。タグ担当に割り当て、期日と優先度を付けることで、誰がいつ動くのかが宙に浮きにくくなります。

期日の近い修正依頼はマイページのダッシュボードに並ぶため、一本化の日までに何が残っているかを毎朝確認できます。

また、チェックリストとは別に、変更履歴はWikiにも残しています。

記録しているのは、複雑な議事録ではありません。

「いつ・誰が・何を・なぜ変えたか」を、プロジェクトのWikiに1行ずつ残すだけです。

タグの担当、CMPの担当、広告の担当が同じプロジェクトに入っていれば、それぞれの作業がひとつの場所に時系列で積み上がります。

この状態をつくっておくと、月末に代理店から「先月、計測条件変えました？」と聞かれても、Wikiの行を見ながら説明できます。

「6月◯日に ad_storage 側へ寄せました。理由は、Consent Mode一本化に対応するためです」

この一言がすぐ出せるだけで、会話の進み方はかなり変わります。

STEP 3：数カ月分の実績をもとに交渉・提案する

Consent Modeのような計測条件の変更では、変更直後の数字だけを見て判断すると危険です。

一時的にCV数が動いても、それが設定変更の影響なのか、広告配信の変化なのか、ユーザー行動の変化なのかは、すぐには分からないことがあります。

だからこそ、変更前後のCV・主要指標を数カ月分で見られる状態にしておくことが重要です。

私たちは、変更後のCVや主要指標もGoogleアナリティクス連携で同じプロジェクト内から確認できるようにしています。

「変えた」
「数字を見た」
「記録した」

この流れが分断されないことで、あとから振り返りやすくなります。

広告代理店のように同じ社内チームの外にいる相手にも、公開リンクを使って、対応中の修正依頼だけを切り出して共有できます。

「今どこまで進んでいるか」を口頭で説明し直す手間が減り、月次報告の場でも、数字の見方をそろえやすくなりました。

実際に起きた変化

確認表とWikiを組み合わせるようになってから、代理店との会話はかなり早くなりました。

以前は、CV数が動くたびに、

「タグ側で何か変わりましたか？」
「CMP側は確認済みですか？」
「GA側の設定はいつ見ましたか？」
「誰が作業しましたか？」

と、関係者に個別確認する必要がありました。

今は、まずWikiを見る。
次に、修正依頼の履歴を見る。
必要であれば、変更前後のCV・主要指標を見る。

この順番で確認できます。

その結果、数字のブレを「計測条件の変更によるものか」「実際の成果によるものか」切り分けやすくなりました。

もちろん、すべてが自動で判断できるわけではありません。それでも、判断材料がひとつの場所に残っているだけで、説明のスピードは大きく変わります。

注意点・限界

Consent Modeの設定や同意の取り方が正しいかどうかは、ツールが自動で保証してくれるものではありません。

サイトごとに、どの国のユーザーがいるのか。
どのような同意を取っているのか。
CMPと ad_storage が正しく連動しているのか。
法務や経営の確認が必要な範囲はどこまでか。

こうした判断は、サイトの事情を知っている自分たちで持つ必要があります。

チェックリストやWikiは、その判断をするための土台です。判断そのものを代わってくれるわけではありません。

だから私たちは、確認項目をそろえる作業は仕組みに任せ、最後の「これでいく」という判断は自分たちで握る、という線引きをしています。

広告代理店に任せる部分はあっても、計測条件の変更履歴と説明責任まで丸ごと任せきりにはしない。

今回のConsent Mode一本化は、その線引きをあらためて確認する機会になりました。

現場から生まれたWeb運用プラットフォーム MONJI+

ここまでお伝えしてきたように、Webサイト運用では「設定を変えること」そのものよりも、その前後の確認・記録・共有が大切になる場面が多くあります。

私たちが現場で感じてきた課題を解決するために生まれたのが、Web運用プラットフォーム MONJI+ です。

MONJI+は、Webサイト運用に携わる「人」を1つの「チーム」にまとめ、Webサイト運用のあらゆるフェーズを横断して、課題を解決するプラットフォームです。

私たちは、最初から“完成されたプロダクト”を開発することを目指していません。

本当に向き合うべき課題はWebサイト運用の現場にあり、だからこそ私たちは、現場のリアルな声と向き合い続けてきました。

一つひとつの声を受け止めながら、小さな違和感を解消するアップデートを重ね、現場の課題から新たな機能も生まれてきました。

そうした積み重ねを経て、MONJI+は世界77ヶ国のユーザーさまに支えられる存在となりました。

▼MONJI+について、詳しくはこちらをご覧ください
https://monji.tech/ja/plus/

Webサイト運用の現場で働く人が、誇りを持って「この仕事が好きだ」と言える世界。

▼その実現のために、あなたの声をお待ちしております
https://monji.tech/ja/plus/co-creation/

まとめ

Consent Mode一本化は、単なる設定変更として扱うと、あとからCV数の変化を説明しづらくなる可能性があります。

特に、事業会社のWeb担当者がタグ、CMP、広告代理店のあいだに立っている場合は、「誰が・いつ・何を・なぜ変えたか」を残しておくことが重要です。

今回の記事では、私たちの運用をもとに、次の流れで整理しました。

• Consent Mode（ad_storage）の状態、CMP連動、Google Signals前提のレポート有無を事前に確認する
• 変更前のCV・主要指標をスクリーンショットで残す
• EU圏ユーザーがいる場合は、同意まわりの通知が必要かを法務や経営も含めて確認する
• 変更作業を修正依頼として登録し、担当者・期日・優先度を明確にする
• 変更履歴をWikiに残し、代理店からの確認にすぐ答えられる状態にする
• 変更後の数字も同じプロジェクト内で確認し、「変えた→数字を見た→記録した」をつなげる

「先月、何か変えました？」と聞かれたときに、慌てず答えられる状態をつくる。

そのために、まずは確認表をひとつ用意するところから始めてみるのがよいと思います。