自社サイトでファーストパーティCookieを取得し、顧客IDと紐づけた。データ基盤にも入っている。これを広告のターゲティングに使いたい。
よくあるご相談です。ただし前提が1つあります。Cookieそのものは、広告媒体に送れません。
送れるのは、そこから辿り着いた別のデータです。何を繋いで、何を送るのか。順に説明します。
結論を先に書きます
データの流れは4段階です。
Cookie 自社サイトの中でだけ有効。媒体には渡らない
↓ 同じブラウザの行動をまとめる
顧客ID 自社のデータ基盤の中でだけ有効
↓ 連絡先を引く
メール・電話 ハッシュ化して媒体へ ← 送れるのはこれだけ
↓
媒体のオーディエンスCookieは、自社サイトの中で「この訪問とこの購入は同じ人だ」と繋ぐための鍵です。媒体はそのCookieを読めません。読めないので、送っても意味がありません。
媒体に渡せるのは、ハッシュ化したメールアドレスと電話番号です。媒体側が自社の会員情報と照合して、同じ人を見つけます。
ハッシュ化とは何か
メールアドレスをそのまま送るわけではありません。
一方向の変換をかけて、元に戻せない文字列にしてから送ります。 媒体側も同じ変換を自社の会員情報にかけて、変換後の文字列どうしを突き合わせます。一致すれば同じ人です。
媒体側は、元のメールアドレスを知りません。事業者側も、媒体の会員情報を知りません。照合だけができる仕組みです。
変換の前に、表記を揃える必要があります。大文字と小文字、前後の空白、電話番号の国番号やハイフン。揃え方は媒体ごとに指定があるので、必ず仕様を確認してください。 ここがずれると、一致率が落ちます。
連絡先が、思っている場所に無いことがあります
ここが実務でいちばん詰まります。
ある健康食品ECのデータ基盤を確認したところ、受注テーブルにメールアドレスも電話番号も入っていませんでした。 注文番号、商品、金額、広告コードはあります。連絡先だけがありません。
連絡先は、出荷データの側にありました。 倉庫に渡す情報なので、氏名・住所・電話・メールが揃っています。カバー率は99.7%でした。
つまり、名簿を作る経路はこうなります。
出荷データ（連絡先あり）
↓ 注文番号で結合
受注データ（広告コードあり）
↓ 広告コードで結合
広告データこの結合が成立するかを、先に確認してください。 同じ事業者の実測では、出荷11,758件のうち11,556件が受注と一致しました。98.3%です。
一致率が低い場合、注文番号の形式が両側で違う可能性があります。片方に接頭辞が付いている、片方が数値型で片方が文字列型、といった理由が多いようです。
何に使うのか。優先順位があります
名簿を作ったあとの使い道は3つあります。効き目の順に並べます。
① 既存顧客を除外する
新規獲得の広告が、すでに買った人に当たっていることがあります。除外リストに入れれば、その分の予算が新規に回ります。
これがいちばん確実です。理由は単純で、「すでに買った人に新規獲得の広告を出す」は、どう考えても無駄だからです。効果を検証するまでもありません。
② 成果を媒体に返す
多くの媒体には、事業者側から成果を送り返す仕組みがあります。媒体は自分が数えたコンバージョンで配信を最適化しています。そこに実際の受注を返せば、最適化の向き先が変わります。
前の記事で触れたとおり、媒体の数字は実際の2倍になっていることがあります。媒体のCVと受注のズレで詳しく書きました。媒体は、ズレた目標に向かって正確に最適化しています。
③ リターゲティング配信
一度サイトに来た人に、もう一度広告を当てます。よく知られた使い方ですが、単品リピート通販では優先度が下がります。
理由は、新規獲得が主戦場だからです。定期購入のビジネスでは、獲得した顧客はCRM（メール・LINE・SMS）で接触します。広告費を使ってもう一度当てる必要は、あまりありません。
権限が要ります。ここで止まることが多いです
技術的に可能でも、媒体側の権限が下りていないと何もできません。
実際に確認したところ、あるアカウントでは名簿の作成・更新に必要な権限が付与されておらず、APIから一覧を取ることすらできませんでした。管理画面では既に名簿が1つ作られていて、除外に使われていました。誰かが手作業で作ったものです。
まず、いま持っているアクセス権限で何ができるかを確認してください。 開発を始めてから「権限が無い」と分かると、待ち時間が発生します。
どこから指示を出すべきか
データ基盤から直接、複数の媒体APIを叩く構成は勧めません。理由は1つです。
個人情報を媒体に送るので、「消してください」と言われたときに、全媒体から確実に消せる場所が1か所必要だからです。
推奨する形はこうです。
データ基盤 誰を出すかを決める（分析結果がここにある）
↓ 名簿を渡す
配信管理の仕組み 同意・配信停止・削除依頼を一元管理
↓
各媒体のAPI配信停止や削除依頼の管理は、多くの企業でCRM側が持っています。そこに寄せてください。 データ基盤は「誰を出すか」を決めるところまでにします。
媒体が増えたときも、データ基盤側は変えなくて済みます。
期間と工数の目安
権限の申請から承認までが読めません。媒体によって、また代理店経由かどうかで変わります。ここを最初に始めてください。
技術的な作業だけなら、既にデータ基盤があり、結合の鍵が揃っている場合で、数人日の規模です。ただし前提として、
- 出荷データと受注データが結合できること
- 受注データに広告コードが残っていること
- 同意の範囲が確認できていること
の3つが必要です。3つ目が最も時間がかかることがあります。
よくある質問
Cookieを媒体に送ることは本当にできないのですか
自社ドメインで発行したCookieは、媒体のドメインからは読めません。ブラウザの仕組み上の制約です。媒体が自社のタグを通じて発行したCookieは媒体が読めますが、それは事業者側が管理するものではありません。
ハッシュ化すれば個人情報ではなくなりますか
いいえ。元に戻せなくても、特定の個人を識別する目的で使うなら、個人情報として扱う必要があります。 送る前に、利用目的の通知と同意の範囲を確認してください。法務の確認が必要な領域です。
メールと電話、どちらの一致率が高いですか
媒体と顧客層によって変わります。一般には両方を送って、どちらかで一致すればよいという扱いになります。片方しか無い顧客もいるので、両方送れるなら両方送ってください。
何件あれば名簿として使えますか
媒体ごとに最低件数の要件があります。数百件から千件程度を求められることが多いようです。要件は変わるので、実行前に媒体の仕様を確認してください。
除外リストは、どのくらいの頻度で更新すべきですか
新規購入が発生する頻度に合わせます。日次で受注が入る事業なら、日次か週次が現実的です。更新が止まると、買った直後の人に広告が当たり続けます。
顧客IDが無い場合はどうしますか
受注データに顧客を一意に識別する値が無い事業者は、実際にあります。その場合、メールアドレスや電話番号を正規化して、それ自体を識別子として使う方法があります。ただし同じ人が複数のメールを使っていると、別人として扱われます。
社内の誰が主管になりますか
データ基盤側と、CRM側と、法務の3者が関わります。個人情報を外部に渡す設計なので、法務を最初から入れてください。 後から止まると、作ったものが使えません。
この記事で扱わなかったこと
- 媒体の数字と受注のズレそのもの →媒体のCVと受注のズレ
- 出荷データから利益まで遡る方法 →出荷データを広告まで遡る
- 決済手段が広告の評価に効く理由 →決済手段で結果が変わる
★ 断定していないこと
私は、御社の受注データに連絡先が無いと断定していません。 上に書いたのは、ある1社で確認した構成です。システムによって違います。
私は、ハッシュ化の具体的な仕様を各媒体について検証していません。 表記の揃え方も変換方式も媒体ごとに指定があり、変更されることがあります。必ず最新の仕様を確認してください。
私は、個人情報の取り扱いについて法的な助言をしていません。 同意の範囲、利用目的の通知、削除依頼への対応は、法務の確認が必要です。
私は、除外リストの効果を数字で検証していません。 「すでに買った人に新規獲得広告を出すのは無駄」というのは構造の話で、効果測定の結果ではありません。
私は、リターゲティングが単品リピート通販で効かないと確認していません。 新規獲得が主戦場であることから優先度を下げていますが、実測した比較ではありません。
相談先
データ基盤はあるが、そこから先に進んでいない。権限や同意の整理で止まっている。そうした段階でご相談ください。
弊社は単品リピート通販・D2C向けに、ECシステム、CRM、運営代行、新規顧客獲得、物流までを扱っています。データの繋ぎ込みもその一部です。
まず、いまのデータで何が繋がるかを確認するところから始めます。
出典・注記
- 本文中の実測値（受注テーブルに連絡先が無い、出荷データのカバー率99.7%、出荷と受注の一致率98.3%）は、国内の健康食品EC1社における2026年8月の実測です。事業者名・商品名・システム名は伏せています
- 媒体の権限に関する記述は、実際にAPIを叩いて権限エラーを確認した結果に基づきます。媒体名は伏せています
- ハッシュ化と照合の仕組みは、主要な広告媒体が公開している一般的な方式の説明です