网络推广外包服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /38cafd54bd46.html
📄
网络推广外包服务：项目结束后历史文档需要保留到什么粒度
没有统一粒度，决定因素是这批文档未来要承担什么责任。如果外包项目结束后仍可能发生账号争议、内容追责或二次接手，就要保留到能独立还原一次操作的程度；如果项目只是短期投放且账号与数据都已完整移交，保留到能说明结论和归属即可。判断标准不是文档多少，而是离开原执行人后，别人能否凭它回答“当时做了什么、依据什么、结果归谁”。
先分清两种结束条件，再决定保留粒度
第一种条件：外包方仍持有部分账号权限、素材源文件或投放后台的历史操作记录，或者合同里还有验收、尾款、质保条款未走完。此时文档粒度要细到操作层，至少包括每次改动的对象、时间、执行账号、改动前后状态和审批记录。原因是后续一旦出现排名波动、内容被投诉或账号异常，需要区分是外包方操作造成，还是需求方自己接手后改动造成。没有操作层记录，双方只能靠回忆争论，责任无法核对。
第二种条件：项目账号、域名、内容源文件、数据报表已全部移交给需求方，合同义务已结清，且不再续约。此时可以降到结论层，保留目标、策略说明、关键决策记录、最终数据快照和资产清单。操作日志、中间草稿、重复的沟通截图可以按批次归档后清理。粒度变粗的前提是移交已经可验证，而不是口头确认。
用可核对的证据判断该留细还是留粗
出现与直觉相反的结果时，不要急着归因。常见反常现象是：项目结束后流量或咨询量反而下降，需求方怀疑外包方做了隐藏操作，外包方认为是需求方接手后改了设置。能区分两种解释的证据包括：
- 账号操作日志的时间戳，看下降起点前后是否有登录和改动记录；
- 内容发布记录与索引状态快照，区分是内容被删改还是抓取减少；
- 投放后台的预算、出价、受众设置变更记录，排除广告端因素；
- 需求方内部接手人员的操作记录，确认下降是否发生在移交之后。
如果这些记录都缺失，流量下降既可能是外包遗留问题，也可能是季节波动、平台规则变化或需求方自己调整所致，无法单独归因。这时文档粒度不足本身就是风险，而不是“省了存储成本”。
一个可执行的保留动作及它对下一步的影响
假设某次外包项目结束，需求方计划三个月后由内部团队接手同一批账号。建议动作：在移交当天做一次“可还原性抽查”，随机抽取三条已发布内容和一次投放调整，要求仅凭归档文档还原出当时的操作步骤、使用账号和判断依据。抽查通过，说明粒度够用，后续可以只保留结论层文档；抽查不通过，说明必须补录操作层记录，并把补录范围限定在最近一个完整投放周期内，而不是无限回溯。
这个动作的结果直接决定下一步：通过则可以把归档周期设为合同结束后六个月，到期后只留资产清单和结论报告；不通过则要把操作日志、审批记录和变更说明至少保留到内部团队能独立完成一次同类操作为止。保留期限取决于接手能力，而不是固定月数。
哪些文档可以降级，哪些不能删
可以降级或清理的：重复的日报、已被最终版取代的草稿、无决策价值的群聊截图、与结果无关的过程文件。不能删的：账号所有权与权限变更记录、内容发布与删除记录、涉及费用和验收的确认记录、对外承诺的书面依据、最终数据口径说明。判断方法是问一句：如果明天有人质疑这个项目，我能否用剩下的文档说清楚谁在什么时候做了什么、依据是什么。答不上来的部分，就是不能删的部分。
例外情况：出现争议或监管要求时粒度要上调
如果项目结束后已经出现投诉、账号纠纷、费用争议，或者所在行业对宣传内容有留存要求，保留粒度要立即上调到操作层，并暂停任何清理动作。此时文档的作用不是复盘，而是举证。保留范围应覆盖争议涉及的时间段，并保持原始状态，不做二次编辑。争议解决后再按前述两种条件重新判断，而不是一直维持最高粒度。粒度选择始终服务于具体责任，不服务于“留得越多越安全”的直觉。
