结论先说:不是把所有原始文件都封存,也不是只留一份结案报告。可执行的粒度是“能独立复原关键判断和账户状态”这一层:账户结构快照、关键词与出价决策记录、素材版本与审核结果、转化跟踪配置、以及一份能解释这些数据来源的说明。更细的日志、临时表格和中间稿,除非合同或合规另有要求,通常可以按保留期限清理。
很多团队在百度推广外包结束时,会把外包方交付的报表、截图、批量表、聊天记录全部归档,觉得“留着总没错”。但几个月后要复盘或接手时,常见的情况是:文件夹里有几十个版本的报表,却没人能说清当时为什么停掉某组词、为什么把预算挪到另一个计划、某次落地页改动对应哪一批创意。文件数量增加了,可追溯性反而下降。
这背后有两种合理解释。第一种是保留粒度选错了:把“过程产物”当成了“决策依据”,存的是中间稿而不是结论及其上下文。第二种是交接时缺少索引:文件本身齐全,但没有说明哪个版本对应哪个时间段、哪次调整由谁批准。两种情况的处理方式不同,所以先别急着补文件,先判断你遇到的是哪一种。
找一次真实的复盘需求来测试,比如要解释某个季度转化成本的变化。让接手的人只打开归档目录,限时回答:当时的账户结构是什么样、哪次调整发生在成本变化之前、这个调整的依据来自哪份数据。如果能顺畅回答,说明问题只是索引不够;如果连账户结构都要翻多个版本才能拼出来,说明保留粒度本身太碎。
假设一个场景:外包结束后半年,内部要评估是否重启某类关键词。如果归档里只有月度消费报表,没有当时的关键词级出价与匹配方式记录,那么重启决策只能重新测试,历史投入无法复用。反过来,如果保留了账户结构快照和调整日志,就能先判断当年停投是因为成本还是因为线索质量,再决定要不要用同样口径重试。这个判断结果直接决定下一步是“复用旧结构小预算验证”还是“完全重做账户”。
把归档分成四类,每类给出最低保留要求,比笼统规定“保留全部”更容易执行。
一个实际动作:在归档前做一次“盲测交接”,让没参与项目的人只凭归档回答上面的三个问题,记录他卡在哪一步。卡在账户结构,就补状态导出;卡在调整原因,就补决策日志;卡在数据口径,就补配置说明。这个动作的结果会直接告诉你哪一类粒度不够,而不是平均地增加所有文件的保留量。
临时批量表、重复导出的报表、聊天记录中的文件传输、未采用的创意草稿,通常不属于必须长期保留的粒度。保留期限不要拍脑袋定一个数字,而是按用途倒推:如果历史数据只用于年度复盘,保留到下一次同口径复盘完成即可;如果涉及合同结算或合规要求,以合同约定为准;如果没有明确要求,可以设一个内部复核节点,到期前抽查一次是否还有引用需求,再决定续留或清理。
需要提醒的是,某项统计归零或某个报表不再更新,不能单独证明归档已经完整或清理正确。它也可能只是导出遗漏、权限变化或口径调整造成的。判断依据仍然是“能否复原关键判断”,而不是某个数字是否还在。
更稳的做法是在外包合作结束前,就把归档粒度写进交接清单:由外包方按上述四类交付,内部指定一人验收盲测。验收通过再结清尾款或确认退出,比项目结束后再回头找文件更省力。粒度定在“能复原判断”这一层,既不会因为存得太碎而无法使用,也不会因为只留结案报告而丢掉关键依据。