lookalike-audience-seeds

類似オーディエンス用のシード

類似オーディエンス、類似ユーザーオーディエンス、または価値ベースのオーディエンスの作成元となるシード顧客リストを選定し、規模を調整して検証します。以下の各ステップでは、次の3つの原則に従います。

• 行数ではなくマッチ数 - アップロードしたリストはすべて、プラットフォームの最小要件に達する前にマッチ率に応じて縮小します。5,000行でマッチ率が40％なら、シードは2,000人です。プラットフォームの最低数要件はマッチ後の数に適用されるため、目標の2～3倍をアップロードしてください。
• 規模より同質性と価値の集中度 - Meta のガイダンスによると、シードの同質性は規模よりもオーディエンスの有効性に大きく影響します。実務者の共通認識（Stackmatix、Grow With Sakib による方向性を示すもので、監査済みではありません）では、一律な登録者を数千人集めるより、価値の高い顧客を数百人集めるほうが効果的です。
• 包含は提案、除外はルール - Meta（Advantage+）と Google（Demand Gen では、類似オーディエンスのリーチ階層が厳格なセグメントではなくシグナルとして機能するようになっています）では、配信アルゴリズムが包含オーディエンスを上書きする場合があります。厳格なルールとして維持されるのは、除外／配信抑制オーディエンスのみです。

シードの役割は、オーディエンスを囲い込むことではなく、最もクリーンなシグナルをアルゴリズムに与えることです。つまり、品質基準を下げるのではなく、むしろ引き上げることになります。

このスキルは、指定済みで検証済みのシード定義と、そのエクスポート／引き継ぎ仕様をまとめた時点で終了します。広告プラットフォームのインターフェース内でオーディエンスを作成またはアップロードする手順は扱いません。

関連する課題の担当箇所：

• 全体的なターゲティング計画（インタレスト、行動、類似オーディエンス、リターゲティングの階層化） - シードの仕組みはこちらで扱い、階層構造は mbfinotti/advertising-skills@ad-audience-targeting で扱います。
• リターゲティングのシーケンス設計、ファネル段階ごとのオーディエンス期間、フリークエンシーキャップ - mbfinotti/advertising-skills@retargeting-funnel。
• B2B の購買委員会とペルソナのマッピング - mbfinotti/advertising-skills@ad-buyer-group-mapper。
• アカウント全体のパフォーマンス低迷の根本原因の特定 - mbfinotti/advertising-skills@ad-account-diagnostic。
• エンゲージメントベースのシードソースにデータを送る Pixel/CAPI の計測設定 - mbfinotti/advertising-skills@ad-conversion-tracking。
• アトリビューションソース間でシードのパフォーマンス評価が食い違う場合の調整 - mbfinotti/advertising-skills@ad-attribution-gap。

インタビュー

何かを選ぶ前に質問してください。1回のメッセージにつき質問は1つにし、可能な場合は選択肢を提示してください。すでに回答済み、または提供されたデータから確認できる項目は省略してください。

• B2B、B2C／Eコマース、それとも両方ですか？
• シードを利用するプラットフォームはどれですか？（Meta／Google／LinkedIn／TikTok／その他。最低件数やマッチの仕組みはプラットフォームによって異なります）
• 顧客データはどこに、どのような形でありますか？（CRM／データウェアハウス／メールプラットフォーム／ピクセルとプラットフォームのイベントデータのみ／ほとんどない）
• 顧客の総数はおよそどれくらいで、各行にどの識別子がありますか？（メールアドレス／電話番号／氏名／郵便住所／モバイル広告ID。1行あたりの識別子の種類が多いほど、マッチ率が上がります）
• 利用可能な価値列はありますか？また、実際には何を測っていますか。累積顧客生涯売上、利益率、予測LTV、あるいは注文数だけですか？列の有無よりも、そのデータの由来が重要です。
• データはどれくらい新しいですか？リストのうち、過去90日間および180日間に購入またはコンバージョンした人の割合はどれくらいですか？
• リストにはEEA／英国の居住者、または米国の州ごとのプライバシー法の適用対象となる消費者が含まれていますか？広告プラットフォームへのアップロードについて、同意または適法な根拠が文書化されていますか？また、エクスポート前にオプトアウト、削除、連絡拒否の記録が適用されますか？
• リストをプラットフォームに取り込む方法は何ですか？手動のCSVですか、それともデータウェアハウス／CDPとの自動同期ですか？更新の担当者は誰ですか？
• 類似オーディエンスで目指す獲得成果は何ですか？新規顧客の目標CPA／CACと、獲得顧客のLTVまたは利益率の期待値を教えてください。
• アカウントにおける現在の平均値は、同じ2つの指標でいくらですか？獲得顧客のCPAと、獲得顧客コホートの90日時点のLTVです。合格基準では、このベースラインを基準にシードを評価します。そのため、ベースラインが不明だとシードをまったく評価できません。そうであることを明示し、最初のコホートのチェックポイントをベースライン作成の実施としてください。
• オーディエンスを稼働させ、広告配信を開始する必要がある期限はいつですか？その期限は絶対ですか？（シードソースによって、所要時間は数分から1週間の調整まで異なり、エンリッチメントの段階では調達手続きが必要です。このため、ステップ3と6の順序は、これが分からないと決められません）
• 最短で公開できるオーディエンスを希望しますか。それとも、自動化されたデータウェアハウス同期、エンリッチメントされた識別子、再利用可能なコホート定義など、今後のあらゆるオーディエンスで効果が積み重なる資産を希望しますか？
• 作業量の上限はどれくらいですか？データチームの作業に何時間を割けますか？その後の更新担当者は誰ですか？プライバシー審査の承認とベンダーとのDPAを実際に取得できますか？（「いいえ」の場合、順序を後ろ倒しにするのではなく、その段階を削除します）

ワークフロー

このスキルの各ランキング（ここでのステップ3、6、9、およびリファレンス内のランキング）は、既定の順序であって、絶対的なルールではありません。いずれも一般的なケース、つまり、契約済みのエンリッチメントベンダーがなく、社内にアイデンティティグラフがなく、今週対応できるアナリストもいない場合を想定しています。実行担当者は、何を実行するかと同じくらい、順序を左右します。

まず、インタビューで確認した期限、継続性、作業量の上限に照らして順序を見直し、どの回答によってどの段階が移動したのかを明示してください。

• 期限が差し迫っていて変更できない場合は、プラットフォーム標準のエンゲージメントシードを優先します。
• 効果が積み重なる資産を求める場合は、セットアップが必要でも、データウェアハウスとの同期とエンリッチメントの段階を優先します。
• プライバシー審査の承認を得る手段がない場合は、リストを使う段階をすべて削除します。

次に、ユーザーが実際に保有しているものを踏まえて、順序を見直してください。以下のいずれかがあれば、該当する段階の作業量はほぼゼロになり、優先順位が上がります。

• エンリッチメントに関する締結済みのDPA。
• データウェアハウスですでに構築済みのアイデンティティ解決機能。
• 今日すぐにコホートSQLを書けるアナリスト。
• いずれにせよエクスポートジョブを担当するデータチーム。

1. インタビューを実施し、単一の行を選択する前にすべての回答を収集します。

2. プライバシーと同意のゲートを実施します。これは選択作業の前に設ける必須の停止条件です。以下の項目のいずれかが未確認の場合は停止し、何が不足しているかを正確に伝えてください。このスキルは法的助言ではありません。適法な根拠は管轄区域によって異なるため、未解決の質問はユーザーの法律顧問に回してください。

   • このリストを広告プラットフォームにアップロードするための、文書化された適法な根拠または同意。GDPR のもとでは、ミュンヘン上級行政裁判所が支持したバイエルン州データ保護機関（2018年、Ref. 5 CS 18.1157）の見解により、顧客リストのカスタムオーディエンスには事前の同意が必要であり、ハッシュ化しても変わりません。SHA-256 の出力は仮名化されたものであり、匿名化されたものではないため、同意義務は引き続き適用されます。
   • Google Customer Match を EEA で使用する場合、Consent Mode v2 で渡される同意シグナルにおいて、両方の ConsentStatus フィールドが GRANTED であること（2024年3月から必須）。
   • CCPA/CPRA の「共有」に関するオプトアウトと Global Privacy Control シグナル（米国の12州で尊重されます）が、エクスポート前に反映されていること。
   • 機微なカテゴリー（健康、性的指向、宗教、人種、政治的所属、犯罪歴）をもとにシードを作成していないこと。
   • 対象の広告アカウントに対するプラットフォームの顧客リスト規約に同意済みであること（Meta では、バリューベースオーディエンスには別途規約への同意が必要です）。
   • 抑制対象、オプトアウト、削除が、一度だけ、同期前にウェアハウスで適用されていること。プラットフォームごとに後から適用するのではありません。

3. シードのソースを選びます。まず必ず購入データを使います。購入データが少なすぎる場合は、収集済みの代替案8つから選びます。ただし、価値の順位だけで選ぶことは避けてください。作業量とコンプライアンスコストはどちらも価値の順位と逆順になるからです。4つの軸は一致しないため、すべて確認してください。

   • 価値：purchasers > checkout/add-to-cart initiators > high-intent page viewers > lead-form submitters > email clickers > video viewers > page engagers > all visitors
   • 作業量：video viewers == page engagers == all visitors > high-intent page viewers == lead-form submitters > checkout initiators > email clickers > purchasers - プラットフォーム標準のエンゲージメントオーディエンスは、広告アカウント内で、ピクセルがすでに発火しているルールを使って数分で作成でき、顧客リストのアップロードとステップ2の同意ゲートを完全に省略できます。購入者または CRM のシードには、ウェアハウスからのエクスポート、ID 照合の結合、ゲート全体への対応が必要です。どちらの同順位も実際に同等です。最初の3つは、すでに発火しているイベントに対する包括的な単一ルールであり、次の2つは、同じ単一ルールの対象を特定の URL 群または特定のフォームにするだけです。どちらも同じ担当者が数分で設定できます。
   • コンプライアンスコスト：purchasers == checkout initiators == email clickers > lead-form submitters > high-intent page viewers == video viewers == page engagers == all visitors - 顧客リストとしてプラットフォームに渡すものはすべて、ステップ2のゲート（適法な根拠、EEA での Consent Mode v2、オプトアウトの反映、バリューベースオーディエンスに対する別途の規約への同意）を通過します。一方、プラットフォーム標準のエンゲージメントオーディエンスは広告アカウントから外に出ないため、そのどれも必要ありません。どちらの同順位も概算ではなく、厳密な同等です。リストベースの3つのソースは項目ごとに同一のゲートを適用し、標準機能による4つのソースはそのどれも適用しません。このゲートに部分的な適用方法はないため、この軸で両者を区別することはできません。この軸だけで選択を決めることもできます。アップロードへの同意が未確認の場合、リストベースの順位に属するものはすべて利用できず、単にコストが高くなるわけではありません。
   • 効率：purchasers > high-intent page viewers > lead-form submitters > checkout initiators > email clickers > video viewers (75%+) > page engagers > all visitors。顧客データのエクスポートがすでに存在する一般的なケースでは、購入者が最上位です。価値の差が大きい一方、必要なのはクエリ1つだけです。エクスポートが存在しない場合は、インテントの高いページの閲覧者とリードフォーム送信者が、リストの中で最も優れた比率です。設定はほぼゼロで、アップロードも新たな露出もなく、それでも価値は上位半分に入ります。この2つは同順位ではなく、順番があります。設定はどちらも同じ単一ルールなので、価値の軸で順位が決まります。ただし、B2B のリード獲得では、フォーム送信自体がコンバージョンであるため、送信者が上位になります。それより下に選択を引き下げる理由として、作業量を決して使わないでください。その点を過ぎると、行ごとの品質は作業量よりも急速に低下します。ソースごとの内訳と、この順序を変える条件については、references/seed-selection.md を参照してください。 この効率性の順序によって後回しにされるのは、顧客IDという資産そのものです。つまり、購入者またはCRMのシードと、それを利用可能にするIDエンリッチメントです（フォールバックの第1段階）。価値軸では最上位にあり、工数とコンプライアンスコストの両方では最下位にあるため、エクスポートがまだ存在しない場合は、数分で設定できるピクセルルールに毎回負けます。そして、次に依頼したときもアカウントにはエクスポートがありません。

   次の場合は、比率にかかわらず優先してください。

   • インタビューで「早期の稼働」ではなく「複利的に価値が増す資産」と回答された場合。
   • シードがB2Bで、エンリッチメントなしではネイティブのマッチ率が最低基準に届かない場合。
   • 同じアカウントが今回も含めて2回、選定から外れた場合。

   プライバシー審査の承認経路がない場合、またはベンダーのDPAを利用できない場合は、選択肢から名前ごと削除してください。適法な根拠のないリストベースのソースは、単に時間がかかる選択肢ではなく、選択肢ではありません。最下位に残しておくと、オーディエンスの配信開始後にスコープとして再浮上します。

   クリックしたメールユーザーを使い、開封したユーザーは使わないでください。Apple Mail Privacy Protection（2021）によって、開封数はノイズだらけになりました。B2Bでは、すべてのMQLのエクスポートではなく、受注済みのCRM案件からシードを作成してください。SQLのみのほうが、すべてのMQLより優れています。

4. 行を選択します。references/seed-selection.md に、コホートの定義、期間のガイダンス、除外リストの詳細があります。

   • デフォルトの選択：RFMの優良顧客＋ロイヤル顧客のコホート、または予測LTVや利益率の上位10-25％。累計生涯売上を基準にするのは避けてください。これは顧客期間を示すもので、価値を示すものではありません。
   • 直近期間：まずは30-90日とし、ピクセル/CAPIで追跡されている購入者の場合は最大180日までとします。12-18か月を超えた連絡先データでは、マッチ率とパフォーマンスの両方が大幅に低下します。
   • 除外対象の確認（多くのチームが忘れがちです）：返金を受けた顧客、チャージバックを起こした顧客、返品を繰り返す顧客、割引のみを利用する顧客、従業員、卸売アカウントを除外します。既存顧客はシードに残しますが、配信段階で獲得キャンペーンから除外します。

5. 有効なシード数を計算します：effective seed = uploaded rows x expected match rate。references/platform-floors.md に記載されたプラットフォームの公表範囲を基に、リストの識別子の密度とデータの古さに応じて予想マッチ率を調整します。例：

   • Google Customer Match：ほとんどの広告主で29-62％（Googleの公式ドキュメントによる）。
   • Meta：質の高いリストでは50-80％。
   • LinkedIn：仕事用メールアドレスの連絡先リストでは約30-40％。
   • Reddit：ネイティブCSVでは約2％。

   結果をプラットフォームのマッチ件数の最低基準と比較し、目標の2-3倍の規模でアップロードします。ハーネスが顧客エクスポートを読み取れる場合は、件数を直接計算します。それ以外の場合は、ユーザーのデータチームが実行する正確なフィルター定義（ソーステーブル、フィルター条件、直近期間の境界、価値のしきい値）を出力し、先に進む前に件数が届くのを待ちます。

6. 実効シードが最低ラインをクリアできない場合は、選定品質を最初に緩めるのではなく、フォールバックの段階を順に進めます。段階番号は仕様ブロックや具体例で使われる固定 ID です。各段階には、それぞれ価値、労力、コンプライアンスコストがあります：

   • 段階 1、識別子を拡充する - ID 解決によって個人のメールアドレスや電話番号を追加します。価値：モデルが学習する内容を変えずにマッチした人物を増やせる唯一の段階であり、B2B の仕事用メールアドレスのリストを消費者向けプラットフォームに照合する場合、ネイティブマッチ率が約 5％でも最低ラインに届く唯一の段階です。労力：段階の番号付けからは見えにくい難所です。ベンダーの選定、セキュリティ審査、予算承認、その後のマッチテストが必要で、1 件の行が追加されるまでに 1 週間以上の調整が必要になります。コンプライアンス：処理者が新たに加わります。DPA、法務担当者の承認、アップロードだけでなく拡充も対象とする適法根拠の再確認が必要です。契約後に取り消すのが最も難しい段階です。

   • 段階 2、鮮度の期間を 1 段階広げる（90 日から 180 日、180 日から 365 日）。価値：中程度ですが、その代わりにシグナルの鮮度が低下します。労力：ほぼゼロです。クエリを編集するだけで数分で済み、完全に元に戻せます。コンプライアンス：新たな要件はありません。

   • 段階 3、同じ同質性を持つ隣接セグメントを追加する - チャンピオンにロイヤルを加える、または行動が本当に似ている場合に別の製品ラインの購入者を加えます。価値：中程度で、リスクにさらされるのは同質性です。労力：約 1 時間です。実際の作業となる判断も必要です。コンプライアンス：新たな要件はありません。

   • 段階 4、ステップ 3 のランキングで次に来る、購入以外のシードソースに切り替える。 価値：最も低く、モデルが学習する内容を変える唯一の段階です。労力：イベントソースがすでに計測されていれば約 1 時間です。コンプライアンス：より高くなるのではなく、低くなります。プラットフォームネイティブのソースなら、アップロードも同意のゲートも必要ありません。 デフォルトの効率順：rung 1 > rung 2 > rung 3 > rung 4。最低ラインをクリアした最初の段階で止め、仕様に記録します。

     例外として順序を入れ替えるケースが 1 つあります。rung 2 > rung 1 となるのは、拡充ベンダーと未契約で、かつ鮮度の期間を広げる余地がある場合です。調達に着手する前に午後の作業だけで問題が解決する可能性があり、解決しなければ段階 1 を引き続き利用できます。この入れ替えは、安価な段階に構造的な余地がない標準的な B2B ケースには当てはまりません。全期間の成約済みリストには鮮度の余地がなく、失注案件以外に追加できる隣接セグメントもなく、ネイティブマッチ率も低すぎるため、段階 2〜4 ではどの最低ラインにも届きません。

     段階 1 は、順位を下げるのではなく削除すべき段階でもあります。調達ルートがない、DPA がない、またはベンダー予算の責任者がいない場合は、段階 1 をラダーから完全に外します。削除したことを明記し、段階 2〜4 を実行します。誰も実行できない段階を効率順の最上位に残しておくと、仕様がそれを前提としてしまいます。

     標準的な B2B ケースでは、これによりラダーがまったく残らないことがあります。その場合は、より条件の緩いシードで埋めるのではなく、それを調査結果として報告します。

7. シードが価値ベースの場合：

   • 粗利益または予測 LTV を使用します。
   • 正の値のみを使用します。
   • 値がすべて同一にならないようにします。
   • リスト内の通貨は 1 種類に統一します。
   • 一部の大口アカウントがモデルを歪めないよう、極端に大きい外れ値を上限処理するか、ウィンザー化します。
   • アップロード時に値の列がマッピングされていることを確認します。値の列がマッピングされていないと、プラットフォームは値ベースではなく、標準の類似オーディエンスをひそかに作成します。オーディエンスの作成時に値ベースのオプションが表示されない場合、その列はマッピングされていません。

8. 識別子の準備方法を指定します：

   • 1 行につき複数の識別子を用意するほうが、メールアドレスだけの場合より効果的です。
   • 電話番号は国番号を含む E.164 形式の数字で記載し、プラス記号や先頭のゼロは付けません。
   • メールアドレスは小文字に変換し、前後の空白を削除します。
   • UI アップロード用のファイルを事前にハッシュ化してはいけません。プラットフォームは取り込み時にハッシュ化するため、ソルト付きのハッシュや二重ハッシュはマッチしません。

   Meta では、実務上のベンチマークとして Event Match Quality スコア 6.0 以上を目標にします。

9. 分割、更新、重複を決定します。 分割。 country > product line > high-AOV vs. all の順に分割し、指名された更新担当者の対応能力が尽きた時点で止めます。分割ごとの作業量は同じ（WHERE句が1つ）ですが、そのたびに、更新し、重複を監視し、常に最低件数を上回る状態に保つ必要があるオーディエンスが1つ、恒久的に追加されます。

   国は選択肢ではありません。Metaの類似オーディエンスは仕様上、国ごとに分かれているため、複数の国をカバーするには、国ごとにシードと類似オーディエンスのペアが1組ずつ必要です。分割を確定する前に、各分割の実効シード件数が最低件数を満たしているか確認してください。

   更新。 指名した担当者とともに、更新頻度を決めます。静的なCSVアップロード（LinkedInのリスト、手動で作成するMetaの顧客リスト）は自動更新されないため、週次から月次での更新を予定するか、自動化されたデータウェアハウス同期に移行してください。

   この2つを比較すると、automated sync > manual CSV は作業量では劣りますが、効率とコンプライアンスコストでは優れています。エンジニアリング作業を1〜2日、一度だけ行い、その大半を同期とオプトアウト反映のテストに充てれば、データ減衰による障害要因を完全になくし、オプトアウトと削除を継続的に反映できます。CSVは開始時の作業がほぼゼロですが、毎回、前回のオプトアウトを再アップロードする作業が恒久的に発生します。

   CSVを推奨するのは、同期が実現する日付を定めたうえで、指名された担当者がいる場合のつなぎとしてのみです。Google Customer Matchでは、540日以内に更新されなかったメンバーは削除されます。

   重複。 このシードのオーディエンスと既存のオーディエンスとの重複を確認してください。実務上の懸念の目安はおよそ20～30％です。それを超える場合は、統合するか除外してください。

10. Seed Specificationブロック（以下の形式。B2C版とB2B版の記入例はreferences/examples.md）を記入し、シードのティア配置をmbfinotti/advertising-skills@ad-audience-targetingに渡します。

11. 測定計画と、コホート期間を1つ経過した後の再確認日を添付します。ハーネスに永続メモリがある場合は、次回の実行時に一から再導出するのではなく履歴と比較できるよう、シードのバージョン、定義、件数、再確認日を記憶させてください。

Seed Specification

シードごとに1つのブロックを提出します。

SEED SPECIFICATION - <seed name/version>, <date>
platform        : <destination platform(s)> | audience type: <lookalike | similar | value-based | predictive>
definition      : <source records> filtered by <selection rule> within <recency window>
value column    : <none | column, what it measures, currency> | mapping confirmed: <yes | at upload>
row count       : <n rows> | identifiers/row: <email, phone, ...>
expected match  : <x%> (basis: <platform range + list quality adjustment>)
effective seed  : <rows x match = n matched> vs floor <platform floor> -> <clears | fails>
fallback used   : <none | ladder rung + what changed>
exclusions      : <negative-selection list applied; suppression audiences delivered separately>
consent basis   : <basis + suppression enforced in warehouse date | BLOCKED - missing item>
refresh         : <cadence + owner + mechanism (manual CSV | automated sync)>
measurement     : <new-customer CPA target, cohort LTV checkpoints by seed version>
re-check        : <date - first cohort checkpoint>

エビデンスゲート

以下のいずれかに基づくSeed Specificationの出力を拒否し、代わりに何が不足しているかを述べてください。

• マッチ率の根拠が不明 - 参照したプラットフォームの範囲も、比較基準となる過去のアップロードもありません。見積もりは、文書化された範囲に加え、リストの経過期間と識別子の密度に基づくものに限り、見積もりであることを明記してください。
• 同意の根拠が未確認 - プライバシーゲート（ワークフローのステップ2）を通過していません。選定の質がどれほど高くても、ユーザーにアップロードの法的根拠がない場合、そのアップロードは正当化されません。
• 出所不明の価値列 - 「LTVフィールドがある」ことは根拠になりません。収益、利益、モデルの出力のいずれなのか説明できる人がいなければ、確認が取れるまで、そのシードは価値ベースとはいえません。

顧客リスト、セグメント定義、またはユーザーのデータで裏付けられない閾値を決してでっち上げないでください。一般的なリストで代用するのではなく、不足しているエビデンスを求めてください。

シード診断ラダー

既存の類似オーディエンスのパフォーマンスが期待を下回り、シードに原因があると思われる場合は、次の表を順位付けされたメニューではなく、症状を調べるための一覧として使ってください。各症状には原因が1つ、対処法が1つあるため、互いに順位を付けるのは不正確です。

複数の症状が同時に発生した場合に、どれから修正するかには順序が必要です。まず、オーディエンスの配信やマッチングを妨げる問題を、品質に関する問題より先に修正してください。下限値を下回っている、マッピングが壊れている、またはマッチ率がプラットフォームの範囲を下回っている場合、それ以降の品質評価はすべて意味をなしません。次に、重複と更新頻度の問題を修正し、その後に価値や拡張に関する原因に対処してください。

症状	考えられる原因	対処法
マッチ率がプラットフォームの公開範囲を大きく下回っている	リストが古い、1行につき識別子が1つしかない、または形式が正規化されていない	形式を正規化し（E.164、メールアドレスは小文字）、識別子の列を追加し、18か月を超える行を削除してからデータを補完します
リストはアップロードされたが、オーディエンスを構築または配信できない	マッチした件数が下限を下回っている — 行数をシードサイズと誤認している	実効シード数を再計算し、フォールバックラダーを実行します
オーディエンス構築時に価値ベースのオプションが表示されない	アップロード時に価値の列がマッピングされていない	マッピングを確認して再アップロードします。プラットフォームでは標準の類似オーディエンスが暗黙に構築されていました
CPAは問題ないが、獲得した顧客の90日コホートLTVが低い	利益率の低いコンバージョンユーザーをシードにしている（公開されているChurneyの落とし穴）	利益率または予測LTVを基にシードを作り直し、そのシードのバージョンを廃止します
類似オーディエンスのパフォーマンスがランダムに近い／ブロード配信を上回らない	拡張率が広すぎる、または異なる購入者を含む不均質なシードが混在している	拡張率を絞り込み、製品ライン、セグメント、または国ごとにシードを分割します
計画にGoogle Similar AudiencesまたはLinkedIn Lookalikesが記載されている	古い運用手順書 — Similar Audiencesは2023年8月に廃止、LinkedIn Lookalikesは2024年2月に提供終了	Customer Matchをシグナルとして、またはLinkedIn Predictive Audiences（マッチ数300件以上）を使って再構築します
シードを使った2つのオーディエンスが互いの成果を奪い合っている	オーディエンスの重複が懸念される約20～30％の範囲を超えている	シードを統合するか、相互除外を追加します
変更を加えていないのに、数週間かけてパフォーマンスが低下している	静的なCSVが更新されていないため、メンバーが古くなっている	更新頻度と担当者を決め、同期を自動化し、540日のCustomer Match上限を守ります

プラットフォームの最低件数

最低件数はマッチした件数に適用されます。推奨サイズ、拡張段階、文書化された内部矛盾、非推奨事項、マッチ率と更新の動作を含む全表は、references/platform-floors.md を参照してください。プラットフォームの最低件数は時間とともに変わります。利用しているハーネスがウェブを閲覧できる場合は、仕様を確定する前にプラットフォームの最新の公式ドキュメントを確認してください。そうでない場合は、ユーザーに確認を促してください。

プラットフォーム	マッチ件数の最低値	推奨シード
Meta	100	1,000-5,000（Meta のドキュメント）
Google Customer Match	100（2025 年に 1,000 から引き下げ）	1,000 以上（実務者の推奨）
Google Demand Gen lookalike	マッチ済みの有効ユーザー 1,000 人（API ドキュメント。ヘルプセンターは 100 と記載。より厳しい値を採用）	-
LinkedIn（Matched/Predictive）	マッチ済み 300 人	連絡先リスト：10,000 行以上をアップロード。企業リスト：1,000 社以上
TikTok	1,000（ヘルプセンター。FAQ は 100 と記載。より厳しい値を採用）	10,000（実務者の推奨）
Pinterest	100	1,000 以上（実務者の推奨）
Reddit	マッチ済み 1,000 人	-
X	マッチ済み 100 人	-
Amazon AMC lookalike	ユーザー ID 500 件	10,000 以上（実務者の推奨）
Snapchat	配信に 1,000 人	-

B2B と B2C

**両者で同じもの：**ハッシュ化と正規化の仕組み（SHA-256、E.164、メールアドレスの小文字化）、マッチ率の計算、実効シードの算出、ネガティブ選定、ウェアハウス優先の抑制、測定期間です。これらは同じ広告システム上で動作します。異なるのはリストのサイズと ID です。

B2Bでは、小規模リストの問題が生じます。高 ACV 顧客が 400 人いても、コンシューマー向けプラットフォームの類似オーディエンスには、そのままでは利用できません。仕事用メールアドレスは Meta や TikTok でマッチしにくく、個人用メールアドレスは LinkedIn でマッチしにくいためです。アップロード前の ID エンリッチメントが、文書化されている回避策であり、フォールバックの第 1 段階とする理由です。

B2B のシードは、アカウント単位または連絡先単位です。アップロード前に、役職、職位、職能を使って企業リストを連絡先に展開してください。LinkedIn では、企業リストは 1,000 社以上が必要です。一方、連絡先リストでは、マッチ件数 300 人の最低値を確実に超えるため、約 10,000 件以上のメールアドレスをアップロードする必要があります。シードには MQL ではなく、受注済みの顧客を使用してください。

営業サイクルが長いため、B2B シードのコンバージョン評価は数週間遅れます。初期段階ではマッチ品質とエンゲージメントを評価し、シード自体の評価はコホートが成熟してから行ってください。

B2Cでは反対の状況になります。リストは、最低件数を満たすことよりも、選定を適切に行うことが制約になります。

これが機能したかどうかを測定する

マッチ率は、データ品質に関する先行指標にすぎません。Google 自身の表現によれば、マッチ率が高いことはデータが正確であることを示唆しますが、リストのパフォーマンスを保証するものではありません。マッチ率でシードを評価してはいけません。

シードのバージョンは、新規顧客の CPA／CAC、新規ブランド顧客率、獲得した顧客の AOV、そしてスキル独自の KPI、つまり**シードのバージョン別のコホート LTV（90 日／180 日／365 日）**で評価します。よくある落とし穴（Churney）は、CPA の低い類似オーディエンスでも、シードの拡大によって低利益率のコンバージョンが増え、成熟時の LTV が低くなることです。利益率または予測 LTV を基準にシードを再作成し、そのバージョンを廃止して解決します。

シードのバリエーションを比較するには、ユーザーレベルのスプリットテストか地域別のホールドアウトを実施してください。単純な広告セット比較は避けてください。オーディエンスの重複によって結果が汚染されます。有効な 2 つの手法を比べると、次のとおりです。

• 労力の面では、split test > geo holdout です。プラットフォームの設定で済むスプリットテストに対し、地域別ホールドアウトではテスト期間中、市場のトラフィックを丸ごと除外する必要があり、その市場の数値を担当する人の承認が必要です。
• 証拠の強さでは、geo holdout > split test です。地域別ホールドアウトは、デバイス間の識別情報が失われても影響を受けず、プラットフォームが割り当てた売上ではなく、増分売上を測定できます。

プラットフォームが真のユーザーレベルのスプリットテストを提供している場合は、これを標準としてください。シードの判断を覆すコストが高い場合（価値列の再プラットフォーム化、シードのバージョンの廃止、国別の分割など）、またはスプリットテスト自体の結果に異議がある場合は、地域別ホールドアウトに切り替えてください。

結果を読み取る前に、学習フェーズを十分に確保してください。一般に Meta のガイダンスとされる目安は、広告セットごとに週 50 件程度の最適化イベント、またはボリュームが少ない場合は 2〜4 週間です。

合格基準：シードのバージョンから獲得した顧客の 90 日コホート LTV が、CPA を同等以下に保ちながら、アカウント全体の獲得顧客の平均 LTV 以上であること。基準を下回る場合は、価値を基準にシードを再作成する、直近性の条件を厳しくする、または分割するなど、改善を繰り返してください。次のコホート期間を終えた後に再評価します。シードはバージョン管理する成果物であり、一度アップロードすれば終わりではありません。

よくある失敗パターン

意図的に順位付けしていません。これらは、1つの目標に対する複数の選択肢ではなく、失敗と対策の組み合わせです。また、ここにある対策はどれも十分に手間がかからないため、効率で順序付けすると、実際には存在しない優先順位の判断を示唆してしまいます。すべて実施してください。

失敗パターン	なぜ問題になるか	対策
行数を基準に規模を決める	下限が適用されるのは一致したユーザーです。5,000行のリストでも一致率が40％なら、シードは2,000件です	実効シード数を計算し、目標の2～3倍をアップロードします
「最低数を満たす」ために、誰でもシードに加える	シグナルのまとまりが薄まり、規模よりも均質性が重要になります	代わりにフォールバックの手順を実行します。品質を最初に犠牲にしてはいけません
累積の生涯売上を価値の列に使う	顧客の在籍期間を反映し、売上は高くても利益率の低い顧客がモデルに悪影響を与えます	利益率または予測LTVを使います
除外対象の選別を省略する	返金者、割引のみを利用する購入者、従業員、卸売顧客を含めると、モデルが誤った顧客像を学習します	エクスポート前に毎回除外します
UIアップロード用のファイルを事前にハッシュ化する	プラットフォームは取り込み時にハッシュ化します。ソルト付きのハッシュでは何も一致しません	UIから正規化した平文をアップロードします。ハッシュ化は、必要なAPI／ウェアハウス同期の場合に限ります
同意を確認する前にアップロードする	ハッシュ化されたリストもGDPR上は個人データであり、法執行の対象になります	まずプライバシー確認を行い、抑制処理はウェアハウスで一度だけ適用します
一致率でシードを評価する	一致率が測るのはデータの衛生状態であり、オーディエンスの品質ではありません	シードのバージョンごとにコホートLTVで評価します
学習期間中にシードを評価する	最適化のためのデータ量が蓄積するまでは、初期のCPAはノイズです	学習完了まで、または2～4週間待ってから評価します
複数国の類似オーディエンスに1つのグローバルシードを使う	類似オーディエンスは国ごとに作られます。モデルは市場間のデータを平均化します	国ごとにシードと類似オーディエンスのペアを作成します
アップロードは一度きりで済むと考える	静的リストは劣化し、登録者は対象から外れていきます（Customer Matchでは540日ルール）	担当者を決めて定期的に更新するか、自動同期を設定します
プラットフォームごとに仕事用と個人用のIDを混在させる	消費者向けプラットフォームでは仕事用メールアドレスがほとんど一致せず、LinkedInでは個人用メールアドレスがほとんど一致しません	識別子の種類をプラットフォームに合わせ、異なる場合はデータを補完します
2022年当時の手順をそのまま使う	Similar AudiencesとLinkedIn Lookalikesはすでに存在せず、包含条件は提案扱いになりました	最新のドキュメントで機能を確認し、シードはシグナル、除外条件だけを厳格なルールとして扱います

リファレンス

• フロアに照らして規模を見積もる場合は、references/platform-floors.mdをお読みください。日付、不整合、廃止、マッチ率の範囲、更新時の動作を含む、プラットフォームごとの完全な表があります。
• 行を選択する場合は、references/seed-selection.mdをお読みください。RFM コホート、直近性の期間、除外対象のリスト、価値ベースのルール、購入以外のソースの優先順位が記載されています。
• 仕様を書く場合は、references/examples.mdをお読みください。B2C の価値ベースのシードの例と、フロアを満たさずフォールバックの段階を進む B2B の受注済みシードの例があります。