公司网络推广：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7e3f137d068f.html
📄
公司网络推广：项目结束后历史文档需要保留到什么粒度
结论先行：公司网络推广项目结束后，历史文档的保留粒度应当按“能否支撑下一次决策或交接”来定，而不是按“是否属于该项目”来定。能说明目标、口径、责任归属和最终交付物的文档保留到可追溯层级；只服务于执行过程、且已被结果覆盖的中间稿可以只留索引。这个结论有一个重要前提：文档所依赖的系统、账号或合作关系仍然存在，否则粒度要整体上调。
先按文档承担的职能分三档，而不是按文件类型分
很多团队习惯按“策划案、周报、素材、报表”分类保留，结果真正需要复盘时找不到关键口径。更实用的做法是按职能分档：
- 决策档：立项说明、预算与资源分配、渠道取舍理由、关键节点变更记录。这一档建议长期保留，因为它解释的是“为什么当时这样做”，事后无法从结果反推。
- 执行档：排期表、任务分工、日常沟通记录、阶段性素材版本。保留到项目结束后一个完整业务周期即可，用于处理遗留问题。
- 证据档：合同附件、验收记录、账号权限交接单、第三方交付确认。按合同或合规要求保留，与推广效果无关，不能因为项目结束就清理。
这三档的划分标准是“缺少它会不会导致下一次判断失据”，而不是文件大小或数量。
什么情况下可以只留索引，什么情况下必须留全文
判断粒度时，可以问一个具体问题：如果半年后接手的人只看到这份文档的标题和一段摘要，他能不能独立完成交接？
能，就只留索引。典型情况是执行过程中的日常报表，其结论已经写进了月度或结项总结，原始表格只用于核对个别数字，保留文件名、时间范围、存放位置即可。
不能，就必须留全文。典型情况包括：渠道投放的口径定义、内容选题的取舍标准、与合作方约定的交付边界。这类文档一旦只剩标题，接手人很容易按自己的理解重新定义，导致前后数据不可比。
一个假设例子：某次推广把“有效咨询”定义为提交表单且电话可回拨，另一阶段只定义为提交表单。如果口径文档只留索引，后续对比两个阶段的转化数据就会失真，而这种失真在数字上完全看不出来。
会使上述结论失效的反例：旧系统或旧合作关系即将退出
如果文档所依赖的后台、账号或合作渠道本身要关停或终止，按职能分档的宽松策略就不再成立。此时执行档也要升级为全文保留，因为原始数据一旦无法再登录导出，索引就失去了指向的对象。
具体来说，当出现以下任一信号时，应把保留粒度整体上调一档：
- 推广所用的后台或数据工具确认不再续费；
- 合作方合同到期且不再续约，历史沟通记录只存在于对方系统；
- 负责该项目的岗位已经撤销，且没有明确的接手人。
反过来，如果系统仍在、合作仍在、接手人明确，就没有必要把所有中间稿都全文归档，那只会增加检索成本。
一个可执行的动作：先做退出清单，再决定粒度
与其先争论“保留多久”，不如先列出这个项目涉及哪些系统、账号和合作关系，逐项标注“继续存在”还是“即将退出”。对标注为即将退出的项，把相关文档导出为不依赖原系统的格式，并写一份说明文件，记录数据口径、时间范围和已知缺失。
做完这一步，再回头看哪些文档需要全文、哪些只需索引，判断会清晰很多。动作的结果直接影响下一步：如果退出清单显示大部分依赖项仍然存在，就可以按职能分档正常清理；如果显示多数依赖项即将消失，就需要安排一次集中导出和校验，而不是等到系统关闭前临时处理。
最后提醒一点：保留粒度不是越细越好。文档过多会稀释检索效率，让真正关键的决策记录被淹没。粒度是否合适，检验标准只有一个——接手人能否在不追问原作者的情况下，复现当时的判断逻辑。
