「自社データを活用しましょう」。この一文が資料に入っていない広告の提案書は、いまほとんどありません。ただ、そのあとに続くのが「まずはデータを集めましょう」だと、着手した瞬間から回り道になります。
集めることは、いちばん最後でも間に合います。先に決めるのは渡し先です。どの媒体の、どの機能に、どの形で渡すのか。それが決まっていないと、集めた顧客データは社内のどこかに置かれたまま、広告の管理画面には一度も届きません。実際、CRMに購入履歴が何年ぶんも貯まっているのに、広告側の設定は初期のままという状態は珍しくありません。
この記事は、1stパーティデータをWeb広告の計測へつなぐまでの道筋を、順番に並べ直したものです。ツールの比較記事ではありません。自社の側で何を決め、何を整え、どの順に手を動かすかを、公式ドキュメントに書かれていることだけを土台にして書いています。
こんなふうに調べていませんか
- 「1stパーティデータ 広告」で検索して、何から着手するか探している
- CRMの顧客データを広告に使いたいが、同意まわりで止まっている
この記事を読み終えたときに手に入るもの
- 1stパーティデータと借り物の識別子の違いを、社内で説明できるようになります
- 顧客データを広告へ渡す前にそろえる同意と通知の項目を、点検できるようになります
- CRMの接続を、出口・識別子・整形・照合の順に手順へ落とせます
結論30秒でわかる、この記事の結論
- 1stパーティデータの整備は、集める作業ではなく「渡し先を決める」作業から始まります。出口が決まると、必要な項目が自動的に絞れます。
- 渡す前に要るのは、同意と通知の整理です。ここは技術の話ではなく、プライバシーポリシーと社内合意の話になります。
- 渡すときは、決められた形に整えてからです。前後の空白を落とし、小文字にそろえ、ハッシュ化してから送ります。
本記事の内容は2026-08-28に、各社の公式ドキュメントと公的機関のページ本文で確認したものです。
011stパーティデータとは何ですか？Web広告の計測でなぜ土台になるんですか？
若葉さんそもそもなんですが、1stパーティデータって「自社が持っているデータ」という理解でいいんでしょうか。
鈴木さんほぼ合っています。もう少し正確に言うと、自社が、自社の接点で、自分の顧客から直接受け取ったデータです。「持っている」よりも「直接受け取った」のほうが要点に近いです。
1stパーティデータ（ファーストパーティデータ）とは、自社のサイト・アプリ・店舗・問い合わせフォーム・受注システムといった、自社が用意した接点で本人から直接受け取ったデータを指します。会員登録のメールアドレス、購入時の電話番号、商談で受け取った会社名と担当者名。こうしたものが該当します。
対になるのが、借りている識別子です。ブラウザが発行するcookie、媒体が発行する広告ID、他社から受け取ったリスト。これらは自社が発行したものではないので、発行元の方針が変われば、そのまま使えなくなります。
ここで押さえておきたいのが、cookieの位置づけです。個人情報保護委員会は、Cookie等の端末識別子について、個人情報に該当しない場合には通常「個人に関する情報」に該当し、個人関連情報に該当することとなると考えられる、という見解を示しています（出典: 個人情報保護委員会）。つまり、識別子は「自社のものでない」だけでなく、「本人に関する情報として扱う」という前提が乗ります。
土台になる理由は、単純です。広告媒体に成果を伝えるとき、媒体側は「誰の成果か」を照合する手がかりを必要とします。ブラウザ側で拾える手がかりが細っていくと、代わりの手がかりを渡せるかどうかで結果が分かれます。その代わりの手がかりを自社が持っているか。それが1stパーティデータの整備という言葉の中身です。
この章のまとめ
1stパーティデータは、自社の接点で本人から直接受け取ったもの。借りている識別子とは、切れたときの立て直し方が違う。
021stパーティデータの整備は、広告運用のどこから効いてくるんですか？
整備した結果がどこに出るのかを、先に見ておきます。出口は大きく3つあります。
1つ目は、コンバージョンの補完です。Google広告の拡張コンバージョンは、メールアドレス、氏名、住所、電話番号などのファーストパーティの顧客データを、SHA256と呼ばれるセキュアな一方向のハッシュ アルゴリズムを使用してハッシュ化し、Googleへ送る仕組みだと説明されています（出典: Google 広告ヘルプ）。
2つ目は、配信対象の指定です。手元の顧客リストを媒体へ渡し、既存顧客を除外したり、類似の層へ広げたりできます。
3つ目は、学習の材料です。自動入札は、届いた成果データをもとに調整します。届く成果が欠けていれば、機械が見ている景色そのものが欠けます。ここは設定の巧拙より前の、材料の話です。
高梨課長3つとも同時に手をつけるのは、正直きついです。優先順位はありますか。
鈴木さん出口のうち、いま広告費がいちばん動いている媒体に効くものから1つだけ選んでください。3つ並行だと、どれも中途半端なまま止まりやすいです。
この章のまとめ
出口は3つ。成果の補完・配信対象の指定・学習の材料。まず1つだけ選んで、そこから逆算する。
03同意はどう取ればいいんですか？1stパーティデータをWeb広告に使うときの線引きは？
ここが実務でいちばん止まる箇所です。技術ではなく、書面と社内合意の問題だからです。
まず法令側から。個人情報保護委員会は、個人関連情報取扱事業者が第三者へ提供する際、第三者がそれを個人データとして取得することが想定される場合には、原則として「当該第三者が個人関連情報の提供を受けて本人が識別される個人データとして取得することを認める旨の当該本人の同意が得られていること」が必要だと説明しています（出典: 個人情報保護委員会）。外国にある第三者への提供では、あらかじめ当該外国の制度などの情報を本人に提供していることの確認も求められます。
次に通知です。総務省は外部送信規律について、ウェブサイト事業者やアプリケーション提供事業者が、利用者に関する情報を外部へ送信させるとき、「通信することと当該ユーザーに関する情報の内容」「その情報の送信先」「その情報の利用目的」を、利用者が容易に知り得る状態に置くことを求めています（出典: 総務省）。
この2つは、性質が違います。前者は「提供してよいか」の話で、後者は「知らせているか」の話です。同意の画面を作っただけでは通知の要件は満たされませんし、通知を書いただけでは提供の根拠になりません。別々にそろえると覚えてください。
この章のまとめ
法令側で要るのは、本人の同意と外部送信の通知。提供してよいかと、知らせているかは別々にそろえる。
04媒体側のポリシーは、1stパーティデータのWeb広告利用に何を求めているんですか？
法令とは別に、渡し先の媒体が置いている条件があります。ここを法令の話と混ぜると、確認が抜けます。
Googleのカスタマーマッチのポリシーは、アップロードできるのは「ファーストパーティの文脈で直接収集した顧客情報」に限られるとしています。例として、広告主のウェブサイトで商品を購入した顧客の情報が挙げられています。加えて、そうした共有をプライバシー ポリシーで開示すること、法律上必要な場合、またはパーソナライズド広告かユーザーの同意に適用されるGoogleのポリシーの少なくとも一方で求められる場合には同意を得ることが求められます（出典: Google 広告ポリシー ヘルプ）。
認められていない使い方も明示されています。13歳未満の顧客の情報のアップロード、13歳未満向けのサイトやアプリから収集した情報のアップロード、デリケートな情報に該当するインタレスト カテゴリの利用、そのカテゴリを特定するためにカスタマー マッチ キャンペーンのデータを使うこと。いずれも許可されていません（出典: Google 広告ポリシー ヘルプ）。
読み取れるのは、媒体側が見ているのは形式ではなく入手経路と使い道だということです。形式どおりに整形できることと、そのデータを送ってよいことは、別々に確認する必要があります。
この章のまとめ
媒体ポリシーが見ているのは入手経路と使い道。形式の要件とは別の欄で確認する。
051stパーティデータの識別子は、広告運用でどれを持てばいいんですか？
同意の整理が済んだら、次は「何を鍵にして照合するか」です。候補は多くありません。
| 識別子 | どこで手に入るか | 照合の性質 |
|---|---|---|
| メールアドレス | 会員登録・購入・問い合わせ | 本人が使い分けると別人扱いになりやすい |
| 電話番号 | 購入・予約・商談 | 表記のゆれが大きく、整形の規則が要る |
| 氏名・住所 | 配送・請求 | 単独では弱く、他の識別子と併用する |
| 自社の会員ID | 自社の会員基盤 | 媒体側では外部IDとして扱う |
| クリックID | 広告クリック時のURL | 期限がある。保存し忘れると復元できない |
MetaのコンバージョンAPIでは、メール（em）、電話番号（ph）、氏名（fn・ln）、生年月日、性別、市区町村、都道府県、郵便番号、国、外部ID（external_id）といった顧客情報パラメータが定義されています。連絡先情報はハッシュ化して送る前提で、外部IDはハッシュ化が推奨と位置づけられています（出典: Meta for Developers）。
高梨課長全部そろえたほうが照合は良くなりますよね。最初から全部やるべきですか。
鈴木さんそこは逆をおすすめします。まず1つに決めて、通し切ってください。項目を増やすほど、正規化の規則も同意文言も増えます。1つ通れば、2つ目は同じ配管に乗るだけです。
この章のまとめ
識別子は最初から全部そろえない。いちばん欠けが少ない1種類を決めて、そこだけを通し切る。
06集めた1stパーティデータは、Web広告へ渡す前にどう整えるんですか？
顧客データは、そのままでは照合されません。媒体ごとに決められた形に整えてから送ります。工程は2つです。
正規化は、書き方をそろえる作業です。Metaの公式ドキュメントは、メールアドレスについて前後の空白を取り除き、すべて小文字にすること、電話番号については記号・英字・先頭のゼロを取り除き、国番号を含めることを求めています。氏名や市区町村は小文字で句読点なし、国は小文字の2文字コードで書きます（出典: Meta for Developers）。顧客リストのカスタムオーディエンスでも、同じ方向の正規化が案内されています（出典: Meta for Developers）。
郵便番号や国の書き方まで指定があるのは、照合が文字列の一致で動いているからです。人間なら同じだと分かる書き方の違いが、そのまま別の値として扱われます。
この章のまとめ
正規化は、人間なら同じだと分かる違いを機械にも同じだと分からせる作業。規則は文書にして共有する。
07ハッシュ化は、1stパーティデータをWeb広告へ渡すときに何をしているんですか？
整形のもう一方の工程です。ハッシュ化は、元の値に戻せない形へ変換する作業を指します。メールアドレスをそのまま送るのではなく、決まった計算で作った文字列を送り、媒体側も同じ計算をして突き合わせます。どちらも生の値を見ずに照合できる、という考え方です。
Metaは「データはSHA256でハッシュ化する必要があり、他のハッシュ方式には対応していない」と明記しています（出典: Meta for Developers）。Google広告の拡張コンバージョンも、SHA256と呼ばれるセキュアな一方向のハッシュ アルゴリズムを使用すると説明されています（出典: Google 広告ヘルプ）。
ここで順番を間違えないでください。正規化してからハッシュ化します。 大文字のまま先にハッシュ化すると、小文字で登録された値とはまったく別の文字列になり、照合されません。同じ人なのに一致しない、という事故のかなりの部分がここで起きます。
もうひとつ、混同を避けておきたい点があります。ハッシュ化は、送るときの取り扱いを整える工程であって、そのデータを取得・提供してよいかという判断とは別です。ここを一緒にすると、「ハッシュ化しているから大丈夫」という説明が社内で通ってしまいます。
この章のまとめ
ハッシュ化は生の値を渡さずに照合するための変換。順番は正規化が先。取り扱いと可否は別の話。
08CRMの顧客データは、1stパーティデータとして広告運用へどうつなぐんですか？
ここまでの整理を、実際の接続に落とします。CRM側に成果があり、広告側にクリックがある。この2つを結ぶのが、オフラインコンバージョンのインポートです。
Google広告は、クリック時に付与されるGoogle クリック ID（GCLID）を自社側で受け取って保存し、成果が確定した段階でGoogleへ戻す形を案内しています。前提として自動タグ設定が有効になっている必要があります。インポートできるのは、クリックからコンバージョンまでの期間が90日または14日（データソースに応じて異なる）未満のものです。新しく作成したコンバージョン アクションについては、4〜6時間ほど待ってからデータをアップロードすることが案内されています（出典: Google 広告ヘルプ）。
この形が成り立つ条件は、ひとつだけです。クリックの時点で受け取った値を、成果が確定するまで自社側で持ち続けていること。 商談が長い商材ほど、この保持期間が問題になります。
この章のまとめ
CRM接続の骨格は、クリック時の値を自社で保持し、成果の確定後に戻すこと。自動タグ設定が前提になる。
09クリックIDを保存していないと、1stパーティデータと広告運用の照合はどうなるんですか？
戻す値がないので、その成果は広告側から見えないままになります。あとから復元する方法もありません。だから、この工程は4つに分けて点検します。
| 工程 | 自社側でやること | つまずきやすい点 |
|---|---|---|
| 受け取る | 広告からの着地ページでクリックIDを取得する | 途中のリダイレクトで落ちる |
| 貯める | フォームやCRMの項目として保存する | 項目を作っていないと保存されない |
| 戻す | 成果の確定後にアップロードする | 期限を過ぎた分は戻せない |
| 確かめる | 管理画面に反映されたかを見る | 反映を待たずに設定を触ってしまう |
いちばん多いのは、2番目でつまずく形です。着地ページのURLには値が付いているのに、フォームにその項目がないので、送信された時点で消えています。ここは開発側に依頼して、隠し項目として持たせる作業になります。
高梨課長クリックIDを保存する項目を、いまからCRMに足すことになりますよね。工数はどれくらい見ればいいですか。
鈴木さん項目を足す作業そのものは軽いことが多いです。重いのは、その項目に値が入っているかを確かめる工程のほうです。フォームの改修と、テスト送信での確認まで含めて見積もってください。
この章のまとめ
CRM接続は、受け取る・貯める・戻す・確かめるの4工程。期限を過ぎた成果は戻せないので、貯める仕組みを先に作る。
10カスタマーマッチは、1stパーティデータの広告運用でどこまで使えるんですか？
顧客リストそのものを配信に使う場合の話です。ここには運用上の条件があります。
Googleのカスタマーマッチは、顧客から提供された連絡先情報でリストを作成する機能で、検索、ショッピングタブ、YouTube、Gmail、ディスプレイで利用できると案内されています。リストの有効期間は最大540日で、過去540日以内に少なくとも100人のユーザーを追加または更新する必要があるとされています（出典: Google 広告ヘルプ）。
Meta側では、顧客リストからのカスタムオーディエンスに、メールアドレス、電話番号、氏名、生年月日、性別、居住地、アプリのユーザーIDなどを使えます。1つのオーディエンスに追加できるレコード数に上限はないとされていますが、一度に送れるのは10,000件までです（出典: Meta for Developers）。
この章のまとめ
顧客リストの活用には、有効期間と更新の条件がある。作って終わりにせず、書き出しを定例作業にする。
11サーバー側から送ると、1stパーティデータのWeb広告計測は何が変わるんですか？
ブラウザからではなく、自社のサーバーから直接送る経路もあります。MetaのコンバージョンAPIがこれにあたります。
送れる値は前述の顧客情報パラメータで、連絡先情報はハッシュ化が前提です。一方で、接続元のIPアドレス（client_ip_address）やユーザーエージェント（client_user_agent）はハッシュ化しない値として扱われ、この2つを併せて送ることが照合の改善に役立つ場合があると案内されています（出典: Meta for Developers）。
サーバー側から送るときに決まって出てくるのが、二重計上の話です。ブラウザ側のピクセルとサーバー側の両方から同じ成果が届くためです。Metaは、ピクセルのeventIDとコンバージョンAPIのevent_idを一致させ、eventとevent_nameも一致させる方法を案内しています。重複排除が働くのは、最初のイベントを受け取ってから48時間以内に届いたものに限られます（出典: Meta for Developers）。
サーバー側から送る仕組みそのものの詳細は、AIMJ-0906 で扱っています。ここでは「1stパーティデータの渡し方の1つ」として位置づけるにとどめます。
この章のまとめ
サーバー側から送る経路では、二重計上を防ぐ鍵を先に決める。重複排除には有効な時間の枠がある。
12同意が取れなかった分は、AI活用が進んだ広告運用でどう扱われるんですか？
同意を取る設計を入れると、当然ながら「同意しなかった人」が出ます。その分をどう扱うかが、次の論点です。
Googleの同意モードは、ユーザーのCookieまたはアプリの識別子の同意ステータスをGoogleへ伝えることで、タグの動作を調整する仕組みだと説明されています。同意ステータスにはad_storageやanalytics_storageといったパラメータがあります。実装には基本と詳細があり、基本ではユーザーが操作するまでタグの読み込み自体がブロックされ、詳細では既定を拒否として読み込んだうえで、同意がない場合にCookieのないpingを送ります。欠落した収集データを補うため、Googleのサービスではこのpingを使って指標がモデリングされると案内されています（出典: Google 広告ヘルプ）。
この章のまとめ
同意しなかった分は、補完という別の性質の数字になる。実測と並べるときは、区別を残したまま扱う。
131stパーティデータの品質は、AI活用の自動入札にどう効くんですか？
配管ができても、流れるものが濁っていれば結果は濁ります。品質の観点は5つあります。
- 欠損 … 必須にしていない項目は、思っているより埋まっていません
- 表記のゆれ … 全角と半角、ハイフンの有無、都道府県の書き方
- 重複 … 同じ人が別のメールアドレスで複数回登録している
- 鮮度 … 退会・解約した人が残ったまま配信対象になっている
- テストデータ … 社内の検証用アカウントが本番のリストに混ざっている
このうち、広告の成果にいちばん直結するのは鮮度です。すでに解約した層へ配信を続けると、費用が出ていくだけでなく、自動入札に「反応しない層」という誤った学習材料を渡すことになります。
この章のまとめ
品質の観点は、欠損・表記ゆれ・重複・鮮度・テストデータの5つ。効きがいちばん大きいのは鮮度。
14照合できた割合は、1stパーティデータと広告運用でどう読めばいいんですか？
若葉さん品質が良いかどうかは、どこを見れば分かるんでしょうか。
鈴木さん一次的には、媒体側で照合できた割合を見ます。ただ、数字そのものより前の月と比べて動いたかどうかのほうが実務では役に立ちます。急に落ちたときは、たいてい書き出しの手順が変わっています。
照合の割合は、業種・商材・会員基盤の性質によって水準が大きく変わります。他社の水準と比べても、自社の何を直せばよいかは出てきません。見るべきは、自社の中での変化です。
読み方は3つに整理できます。1つ目は水準ではなく推移で見ること。2つ目は、下がったときに「データの質」ではなく「書き出しの手順」を先に疑うこと。3つ目は、送った側の数と受け取られた側の数を、同じ表に並べて残すことです。
3つ目が抜けると、あとから振り返れません。送信の記録だけが残っていて、照合の結果が残っていない、という状態が実際によくあります。記録を残すのは、下がった月ではなく、うまくいっている月です。
この章のまとめ
照合の割合は、他社水準ではなく自社の推移で読む。送った数と受け取られた数を、同じ表に残す。
151stパーティデータの整備は、広告運用のどの順番で着手すればいいんですか？
ここまでの内容を、着手の順番に並べ替えます。
- 出口を1つ決める — 成果の補完・配信対象の指定・学習の材料のうち、いま広告費が動いている媒体に効くものを選びます
- 同意と通知を整える — プライバシーポリシーの記載、同意の取得画面、外部送信の通知を、法務と合わせて確認します
- 識別子を1つ決める — いちばん欠けが少ない項目を選び、それだけで通します
- 正規化の規則を書く — 空白・大文字小文字・国番号・国コードの扱いを文書にします
- つなぐ — 選んだ出口に合わせて、書き出しか、クリックIDの保存か、サーバー側からの送信かを実装します
- 突き合わせる — 送った件数と、媒体側で受け取られた件数を並べて確認します
この6つのうち、飛ばされやすいのが6番目です。送った時点で終わったことにすると、照合されていない状態に何か月も気づけません。送信の完了と、照合の成立は別の出来事です。
この章のまとめ
着手は6段階。出口を決める→同意と通知→識別子を1つ→正規化の規則→接続→突き合わせ。最初と最後を飛ばさない。
161stパーティデータの整備で、Web広告の現場がつまずくのはどこですか？
最後に、実際につまずきやすい3つを挙げます。
1つ目は、集めることから始めてしまうつまずきです。渡し先が決まっていないと、必要な項目も、必要な同意文言も決まりません。結果として「とりあえず全部集める」形になり、同意の範囲を超えたデータまで手元に置くことになります。着手の順番を逆にするだけで避けられます。
2つ目は、正規化とハッシュ化の順番を取り違えるつまずきです。前述のとおり、媒体側は正規化された値を前提にした照合を案内しています（出典: Meta for Developers）。先にハッシュ化してしまうと、あとから直す方法がありません。書き出しの処理を作った段階で、テスト用の値で一度確かめてください。
3つ目は、媒体ポリシーを技術要件と混同するつまずきです。カスタマーマッチのポリシーは、データの入手経路そのものに条件を置いています（出典: Google 広告ポリシー ヘルプ）。仕様どおりの形式で送れることと、そのデータを送ってよいことは、別々に確認する必要があります。
この章のまとめ
つまずきは3つとも順番の問題。集める前に渡し先、ハッシュ化の前に正規化、送信の前にポリシー。
171stパーティデータの整備は、広告運用としてどう点検すればいいんですか？
点検は、担当者の記憶ではなく一覧で行います。次のチェックリストは、ここまでの内容を実務に落とし込むための8項目です。上から順に、書面・データ・接続の並びになっています。
- いま整備しようとしているデータの渡し先（出口）を1つに決めた
- プライバシーポリシーに、広告媒体との共有についての記載があるかを確認した
- 外部送信の通知として、情報の内容・送信先・利用目的が示されているかを確認した
- 媒体ポリシー上、アップロードしてよい入手経路のデータかを確認した
- 照合に使う識別子を1つに絞り、その項目の欠けている割合を見た
- 正規化の規則（空白・大文字小文字・国番号・国コード）を文書にした
- 正規化してからハッシュ化する順番になっているかを、テスト値で確かめた
- 送った側の数と、媒体側で受け取られた数を並べて確認する担当を決めた
上の4つは書面と設計、下の4つは実装と運用です。書面側が埋まらないうちに実装へ進むと、あとで止まります。着手の会議では、上半分だけを議題にしても構いません。
この章のまとめ
点検は一覧で行う。上半分の書面が埋まってから、下半分の実装へ進む。
18よくある質問
1stパーティデータとファーストパーティデータは違うものですか
同じものを指す言葉です。表記が分かれているだけで、意味の違いはありません。社内資料ではどちらかに統一しておくと、検索したときに漏れが出にくくなります。本記事では見出しを「1stパーティデータ」に、本文の初出説明を「ファーストパーティデータ」に揃えています。
顧客リストを広告媒体にアップロードするのに、本人の同意は要りますか
まず自社の取得状況を確認してください。個人情報保護委員会は、第三者が個人データとして取得することが想定される場合には、原則として本人の同意が得られていることが必要だとしています（出典: 個人情報保護委員会）。加えてGoogleのカスタマーマッチのポリシーは、共有をプライバシー ポリシーで開示することと、法律上必要な場合などに同意を得ることを求めています（出典: Google 広告ポリシー ヘルプ）。個別の可否は法務にご確認ください。
ハッシュ化すれば、どんなデータでも送ってよいことになりますか
なりません。ハッシュ化は送信時の取り扱いの話で、そのデータを取得・提供してよいかという話とは別です。Googleのカスタマーマッチのポリシーは、13歳未満の顧客の情報や、13歳未満向けのサイト・アプリから収集した情報のアップロードを認めていません（出典: Google 広告ポリシー ヘルプ）。形式の要件と、入手経路の要件を分けて確認してください。
CRMに古いクリックIDが残っていますが、いまからでも送れますか
期限があります。Google広告は、クリックからコンバージョンまでの期間が90日または14日（データソースに応じて異なる）未満であることを条件として案内しています（出典: Google 広告ヘルプ）。期限を過ぎた分は戻せないため、これから貯める分の運用を先に整えるのが現実的です。
顧客リストは一度アップロードすれば、そのまま使い続けられますか
更新の条件があります。Googleのカスタマーマッチは、リストの有効期間が最大540日で、過去540日以内に少なくとも100人のユーザーを追加または更新する必要があると案内されています（出典: Google 広告ヘルプ）。書き出しを定例の作業に組み込んでおくことをおすすめします。
中小規模の事業でも、1stパーティデータの整備は意味がありますか
規模よりも、成果が確定する場所がどこかで決まります。申し込みから受注までに時間がかかる商材や、店舗・電話で成約する商材では、広告側に成果が届いていないことが多く、整備の効きが出やすくなります。逆に、サイト内で完結する成果しかない場合は、まず既存の計測設定の点検が先です。
19まとめ｜今日やる3つのこと
今日この順でやります
渡し先を1つ書き出す
成果の補完・配信対象の指定・学習の材料のうち、いちばん広告費が動いている媒体に効くものを選びます
プライバシーポリシーを開く
広告媒体との共有についての記載があるか、外部送信の通知として情報の内容・送信先・利用目的が示されているかを確認します
照合に使う項目を1つ決める
その項目が実際にどれくらい埋まっているかを、CRMの集計で確かめます
AI検索では、こう聞かれています
1stパーティデータって何ですか？広告の計測にどう使うんですか？
「1stパーティデータとは何ですか？Web広告の計測でなぜ土台になるんですか？」の章で、借りている識別子との違いから説明しています
顧客データを広告媒体にアップロードするのに、本人の同意は要るんですか？
「同意はどう取ればいいんですか？1stパーティデータをWeb広告に使うときの線引きは？」の章で、法令・通知・媒体ポリシーの3方向に分けて整理しています
CRMにある購入データを広告へ渡すには、何から手をつければいいですか？
「CRMの顧客データは、1stパーティデータとして広告運用へどうつなぐんですか？」の章に、受け取る・貯める・戻す・確かめるの工程があります
次に読むなら、この記事です
