网站推广外包：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /88d7659d9bb2.html
📄
网站推广外包：项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度由“下一次接手的人要用它做什么”决定，而不是由文档数量决定。如果后续还要续做推广、换服务商或自查投放逻辑，至少保留到能复现一次关键动作的粒度；如果项目已彻底终止且无合规留存义务，可以只留结论性记录，把过程稿清掉。两种做法都成立，代价不同。
先判断文档会被谁再用
项目结束后的历史文档，真正会打开它的人通常只有三类：接手推广的内部同事、下一家外包团队、以及需要解释历史投放的负责人。粒度可以按这三类人的使用深度来定。
- 只用于交接结论：保留目标、周期、预算口径、最终结果和未完成事项，过程稿可归档或删除。
- 用于继续执行：保留账户结构、素材版本、落地页对应关系、关键词分组逻辑，以及每次调整的原因。
- 用于复盘或争议处理：保留审批记录、变更记录和对外承诺的书面版本，这类文档不宜只留摘要。
一个实际动作：让接手人试着只凭文档复现最近一次投放调整。如果能复现，粒度够了；如果必须回头问原执行人，说明还缺关键记录。这个测试的结果直接决定下一步是补文档还是停止整理。
保留、改写、退出三种取舍的适用条件
“保留”适合后续还会沿用同一套推广结构的情况，代价是存储和检索成本，以及旧信息可能误导新人。“改写”适合项目方向已变、但历史结论仍有参考价值的情况，把过程压缩成决策记录，代价是丢失部分可复现细节。“退出”适合项目彻底结束、无续做计划且无合规要求的情况，只留结论和对外材料，代价是将来重启时要重新摸索。
判断依据可以看一个信号：如果历史文档里的账户结构、素材命名或落地页路径，与当前在用的体系已经不一致，那么全量保留反而增加误用风险，此时改写或退出更合理。反之，如果结构仍在沿用，只是执行人换了，保留原始粒度更省事。
一个注明假设的粒度示例
假设某项目投放周期为六个月，结束后半年内可能换服务商。可以这样分层：
- 结论层：目标、总预算区间、各渠道大致占比、最终达成的方向性结果。这层必须留。
- 结构层：账户或计划的分组逻辑、素材与落地页的对应关系、排除项和限制条件。这层在可能续做时留。
- 过程层：每次调整的日期、原因、前后差异。这层只在需要复盘归因时留，且建议只留影响过预算或方向的调整。
这里的数字只是说明分层方法，不代表任何真实项目的效果。关键是每一层都要能回答“谁在什么情况下会用到它”，答不上来的层就可以考虑清理。
清理前要确认的两件事
第一，确认没有合同或合规要求的留存期限，这类要求优先于整理偏好。第二，确认历史文档里没有仍在使用的账号权限、密钥或对外承诺，这类内容不能简单随过程稿一起删除。
执行顺序建议是先分层、再标记、最后处理。标记时给每份文档写一句用途说明，例如“供续做时参考结构”或“仅用于解释某次预算变化”。完成标记后，用途重复的过程稿可以合并，用途缺失的可以退出。这样处理的结果是：下一次有人接手时，能先看到用途说明，再决定打开哪一层，而不是在一堆无标注文件里翻找。
什么时候该停止整理
如果整理文档所花的时间已经超过它可能带来的交接收益，就该停。一个可操作的判断是：连续两次整理都没有新增“接手人必须知道”的信息，说明粒度已经够细，继续拆只会增加维护负担。此时把剩余工作转为写一份一页以内的交接说明，比继续归档更有效。
