交接期间的可追溯性,靠的不是一份最终截图,而是一条能还原“谁在何时为什么改了什么”的记录链。最稳妥的做法是:交接前冻结改动范围,交接中只通过共享日志记录变更,交接后再开放批量操作。如果代理方拒绝留下操作记录,或者账户后台无法导出变更历史,就应该把交接拆成只读核对与写权限移交两步,而不是一次性交完。
不是所有操作都值得进入交接记录。判断标准是:这个改动会不会影响后续投放决策,或者会不会让接手方误判账户现状。
一个实际动作:交接启动时,先在共享文档里建一张变更登记表,字段至少包含时间、操作人、对象层级、改动前后值、原因、是否已通知接手方。登记表由交出方填写,接手方每次核对后在同一行补一句确认。这个动作的结果是:后续出现效果波动时,能先分清是交接前遗留、交接中误改,还是接手后的新决策,而不是一上来就互相归因。
这三个选择对应不同的前提,不需要同时做。
保留原始记录适用于账户后台本身能导出较完整的变更历史,且双方都还能登录。此时不要急着整理成漂亮报告,先把原始导出按日期归档,保留字段原样。原始记录的价值在于它不带解释,日后出现争议时可以回溯。缺点是它只说明“改了什么”,不说明“为什么”。
改写为决策日志适用于后台历史不完整、导出字段缺失,或者代理方即将失去账户访问权。这时要把能拿到的操作记录与当时的沟通记录对齐,写成一条条带原因的条目。改写会引入主观判断,所以每条都要标注依据来源,例如“依据某次邮件确认”或“依据会议纪要”。如果找不到依据,就如实写“原因待确认”,不要补一个看起来合理的解释。
直接退出适用于两种情况:一是代理方无法提供任何可核对的操作记录,且拒绝配合只读核对;二是账户内存在大量无法解释的历史改动,继续交接只会把风险转移到接手方。退出的动作不是删账户,而是先撤销写权限、保留只读权限,把已确认的变更清单固定下来,再决定是否重新搭建账户结构。这个动作的结果是:把不可追溯的部分隔离在旧账户里,新账户从干净状态开始,代价是历史数据连续性会中断。
批量操作在后台往往只留一条汇总记录,看不到具体增删了哪些词或人群。如果交接期必须做这类调整,先导出改动前的完整列表,改完再导出一次,两次导出作为附件挂在变更登记表上。不要只写“优化了否定词”。
这类改动会直接改变后续数据的含义。交接期间如果必须调整,要在登记表里同时记录旧设置、新设置和生效时间点,并注明“此前数据按旧口径,此后按新口径”。否则接手方会把口径变化误读成效果变化。
交接期最常见的追溯性丢失,是交出方和接手方同时能改,事后分不清是谁操作的。可行做法是设一个短暂的只读窗口:先由交出方完成约定内的最后调整,再把写权限移交给接手方,中间留出一段双方都不做批量改动的核对期。核对期内只允许记录,不允许优化。
交接结束时,不要问“记录全不全”,而是做一次可还原测试。假设一个月后有人问“某个广告系列为什么在交接期间被暂停”,你能否在不询问任何当事人的情况下,从记录里找到时间、操作人和原因?如果找不到,说明追溯链有断点。
可以按下面顺序核对:
如果第2条或第4条不成立,优先补的是导出文件和权限时间线,而不是继续美化文档。如果第5条不成立,说明记录写得再全也没有完成交接,需要让接手方用自己的话复述一遍关键变更,复述不一致的地方就是下一轮要补的证据。
可追溯性不是交接的附加项,而是完成条件之一。比较稳妥的约定是:写权限移交前,双方确认变更登记表已覆盖约定范围内的所有关键改动;写权限移交后,接手方在约定周期内只做记录、不做批量优化,直到能独立还原上一阶段的主要变更。这个约定不保证投放效果,也不替代平台官方的操作日志,但它能让交接期间的变化有据可查,减少后续把口径变化误判为效果变化的情况。