在 Amazon Ads 数据平台里，最常见的建模简化之一，是把 keyword、search term、product target 和 negative keyword 都塞进“关键词”表。字段通常包括文本、match type、campaign、ad group、bid、state，再加几个表现指标。这个模型足以出报表，却无法可靠回答：某条负向规则究竟阻断什么；一个搜索词被迁入精准 Target 后是否必须从自动投放中排除；同一文本出现在不同 marketplace、不同广告产品或不同作用域时，是否还是同一个对象。
否定投放不是维护一张黑名单，而是在多个投放制度之间声明阻断关系。治理重点不在词面是否相同，而在对象类型、作用域、匹配语义、证据成熟度和策略目的是否同时成立。 本体建模的价值，是把这些隐含条件变成可以查询、验证、审批和回放的关系，使“搜索词收割”从个人经验变成有边界的状态迁移。
背景：投放对象看似都是词，实际上属于不同制度
search term 是购物者实际输入或平台报告出来的查询表达，它是观察事实；keyword target 是广告主配置的投放对象，它是控制意图；negative keyword 是阻断条件；product target 面向 ASIN 或品类；自动投放中的 close match、loose match、substitutes、complements 又是平台定义的 Target 分组。它们可能共享一段文本，却不是同一类实体。
四类对象身份证柜把本节的判断压缩成可检查的关系：拆开搜索词、关键词 Target、商品 Target 与否定规则。人物动作对应执行责任。
Sponsored Products targeting guide说明自动投放和手动投放承担不同作用：自动投放根据商品信息匹配购物查询，search term report 可用于发现表现较好的查询，再进入手动关键词或商品投放。Amazon Ads 报告指南也明确区分 targeting report 与 search term report。前者描述广告主配置或平台 Target 的表现，后者描述触发点击的购物者查询。把两者压成一列，会把观察事实与控制对象混在一起。
作用域同样构成对象身份。Sponsored Products negative targeting API把负向关键词放在明确的 campaign 或 ad group 上，并带有 match type 与 state。Sponsored Brands OpenAPI也定义自己的对象结构。相同文本在 Sponsored Products ad group 与 Sponsored Brands campaign 中，并不是一条规则的两个副本，而是两个受不同产品 schema 管理的对象。
因此，本体里的核心问题不应是“关键词有哪些字段”，而应是“哪些对象能以什么关系作用于哪些流量”。业务最小集合包括：Campaign、AdGroup、AdvertisedProduct、KeywordTarget、ProductTarget、AutoTargetGroup、SearchTermObservation、NegativeKeyword、NegativeProductTarget、Placement、Marketplace、EvidenceWindow 和 StrategyDecision。
当下问题：关键词表为什么管不住冲突与误杀
第一类失败是文本等同。系统看到 search term 与 keyword target 文本一致，就认定两者相同；看到单复数、词序或停用词变化，又把它们视为完全不同。实际上，匹配由广告产品和 match type 共同定义，平台行为还可能变化。词面标准化可以帮助检索，不能替代官方匹配语义。
同词异体分流台把本节的判断压缩成可检查的关系：相同文本在观察、配置和约束中的不同身份。人物动作对应执行责任。
第二类失败是作用域丢失。某个 ad group 添加 negative phrase 后，系统只记录文本和 negative=true，没有保存它作用于哪个 campaign、ad group 和广告产品。后续做冲突检查时，要么遗漏真实阻断，要么把其他作用域内合法 Target 标成冲突。Amazon 官方帮助把负向关键词与负向商品作为不同能力，进一步说明“负向”不是一个能覆盖所有对象的布尔字段。
第三类失败是把策略偏好写成平台事实。围绕 search term harvesting，社区长期争论“将自动或广泛匹配中的赢家迁入 exact 后，是否要在原 campaign 中 negative exact”。2024 年的流量蚕食讨论、2025 年关于是否阻断原入口的讨论和 broad match 策略讨论给出了互相冲突的经验。它们适合暴露真实问题，但不能证明平台一定自我竞价，也不能生成全账户规则。
第四类失败是证据与动作脱节。一个 search term 在 7 天里花费较高、没有归因订单，不等于它已满足负向条件。需要检查归因窗口是否成熟、点击量是否足够、该词是否承担新品探索、是否与高利润 ASIN 相关、添加 negative phrase 会阻断多少长尾流量。若数据模型只存累计 spend 和 orders，Agent 无法解释为何选择 exact negative 而不是降 bid、暂停 Target 或继续观察。
本体机制：把搜索词、Target、作用域和证据分开
本体第一步是建立明确身份。KeywordTarget 的身份至少由广告产品、profile、campaign/ad group scope、原始文本、match type 与平台对象 ID 组成；SearchTermObservation 的身份由报告族、profile、业务日、触发 Target、原始查询和抽取版本组成；NegativeKeyword 则是一个配置对象，不能与被它可能阻断的 SearchTerm 合并。
第二步是定义关系，而不是增加更多外键。observedThrough 表示 search term 通过哪个 Target 被观察；configuredIn 表示 Target 属于哪个 ad group；blocksWithinScope 表示负向对象在哪个作用域生效；derivedFromEvidence 连接策略动作与成熟证据；promotedTo 表示一个搜索词被转换成新的 Target；supersedes 表示新策略替代旧策略，而不是删除历史。
SKOS Reference适合表达首选标签、别名、上下位词与相关词，例如同一业务概念的拼写变体；OWL 2 Overview用于表达类、属性、互斥和约束。二者都不能自动复制 Amazon 的实际匹配算法。本体可以声明“这些字符串可能属于同一商品意图”，最终 eligibility 与 match 事实仍以 Amazon 官方能力和报告证据为准。
第三步是给关系加时间和来源。search term 在 11 月 1 日通过 loose match 出现，11 月 8 日被迁为 exact target，11 月 10 日又因库存风险暂停；这些不是对象属性被反复覆盖，而是三个带时间的状态事件。策略回放需要看到迁移前后表现和当时可见证据，不能只读取当前 state。
策略一：先建立可判定的冲突类型，而不是堆规则
“冲突”不是一个单一标签，至少要拆成四类。第一类是直接阻断冲突：活动中的正向 Target 被同作用域负向规则覆盖。第二类是发现能力冲突：过宽的 negative phrase 把本应继续探索的长尾流量一起阻断。第三类是路由冲突：同一 search term 同时可由多个发现型和收割型 campaign 承接，导致控制边界不清。第四类是经营冲突：流量路由本身合法，但被导向缺货、低利润或失去 Featured Offer 的 ASIN。
否定作用域套娃盒把本节的判断压缩成可检查的关系：表现 campaign 与 ad group 的继承边界。人物动作对应执行责任。
每类冲突都需要不同处置。直接阻断通常要求阻止发布或修正作用域；发现能力冲突应评估预计覆盖集合，并由投放 owner 审批；路由冲突需要定义 campaign 角色和流量优先级；经营冲突则调用库存、利润和零售就绪度门禁。把四类都归结为“重复关键词”，只会生成越来越长的排除表。
冲突判定可以分三层。字符串层做大小写、空格、符号和已批准的同义词归一；语义层根据商品意图、ASIN、品类和 match type 计算可能覆盖关系；平台证据层用 search term report 验证实际触发。前两层给出候选冲突，第三层决定是否已有事实支持。没有平台证据时，系统应标记 possible_conflict，不能直接自动 negative。
SHACL适合把确定性不变量写成 Shape。例如 NegativeKeyword 必须属于一个合法作用域，不能同时声明 campaign 与另一个 campaign 的 ad group；match type 必须来自该广告产品允许集合；发布动作必须带 evidence window、owner 和 expiry。对可能覆盖集合、语义相似度等概率判断，则保留为模型输出，不能伪装成 Shape 的硬事实。
策略二：把搜索词收割设计成状态迁移
搜索词收割不是“复制文本并加负向”两步操作，而是一条可回滚状态机。候选 search term 先处于 observed，满足成熟度、相关性、订单、利润与库存门槛后进入 qualified；创建 exact 或 phrase Target 后进入 promoted；只有当新 Target 已审核、可投放并获得足够 delivery 证据，系统才评估原入口是否需要限制；最终状态可能是 coexisting、routed、rolled_back 或 retired。
流量误杀事故现场把本节的判断压缩成可检查的关系：还原宽泛否定覆盖有效精准词的路径。人物动作对应执行责任。
这种状态机解决两个常见事故。其一，系统先在原 campaign 添加 negative，再创建新 Target 失败，导致有效流量被切断；其二，新 exact Target 创建成功但 bid、预算或广告位不足，原入口又被立即阻断，search term 失去展示。迁移应采用“先创建、再验证、后收紧”的顺序，并为每一步设置幂等键和补偿动作。
证据包至少包含：原始 SearchTermObservation、触发 Target、窗口内 clicks、spend、orders、attributed sales、ACOS、总销售与利润边界、库存覆盖、当前 campaign 角色、建议 Target、建议 bid、是否负向原入口、预计影响范围、审批人和复查日期。Amazon campaign recommendations guide说明推荐可编辑、拒绝并具有过期性，这种产品边界值得保留在自建 Agent 中。
状态迁移不能把“订单数达到 N”写成普适标准。品牌词、竞品词、泛品类词和 ASIN Target 的价值结构不同；新品探索和成熟利润期的容忍度也不同。规则应引用 strategy profile，例如 launch-discovery-v2、profit-defense-v4，并记录 profile owner、适用 ASIN 集、最大 spend 和退出条件。
策略三：用约束查询和人工审批治理高风险负向动作
本体建立后，治理不应只靠可视化图谱。约束查询需要直接回答：哪些 active KeywordTarget 被同 scope 的 NegativeKeyword 可能覆盖；哪些 negative phrase 没有到期日；哪些收割动作缺少成熟证据；哪些 ASIN 已低库存却仍被扩量；哪些新 Target 创建后没有 delivery，原入口却已阻断。
对象关系编织架把本节的判断压缩成可检查的关系：把 contains、matches、negates 与 belongs-to 连起来。人物动作对应执行责任。
SPARQL 1.1的属性路径适合穿过 Campaign—AdGroup—Target—SearchTerm—Decision 关系，pySHACL与 Apache Jena SHACL可把硬约束放进 CI 或运行时。关系型系统也能实现同样控制，关键是查询对象来自统一本体，而不是每个脚本自行解释列名。
动作按风险分级。添加单个 exact negative 且预计覆盖有限、证据成熟、可快速回滚，可以进入低风险自动执行；negative phrase、campaign 级负向、大范围 ASIN 排除和跨 campaign 流量重构需要人工审批；证据不足或对象身份不完整直接拒绝。审批界面显示影响对象和理由，不只显示一段模型摘要。
PPC.io 的冲突检查文章与 Anata 的 search term report 指南可以帮助发现工程流程，但属于服务商或实践材料。Amazon Ads 的 match、scope 和对象结构必须回到官方资料核验，社区阈值不能直接写进生产规则。
数据与服务设计：图不替代数仓，数仓也不替代本体
表现事实继续保存在按 grain 声明的数仓表：search term 日报、target 日报、advertised product 日报、placement 日报。图或本体服务保存对象身份、作用域、关系、策略角色、版本与状态迁移。查询服务先从本体得到合法路径和对象集合，再从数仓读取规模化指标。两者通过稳定 ID 和有效期连接。
冲突雷达桌把本节的判断压缩成可检查的关系：在提交否定动作前扫描身份与作用域冲突。人物动作对应执行责任。
不建议把每天所有 clicks、impressions 都转成 RDF 三元组。高频数值事实适合列式存储，图更适合表达“这个 Target 属于哪个策略角色”“这条负向规则在哪个 scope 生效”“这个决定由哪版证据产生”。架构目标不是技术统一，而是语义一致。
API 层需要区分读取、建议与执行。读取接口返回对象和证据；建议接口生成候选迁移与冲突解释；执行接口只接受通过 Shape、权限和审批验证的决策 ID。LLM 可以解析投放人员意图和生成说明，但不能直接拼 Amazon Ads API 请求绕过动作服务。
变更采用事件记录。创建 Target、更新 bid、添加 negative、暂停 campaign 都生成不可变 decision event，当前状态由事件投影。发生回滚时新增补偿事件，不删除原记录。这样才能评估一条策略在不同 ASIN、match type 和 marketplace 上的真实效果。
验证方法：证明系统没有漏拦，也没有过度阻断
测试集至少覆盖同文本不同 scope、同 scope 不同 match type、单复数和词序变体、品牌词与泛词、keyword 与 product target、自动投放迁移、创建失败后的补偿、归因未成熟、库存骤降和 campaign 已暂停等场景。每个样本同时给出期望冲突类型、允许动作和拒绝理由。
离线回放使用历史 search term 与 Target 事件，比较新旧规则产生的候选 negative 集合。不能只看节省 spend，还要看被阻断搜索词后续是否产生订单、发现型 campaign 的新增词数量是否下降、exact Target 是否获得足够 delivery、整体 TACOS 与利润是否改善。误杀成本通常比漏掉一个低效词更难恢复。
线上采用小范围、可逆、带 holdout 的发布。先只给建议，再开放 exact negative 自动执行，最后才考虑 phrase 或 campaign 级动作。监控包括冲突数量、审批拒绝率、执行失败、补偿次数、被阻断流量、Target delivery、搜索词多样性、成熟后利润和库存风险。
Ontology Development 101强调本体是迭代产物，Protégé可用于领域专家共同审阅类与关系。真正的验收不在图画得完整，而在投放人员能否用它解释具体冲突，工程系统能否依据它拒绝危险动作。
未来探索：从文本匹配走向意图与商品关系治理
下一阶段可以把搜索词意图、ASIN 属性、品类与商品替代/互补关系纳入本体，使系统识别“文本不同但需求相同”和“文本相同但商品意图不同”。这有助于治理 product targeting、品牌防守和长尾发现，但模型推断必须与实际 search term、点击和订单证据分层。
生命周期证件更新站把本节的判断压缩成可检查的关系：处理搜索词迁移后旧关系的失效与保留。人物动作对应执行责任。
还可以建立策略仿真：在执行 negative phrase 前，基于历史触发记录估计可能被阻断的 search term 集合，计算其中的成熟订单、利润、发现价值和不确定性。仿真不是平台拍卖的精确复制，只用于展示影响范围和最坏情形，降低审批者面对单个文本时的盲区。
本体版本也要与 Amazon Ads API 版本分开。平台新增对象或 match 能力时，先扩展 ontology schema，再迁移策略规则和查询，最后开放动作。不能因为 API 返回新字段，就让旧 Agent 自动把它当作已有概念。
先做一个可运营的最小本体
第一版不要追求覆盖全部广告产品。可以限定 Sponsored Products，只纳入 Campaign、AdGroup、KeywordTarget、ProductTarget、AutoTargetGroup、SearchTermObservation、NegativeKeyword、AdvertisedProduct、ASIN、EvidencePackage 和 StrategyDecision。每个类只保留能够改变冲突判断或动作资格的属性，其余表现指标仍由数仓提供。范围越清楚，投放人员越容易发现关系是否符合真实操作。
最小本体需要配一份判定手册。手册不用解释 RDF 语法，而用 Amazon Ads 场景说明：同一个 search term 在两个 ad group 出现，是两个 Observation；同一个 keyword text 配置成 broad 和 exact，是两个 Target；负向对象是否冲突，要同时检查广告产品、scope、match type、状态与生效时间。遇到无法判定的匹配行为，标为平台待验证，不把经验写成公理。
迁移旧数据时，先建立身份映射表。平台 object ID 存在时作为外部身份；没有稳定 ID 的报告事实，使用 report type、profile、date、triggering target 与原始文本组成可追溯键。字符串清洗结果只作为索引，不覆盖原值。任何合并都记录规则和置信度，避免“统一小写去空格”把不同商品意图强行合并。
上线后每周抽样三类案例：系统判定直接冲突但投放人员认为合法，系统没有报警却出现流量误杀，模型判断语义相似但报告从未出现相互触发。第一类修正 scope 或规则，第二类补关系和测试，第三类降低模型结论权重。治理迭代围绕错误案例，不围绕类数量。
负向策略也需要经营损益表
负向动作的收益通常被写成“节省无效 spend”，损失却分散在后续：搜索词发现减少、精准 Target 未获得 delivery、自然排名测试中断、品牌防守覆盖下降。评估策略不能只统计被拦截花费，还要建立 counterfactual 近似和观察组。可选方法是在相似 ASIN 或部分 ad group 保留原路由，比较成熟窗口后的订单、利润和新词发现。
若无法做严格实验，至少保存动作前后的候选流量集合。negative exact 预计影响较窄，negative phrase 可能覆盖一组长尾；系统应展示历史上包含该短语的 search term、累计 spend、成熟订单、利润和最近出现时间。审批人看到的是影响面，而不是一个孤立词条。
策略复盘还要区分“规则正确但执行失败”和“规则本身错误”。新 exact Target 没有预算、bid 太低或创建失败，随后原入口被 negative，属于迁移事务问题；平台实际匹配范围与预期不同，属于知识问题；库存突然断供导致暂停，属于外部状态变化。三类问题进入不同 owner，不能都归因于 Agent 推荐质量。
当这套损益表稳定后，自动化权限才逐步扩大。低风险 exact negative 可在成熟证据和小影响范围内自动执行；phrase、campaign 级和商品负向继续由人工审批；任何新广告产品、新 match type 或未知作用域回到只读建议。自治范围跟随证据增长，而不是跟随模型版本宣传。
治理看板也不应只统计本体实体数。更有价值的指标是：直接冲突发现后平均多久修复，迁移动作有多少因新 Target 无 delivery 而回滚，negative phrase 审批中有多少因影响面过大被拒绝，多少 SearchTermObservation 无法绑定触发 Target，以及策略版本升级后旧决策能否重放。类和关系增加却没有改善这些指标，说明本体正在变成维护负担。
当投放团队提出新规则时，先要求给出正例、反例和撤回条件。例如“成熟词都要迁入 exact”必须说明成熟定义、哪些品牌词或低搜索量词例外、新 Target 多久没有曝光算失败、是否保留原发现入口。规则能被反例挑战，才有资格进入机器治理。
所有规则还要注明观察截止日期。Amazon Ads 的匹配和对象能力会变化，去年账户中成立的触发关系不能自动成为今年的永久知识。定期用新报告证据复核，过期而无证据的规则先降级为提示，再决定保留或删除。
总结概要：负向投放治理的核心是可解释边界
search term 是观察，Target 是控制对象，negative target 是带 scope 的阻断条件，campaign 与 ad group 定义作用域，证据窗口决定动作资格。把它们合并为关键词表，系统只能做字符串去重，无法可靠处理冲突、迁移、误杀和回滚。
安全路由编组场把本节的判断压缩成可检查的关系：让发现、收割与否定形成可解释流量分工。人物动作对应执行责任。
可落地的治理顺序是：建立对象身份和关系，定义直接阻断、发现能力、路由与经营四类冲突，把搜索词收割改造成状态迁移，再用 SHACL、查询、审批和事件审计控制执行。社区经验用于发现争议，官方文档决定平台事实，组织策略决定风险边界。本体不是为了让图更复杂，而是让每个负向动作都能回答“阻断谁、在哪生效、基于什么、何时复查、怎样撤回”。