增长时间线：每次预算改动自动落库为事件
摘要
我们把每次优化动作（预算、出价、状态、关键词、否定词、广告推送）自动落库为带时间戳的事件，含实体、字段、旧值与新值——并曾因 32 位整数溢出静默丢失 3 条事件，后将列加宽为 64 位。
快速答案
定义事件字段（实体、字段、旧值、新值、时间戳），在每个写操作处埋点，让预算、出价、状态、关键词、否定词与广告推送自动落库，并用明确的已记入提示确认关键操作。事件 ID 要用 64 位——我们曾因 32 位溢出丢失 3 条事件——再把时间线与每日快照搭配做因果复盘。
有一个问题，我们很多年都答不上来：上个月，我们到底对这个账户做了什么？预算改过、出价调过、关键词暂停过、否定词加过。每一次改动在当时都有理由——可真到某个指标波动时，我们却拿不出一份可靠的改动序列记录。
问题：操作是不可见的
当多个人共同优化一个账户时，改动散落在各处：Ads 界面、电子表格、聊天记录、记忆力。问一句我们改了什么、什么时候改的，得到的只有耸肩。没有记录，因果就全靠猜——你没法把一个结果归因于一件无法证明其发生的动作。
方案：事件时间线
我们搭了一条时间线：每次优化动作都变成一条带时间戳的增长事件。预算调整、出价调整、状态切换、关键词编辑、否定词添加、广告推送——每一条都记录实体、字段，以及旧值和新值。而对涉及花钱或改变结构的操作，执行后会明确提示：已记入时间线。
设计里有两个用代价换来的细节。第一，事件 ID 的类型必须够大。我们曾因 32 位整数溢出静默丢失 3 条事件，后来把列加宽到 64 位才解决——这是一种只有在你最需要记录时才显现的隐蔽 Bug。第二，每条事件都带快照上下文，让单条事件永远不会被孤立地解读。
时间线给你什么
从此每个操作都可回放、可审计、可归因。转化指标跳升或下跌时，我们可以沿时间线走一遍：预算是在这时改的、关键词是在这时暂停的、这是之后的走势。配合每日状态快照，时间线成为因果推理与实验评估的输入——改了什么、结果如何，这个问题终于有了带证据的答案。它还把团队里常见的争执变成一次查询：不用再争论上周到底有没有动过这个广告系列，打开时间线，就能读到完整的操作序列。
可复用清单
- 定义事件类型与字段。实体、字段、旧值、新值、时间戳。
- 在每个写操作处埋点。预算、出价、状态、关键词、否定词、广告。
- 关键操作给出明确确认。花钱与结构改动都要有已记入的提示。
- 时间线与每日快照搭配。事件说明改了什么，快照说明结果如何。
这条时间线正是我们 iport 归因增长引擎的事件底座——每次优化都自动成为记录的一部分。
常见问题
为什么 32 位事件 ID 会丢数据？
当 ID 计数器超出 32 位范围时，写入是静默失败的，而不是显式报错——3 条事件就这样无声消失。把列加宽到 64 位后不再有上限；教训是：标识符要按长期规模设计，因为溢出总是悄悄失败。
事件到底应该记录什么？
至少要记录实体（哪个账户、广告系列或关键词）、被改的字段、旧值与新值，以及时间戳。有了这些，记录本身就自洽：你可以完整回放发生过什么，而不用去问任何人。
事件与快照如何配合？
事件回答改了什么、何时改的，快照回答结果如何。时间线事件解释指标为何如此变动，每日快照则确认对指标的实际影响——两者结合，把观察变成因果分析。