消息事件集掉线没提示，每周巡检该记哪几项

做 TikTok 广告、把客户接到 WhatsApp 里谈的团队，大概都遇到过这种事：某天翻报表，发现对话数比前一周少了一截，广告花费没变、点击也没少，就是聊天那边安静了。查了一圈，最后发现是数据源断开了，或者中转工具的授权过期了。

麻烦在于，这类断开多半不会弹一条醒目的提示。广告后台照常花钱，落地页照常跳，客户照常发消息，只有「对话有没有被记下来」这一格悄悄空了。等月底发现数对不上，往回查往往已经跑了两三周，那段时间的投放数据也没法补。

这篇给一份能直接照着做的每周巡检清单：六项各看什么、按什么顺序、记录怎么留、谁来签字。TikTok 消息事件集本身不负责提醒，桥梁通不通要靠人定期去看。文中涉及的后台路径与界面名称，以官方当前公示为准。

一、掉线为什么不容易被发现

先把这条桥拆成三截：号码、中转工具、广告后台的事件管理器。客户发来的第一句，要经过中转工具回传给广告平台，广告侧才拿得到「对话」这个事件。三截里任何一截松了，回传就断。

松了之后，前台几乎没变化。客户照样能进 WhatsApp，客服照样能回话，收件箱里照样有新消息。变的只有广告后台那一列数字——从某个时间点开始变少，或者干脆不涨。

更隐蔽的是「部分断」。某个号码断了、别的号码还好，汇总数看起来只是小幅波动，容易被当成素材波动或者工作日差异。多号码团队尤其容易中招。

所以别指望有人主动来报故障。这一层没声音，就得排一个固定的时间去主动看。每周一次，比出事之后花半天倒查划算得多。

二、巡检不是出事后的排查

这两件事顺序不同、目的也不同。排查是发现异常之后往回找原因，从现象出发；巡检是还没出现异常时，逐项确认桥还通着，从结构出发。

排查通常按「先查桥、再查配置」的顺序：数据源状态、号码有没有换、授权有没有过期、数据源类型是不是选错，然后再看广告组里有没有选中事件集。这个顺序在「未连接怎么办」那类文章里已经写得很清楚，六处逐一排查可以照着走。

巡检不一样，它不假设哪里坏了，六项逐个过一遍，每项记一个「正常 / 异常 / 待观察」。哪怕这周全正常，记录也要留下来——下次出问题时，最后一份全正常的记录就是分界点，能直接把故障范围框在七天以内。

还有个区别：巡检要能交给别人做。写清楚看哪个页面、看哪个字段、什么算通过，换个人也能照着打勾。排查靠经验，巡检靠清单，两者别混在一张表里。

三、第一项：数据源状态

进事件管理器，找到消息类型的数据源，看状态和最近一次事件时间。状态显示已连接，只说明桥通着；还要确认最近确实有事件进来，别只看那四个字。

「最近一次事件」比状态更有用。状态可能还挂在已连接，但事件已经好几天没回了，这种半通不通的情况，光看状态会漏。取数时把日期记下来，和上周那份记录比一下。

如果最近一次事件停在几天前，先别急着改配置。事件回传有延迟，但延迟以分钟计，不会以天计。真停了几天，多半是授权、号码或者绑定关系出了问题，按第四、第五项往下查。

回传数据对不上时先查哪三处，这篇给过顺序，巡检时可以直接拿来当第二层检查表。第一层看「有没有」，第二层才看「准不准」。

四、第二项：号码绑定关系

核对当前在用的 WhatsApp 号码，和建事件集时绑定的那个是不是同一个。号码换过、或者临时拿另一个号顶过几天，是常见的人为变动，交接单上不写就没人知道。

再看这个号码是不是还挂在别的应用上。消息事件集按「广告账户 + 号码」配对生成，认的是这条对应关系。号码同时挂在个人应用或者多个账户上混着用，记出来的数就对不上。

多市场团队要按号码逐个核，别只看主号。某个市场的号断了，汇总数只是小幅往下，很容易被当成正常波动。每个号码单独记一行，出问题时才能一眼看出断的是哪一个。

这项的记录要写具体：核了哪几个号、每个号当前状态、有没有近期变更。写「号码正常」四个字没用，出事时没法回溯。

五、第三项：中转工具授权

号码和广告账户之间需要一层中转，由它把对话事件回传给广告平台。授权是这层桥的凭证，过期或者被管理员改过权限，桥就断了。

巡检时看三样：授权是否还在有效期、管理员账号有没有人员变动、工具后台里能不能看到近期回传日志。第三样最实在，日志里有记录，说明这段确实在跑。

人员变动容易被忽略。同事离职、账号回收、权限重新分配，这些事通常发生在行政流程里，不会有人想到要通知投放同事。把「管理员账号是否有变动」写进清单，就是给这类变动留一个入口。

授权出问题时的表现，和号码出问题很像：前台一切正常，广告侧悄悄没数。所以这几项要连着看，别查到一个「已连接」就收工。

六、第四项：广告组选中的事件集

进广告组，确认优化位置、目的地和选中的事件集，跟建事件集时记下的那一条对得上。账户里同时跑着几组广告、或者中途复制过广告组，很容易出现「新复制的那组没选事件集」。

尤其留意从点击目标切到对话目标那段过渡期。老组还在按点击跑、新组按对话跑，两边混着，巡检时要分别记，别拿一组的结论套到全部。

还要看数据源类型是不是选成了网页而不是消息。这个错在初次配置时常见，改版或者重建数据源后也可能复发。类型选错，后面广告组里就选不到事件集，或者选到了也不回事件。

这项的记录按广告组写：组名、目标、优化事件、选中的事件集、是否正常。一行一组，出问题时能直接查到哪一组、哪一天开始不对。

七、第五项：报表列和回传延迟

在广告后台自定义列里，把「对话（即时通讯应用）」调出来，确认这一列还在、数字和上周记录对得上。列被别人改掉、或者视图被重置，也会造成「以为没数」的假故障。

然后看时间。事件回传不是即时的，刚走完真机测试那一两分钟看不到数，属于正常。巡检时记下取数的具体时间点，和最近一次事件时间放一起，别把延迟当成断连。

每天该看哪几个数，这篇列过一遍，巡检可以拿它当列名基准，但频率不同：日报看趋势，周报看结构是否还完整。

这项还顺带管一件事：报表口径有没有被人改过。统计周期、按号码还是按账户分组、免费额度算在哪一列，只要有人动过，前后两周的数字就没法直接比。改动要记在巡检表的备注里。

八、第六项：预填消息与首句

最后一项回到客户那一侧：广告层写的预填首句，现在是不是原样出现在输入框里。素材换版、广告组复制、目的地重选，都可能把这句话带歪或者清空。

用真机从预览入口走一遍，看三件事：能不能自动进 WhatsApp、打开的是不是绑定的那个号、预填内容有没有被改写。改了字不影响事件本身，但会让工作台里那条消息认不出来源。

再测「不点发送直接退出」这一种：数据源下应该查不到这次事件。三种测法合起来，才能说明「对话开始」这一环真的通着。上线前那八个验收动作，这份清单可以复用。

我们内部用 TK获客宝 把工作台那一侧的对话按来源归到同一处，巡检时对照收件箱和广告后台会省一点手工。但归好只是让数字摆得齐，桥通不通还得一项项去看，工具不替你签字。

九、巡检记录怎么留、谁来签字

一张表就够：日期、执行人、六项各自的结果（正常 / 异常 / 待观察）、最近一次事件时间、本周变更备注、复核人。不用做系统，一个固定文件存着，按周追加。

「本周变更备注」是最容易被省掉、也最有用的一栏。换过号码、换过素材、加过广告组、有人离职、权限调整，都写一行。出事时先翻这一栏，能省掉大半排查时间。

签字这件事别省。执行人和复核人分开，一个人看、另一个人抽两项复看，比一个人从头到尾打勾可靠。人少也要留名字，不是为了追责，是为了下次有人能问「那天是谁看的」。

异常项要写清后续：谁跟进、什么时候再看一次、有没有临时动作。只写「异常」不写后续，等于没记。全正常的那一周也要存档，它就是下次故障的时间分界点。

十、写在后面

交代一下背景：这篇是广州市宝晨科技文化传媒有限公司整理的，我们做的产品叫 TK获客宝，平时接触的团队大多在跑 TikTok 广告，把来咨询的人接到 WhatsApp 里继续谈。写这份巡检清单，不是要推什么方法，是这两个月反复看到同一件事：配置那一层大家越做越熟，桥什么时候松的却常常没人说得清。

TikTok 消息事件集能补上「对话有没有开始」这一格，桥通不通、窗口里有没有人接，仍然要团队自己定期去看、自己排班。工具只负责记，接不接得住是人的事。各家账户结构、号码数量、市场费率和排班都不一样，上面这六项只当一份自查顺序看，别照搬。

本文所述后台路径、界面名称与计费规则，以官方当前公示为准；不同账户、不同市场的可见项与费率可能有差异。