Google広告 Confidential Matching実務ガイド｜TEE・attestation・任意暗号化を説明責任に変える方法
カスタマーマッチや拡張コンバージョンでCRMの顧客データをGoogle広告に渡そうとすると、ほぼ必ず「そのデータはGoogleの中でどう扱われるのか」「誰が見られるのか」という質問が法務や情報システム部門から返ってきます。ハッシュ化しているので安全です、という説明だけでは、社内の稟議が止まってしまうケースも少なくありません。
こうした不安に技術面から答えるために用意されたのが、Google広告のConfidential Matching（日本語ヘルプでは「機密情報の照合」）です。2024年9月にGoogleが発表し、カスタマーマッチのデータ接続では標準で適用される形になりました。ところが日本語で読める解説の多くは発表時の概要にとどまり、TEEやattestation、任意の暗号化を「社内への説明責任」にどう結びつけるかまでは整理されていません。
本記事ではConfidential Matchingだけに絞り、仕組みの理解から、カスタマーマッチ・拡張コンバージョン・オフラインコンバージョンとの関係、そして広告運用者が法務と情シスに何を説明し何を確認すべきかまでを解説します。仕様は2026年10月4日時点で確認できたGoogle公式ヘルプ・公式ブログ・開発者ドキュメントにもとづいています。
この記事の要点
- Confidential Matchingは、広告主の顧客データとGoogleのデータの照合をTEE（高信頼実行環境）の中で行う仕組みで、追加費用なしで標準適用される
- attestation（構成証明）は「決められた照合ソフトだけがTEEで動いている」ことを暗号署名で証明する機能で、任意暗号化と組み合わせると鍵の解放条件にできる
- 暗号化は必須ではなく任意。Data Manager APIではGoogle Cloud KMSまたはAWS KMSの鍵で、ハッシュ化済みの値をさらに暗号化できる
- 技術的な保護は「取得の適法性」や同意取得の代わりにはならないため、法務・情シス・広告運用で責任範囲を分けて合意しておく
Google広告 Confidential Matchingは照合処理を隔離環境に閉じ込める仕組み
Google広告のConfidential Matchingは、広告主がアップロードした顧客データとGoogleのデータを突き合わせる処理を、外部から覗けない隔離環境の中だけで実行する仕組みです。照合の結果として広告主の手元に返るのは、Google広告アカウント内のオーディエンスリストという形の「一致したGoogleユーザーのリスト」であり、元の顧客データが広告運用の画面に並ぶことはありません。
Confidential Matchingとは、Google広告データマネージャーの機能の一つで、Confidential Computing（機密コンピューティング）の技術を使ってオフラインのファーストパーティデータとGoogleのデータを照合するものです。Googleデータマネージャーヘルプでは、照合時にTEEと呼ばれる特別なハードウェアとソフトウェアの構成を使うと説明されています。
公式に確認できる仕様
Googleは2024年9月12日の公式ブログで、Confidential Matchingをカスタマーマッチのデータ接続に標準で適用したと発表しました。記事では、処理中の事業者データを隔離し、Googleを含む誰も処理中のデータにアクセスできないようにすると説明されています。あわせて、Googleタグを使った拡張コンバージョンにも数か月以内に広げる予定であることが示されていました。
データマネージャーヘルプでは、Google広告データマネージャーまたはオーディエンスマネージャーの「直接接続」でカスタマーマッチを使う場合、データは自動的にConfidential Matchingで処理されると記載されています。さらに標準で有効になっており、広告主に費用はかからないとも明記されています。設定画面で何かをオンにする必要はなく、広告運用者が意識しないうちに使っているケースが大半です。
| 項目 | 公式情報で確認できる内容 | 出典 |
|---|---|---|
| 発表 | 2024年9月12日 | Google公式ブログ |
| 処理基盤 | TEE（Google CloudのConfidential Space） | データマネージャーヘルプ |
| 適用条件 | データマネージャー／オーディエンスマネージャーの直接接続によるカスタマーマッチは自動適用 | データマネージャーヘルプ |
| 費用 | 追加費用なし・標準で有効 | データマネージャーヘルプ（英語版） |
| 暗号化 | 任意。使わなくても照合は利用可能 | データマネージャーヘルプ |
| 外部検証 | Confidential SpaceのNCC Groupによる独立審査、照合コードのGitHub公開 | データマネージャーヘルプ |
なお、2026年10月時点で日本語版ヘルプは「現在はカスタマーマッチで利用可能（直接接続の場合）」という書きぶりで、英語版ヘルプは拡張コンバージョンも対象として挙げています。言語版で更新時期がずれている可能性があるため、社内資料に対象範囲を書くときは英語版と日本語版の両方を確認した日付を添えておくと安全です。
ハッシュ化や準同型暗号との違い
Confidential Matchingは、従来のSHA-256によるハッシュ化を置き換えるものではありません。カスタマーマッチや拡張コンバージョンでは引き続きメールアドレスや電話番号を正規化してハッシュ化してから送ります。そのうえで、ハッシュ化された値が照合される「場所」をTEEに限定するのがConfidential Matchingの役割です。ハッシュ化はデータの形を変える対策、TEEは処理する環境を守る対策と整理すると理解しやすくなります。
一部の日本語解説では、Confidential Matchingを「準同型暗号で暗号化したまま計算する技術」と紹介しているものがあります。しかし公式ヘルプが説明しているのはTEEとattestationによる仕組みであり、準同型暗号という言葉は出てきません。法務への説明資料に誤った技術名を書くと、後から説明全体の信頼性が揺らぐため、公式ヘルプの用語に合わせて記載するのが基本です。
データマネージャー全体の機能や、顧客データ連携の始め方については以下の記事で詳しく解説しています。
TEEとattestationは「誰も覗けない部屋」と「部屋の中身の証明書」
TEEとattestationの関係は、外から誰も覗けない部屋と、その部屋で決められた作業だけが行われていることを示す証明書の関係にたとえられます。TEEがデータを隔離して守り、attestationがその隔離環境で何のソフトウェアが動いているかを第三者が検証できる形で示します。この2つがそろうことで、「安全なはずです」ではなく「こう証明できます」という説明が可能になります。
TEE（Trusted Execution Environment）の役割
データマネージャーヘルプでは、TEEを「ハードウェアのルート・オブ・トラストを使ってデータ処理の機密性を確保する、ハードウェアとソフトウェアの特別な構成」と説明しています。ポイントは、信頼の起点がソフトウェアの設定ではなくCPUなどのハードウェアにあることです。サーバーの管理者権限を持つ人であっても、TEEの中で処理中のメモリの内容を観察したり、処理を書き換えたりすることを防ぐ設計になっています。
Confidential Matchingは、Google CloudのConfidential Spaceというプロダクトを使って構築されています。Confidential Spaceは、複数の組織がお互いに生データを見せずに共同でデータ処理を行うための基盤として提供されているもので、ヘルプではNCC Groupによる独立したセキュリティ審査の報告書へのリンクも案内されています。社内説明では「Googleの自己申告だけでなく、第三者の審査結果が公開されている」点が説得材料になります。
TEEの考え方は、データを「保存しているとき」と「送っているとき」だけでなく、「処理しているとき」まで守る点に特徴があります。保存時の暗号化や通信の暗号化はすでに一般的ですが、計算の瞬間にはデータがメモリ上で扱える状態になるため、ここが従来の弱点でした。Confidential Matchingは、この処理中の区間をハードウェアの力で囲い込む発想だと説明すると、法務にも伝わりやすくなります。
attestation（構成証明）が証明するもの
attestationは、TEEが特定のソフトウェアを実行していることを暗号署名によって証明するConfidential Computingの機能です。日本語版ヘルプでは「構成証明」と訳されています。照合処理を担うプログラムのイメージが改ざんされていないこと、決められた照合ロジック以外が動いていないことを、署名を検証することで確かめられます。
ここで押さえておきたいのは、attestationが保証するのは「どのソフトウェアが動いているか」であって、「そのソフトウェアが出す結果が広告主にとって望ましいか」ではないという点です。照合率やオーディエンスの規模といった成果面は、従来どおり広告運用の側で確認する必要があります。技術的な証明と運用上の評価を混同しないことが、社内説明をぶれさせないコツです。
実務上の意味が大きいのは、attestationを鍵の解放条件として使える点です。広告主がデータを暗号化して渡す場合、データの復号と処理を許可する前に、Confidential Matchingを実行しているTEEの構成証明を要求できます。つまり証明が確認できない環境では、そもそも鍵が渡らずデータを復号できない状態を作れます。これは運用ルールではなく、技術的に担保される制御です。
コード公開と外部検証の位置づけ
データマネージャーヘルプでは、Confidential Matchingでデータ処理を行うコードをGitHubの専用ページで確認できると案内されています。attestationで「どのソフトウェアが動いているか」を証明できても、そのソフトウェアが何をしているかが分からなければ意味が薄いため、コード公開とattestationはセットで機能する仕組みです。
もっとも、広告運用者がコードを読み込む必要はありません。社内説明で押さえるべきなのは、処理コードが公開されていること、基盤の第三者審査が公開されていること、暗号化を使えば構成証明を鍵の条件にできることの3点です。技術的な検証が必要な場合は、情シスやセキュリティ担当がこれらの公開資料を確認する、という役割分担にしておくと議論が早く進みます。
任意暗号化は説明責任を一段強めるための選択肢
任意暗号化は、Confidential Matchingの標準の保護に加えて、広告主自身が管理する鍵でデータの解放条件をコントロールするための選択肢です。データマネージャーヘルプでは、暗号化は必須ではなく、暗号化しなくてもConfidential Matchingは利用できると明記されています。そのため「全社で必ず暗号化する」のではなく、扱うデータの機微度や社内規程に応じて採否を判断するのが現実的です。
暗号化しない場合でも守られる範囲
暗号化を使わない場合でも、直接接続のカスタマーマッチであれば照合はTEEの中で行われ、ハッシュ化された値はConfidential Matchingで処理されます。広告主側の作業負担は増えず、データマネージャーの画面からCRMやクラウドストレージを接続するだけで標準の保護を受けられます。多くの中小規模の広告主にとっては、まずこの状態を正しく説明できることが出発点になります。
一方で、暗号化しない場合は「TEEで処理されること」をGoogleの仕組みとして信頼する形になります。社内規程で外部委託先にデータを渡す際に自社管理の鍵による暗号化を求めている企業や、金融・医療など機微な顧客情報を扱う企業では、暗号化なしでは規程上の要件を満たせない可能性があります。この判断は広告運用者ではなく、規程を所管する部門に委ねるべき論点です。
暗号化する場合の構成
Data Manager APIの開発者ドキュメントでは、Google Cloud Key Management ServiceとAWS Key Management Serviceのいずれかを使った暗号化手順が案内されています。構成は、データを暗号化する共通鍵のDEK（データ暗号鍵）と、そのDEKを暗号化するKMS上の鍵KEK（鍵暗号鍵）の二段構えです。KEKへのアクセスは、Workload Identityプールのプロバイダを通じて、構成証明の条件を満たした呼び出しにだけ許可します。
処理の順番も決まっています。メールアドレスなどを正規化してハッシュ化し、ハッシュ値をBase64でエンコードしてからDEKで暗号化し、暗号文をエンコードしてAPIリクエストの暗号化情報と一緒に送ります。開発者ドキュメントにはハッシュ化していない値を暗号化してはいけないと明記されているため、「暗号化するならハッシュ化は不要」という誤解は避けなければなりません。
| 比較項目 | 暗号化なし（標準） | 任意暗号化あり |
|---|---|---|
| 照合の処理場所 | TEE内 | TEE内 |
| 鍵の管理者 | なし（Googleの仕組みに委ねる） | 広告主自身のKMS |
| attestationの使い方 | 公開情報として確認する | 鍵を解放する条件として強制できる |
| 主な接続経路 | データマネージャーの直接接続 | Data Manager API、クラウドストレージ経由など |
| 必要な体制 | 広告運用者だけでも開始可能 | クラウドの鍵管理を扱えるエンジニア |
| 向いている企業 | 一般的な会員・購買データを扱う企業 | 社内規程で自社鍵による暗号化を求める企業 |
暗号化の運用で見落としやすいのが、鍵の権限エラーや復号エラーの監視です。開発者ドキュメントでは、KEKの権限不足やDEKの復号失敗といった警告を診断機能で確認するよう案内されています。暗号化を導入した後は、オーディエンスのサイズが急に減っていないかを広告運用側が見て、異常があれば情シスに鍵の状態を確認してもらう連携が欠かせません。
暗号化を採用するかどうかで迷った場合は、まず標準の保護で運用を始め、社内規程の見直しや監査のタイミングにあわせて暗号化の要否を再検討する進め方も現実的です。最初から暗号化を前提にすると、鍵管理の体制が整うまで顧客データの活用自体が止まってしまうことがあるため、段階的に強化する選択肢を残しておくと判断がしやすくなります。
カスタマーマッチ・拡張コンバージョン・オフラインCVとの関係
Confidential Matchingは、カスタマーマッチや拡張コンバージョンと並ぶ別の機能ではなく、それらの機能の裏側で照合処理を守る共通の土台です。そのため「Confidential Matchingを使うか、カスタマーマッチを使うか」という比較は成り立たず、正しくは「どの機能をどの経路で使うと、照合がConfidential Matchingで処理されるか」を整理する必要があります。
機能ごとの適用状況
カスタマーマッチは、データマネージャーやオーディエンスマネージャーの直接接続を使えば自動的にConfidential Matchingで処理されます。拡張コンバージョンについては、公式ブログで展開予定が示され、英語版ヘルプでも対象として挙げられています。オフラインコンバージョンについては、Data Manager APIの暗号化ガイドで、オフラインCVやリード向け拡張コンバージョン、店舗販売のイベント送信も暗号化の対象として案内されています。
注意したいのは、経路によって扱いが異なる可能性がある点です。たとえば管理画面からCSVを手動アップロードする方法や、従来のGoogle Ads APIで送る方法について、公式ヘルプは直接接続ほど明確な記載をしていません。適用を言い切れるのは公式に明記された経路だけと考え、それ以外は「Confidential Matchingで処理される前提では説明しない」ほうが誤解を生みません。
| 機能 | 主な目的 | 送るデータ | Confidential Matchingとの関係 |
|---|---|---|---|
| カスタマーマッチ | 既存顧客へのターゲティング・除外 | ハッシュ化したメール・電話番号・住所 | 直接接続なら自動適用（公式ヘルプ） |
| 拡張コンバージョン（ウェブ） | CV計測の精度向上 | CVページで取得したハッシュ化済みの顧客情報 | 公式ブログで展開を発表、英語版ヘルプで対象と記載 |
| リード向け拡張コンバージョン | 商談・成約を広告に返す | リードのハッシュ化済み識別子と成果情報 | Data Manager APIの暗号化ガイドで対象イベントに記載 |
| オフラインコンバージョン | 来店・電話・受注など広告外の成果の取り込み | クリックIDや識別子と成果情報 | Data Manager API経由で暗号化して送信可能 |
接続経路の選び方
説明責任を重視するなら、カスタマーマッチはデータマネージャーの直接接続に寄せるのが基本です。手動のCSVアップロードは手軽ですが、担当者のPCにリストが残る、誰がいつ上げたか追いにくいといった運用上の弱点もあります。直接接続に切り替えるとConfidential Matchingの自動適用が明確になるうえ、更新の自動化によってリストの鮮度も保ちやすくなります。
代理店や運用パートナーにアカウント運用を任せている場合も、経路の整理は重要です。リストを代理店にメールやチャットで送り、代理店側でアップロードしてもらう運用では、照合処理がTEEで守られていても、受け渡しの途中で複製が生まれます。直接接続であれば、データは自社のシステムからGoogleへ直接届き、代理店は照合後のオーディエンスリストだけを扱う形にできます。
当社の支援現場でも、カスタマーマッチの成果よりも先に「リストの受け渡し方法」で社内承認が止まっているという相談は少なくありません。経路を直接接続に整理するだけで、法務への説明が「担当者の運用ルールを信じてください」から「仕組みとして処理場所が限定されています」に変わります。カスタマーマッチそのものの設定や活用方法は、以下の記事で詳しく解説しています。
広告運用者が法務に説明すべきポイント
広告運用者が法務に説明すべきなのは、Confidential Matchingが「データの処理環境を守る技術」であり、「データを使ってよいかどうか」を決めるものではないという線引きです。ここを曖昧にしたまま「Googleが安全な仕組みを用意しているので大丈夫です」と伝えると、同意取得や利用目的の確認といった本来の論点が抜け落ちてしまいます。
技術的保護と取得の適法性は別の論点
Confidential Matchingは、照合処理中のデータに誰もアクセスできないようにする仕組みですが、そもそもその顧客データを広告目的で使ってよいかは、取得時の利用目的の通知や同意、プライバシーポリシーの記載によって決まります。カスタマーマッチにはGoogleのポリシー上の要件もあり、技術的な保護が整っていてもポリシーや法令への適合が免除されるわけではありません。
また、ハッシュ化や暗号化をしたからといって、国内の個人情報保護法上の取り扱いが変わると断定することはできません。この解釈は企業ごとに法務や顧問弁護士の判断が必要な領域です。広告運用者の役割は、どのデータを・どの経路で・どの機能に使うのかを正確に伝えることであり、法的な評価を自分で下すことではありません。
法務に説明・確認するチェックリスト
- 使うデータ項目（メール・電話番号・住所など）と、送る前にハッシュ化すること
- 使う機能（カスタマーマッチ、拡張コンバージョン、オフラインCV）と利用目的
- 照合はTEE内で行われ、Googleを含め処理中のデータにアクセスできないと公式に説明されていること
- 技術的保護は同意取得や利用目的の通知を代替しないこと
- プライバシーポリシーと同意の取り方が、広告利用をカバーしているかの確認依頼
説明資料に入れておく出典と時点
法務向けの資料には、主張ごとに出典と確認日を添えることが重要です。Confidential Matchingの仕様はGoogle側で更新されることがあり、言語版によって記載の更新時期がずれていることもあります。「データマネージャーヘルプ（英語版・日本語版）を2026年10月4日に確認」のように書いておけば、後日仕様が変わった場合にも、どの時点の情報で判断したかを追跡できます。
説明の順番にも工夫の余地があります。最初に「何のデータを何のために使うのか」を示し、次に「どの経路で送り、どこで処理されるのか」、最後に「処理中に誰がアクセスできるのか」を示すと、法務が判断に必要な情報を順番に受け取れます。技術の説明から入ると、肝心の利用目的の確認が後回しになりやすいため、目的から話し始めるのが基本です。
あわせて、ユーザーの同意状態を広告側に正しく伝える設定ができているかも、法務との会話で必ず出てくる論点です。同意モードの設定や、CMPとの連携の考え方については以下の記事で解説しています。
情シスに確認すべき技術的なポイント
情シスに確認すべきなのは、データの持ち出し経路、接続に使う権限、そして任意暗号化を採用する場合の鍵管理の3つです。Confidential MatchingはGoogle側の処理環境を守る仕組みなので、広告主の社内からGoogleに届くまでの区間と、鍵や権限の管理は広告主の責任範囲として残ります。
データの持ち出し経路と権限
データマネージャーの直接接続では、CRMやクラウドストレージ、データウェアハウスなどとGoogle広告を連携させます。このとき、どのアカウントの権限で接続するのか、接続先のテーブルやファイルに広告目的以外のデータが含まれていないかを、情シスと一緒に確認しておく必要があります。個人の担当者アカウントで接続すると、退職や異動のたびに連携が止まるリスクも生じます。
また、元データの段階で項目を絞ることも大切です。照合に必要なのはメールアドレスや電話番号などの識別子で、購買金額や問い合わせ内容まで連携先に置く必要はありません。照合に使わない項目は接続対象から外すという最小化の原則を守ると、万が一の設定ミスがあっても影響範囲を小さくできます。
社内のネットワークやデータ持ち出しのルールとの整合も確認しておきたい点です。クラウドストレージやデータウェアハウス経由で連携する場合、既存のデータ持ち出し申請の対象になるのか、情報資産の台帳にGoogle広告を連携先として記載する必要があるのかは、企業ごとにルールが異なります。直接接続の設定を始める前に、情シスが社内手続きの要否を判断できるよう、接続先と項目の一覧を渡しておくとスムーズです。
情シスに確認するチェックリスト
- 直接接続に使うアカウントと権限が、個人ではなく管理された共有の仕組みになっているか
- 連携するテーブルやファイルに、照合に不要な項目が含まれていないか
- 任意暗号化を使う場合、Google Cloud KMSとAWS KMSのどちらで鍵を管理するか
- Workload Identityプールのプロバイダに構成証明の条件を正しく設定できるか
- 鍵の権限エラーや復号エラーを誰がどの頻度で監視するか
任意暗号化を採用する場合の鍵管理
任意暗号化を採用する場合、鍵のライフサイクル管理は広告主側の仕事になります。Data Manager APIのドキュメントでは、Google Cloud KMSを使う場合、Workload Identityプールのロケーションをグローバルにすること、構成証明の条件で呼び出し元がConfidential Spaceのサービスアカウントであることや特定のイメージ署名を確認することなどが手順として示されています。
こうした設定は広告運用者が担える範囲を超えるため、導入前に情シスが手順書を読み、工数と運用体制を見積もる段取りが必要です。鍵をローテーションする際の手順や、鍵を誤って無効化したときにオーディエンスの更新が止まる影響まで、事前に洗い出しておくと安心です。オフラインCVをAPIで送る場合の全体設計については、以下の記事も参考になります。
三者の合意を作る進め方と責任分担
三者の合意を作るうえで最も効果的なのは、広告運用・法務・情シスの責任範囲を一枚の表にして、導入前に同じ資料を見ながら確認することです。Confidential Matchingは「Googleが守る範囲」と「広告主が守る範囲」がはっきり分かれる仕組みなので、その境界を明文化するだけで、社内の議論が感覚論から事実確認に変わります。
表を作る際は、Googleの仕組みが担う範囲を「当社が保証するもの」として書かないよう注意が必要です。TEEや構成証明はGoogleが提供し説明している仕組みであり、広告主が自ら検証して保証するものではありません。公式情報の引用であることを明記し、自社の責任範囲は接続・データ項目・同意・鍵管理に限定して書くと、責任の所在が正確に伝わります。
| 担当 | 主な責任範囲 | 合意しておくこと |
|---|---|---|
| 広告運用 | 機能と接続経路の選定、照合率・リストサイズの監視 | 使う機能・経路・データ項目の一覧を作り、変更時に共有する |
| 法務 | 利用目的・同意・ポリシーの適合性の判断 | 広告利用が同意と利用目的の範囲内であることの確認 |
| 情シス | 接続権限、データ最小化、暗号化と鍵管理 | 接続アカウント、鍵の管理者、監視の担当と頻度 |
| Google（仕組み） | TEE内での照合処理、構成証明、処理コードの公開 | 公式ヘルプの記載を出典付きで資料に残す |
導入の進め方
進め方としては、まず広告運用者が現状の顧客データの使い方を棚卸しし、どの機能にどの経路でデータを送っているかを一覧にします。次に、その一覧と公式ヘルプの出典を添えて法務と情シスに説明し、暗号化の要否や接続アカウントを決めます。最後に直接接続への切り替えや暗号化の設定を行い、切り替え前後でオーディエンスのサイズや照合率に大きな変化がないかを確認します。
拡張コンバージョンも含めて顧客データの扱いを見直す場合は、計測側の設定とあわせて整理すると二度手間を防げます。拡張コンバージョンの設定方法やリード向けの活用については、以下の記事で詳しく解説しています。
導入後に定期的に見直すこと
導入後は、少なくとも半年に一度は公式ヘルプの記載を確認し、対象機能や暗号化の対応範囲が変わっていないかを見直します。とくに拡張コンバージョンやData Manager APIまわりは更新が続いている領域であり、社内資料の記載が古くなりやすい部分です。資料の確認日を更新すること自体を運用タスクに組み込むと、監査や問い合わせの際に慌てずに済みます。
顧客データの連携は、一度整えれば広告の学習と計測の精度を長く支える基盤になります。一方で、法務や情シスとの調整に時間がかかり、広告運用者だけでは前に進めにくい領域でもあります。社内の合意形成から設定まで一貫して相談したい場合は、ハーマンドットの無料相談で現状の連携状態を確認するところから始めるのも一つの方法です。
まとめ Confidential Matchingは仕組みと責任分担をセットで説明する
Google広告のConfidential Matchingは、顧客データの照合をTEEの中に閉じ込め、attestationでその処理環境を証明できるようにする仕組みです。カスタマーマッチの直接接続では追加費用なしで標準適用されていますが、その価値を社内で生かすには、次の3点を押さえておくことが重要です。
- 仕組みは公式の用語と出典で説明する。TEE・Confidential Space・構成証明・NCC Groupの審査といった公式情報を、確認日とともに資料に残します。
- 暗号化は社内規程に合わせて選ぶ。標準の保護で足りるか、自社KMSの鍵で構成証明を条件にするかを、情シスと規程の所管部門で判断します。
- 技術的保護と適法性を切り分ける。同意取得や利用目的の確認は法務の論点として残し、広告運用は機能・経路・データ項目を正確に伝える役割に徹します。
まずは無料で広告アカウント診断を
カスタマーマッチや拡張コンバージョン、オフラインコンバージョンで顧客データを活用したくても、社内の説明や接続経路の整理が追いつかず、設定が止まっている企業は少なくありません。どの機能がどの経路でデータを受け取っているのかを把握できていない場合は、まず現状を棚卸しすることから始めるのがおすすめです。
株式会社ハーマンドットでは、Google広告のアカウントと計測設定を確認し、顧客データの連携方法、Confidential Matchingが適用される経路への切り替え、拡張コンバージョンやオフラインCVの設計まで含めて改善点を整理します。お問い合わせフォームからお気軽にご相談ください。社内に説明できる形で顧客データを活用できる状態を一緒に作ります。
初回相談は完全無料・所要時間30分・オンライン対応可能です。