推广网服务，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4e7e73fa2385.html
📄
推广网服务，项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不按“文档类型”决定，而按“下一次可能重新打开它的理由”决定。凡是能被独立复核、独立追责或独立复用的最小单元，就要保留到该单元；只有汇总意义、无法回溯到单元的总表，保留价值很低。你可以拿手边一份项目结案包来对照：里面若只有一份《月度汇总.xlsx》，而删掉了每月的原始投放记录、修改记录和验收记录，那么三个月后有人问“某条素材为什么被换掉”，你无法回答，这份汇总就只是结论，不是档案。
先分清三种保留粒度，而不是笼统说“全部留着”
把历史文档拆成三层，比按文件夹分类更实用。
- 结论层：结案报告、验收单、最终版方案。作用是回答“当时定了什么”。
- 依据层：原始数据导出、素材版本、修改批注、沟通记录。作用是回答“为什么这么定”。
- 过程层：草稿、临时截图、重复的中间稿。作用是回答“怎么一步步走到这里”，多数情况下可以只留关键节点。
粒度边界就落在这里：结论层必须完整保留；依据层保留到“能支撑一次复核”即可；过程层只留发生方向性变化的节点。假设一个推广项目换了三次主视觉，那么三个定稿版本和每次更换的决策记录要留，但每个版本内部被否掉的十几张草稿不必全留——除非客户明确要求可回溯全部提案。
用“能不能独立核对”判断一份文档该留多细
判断标准不是文档数量，而是它能否被一个不在场的人独立核对。做法很简单：把文档交给没参与项目的同事，让他回答三个问题——这条结论对应哪份原始记录、这份记录对应哪个时间点、这个时间点由谁确认。三个问题都能答上，粒度就够了；有一个答不上，就说明还需要下沉一层。
常见误区是只留最终版报表。报表里的数字经过汇总和口径调整，一旦有人对某个数字有疑问，无法反查。更稳妥的做法是：汇总表保留，同时保留生成它的原始导出文件和口径说明。口径说明哪怕只有几行，也决定了这份数据半年后还能不能被正确理解。
把分歧转成可核对项目的具体动作
多个角色对“该留什么”有分歧时，不要开会争论，直接做一次核对演练。选一个已经结束的推广项目，让运营、设计、客户对接三方各自写下“如果三个月后要重做这个项目，我会先找哪三份文件”。把三份清单并排放，重合的部分就是必须保留的核心粒度；只有一方提到的，标记为可选；三方都没提到的，可以进入清理候选。
这个动作的结果会直接影响下一步：如果三方清单重合度很低，说明项目过程中缺少统一的归档约定，需要先补一份归档说明，再谈清理；如果重合度高，就可以按清单执行保留与删除，并把清单作为下一个项目的归档模板。注意，这里比较的是“文件用途”而不是“文件数量”，数量多少不说明粒度对错。
一个注明假设的短例子
假设某推广项目结束后，团队只保留了一份结案PPT和一份总花费表。半年后客户要求说明某月预算调整的原因。此时能查到的只有“调整后金额”，查不到调整依据。要避免这种情况，结案时至少保留：该月的原始投放记录、预算变更的沟通记录、变更后的确认记录。这三份对应“依据层”的最小单元。若当时没有留存，事后无法补造，只能在下一个项目里把这三类记录设为结案必交项。
反过来，如果结案包里已经包含上述三类记录，就不必再保留每一版被否决的草稿。粒度判断的标准始终是“能否独立核对”，而不是“留得越多越安全”。留得过多会拖慢查找，留得过少会失去复核能力，两者都是成本。
执行时先定保留期限，再定清理动作
粒度确定后，期限才有意义。建议按用途分档：结论层长期保留；依据层保留到项目结束后一个可复核周期，例如覆盖下一次同类项目的启动阶段；过程层在结案验收后即可清理。清理前做一次抽样核对：随机抽三条结论，看能否在依据层找到对应记录。抽样通过再执行删除；抽样不通过，先补记录再清理。
最后提醒一点：请求量、抓取量或某项统计归零，不能单独证明归档处理正确。归零可能来自口径变化、统计范围调整或数据源中断，需要结合原始记录判断。把归档粒度定在“可独立核对”这一层，后续无论谁来接手，都能从结论回到依据，而不是只看到一份无法追问的汇总。
