app推广服务：供应商只交文档不实施时怎样设计双方接口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9e1539accd16.html
📄
app推广服务：供应商只交文档不实施时怎样设计双方接口
先给结论：如果供应商只交文档、不负责实施，接口设计要围绕“可独立执行”来做，而不是围绕“文档写得全不全”。具体做法是把每个推广动作拆成输入、输出、触发条件和失败返回，双方只在这些字段上签字，文档本身只是附件。这样做的代价是前期沟通更重，但能避免交付后才发现文档里没有可执行参数。
矛盾现象：文档越厚，实施越卡
在app推广服务里，常见一种交付形态：供应商交来一份渠道说明、素材规范或投放策略文档，但不进后台、不建计划、不调预算。接收方团队拿到文档后，往往卡在“照着做却做不出来”。
这不一定说明文档质量差。有两种合理解释：
- 解释一：文档是策略层产物，本来就不承担执行参数。它回答“投什么渠道、说什么卖点”，不回答“计划命名规则、出价字段、素材尺寸映射”。
- 解释二：供应商把实施责任默认留给了接收方，但接口没有写清。文档里出现的“建议”“可考虑”被接收方当成“照此执行”，两边对交付边界的理解不同。
这两种解释对应完全不同的处理方式。前者需要补执行参数，后者需要重划责任。区分它们的证据不是文档页数，而是：文档中是否出现可被程序或人工直接填写的字段，以及这些字段是否有唯一取值。如果一份文档里同一动作出现三种命名、两个出价口径，那更可能是接口缺失，而不是策略层产物。
取舍一：接口写在文档里，还是单独出接口表
两种做法都成立，但适用条件不同。
接口写在文档里适合渠道少、动作单一、接收方执行人固定的情况。代价是文档更新后，执行人必须重新通读，容易漏掉夹在段落里的字段变更。
单独出接口表适合多渠道、多执行人、需要交接的情况。代价是维护两份材料，文档和接口表可能不同步。此时应约定接口表优先，文档只作背景说明。
一个可操作的判断动作：让接收方执行人只拿文档，尝试填写一个真实推广计划的必填项。如果超过三成字段需要回头问供应商，说明文档不适合承担接口职能，应单独出表。这个动作的结果直接决定下一步：能填完就按文档走，填不完就要求供应商补接口表，而不是继续追问文档细节。
取舍二：接口由供应商定义，还是由接收方定义
供应商只交文档时，容易默认接口由供应商定义。但实施方是接收方，接口应该以接收方的执行系统为准。前提是接收方已经明确自己的推广后台、素材库和审批流程。
如果接收方系统尚未确定，由供应商定义接口反而更现实，因为供应商更清楚推广动作需要哪些输入。代价是接收方后续换系统时，接口需要重做。
假设一个场景：接收方使用A系统建计划，供应商文档按B系统的字段命名。接收方要求供应商改接口，供应商只愿意改文档措辞。这时能区分责任归属的证据是：文档中是否声明了“字段以实施方系统为准”。如果有这句话，供应商改措辞即可；如果没有，双方需要补一份字段映射，明确谁负责转换。这个映射动作的结果会影响验收：映射未完成前，不应把“文档已交付”当作实施条件已具备。
接口最小字段：让文档变成可执行清单
不管选择哪种取舍，接口至少要覆盖以下字段，缺一项就可能导致执行中断：
- 触发条件：什么事件发生后开始这个推广动作，例如素材审核通过、预算到账、活动开始。
- 输入：执行人需要准备什么，包括素材文件、落地页地址、渠道账号、出价范围。
- 输出：执行完成后产生什么，例如计划ID、投放截图、消耗记录、状态标记。
- 失败返回：输入不满足时返回什么，例如“素材尺寸不符”“账号无权限”“预算未确认”。
- 责任方：每个字段由谁填写、谁审核、谁接收。
这些字段不需要复杂系统，用一张表或一段结构化说明即可。关键不是格式，而是每个字段只有一个解释。如果同一字段出现两种解释，接收方应暂停执行，先要求供应商确认，而不是自行选一种继续。
验收动作：用一次干跑代替文档评审
文档评审容易停留在“看懂了”，但接口是否可用要靠干跑。干跑指不实际投放，只按接口走一遍填写和交接。具体动作是：接收方执行人按接口表填一个假设计划，供应商只回答字段问题，不代替填写。
干跑结果有三种，对应不同下一步：
- 全部字段可填、无歧义：接口可用，进入实际执行，文档作为背景保留。
- 少量字段需供应商口头补充：把补充内容写回接口表，再干跑一次，通过后执行。
- 大量字段依赖供应商解释：说明接口未成立，应要求供应商补交可执行字段，或把实施纳入服务范围，而不是继续靠沟通推进。
需要说明的是，干跑通过不代表推广效果会好，它只证明接口可执行。效果判断需要另设指标，不能和接口验收混在一起。把这两件事分开，才能避免用“文档很完整”替代“动作能落地”。
