针对餐厅的 Meta Conversions API 集成：将广告效果对比实际到店访客
您将能够决定是否将经过许可的宾客 WiFi 到店数据发送至 Meta 的 Conversions API，并通过六个步骤完成配置。本指南涵盖了同意机制、哈希处理、去重和每日批处理。同时展示了如何按营销活动读取每次到店成本，以及何时应当开展提升度研究（lift study）。
将 Meta Conversions API 与访客 WiFi 集成，可让餐厅在符合 GDPR 标准的前提下，根据广告支出衡量线下到店情况。通过在 80,000 多家场所传输哈希处理后的 SHA-256 登录记录，运营人员能够将实体店顾客直接归因于特定营销活动，打破仅靠线上预订评估的局限，精准追踪真实的广告投入回报率。
Meta Conversions API 能为餐厅带来什么？
Meta 会根据其能监测到的事件来评估广告效果。对大多数餐厅而言，这些事件指的是网站上的 Pixel 事件：例如完成预订、查看菜单或下载优惠券。如果某位食客看到了您的广告，但跳过了网站直接入店用餐，系统就无法记录这一行为。然而，这种实体到店才是您付费推广的最终目的。
Conversions API (CAPI) 是 Meta 的服务器到服务器连接服务。您的系统可以直接向 Meta 发送事件，而无需依赖浏览器中的脚本。Meta 官方文档提供了对网站、应用和线下事件的支持。线下事件包括对实体场所的访问，并带有标记为 "physical_store" 的操作来源。
为什么仅靠 Pixel 报告会低估餐厅效果
广告实际取得的成果与 Ads Manager 报告的数据之间存在三大差距。
- 访问发生在线下。 Meta Pixel 仅能在浏览器中的自带网页上运行。对于散客到店、电话预订或通过第三方平台进行的预订，Pixel 无法记录任何事件。
- 浏览器丢弃事件。 Meta 官方指南指出，Conversions API 可以减少因浏览器加载错误、网络连接问题和广告拦截程序造成的数据丢失。
- 设备隐私设置限制信号采集。 自 iOS 14.5 推出以来，Apple 要求应用在使用跨其他公司应用和网站的活动数据前必须获得许可。许多用户选择拒绝，这就削弱了 Pixel 原本依赖的信号。
其代价不仅仅是报告数据的偏差。Meta 的投放系统会针对产生已知事件的人群进行优化。如果系统只能接收到线上预订事件，预算就会偏向那些习惯在线预订的人群。而那些能够带来大量散客到店的营销活动看起来成本极高，从而面临被暂停的命运。
当到店数据同步至 Meta 时会发生什么变化
对于每位同意授权并登录 WiFi 的访客，您可以发送一条到店事件，其中包含经过哈希处理的电子邮箱或电话号码以及时间戳。Meta 会尽可能将该事件与其用户账号进行匹配。然后，Meta 会在您的归因设置范围内，针对他们看到或点击过的任何广告报告此次到店。如此一来，您就能按营销活动获取每次到店成本，而不仅仅是每次预订成本。
难点并不在于 API 本身，而在于获取一份可靠且经过授权的到店记录，明确谁在何时光临过。Mailchimp、Klaviyo 和 HubSpot 等电子邮件平台只能向您现有的列表发送营销活动，却无法记录食客是否真正踏入了您的店门。访客 WiFi 则能做到这一点：每一次登录都是一条带有时间戳的一方到店记录，并附有访客的同意授权选项。在 Purple 超过 80,000 个上线场所中，访客在 2024 年登录了 4.4 亿次（Purple 数据）。这就是进行到店衡量的基础数据。
在开始使用 Conversions API 之前需要准备什么？
在编写代码或连接集成之前，请先准备好以下七项内容。
- 具有管理员权限的 Meta 商业资产组合，以及广告报告所对应的数据集。Meta 现在使用“数据集”来指代以前称为 Pixel ID 的内容。
- Conversions API 访问令牌，在 Meta 事件管理器中针对该数据集生成。
- 发送服务端事件的方式。 这意味着您需要自己的开发人员、Meta 合作伙伴集成，或者带有 Meta 连接器的 CRM 或客户数据平台。
- 获得同意的到店数据。 您需要包含电子邮箱或电话、时间戳、场馆和同意状态的 Guest WiFi 登录记录。Purple Engage 会将这些保存为根据每次登录构建的访客档案。
- 合法依据和更新后的隐私声明。 根据 GDPR 第 6 条，与 Meta 共享数据需要具备合法依据。对于广告效果衡量，这通常是同意，且必须满足第 7 条中的条件。
- 对“到店”的统一定义。 确定计数标准：每个场馆每天每位访客登录一次，排除员工。
- 基线数据。 导出每个营销活动四周的仅限 Pixel 的结果，以便比较前后效果。
关于第五项，请阅读欧洲数据保护委员会关于社交媒体用户定向投放的 8/2020 指南。指南阐述了广告主和平台在某些数据处理中如何成为共同数据控制者。Meta 的商业工具条款也列出了您在发送数据时的义务。在第一个事件从您的服务器发出之前，您的数据保护负责人应批准这两项内容。
如何将 Guest WiFi 到店数据连接到 Conversions API？
设置分为六个步骤。Meta 的开发者文档涵盖了技术细节；本节将涵盖由您主导的决策。
1. 在 WiFi 登录时获取同意
您的 WiFi 登录页面是获取同意的起点。请将广告效果衡量同意与电子邮件营销同意分开请求。GDPR 序言第 32 条明确规定，沉默和预先打勾的框不视为同意。出于这个原因，Purple 采用明确选择的同意机制：访客主动做出选择，且该选择会与档案一起存储。
请使用简明易懂的语言编写文案。例如：“允许我们与 Meta 共享加密版本的电子邮箱，以便我们了解广告是否吸引您来到这里。” 一句清晰的话比一个政策链接能赢得更多的同意。
2. 定义到店事件
Meta 的标准事件不包含餐厅到店，因此大多数场馆会创建一个自定义事件。给它起一个直观的名称，例如“VenueVisit”。即使访客登录了三次，每个访客、每个场馆、每天也只发送一个事件。排除员工设备以及每周登录超过四天的任何访客（这通常意味着是员工）。
3. 准备并哈希处理匹配数据
Meta 要求在发送前使用 SHA-256 对电子邮箱和电话等个人身份标识符进行规范化和哈希处理。规范化意味着清除空格、将电子邮箱转为小写并在电话号码中添加国家/地区代码。规范化做得不完善是匹配失败的最常见原因。
每个事件还需要一个事件时间、操作来源 "physical_store" 以及唯一的事件 ID。仅发送 Meta 列出的参数。诸如 MAC 地址之类的网络标识符不属于其中，绝不应离开您的系统。
4. 按每日批次发送事件
Meta 会拒绝超出其文档规定时间窗口的事件，因此切勿让事件积压一周。至少安排每日一次批次发送，并在构建时检查 Meta 文档中的当前时间限制。每日发送还能使 Ads Manager 的数据保持足够实时，以便进行每周广告系列复盘。
5. 在上线前进行测试
Meta 在 Events Manager 内部提供的 Test Events 工具，可以在您携带测试代码发送事件时实时显示到达的事件。请先发送少量已知的访问数据。在切换到实时发送之前，请确认事件名称、时间和操作来源均显示正确。
6. 构建自定义转化并将其添加至报告中
根据您的访问事件创建自定义转化，然后将其作为一列添加到 Ads Manager 中。您现在可以逐个广告系列对比查看单次访问成本与单次预订成本。
您应该向 Meta 发送什么数据，以及何时发送？
从细微处入手。一个干净的访问事件比五个杂乱的事件能带来更多启发。仅在第一个事件匹配良好且您的团队信任该数据时，再添加更多事件。
| 事件 | 数据来源 | 发送的匹配数据 | 何时发送 | 它能告诉您什么 |
|---|---|---|---|---|
| VenueVisit（自定义） | 访客 WiFi 登录，仅限同意的访客 | 哈希处理后的电子邮件、哈希处理后的电话、事件时间、场地 | 每日批次 | 按广告系列计算的单次访问成本 |
| ReturnVisit（自定义） | 30 天内的第二次 WiFi 登录 | 哈希处理后的电子邮件、哈希处理后的电话、事件时间、场地 | 每日批次 | 广告是否能吸引人们再次光顾，而非仅光顾一次 |
| Purchase（标准） | 关联到该访客的收银机或 EPOS 记录 | 哈希处理后的电子邮件、价值、币种、事件时间 | 每日批次 | 归因于广告的收入 |
| Schedule（标准） | 在线预订系统 | 哈希处理后的电子邮件、事件时间、与 Pixel 共享的事件 ID | 一小时内 | 从浏览器数据丢失中挽回的预订 |
| 两条规则适用于每一行。首先，仅发送给予了广告测量同意的访客数据，并在他们撤回同意的时刻立即停止发送。其次，当 Pixel 和服务器同时报告同一个 Web 事件时，请使用相同的事件名称和事件 ID。Meta 会利用该组合进行去重，因此预订不会被重复计算。 |
二次光顾事件对 CRM 总监最为重要。来自广告的首次访问很有价值。而在 30 天内的二次光顾表明，该广告开启了一段可以借助您的电子邮件和短信营销计划继续深入的关系。对于后续跟进渠道，您可以在 WhatsApp 与 SMS 在餐厅营销中的对比：成本与覆盖面比较 中对比成本。
哪种衡量方法适合您的餐厅？
服务端访问事件并不是衡量付费社交媒体的唯一方法。正确的选择取决于您的食客在哪里进行转化以及您掌握哪些数据。
| 方法 | 识别内容 | 统计到店访客 | 所需数据 | 配置工作量 | 适用对象 |
|---|---|---|---|---|---|
| 仅 Meta Pixel | 浏览器中的网站事件 | 否 | 预订和菜单页面上的 Pixel | 低：网站上只需添加一个标签 | |
| 大部分客流通过在线预订的场地 | |||||
| Pixel 加 CAPI 网页事件 | 网站事件，并弥补浏览器丢失的数据 | 否 | Pixel、服务器访问权限、共享事件 ID | 中：合作伙伴集成或开发人员配置 | 在线预订量大的连锁集团 |
| CAPI 结合宾客 WiFi 进店事件 | 网页事件加上已授权的到店访客 | 是，针对已授权的 WiFi 宾客 | 包含邮箱或电话的已授权登录记录 | 中至高：授权审查、哈希处理、每日发送 | 拥有大量到店自来客的餐厅、酒吧和酒店 |
| Meta 转化提升实验 | 通过测试组和对照组分析由广告带来的增量访客 | 是，使用您发送的进店事件 | 进店事件加足够的预算和数据量用于测试 | 高：需计划并进行数周的测试 | 正在测试付费社交广告是否真正有效的集团 |
将此表格作为决策参考路径。如果通过在线预订的客流不足一半，仅靠 Pixel 报告会遗漏大部分结果，因此应优先考虑进店事件。如果您已经发送了进店事件，而财务团队仍对付费社交广告存疑，请运行转化提升实验。归因分析会告诉您谁在看到广告后进行了到店；而提升实验则会告诉您谁是因为广告才来进行到店的。
两个实际应用场景
以下数据为用于演示该方法的说明性计算，并非具体某个场地的实际报告结果。
场景 1：一家拥有 12 家分店的休闲餐饮集团推广午餐特惠
现状。 该集团在四个星期内花费了 6,000 英镑，在 Instagram 和 Facebook 上推广工作日午餐菜单。Ads Manager 报告了 40 次在线预订，单次预订成本为 150 英镑。财务总监要求停止该营销活动。
应对措施。 市场营销团队在 WiFi 登录页面上添加了一个单独的广告测量授权选项。随后为获得授权的宾客每日发送 VenueVisit 事件，并围绕自定义转化重新构建了报告。接下来的四周营销活动采用了相同的预算和创意内容。
结果。 该集团共发送了 1,900 个获得授权的午餐时段进店事件。Meta 在 7 天点击、1 天浏览的归因窗口内，将其中的 310 个进店事件归因于该营销活动。每次归因进店的成本为 19.35 英镑，而此前仅基于 Pixel 数据计算的单次预订成本则为 150 英镑。该营销活动得以继续投放。随后 CRM 团队利用 ReturnVisit 事件发现，其中有 70 名宾客在 30 天内再次光顾。
场景 2：一家拥有 150 间客房且设有对外营业餐厅和酒吧的酒店
现状。 该酒店面向本地餐饮顾客（非住店客人）为其餐厅和酒吧投放了 Meta 广告。酒店此前已经配置了用于预订的 Pixel 和服务器事件，但报告的转化结果在一夜之间翻了一番。
处理措施。 团队发现其预订引擎和服务器集成发送的 Schedule 事件包含不同的事件 ID。Meta 无法对其进行去重。团队统一了事件 ID，然后通过将登录信息与房间关联的资料进行过滤，从 VenueVisit 事件中排除了酒店住客。
结果。 次月报告的预订量从 220 次降至 112 次，与预订系统自身的统计数据相差在 3% 以内。访问事件现在仅统计非住客用餐者，当月为 640 人。团队终于可以将餐厅消费与本地客源进行对比，而不是包含住客和重复数据的混合数据。
如何确认 Conversions API 正常工作？
在第一个月按以下顺序检查五个信号。
接收到的事件与发送的事件一致
您每日统计的已授权访问次数应与 Meta 在事件管理器中报告为已接收的事件一致。超过 5% 的差距意味着发送失败、事件被拒绝或存在时间同步问题。
事件匹配质量正在提升
Meta 会根据服务器事件的匹配数据识别用户的精准度给予 1 到 10 分的评分。在电子邮件旁添加哈希处理后的电话号码通常会提高分数。请观察逐周的趋势，而不是第一天的数字。
去重干净彻底
如果 Pixel 和服务器实现在您上线的当天双双大幅上升，则事件可能被重复计算了。请检查来自两个数据源的共享事件是否包含相同的名称和事件 ID。
每次访问成本保持稳定
两到三周后，每个归因访问的成本应稳定在每个广告系列的合理范围内。剧烈波动表明数据包到达延迟或不规律。
结果经得起对照组检验
归因会将广告归功于任何看过广告随后光顾的人，包括无论如何都会来的熟客。运行一个简单的测试：暂停针对可比场所的广告两周，并比较 WiFi 访问次数。如需更严谨的答案，请使用 Meta 的 Conversion Lift 研究。
会出现什么问题，如何避免？
大多数失败是流程失败，而不是代码失败。以下是让餐饮集团付出最多时间成本的六个问题。
- 在没有有效授权的情况下发送数据。 根据 GDPR 第 7 条，用于“营销”的单一捆绑授权框将无法作为广告衡量的凭证。请分开设置选择性同意，并存储每个选择及其时间戳。
- 重复计算同一个事件。 没有匹配事件 ID 的 Pixel 和服务器事件会夸大您报告的每个数字。在向财务部门展示结果之前，请先解决去重问题。
- 导致数据包过期。 队列时间超过 Meta 时间限制的事件将被拒绝，且不会出现在报告中。请自动化每日发送，并在失败时提醒相关人员。
- 将员工和住客计为用餐者。 员工每班次都会登录，酒店住客每天都会登录。请过滤掉这两类人群，否则您的每次访问成本看起来会比实际情况更好。
- 将每次登录都视为一次访问。 午餐后重新连接的客人仍算作一次访问。请针对每个场所、每个客人、每天仅发送一个事件。
- 将归因与因果关系混淆。 看到您广告的忠实老客会被计入广告驱动的到店访客。在转移大笔预算之前，请先进行对照组测试（holdout）或提升度研究（lift study）。
还有一个失败原因完全存在于 Meta 之外：同意列表过于薄弱。到店测量仅适用于已选择加入的访客。请将 WiFi 登录时的选择加入率（opt-in rate）视为付费媒体指标，因为它决定了您可以测量的上限。
常见问题解答
Meta Conversions API 是否会替代 Meta Pixel？
不会，Meta 建议同时运行 Conversions API 和 Pixel，而不是相互替代。Pixel 实时捕获浏览器事件，而服务器连接可以恢复浏览器丢失的事件并补充线下到店数据。当两者报告同一个 Web 事件时，请发送相同的事件名称和事件 ID。然后 Meta 会将其计算一次。对于实体到店访客，仅适用服务器连接，因为没有可重复的浏览器事件。
与 Meta 共享访客 WiFi 数据是否符合 GDPR 规定？
是的，前提是您拥有合法依据，对于广告测量而言，通常是明确的同意。GDPR 第 7 条规定了相关条件，序言第 32 条排除了预先打勾的框。用通俗的语言告诉访客，其电子邮箱的编码版本将发送给 Meta 以测量广告效果。按照 Meta 的要求使用 SHA-256 哈希处理标识符。一旦访客撤回同意，立即停止发送。请您的数据保护负责人审阅欧洲数据保护委员会（EDPB）的《指南 8/2020》。
这适用于我们现有的 WiFi 硬件吗？
是的，Purple 与硬件无关，可以作为云端覆盖层运行在您现有的接入点上。它支持 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。您无需更换硬件即可捕获经同意的登录记录。然后，到店数据会流入 Purple Engage 生成访客档案，为 Conversions API 做好准备。
这与使用 Mailchimp、Klaviyo 或 HubSpot 有何不同？
不同之处在于到店数据的来源。Mailchimp、Klaviyo 和 HubSpot 是向您已有的列表发送营销活动。它们不会记录顾客实际走进您餐厅的情况。Purple Engage 通过访客 WiFi 登录信息来构建列表，每条记录都是带有时间戳、经过同意的第一方到店记录。正是这项记录将 Conversions API 连接从 Web 测量转化为到店测量。
设置 Conversions API 需要开发者吗？
对于到店事件，通常需要开发者，但工作量不大。网站事件通常可以通过 Meta 合作伙伴集成进行连接，几乎不需要编写代码。到店事件需要一个定时任务，用于读取经过同意的登录记录、规范化并哈希标识符，然后按天批量发送。开发者、代理商或带有 Meta 连接器的 CRM 都可以构建它。在构建的同时，请留出时间用于同意用词和数据保护合规审核。
我们应该期望到店记录与 Meta 账户之间达到怎样的匹配率？
预计 Meta 匹配的访问量会少于您发送的数量。Meta 只能匹配拥有相同电子邮件或电话号码的 Meta 帐户的用户。尽可能同时发送哈希处理后的电子邮件和电话号码，并仔细对两者进行标准化。然后在事件管理器中关注事件匹配质量得分。首月内不断上升的得分表明您的匹配数据正在改善。
访问结果多快会在广告管理器中显示？
访问事件在 Meta 收到后就会显示在事件管理器中，测试事件则会在收到时实时显示。归因结果会在广告管理器中随着每个广告系列的归因期运行而逐步积累。对于为期 7 天的点击归因期，请在评估每次访问成本之前至少给广告系列整整一周的时间。持续 2 到 4 周的每日发送可以为预算决策提供可靠的参考依据。