为 lookalike/similar/value-base…

当你需要为相似受众选种子客户、上传客户名单、判断匹配数是否过平台下限，或现有 lookalike 效果不佳时，用这套做法确定选谁、选多少、如何合规与回退。

适用场景

解决思路

1. 按匹配数而非上传行数计算种子规模：effective seed = uploaded rows × expected match rate；平台下限作用于匹配后人数；按目标上传量的 2-3x 上传，例如 5,000 行、40% match 得到 2,000 人种子。
2. 优先同质性和价值集中度，而非单纯规模：Meta 自身指引认为种子同质性比规模更影响受众效果；从业者共识是几百个高价值客户通常优于数千个无差异订阅者。
3. 把 inclusion 当建议、把 exclusion 当规则：在 Meta Advantage+ 和 Google Demand Gen 上，投放算法可能覆盖 inclusion 受众；只有 exclusion/suppression 受众是硬规则；种子的职责是给算法最干净信号，而不是圈定人群。
4. 先运行访谈，在选任何一行数据前收集全部答案；逐条询问：B2B、B2C/ecommerce 或两者？哪些平台会消费该种子（Meta / Google / LinkedIn / TikTok / other，因为 floors 和 match mechanics 不同）？有哪些客户数据、存放在哪里（CRM / data warehouse / email platform / pixel-and-platform events only / almost none）？客户总数大约多少、每行有哪些标识符（email / phone / name / postal address / mobile ad ID，每行标识符类型越多 match rate 越高）？是否有可用 value column，以及它实际衡量什么（cumulative lifetime revenue、margin、predicted LTV，还是 order count；来源比是否存在更重要）？数据有多新，过去 90 和 180 天内购买或转化的比例是多少？名单是否包含 EEA/UK 居民或受美国州隐私法覆盖的消费者，是否有广告平台上传的 documented consent 或 lawful basis，opt-outs、deletions、do-not-contact 记录是否在导出前执行？名单如何到达平台（manual CSV 或 automated warehouse/CDP sync），谁负责 refresh？该 lookalike 要驱动什么 acquisition outcome（target new-customer CPA/CAC，以及 acquired customers 的 LTV 或 margin 期望）？账户当前在这两个数上的平均值是多少（acquired-customer CPA 和 90 天 acquired-customer cohort LTV；pass threshold 要用基线给种子打分，未知基线则无法打分，应说明并把首个 cohort checkpoint 作为 baseline-building run）？受众必须何时 live and spending，这个日期是否硬性（种子来源从几分钟到一周协调，enrichment rung 还要走 procurement）？想要最快能上线的受众，还是 compounding asset（automated warehouse sync、enriched identifiers、可复用 cohort definition）？effort ceiling 如何，有多少数据团队小时可用，之后谁负责 refresh，能否拿到 privacy sign-off 和 vendor DPA（答 no 会删除 rung，而不是延后 rung）。
5. 在选行前执行隐私与同意门禁，这是硬停；若任一项未确认，停止并明确说明缺失项；本技能不是法律意见，合法依据因司法辖区而异，开放问题交给用户律师。
6. 确认有 documented lawful basis 或 consent 把该名单上传到广告平台；GDPR 下，客户名单 custom audiences 需要事先同意，哈希不改变这一点：SHA-256 输出是 pseudonymous 而非 anonymous，同意义务仍存。
7. 对 EEA 使用 Google Customer Match，按 Consent Mode v2 传递 consent signals，两个 ConsentStatus 字段均为 GRANTED（2024 年 3 月起强制）。
8. 在导出前传播 CCPA/CPRA 的 sharing opt-outs 和 Global Privacy Control signals（十二个美国州认可）。
9. 不基于敏感类别建种子：health、sexual orientation、religion、race、political affiliation、criminal history。
10. 为具体 ad account 接受平台 customer-list terms；value-based audiences 在 Meta 上需要单独接受条款。
11. Suppression、opt-outs、deletions 只在 warehouse 中执行一次，在任何 sync 前完成，不要事后按平台补做。
12. 选择种子来源时始终先选 purchase data；如果 purchase data 太薄，再从八个 sourced alternatives 中选；不要只按 value ranking 选，因为 effort 和 compliance cost 都反向。
13. 价值轴排序：purchasers > checkout/add-to-cart initiators > high-intent page viewers > lead-form submitters > email clickers > video viewers > page engagers > all visitors。
14. 努力轴排序：video viewers == page engagers == all visitors > high-intent page viewers == lead-form submitters > checkout initiators > email clickers > purchasers；平台原生 engagement audiences 在广告账户内几分钟基于 pixel 已触发规则构建，跳过 customer-list upload 和 step-2 consent gate；purchaser 或 CRM seed 需要 warehouse export、identity-resolution join 和完整门禁。
15. 合规成本轴排序：purchasers == checkout initiators == email clickers > lead-form submitters > high-intent page viewers == video viewers == page engagers == all visitors；任何以 customer list 到达平台的来源都跑完整 step-2 gate（lawful basis、EEA 的 Consent Mode v2、opt-out propagation、value-based audiences 的单独条款接受），平台原生 engagement audience 不触发这些；若上传 consent 未确认，所有 list-based rung 不可用，而不只是更贵。
16. 效率轴排序：purchasers > high-intent page viewers > lead-form submitters > checkout initiators > email clickers > video viewers (75%+) > page engagers > all visitors；当 customer export 已存在时 purchasers 领先；否则 high-intent page viewers 和 lead-form submitters 比例最好，near-zero setup、no upload、no new exposure；B2B lead gen 中 form submission 就是 conversion，submitters 提前；不要因 effort 把选择拉到这两者以下。
17. 效率排序会饿死 customer-identity asset 本身：purchaser 或 CRM seed 及使其可用的 identity enrichment 在 value 轴最高，但在 effort 和 compliance cost 上垫底；当 export 尚不存在时，它会输给几分钟上线的 pixel rule；在以下情况提升它：访谈回答 compounding asset 而非 live soonest；B2B 且 native match rate 无法不 enrichment 就过 floor；同一账户已连续两轮丢失该选项。
18. 在无隐私签核路径或无 vendor DPA 时，按名字从菜单删除 list-based source；无 lawful basis 的名单不是慢选项，而是不可选项；留在底部会以 scope 形式在受众上线后重现。
19. 用 email clickers，不要用 openers；Apple Mail Privacy Protection (2021) 使 opens 变成噪声；B2B 从 closed-won CRM opportunities 建种子，不要 all-MQL exports；SQL-only 优于 all-MQL。
20. 默认选 RFM Champions + Loyal cohorts，或按 predicted LTV 或 margin 选 top 10-25%；绝不要按 cumulative lifetime revenue 选，它跟踪 tenure 而非价值。
21. Recency window：30-90 天作为起点，对 pixel/CAPI-tracked buyers 可到 180 天；联系数据超过 12-18 个月会实质性降低 match rate 和表现。
22. 执行 negative-selection pass：移除 refunders、chargebacks、serial returners、discount-only buyers、employees、wholesale accounts；在种子里保留 existing customers，但在 delivery level 从 acquisition campaign 中 suppress 他们。
23. 计算 effective seed = uploaded rows × expected match rate；从平台文档范围取 expected match rate，并按 list 的 identifier density 和 age 调整。
24. 使用示例范围：Google Customer Match 在大多数广告主为 29-62%；Meta 在好名单上为 50-80%；LinkedIn 在 work-email contact lists 上约 30-40%；Reddit 原生 CSV 约 2%。
25. 将 effective seed 与平台 matched-count floor 比较，并按目标 2-3x 确定 upload；若 harness 能读取 customer export，直接计算 counts；否则输出精确 filter definitions（source table、filter conditions、recency bounds、value threshold）给用户数据团队运行，并在继续前等待 counts。
26. 若 effective seed 无法清 floor，走 fallback ladder；绝不要先放宽 selection quality；rung numbers 是稳定 ID，每级有自己的 value、effort、compliance cost。
27. Rung 1 enrich identifiers：用 identity resolution 追加 personal emails/phones；这是唯一能在不改变模型学习内容的情况下增加 matched people 的 rung；在 B2B work-email 名单对 consumer platform 的约 5% native match 场景，这是唯一能到达任何 floor 的 rung；effort 包括 vendor selection、security review、budget sign-off、match test，需一周以上协调；compliance 增加新 processor，需要 DPA、counsel sign-off、覆盖 enrichment 而不仅是 upload 的 lawful-basis re-check；这是最难逆转的 rung。
28. Rung 2 将 recency window 放宽一档（90 到 180，180 到 365）；value 中等，代价是 signal freshness；effort near-zero，只是 query edit，几分钟，完全可逆；compliance 无新增。
29. Rung 3 stack 一个同质相邻 segment，例如 Champions 加 Loyal，或第二产品线买家若行为确实相似；value 中等，同质性是风险；effort 约一小时加判断；compliance 无新增。
30. Rung 4 切换到 step-3 排名中下一个非购买 seed source；value 最低，是唯一改变模型学习内容的 rung；若 event source 已埋点，effort 约一小时；compliance 更低，因为平台原生来源不需要 upload 和 consent gate。
31. 默认效率：rung 1 > rung 2 > rung 3 > rung 4；停在第一个清 floor 的 rung，并记录在 spec 中。
32. 一个已记录 flip：当未签约 enrichment vendor 且还有 recency 可放宽时，rung 2 > rung 1；一个下午可能先解决问题，若不行 rung 1 仍可用；该 flip 不适用于标准 B2B 场景，因为 cheap rungs 结构性为空（all-time closed-won list 没有 recency 可放宽，没有不是 lost deals 的相邻 segment，native match 太低）。
33. Rung 1 也可删除而非降级：无 procurement route、无 DPA、无 vendor budget owner 时，把它从 ladder 删除，运行 rungs 2-4；无人能执行的 rung 留在效率排序顶部会让 spec 假设它。
34. 在标准 B2B 场景上可能没有 ladder：报告该发现，而不是用更宽松 seed 填充。
35. 若 seed 是 value-based：喂 margin 或 predicted LTV。
36. 若 seed 是 value-based：只保留 positive values。
37. 若 seed 是 value-based：值不能全部相同。
38. 若 seed 是 value-based：每个 list 一种 currency。
39. 若 seed 是 value-based：cap 或 winsorize whale outliers，避免少数大账户偏斜模型。
40. 若 seed 是 value-based：上传时确认 value column 已映射；未映射会让平台静默构建 standard 而非 value-based lookalike；若 audience-build 时 value-based 选项不出现，说明列未映射。
41. Identifier preparation：每行多个 identifiers 优于仅 email。
42. Identifier preparation：phone 使用 E.164-style digits，含 country code，无 plus sign，无 leading zero。
43. Identifier preparation：emails 小写并 trim。
44. Identifier preparation：绝不要为 UI upload 预哈希文件；平台在 ingest 时哈希，salted 或 double hash 永远不会匹配。
45. 在 Meta 上以 Event Match Quality score 6.0+ 作为从业者基准。
46. Splits 按 country > product line > high-AOV vs. all 顺序执行，并在 named refresh owner 容量耗尽时停止；每个 split 的 effort 相同（一个 WHERE clause），但会增加永久工作：刷新、监控 overlap、永久保持 above floor。
47. Country 不是可选项：Meta lookalikes 按国家范围构建，多国覆盖需要每个国家一个 seed-and-lookalike pair；承诺前检查每个 split 自己的 effective seed 是否过 floor。
48. Refresh：设置 cadence 和 named owner；static CSV uploads 不自动刷新（LinkedIn lists、manual Meta customer lists），因此安排 weekly-to-monthly refresh 或迁移到 automated warehouse sync。
49. 在 automated sync 和 manual CSV 之间，efficiency 和 compliance cost 上 automated sync > manual CSV，尽管 effort 更高；一周工程一次可消除整个 decay failure mode，并持续传播 opt-outs 和 deletions；CSV 只建议作为 bridge，并指定 owner 和 sync 落地日期；Google Customer Match 会 drop 540 天内未刷新的成员。
50. 检查此 seed 的 audience 与现有 audience 的 overlap；从业者 concern threshold 约为 20-30%；超过则 consolidate 或 exclude。
51. 填写 Seed Specification block：platform、audience type、definition、value column、mapping confirmed、row count、identifiers/row、expected match、effective seed、fallback used、exclusions、consent basis、refresh、measurement、re-check；并把种子的 tier placement 交给 ad-audience-targeting。
52. 附上 measurement plan 和一个 cohort window 后的 re-check date；若 harness 有 persistent memory，记忆 seed version、definition、counts、re-check date，让下一次运行比较历史而不是重新推导。
53. Evidence Gate：若 match rate basis 未知（未查平台范围且无历史 upload 校准），拒绝输出 Seed Specification，只能从文档范围加 list age/identifier density 估算并标记为 estimate。
54. Evidence Gate：若 consent basis 未确认（privacy gate 未通过），拒绝输出 Seed Specification；没有任何 selection quality 能证明用户无 lawful basis 的上传是合理的。
55. Evidence Gate：若 value column 来源未知（例如只说有 LTV 字段，但无法说明是 revenue、margin 还是 model output），在有人能说明前，seed 不是 value-based。
56. 绝不要编造 customer list、segment definition 或用户数据不支持的 threshold；请求缺失证据，而不是替换为通用 list。
57. 当现有 lookalike 表现不佳且怀疑 seed 时，使用症状查找表，不排序：match rate 远低于平台文档范围，原因是 stale list、single identifier per row 或 unnormalized formats，行动是 normalize（E.164、lowercase email）、增加 identifier columns、删除 18 个月以上行，然后 enrich。
58. 症状：list uploaded 但 audience 无法 build 或 serve；原因是 matched count 低于 floor，row count 被误读为 seed size；行动是重新计算 effective seed，运行 fallback ladder。
59. 症状：value-based option 在 audience build 时缺失；原因是 value column 未在上传时映射；行动是重新上传并确认 mapping，因为平台已静默构建 standard lookalike。
60. 症状：CPA 正常但 acquired customers 的 90-day cohort LTV 弱；原因是 seed 放大了低 margin converters（Churney pitfall）；行动是用 margin 或 predicted LTV 重新 seed，并 retire 该 seed version。
61. 症状：lookalike 表现接近随机或不如 broad；原因是 expansion percentage 太宽，或 heterogeneous seed 混入不像买家；行动是收紧 percentage，按 product line、segment 或 country 拆分 seed。
62. 症状：计划引用 Google Similar Audiences 或 LinkedIn Lookalikes；原因是 stale playbook，Similar Audiences 于 2023 年 8 月移除，LinkedIn Lookalikes 于 2024 年 2 月 sunset；行动是重建为 Customer Match as signal 或 LinkedIn Predictive Audiences（300 matched min）。
63. 症状：两个 seeded audiences 互相 cannibalize；原因是 audience overlap 高于约 20-30% concern band；行动是 consolidate seeds 或增加 mutual exclusions。
64. 症状：表现数周衰减且未做改动；原因是 static CSV 从未刷新，members aging out；行动是设置 cadence 和 owner，automate sync，并遵守 540-day Customer Match cutoff。
65. 修复顺序：先修任何阻止 audience serving 或 matching 的问题（floor failure、broken mapping、match rate 低于平台 band），再修 overlap 和 refresh，最后修 value/expansion 原因。
66. Platform floors 作用于 matched count；使用 compact view：Meta 100、Google Customer Match 100（2025 从 1,000 下调）、Google Demand Gen lookalike 1,000 active matched（API docs；Help Center 说 100，取更严格）、LinkedIn Matched/Predictive 300 matched、TikTok 1,000（Help Center；FAQ 说 100，取更严格）、Pinterest 100、Reddit 1,000 matched、X 100 matched、Amazon AMC lookalike 500 user IDs、Snapchat 1,000 to serve。
67. 推荐 seed 大小：Meta 1,000-5,000（Meta docs）、Google Customer Match 1,000+（practitioner）、LinkedIn contact list 上传 10,000+ rows、company list 1,000+ companies、TikTok 10,000（practitioner）、Pinterest 1,000+（practitioner）、Amazon AMC 10,000+（practitioner）。
68. Platform floors 会随时间移动；若 harness 能浏览 web，定稿前对照平台 live documentation 验证；否则让用户验证。
69. B2B 和 B2C 相同之处：hashing 和 normalization mechanics（SHA-256、E.164、lowercase email）、match-rate arithmetic、effective-seed computation、negative selection、warehouse-first suppression、measurement windows，因为它们运行在同一套 ad systems 上。
70. B2B 面临 small-list problem：400 个高 ACV 客户无法原生喂 consumer-platform lookalike，因为 work emails 在 Meta 和 TikTok 匹配差，personal emails 在 LinkedIn 匹配差；上传前 identity enrichment 是 documented workaround，也是 fallback rung 1。
71. B2B seeds 是 account-level 或 contact-level：上传前按 title/seniority/function 将 company list 扩成 contacts；在 LinkedIn 上，company list 要 1,000+ companies，contact list 约需 10,000+ emails 上传才可靠过 300-match floor；从 closed-won 建种子，而不是从 MQL；长销售周期意味着 conversion read 滞后数周，早期看 match quality 和 engagement，种子本身等 cohort maturity 再判断。
72. B2C 得到相反 trade：名单通常足够大，binding constraint 是 selection discipline，而不是 floor-clearing。
73. Match rate 只是 data-quality leading indicator；按 Google 自己的措辞，高 match rate 只说明数据可能正确，不保证 list performance；绝不要用它给 seed 打分。
74. 用 new-customer CPA/CAC、new-to-brand rate、acquired customers 的 AOV，以及本技能 KPI：cohort LTV at 90/180/365 days by seed version 来评价 seed version；低 CPA lookalike 在成熟时 LTV 差（Churney）的修复是用 margin 或 predicted LTV 重新 seed，并 retire 版本。
75. 比较 seed variants 用 user-level split test 或 geo holdout，绝不用 naive ad-set comparison；audience overlap 会污染。split test > geo holdout on effort；geo holdout > split test on evidence strength。平台提供 true user-level split test 时默认 split test；当 seed decision 昂贵难逆（re-platformed value column、retired seed version、country split）或 split test 自己的 read 有争议时升级 geo holdout。
76. 读取前尊重 learning phase：大约每个 ad set 每周 50 optimization events（常归于 Meta guidance）或低量时 2-4 周。
77. Pass threshold：seed version 的 90-day acquired-customer cohort LTV 达到或超过账户平均 acquired-customer LTV，且 CPA 等或更好；低于则 iterate：re-seed on value、tighten recency 或 split；一个 cohort window 后 re-check；seed 是 versioned artifact，不是一次性 upload。
78. Common failure mode fix：不要按 row count 定容；floor 作用于 matched people，5,000 行 @40% match 是 2,000 seed；计算 effective seed，上传 2-3x target。
79. Common failure mode fix：不要为 hit minimum 填充所有人；那会稀释 signal cluster，homogeneity 胜过 size；运行 fallback ladder，质量绝不首先交易。
80. Common failure mode fix：不要喂 cumulative lifetime revenue 当 value column；它跟踪 tenure，高收入低 margin 客户毒害模型；用 margin 或 predicted LTV。
81. Common failure mode fix：不要跳过 negative-selection pass；refunders、discount-only buyers、employees、wholesale 会教模型错误客户；每次导出前剔除。
82. Common failure mode fix：不要为 UI upload 预哈希文件；平台 on ingest 时哈希，salted hash 不匹配；通过 UI 上传 normalized plaintext，只在 API/warehouse syncs 要求时 hash。
83. Common failure mode fix：不要在 consent 确认前 upload；hashed lists 在 GDPR 下仍是 personal data；先过 privacy gate；suppression 在 warehouse 中一次执行。
84. Common failure mode fix：不要用 match rate 给 seed 打分；它衡量 data hygiene，不是 audience quality；用 cohort LTV by seed version。
85. Common failure mode fix：不要在 learning phase 内判断 seed；早期 CPA 是 noise，等 learning exit 或 2-4 周后再读。
86. Common failure mode fix：不要为一个 multi-country lookalike 用一个 global seed；lookalikes 按 country-scoped，模型会跨市场平均；每个国家一个 seed-lookalike pair。
87. Common failure mode fix：不要把 upload 当成永久完成；static lists 衰减，members age out（Customer Match 有 540-day rule）；设置 refresh cadence 和 owner，或 automated sync。
88. Common failure mode fix：不要按平台混用 work 和 personal identity；work emails 在 consumer platforms 匹配差，personal emails 在 LinkedIn 匹配差；按平台匹配 identifier type，不一致时 enrich。
89. Common failure mode fix：不要照抄 2022-era playbooks；Similar Audiences 和 LinkedIn Lookalikes 已不存在，inclusions 变成 suggestions；对照 live docs 验证功能；把 seed 当 signal，exclusions 当唯一硬规则。

适用边界 · 注意事项

• 不要用于设计整个 targeting tier structure；种子机制属于本经验，层级架构应交给 ad-audience-targeting。
• 没有合法依据或同意、无法完成隐私合规门禁时，不要上传任何客户名单或输出 Seed Specification。
• 没有可用客户数据、价值字段来源未知或无法验证匹配率依据时，不要编造名单、分群定义或阈值。