餐廳專用的 Meta Conversions API 整合：對照實際到訪次數衡量廣告效果

將 Meta Conversions API 與訪客 WiFi 結合，讓餐廳能在符合 GDPR 標準的前提下，衡量實體造訪與廣告支出的關係。透過在 80,000 多個場地發送經過 SHA-256 哈希處理的登入記錄，營運商可以直接將實體顧客進店歸因於特定的廣告活動，超越線上預約的限制，進而追蹤真實的廣告投資報酬率。

Meta Conversions API 能為餐廳帶來什麼效益？

Meta 根據其能觀測到的事件來評估您的廣告效益。對大多數餐廳而言，這些是網站上的 Pixel 事件：預約、查看菜單或下載優惠券。看過您的廣告、跳過網站並直接進店享用午餐的饕客，永遠不會出現在數據中。然而，那次造訪才是您付費希望獲得的成果。

Conversions API (CAPI) 是 Meta 的伺服器對伺服器（server-to-server）連線機制。您的系統可以直接將事件傳送到 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 之前，您需要準備什麼？

在撰寫任何程式碼或連接整合功能之前，請先收集以下七項資訊：

1. 具有管理員權限的 Meta 企業管理平台，以及您的廣告所針對的資料集。Meta 現在將過去稱為 Pixel ID 的名稱改稱為「資料集（dataset）」。
2. Conversions API 存取權杖，在 Meta 事件總管中針對該資料集所產生。
3. 傳送伺服器端事件的方法。 這代表您需要有自己的開發人員、Meta 合作夥伴整合服務，或是帶有 Meta 連接器的 CRM 或客戶資料平台。
4. 獲得同意的造訪資料。 您需要包含電子郵件或電話、時間戳記、場地與同意狀態的訪客 WiFi 登入記錄。Purple Engage 會將這些資料儲存為根據每次登入建立的訪客輪廓。
5. 合法依據與最新的隱私權通知。 根據 GDPR 第 6 條，您與 Meta 分享資料時必須具備合法依據。就廣告成效衡量而言，這通常是同意，且必須符合第 7 條的條件。
6. 對造訪的共同定義。 決定採計標準：每位訪客每個場地每天登入一次，排除員工。
7. 基準點。 匯出每個行銷活動四週的純 Pixel 結果，以便比對前後差異。

關於第五點，請參閱歐洲資料保護委員會（EDPB）針對社群媒體使用者定位所頒布的 Guidelines 8/2020。當中說明了廣告主與平台如何在某些處理環節中擔任共同控制者。Meta 的商業工具條款也列出了您傳送資料時的義務。在第一個事件離開您的伺服器之前，您的資料保護負責人應簽署核准這兩者。

如何將訪客 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 中的測試事件工具，可以在您附帶測試程式碼傳送事件時，即時顯示收到的事件。請先傳送少量的已知造訪資料。在切換為正式傳送前，請確認事件名稱、時間與操作來源皆顯示正確。

6. 建立自訂轉換並新增至報表

從您的造訪事件建立自訂轉換，然後將其作為一欄新增至 Ads Manager 中。現在您就可以在各個廣告活動中，同時檢視每次造訪成本與每次預訂成本。

您應該傳送什麼資料給 Meta？何時傳送？

從精準的小範圍開始。一個乾淨的造訪事件，比五個混亂的事件能提供更多有價值的資訊。僅在第一個事件配對良好且您的團隊信任這些數據時，才新增更多事件。

事件	資料來源	傳送的配對資料	何時傳送	能告訴您什麼
VenueVisit（自訂）	顧客 WiFi 登入（僅限同意的顧客）	雜湊處理的電子郵件、雜湊處理的電話、事件時間、場地	每日整批	各廣告活動的每次造訪成本
ReturnVisit（自訂）	30 天內的第二次 WiFi 登入	雜湊處理的電子郵件、雜湊處理的電話、事件時間、場地	每日整批	廣告是否能吸引顧客再次光顧，而非僅光顧一次
Purchase（標準）	與顧客連結的收銀機或 EPOS 紀錄	雜湊處理的電子郵件、價值、貨幣、事件時間	每日整批	歸因於廣告的營業額
Schedule（標準）	線上預訂系統	雜湊處理的電子郵件、事件時間、與 Pixel 像素共用的事件 ID	一小時內	從瀏覽器資料遺失中救回的預訂
每一行資料都適用兩項規則。第一，僅傳送同意廣告衡量追蹤的顧客資料，並在他們撤回同意的瞬間立即停止傳送。第二，當 Pixel 像素與伺服器皆回報相同的網頁事件時，請使用相同的事件名稱與事件 ID。Meta 會利用該配對進行重複排除，以確保預訂不會被重複計算。

再次造訪事件對顧客關係管理（CRM）主管最為重要。來自廣告的首次造訪很有價值。但在 30 天內的第二次造訪，則代表該廣告開啟了一段顧客關係，可供您的電子郵件與訊息行銷計畫進一步延伸。關於後續聯繫管道的比較，請參考 WhatsApp vs SMS for restaurant marketing: cost and reach compared。

哪種衡量方法最適合您的餐廳？

伺服器端的造訪事件並非衡量付費社群廣告的唯一方式。正確的選擇取決於您的顧客在何處進行轉換，以及您擁有哪些資料。

方法	觀察內容	是否計算現場直接入座的顧客？	您需要的資料	設定工作量	適用對象
僅使用 Meta Pixel	瀏覽器中的網站事件	否	預訂與菜單頁面上的 Pixel	低：網站上放置一個標籤	大部分餐點預訂均透過線上完成的場地
Pixel 加上用於網頁事件的 CAPI	網站事件，並補回瀏覽器遺失的資料	否	Pixel、伺服器存取權限、共用事件 ID	中：合作夥伴整合或開發人員	線上預訂量高的集團
搭配訪客 WiFi 造訪事件的 CAPI	網頁事件以及獲得同意的現場造訪	是，針對同意的 WiFi 訪客	包含電子郵件或電話且獲得同意的登入記錄	中至高：同意條款審查、雜湊處理、每日傳送	現場直接入座顧客比例高的餐廳、酒吧與飯店
Meta 轉換提升研究 (Conversion Lift)	由廣告帶來的增量造訪（透過測試組與對照組）	是，使用您傳送的造訪事件	造訪事件加上足夠進行測試的預算與資料量	高：需規劃數週的測試	正在測試付費社群廣告是否真的有效益的集團

請將此表格作為決策路徑。如果線上預訂的餐點數量少於一半，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 的 Conversions Lift 增量分析研究。

會出現什麼問題，又該如何避免？

大多數失敗都是流程問題，而不是程式碼問題。以下是讓餐飲集團耗費最多時間的六個問題。

• 在沒有有效同意的情況下傳送資料。 包含「行銷」的單一打包同意核取方塊，在 GDPR 第 7 條規範下無法作為廣告衡量依據。請分開選擇性同意，並儲存每個選擇及其時間戳記。
• 重複計算相同事件。 沒有配對事件 ID 的 Pixel 與伺服器事件會誇大您報告的每個數字。在向財務部門展示結果之前，請先修復重複資料刪除問題。
• 讓批次資料過期。 排隊時間超過 Meta 時間限制的事件會被拒絕，且不會出現在報告中。請自動化每日傳送，並在失敗時發出警報通知。
• 將員工和住客算作用餐者。 員工每個班次都會登入，飯店住客每天都會登入。請將兩者過濾掉，否則您的每筆造訪成本看起來會比實際情況更好。
• 將每次登入都視為一次造訪。 午餐後重新連線的顧客仍然算作一次造訪。請為每位顧客、每個據點、每天傳送一個事件。
• 將歸因與因果關係混淆。 見過您廣告的忠實老顧客會被計算為由廣告驅動的造訪。在調整大筆預算之前，請先進行保留組（holdout）或增量研究（lift study）。

還有一個失敗原因完全與 Meta 無關：同意名單過於單薄。造訪量測僅適用於已選擇選擇性同意（opt-in）的顧客。請將 WiFi 登入時的 opt-in 率視為付費媒體指標，因為它決定了您所能量測的上限。

常見問題

Meta Conversions API 是否會取代 Meta Pixel？

不會，Meta 建議同時執行 Conversions API 與像素，而不是互相取代。像素可以即時擷取瀏覽器事件，而伺服器連線則能補回瀏覽器遺失的事件並新增離線造訪。當兩者報告相同的網絡事件時，請傳送相同的事件名稱與事件 ID。Meta 隨後會將其計算為一次。對於門市造訪，僅適用伺服器連線，因為沒有可以重覆的瀏覽器事件。

與 Meta 分享訪客 WiFi 資料是否符合 GDPR？

是的，前提是您擁有合法依據，針對廣告量測，這通常是明確的同意。GDPR 第 7 條規定了相關條件，而前言第 32 條則杜絕了預先勾選的核取方塊。請用通俗易懂的語言告知顧客，其電子郵件的加密版本將傳送至 Meta 以量測廣告。依據 Meta 的要求，使用 SHA-256 對識別碼進行雜湊處理。當顧客撤回同意時，請立即停止傳送。請要求您的資料保護主管審閱歐洲資料保護委員會（EDPB）的 Guidelines 8/2020。

這能與我們現有的 WiFi 硬體搭配使用嗎？

是的，Purple 獨立於硬體，可以作為雲端重疊層在您現有的存取點（AP）上執行。它支援 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 連線從網絡量測轉變為造訪量測。

設定 Conversions API 是否需要開發人員？

針對造訪事件，通常需要開發人員，不過工作量不大。網站事件通常可以透過 Meta 合作夥伴整合進行連線，幾乎不需要程式碼。造訪事件則需要一個排程作業，用於讀取獲得同意的登入記錄、對識別碼進行正規化與雜湊處理，並傳送每日批次資料。開發人員、代理商或帶有 Meta 連接器的 CRM 都可以進行建置。在建置的同時，請預留同意條款措辭與資料保護審查的時間。

我們應該預期造訪與 Meta 帳號之間的配對率是多少？

預計 Meta 比對到的造訪次數會少於您傳送的數量。Meta 僅能比對擁有相同 Email 或電話號碼之 Meta 帳號的使用者。請盡可能同時傳送雜湊處理過的 Email 與電話號碼，並仔細進行標準化。接著請在事件管理員中觀察「事件比對品質」分數。開頭一個月內上升的分數代表您的比對資料正在改善。

造訪結果多久會顯示在廣告管理員中？

造訪事件在 Meta 收到後就會顯示於事件管理員中，而測試事件則會在收到時即時顯示。歸因結果會隨著每個廣告活動的歸因時間範圍運作，逐漸累積在廣告管理員中。若使用七天點擊歸因時間範圍，請在評估每次造訪成本前，給予廣告活動至少一整週的時間。持續二至四週的每日傳送，能為預算決策提供可靠的參考依據。