网络推广服务：项目结束后历史文档保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7572a72e6075.html
📄
网络推广服务：项目结束后历史文档保留到什么粒度
结论先行：文档保留粒度应由“下一次可能用到的决策”决定，而不是由项目是否结束决定。项目结项后仍可能发生预算追加、渠道换人、合规抽检或效果复盘，因此保留对象不是全部过程文件，而是能复现判断依据的最小集合。通常建议保留三层：结论层、口径层、证据层；日常聊天记录、中间版本和重复导出文件可以清理。
一个常见矛盾：文件越多，越没人敢删
很多团队在推广项目结束后遇到同一个现象：交付时整理出几百个文件，半年后真正被打开的只有少数几个。于是出现两种解释。第一种解释是“保留总比删掉安全”，因为不知道哪天会被追问。第二种解释是“保留粒度错了”，大量文件只是过程噪音，关键结论反而散落在聊天记录里，导致想找的时候找不到。
这两种解释会导向完全不同的动作。如果原因是前者，做法是继续扩容存储、延长保存期；如果原因是后者，做法是重新定义保留层级，把有限精力放在可复现的决策记录上。区分二者的证据并不复杂：统计过去一段时间内被实际调用的文件类型。若被调用的大多是结项报告、投放口径表和变更记录，说明问题在粒度；若被调用的大多是原始素材和逐日数据，说明业务确实依赖过程证据，此时应保留更细一层。
按“能否复现一次判断”划分三个保留层级
把文档按用途分层，比按时间或文件夹分层更耐用。可以这样操作：
- 结论层（长期保留）：项目目标、最终采用的渠道组合、预算分配结论、结项说明、遗留问题和责任人。这一层回答“当时为什么这么定”。
- 口径层（长期保留）：指标定义、统计周期、归因方式、素材版本说明、账号与权限归属。这一层回答“数字是怎么算出来的”。
- 证据层（按需保留）：原始导出数据、中间稿、会议记录、日常沟通记录。这一层只在可能复算或合规要求时保留，其余可设定期限后清理。
判断某个文件属于哪一层，可以问一句：如果明年有人质疑当时的结论，我需要拿出它吗？需要，就进结论层或口径层；不需要，就进证据层并设定清理条件。
前提变化时，保留粒度要跟着变
保留策略不是一次定死的。以下前提发生变化时，应调整粒度：
- 对接人更换：口径层必须补齐，因为新接手的人无法靠记忆还原统计方式。此时把口头约定写成文档，比多留一批原始数据更有用。
- 渠道结构调整：如果原有渠道被替换，结论层要注明替换原因和对比条件，否则后续复盘会把不同口径的数据直接比较。
- 合规或审计要求出现：证据层保留期需要按外部要求延长，此时不能沿用“半年后清理”的默认规则。
- 业务方向未变且团队稳定：可以适度压缩证据层，只保留能复算关键结论的最小数据集。
这里的关键动作是：在结项时给每个文件标注所属层级和保留期限，而不是等交接时临时判断。标注完成后，清理动作才有依据，下一次项目启动时也能直接复用口径层，减少重复对齐。
一个假设例子：两种保留方案的分岔
假设某团队做完一轮推广，结项后有 40GB 素材和 12 份报告。方案 A 全部保留，不做标注；方案 B 只保留结论层和口径层共 8 份文件，证据层保留 90 天并注明清理条件。三个月后，业务方要求解释某次预算调整的依据。方案 A 需要人工翻找，可能找到多个版本互相矛盾；方案 B 能直接定位到结论层的变更记录和口径层的指标定义。这个对比说明：保留粒度影响的是可检索性和可解释性，而不是存储成本本身。数字仅用于说明比较方法，不代表任何真实项目结果。
需要提醒的是，请求量、抓取量或某项统计归零，不能单独证明清理正确或错误。它还可能来自渠道暂停、统计口径调整或数据延迟。判断保留是否够用，应看能否复现当时的判断链，而不是看某个指标是否还在变化。
落地时先做哪一步
如果只能先做一件事，建议先补一份口径层文档：写明指标定义、统计周期、归因方式和数据来源。这份文档补齐后，结论层的可信度会明显提高，证据层的清理范围也更容易界定。之后每次结项都按同一模板更新，保留粒度就会从“凭感觉”变成“按用途”。当对接人更换或渠道调整时，再回头检查口径层是否仍然成立，不成立就补充变更说明。这样处理，历史文档既不会无限膨胀，也不会在需要解释时缺关键依据。
