ConnectWiz + Meta Conversions API
已上线的集成带来这场对话的那条广告，终于知道它是怎么收场的
如果没人告诉 Meta 什么算转化，消息类广告就只能闭着眼睛优化。ConnectWiz 会把赢下的商机作为 Purchase 事件上报——带真实金额，也带各渠道各自正确的身份标识——送进你自己的 Events Manager 数据集，前面设四道闸门，每一次拒绝都记在案。
广告
它到底能做什么
商机变成信号
赢下一个商机，就上报一次带真实金额的 Purchase；进入一个映射好的阶段，就触发你指定的事件——无论走哪条路径：界面、自动化还是导入。
身份标识做对了
WhatsApp 用点击 ID，Messenger 用页面范围的用户 ID，Instagram 用它自己的——每个渠道都用该用的那个匹配键，并按 Meta 规定的方式做哈希。
四道闸门，一个出口
租户开了吗？同意允许用于广告定向吗？事件格式合法、能匹配上吗？是不是已经发过了？每一次拒绝都带原因记录在案——可审计，而不是一团谜。
一块健康面板
看得见发出去了什么、拒掉了什么，以及为什么——这套转化管道是真能被检查的。
Meta 自己的事件，回声也处理得对
Meta 在会话内识别到的购买会被回传，金额按 Meta 自己的计数单位解码，事件 ID 则由那条消息推导而来——所以 Webhook 重试会被折叠掉，而不是记成第二笔成交。金额未知时干脆不带金额：一个假的 0 会告诉 Meta 这次转化一文不值。
格式合法与否，都说得出名字
事件在发出前先做校验——名称长度、时间戳是不是未来或过期、参数预算、能不能匹配上——每一项不合规都会以具名拒绝写进日志，而不是一笔糊涂账。
技术细节
转化管道，用小心的做法铺
为什么事件名是固定的
一个 Meta 数据集永久接受 1,000 个不同的事件名——它们删不掉，超过上限之后新的事件干脆不再记录。所以事件名取自一份固定词表，变化放在参数里，那才是它该待的地方。
确定性的事件 ID
每个事件的 ID 都由它所描述的内容推导出来，而不是随机生成——所以重试会产生同一个 ID 并被去重，不会把同一笔成交算两遍。用随机数就等于把整套机制废掉。
Meta 接收之后才标记为已发送
本地去重记录是在 Meta 接收之后才写的，绝不会提前——网络出错会重试，不会把自己压成一次丢失的转化。
和 Meta 完全一致的归一化
邮箱转小写，但 Gmail 的点和 + 标签都保留——因为 Meta 就是这么做的。电话号码必须能解析成带国家码的 8–15 位数字；没有国家码的本地号码直接丢弃，绝不瞎猜。丢掉一个键，代价是少一次匹配；用错一个键，代价是配错一个人。
各渠道的身份标识，精确到位
WhatsApp 事件带点击 ID 加电话——有些版位本来就没有点击 ID，这时电话还在。Messenger 的身份必须是主页加页面范围用户 ID 一起才算数；Instagram 用它自己的范围内 ID；线索事件带平台自己的 lead ID，且仅限来源为 Meta 的线索。
一块对自己的算法负责的健康面板
新鲜度、事件频次、强匹配键覆盖率、购买金额，以及每一条拒绝原因——都按 28 天窗口统计，并明确标注这是我们自己的测量结果，因为把我们的算法说成 Meta 的评分，等于凭空给自己发一张不存在的权威证书。
接入设置
连接方式
粘贴你的数据集
你的 Events Manager 数据集 ID 和令牌——加密存储，归你所有，随时可吊销。
映射你的阶段
选定哪些管道阶段触发哪些转化事件。
赢下商机
上报会自己完成——过闸门、去重、写日志。
安全与保证
无聊但管用的保证
你的数据集，你的令牌
事件发往你从自己的 Events Manager 里粘贴过来的那个数据集——访问令牌加密存储，永远不会再显示出来。数据关系存在于你的企业和 Meta 之间。
同意是一道闸门，不是一个设置项
只有当联系人的同意允许用于广告定向时，事件才会发出——还没走完二次确认的不算，而且这次拒绝会具名记录在案。
测试模式是看得见的
忘了删掉的测试事件码会悄悄让真实转化不再计数——所以测试模式在面板里是一个独立的显式标记，不可能在你看不见的地方被忘掉。
重复计数这个问题，我们会问
如果你已经在跑 CAPI 或 Signals Gateway，这边再发一份就会重复计数——同一笔成交用了两个不同的 ID，去重救不了。面板会主动问；你不回答，它就给出警告，而不是替你假设。
不加粉饰的细则
边界，写清楚
身份绝不靠猜
没有国家码的电话号码会被丢弃，而不是猜出来——一次错误匹配花的是别人的隐私。没有金额的商机则什么都不发，绝不用一个假的 0 顶上。
关着也是一种正当状态
整个集成出厂时是关着的；关着不是什么降级模式。你的广告数据只在你决定让它走的时候才走。