Meta Conversions API integration for restaurants: measuring ads against real visits
You will be able to decide whether to send consented guest WiFi visits to Meta's Conversions API, and set it up in six steps. The guide covers consent, hashing, deduplication and daily batches.
Video overview
Integrating the Meta Conversions API with guest WiFi allows restaurants to measure offline visits against ad spend under CCPA/CPRA standards. By sending hashed SHA-256 login records across 80,000+ venues, operators attribute physical walk-ins directly to campaigns, going beyond online bookings to track true ad returns.
What does the Meta Conversions API do for a restaurant?
Meta judges your ads on the events it can see. For most restaurants, those are pixel events on a website: a booking, a menu view or a coupon download. A diner who saw your ad, skipped the website and walked in for lunch never appears. Yet that visit is the outcome you paid for.
The Conversions API (CAPI) is Meta's server-to-server connection. Your systems send events to Meta directly, instead of relying on a script in a browser. Meta documents it for website, app and offline events. Offline events include visits to a physical location, marked with the action source "physical_store".
Why pixel-only reporting undercounts restaurant results
Three gaps open between what your ads achieve and what Ads Manager reports.
- The visit happens offline. The Meta Pixel runs only in a browser, on your own pages. A walk-in, a phone booking or a booking through a third-party platform leaves no pixel event.
- Browsers drop events. Meta's own guidance says the Conversions API reduces data loss from browser loading errors, connectivity issues and ad blockers.
- Device privacy settings limit signals. Since iOS 14.5, Apple requires apps to ask permission before using activity data across other companies' apps and websites. Many people decline, which removes signals the pixel once relied on.
The cost is more than a reporting gap. Meta's delivery system optimizes towards the people who produce the events it receives. If those are only online bookings, budget drifts towards people who book online. Campaigns that fill tables with walk-ins look expensive, so they get paused.
What changes when visits reach Meta
You send one visit event for each consented guest who logs in to your WiFi, with a hashed email or cell phone number and a timestamp. Meta matches that event to the person's Meta account where it can. It then reports the visit against any ad they saw or clicked within your attribution setting. You get a cost per visit by campaign, not just a cost per booking.
The hard part is not the API. It is a reliable, consented record of who visited, and when. Email platforms such as Mailchimp, Klaviyo and HubSpot send campaigns to a list you already have. They do not record that a diner walked through your door. Guest WiFi does: each login is a timestamped, first-party visit record with the guest's consent choice attached. Across Purple's 80,000+ live venues, guests logged in 440 million times in 2024 (Purple data). That is the raw material for visit measurement.
What do you need before you start with the Conversions API?
Gather seven things before anyone writes code or connects an integration.
- A Meta business portfolio with admin access, plus the dataset your ads report against. Meta now uses "dataset" for what used to be called the pixel ID.
- A Conversions API access token, generated in Meta Events Manager for that dataset.
- A way to send events server-side. That means your own developer, a Meta partner integration, or a CRM or customer data platform with a Meta connector.
- Consented visit data. You need guest WiFi login records with email or cell phone, timestamp, venue and consent status. Purple Engage holds these as guest profiles built from each login.
- A lawful basis and an updated privacy notice. Under the CCPA/CPRA, you need a clear disclosure and consent framework for sharing data with Meta. For ad measurement, that is usually consent.
- A shared definition of a visit. Decide what counts: one login per guest per venue per day, staff excluded.
- A baseline. Export four weeks of pixel-only results per campaign so you can compare before and after.
On item five, review relevant FTC guidance and privacy frameworks on the targeting of social media users. They describe how an advertiser and a platform can share responsibilities for processing. Meta's Business Tools Terms also set out your obligations when you send data. Your data privacy lead should sign off before the first event leaves your server.
How do you connect guest WiFi visit data to the Conversions API?
The setup runs in six steps. Meta's developer documentation covers the technical detail; this section covers the decisions you own.
1. Capture consent at the WiFi login
Your WiFi login page is where consent starts. Ask for ad measurement consent separately from email marketing consent. Unchecked opt-in boxes ensure compliance. Purple uses conscious-choice opt-ins for this reason: the guest actively chooses, and the choice is stored with the profile.
Write the wording in plain English. For example: "Let us share a coded version of your email with Meta so we can see whether our ads brought you here." A clear sentence earns more opt-ins than a link to a policy.
2. Define the visit event
Meta's standard events do not include a restaurant visit, so most venues create a custom event. Call it something obvious, such as "VenueVisit". Send one event per guest, per venue, per day, even if they log in three times. Exclude staff devices and any guest who logs in on more than four days a week, which usually signals an employee.
3. Prepare and hash the matching data
Meta requires personal identifiers such as email and cell phone to be normalized and hashed with SHA-256 before sending. Normalizing means trimming spaces, lowercasing emails and adding the country code to phone numbers. Poor normalization is the most common reason matches fail.
Each event also needs an event time, the action source "physical_store" and a unique event ID. Send only the parameters Meta lists. Network identifiers such as MAC addresses are not among them and should never leave your systems.
4. Send events in a daily batch
Meta rejects events older than its documented window, so do not let them queue for a week. Schedule a daily batch at minimum, and check the current time limit in Meta's documentation when you build it. A daily send also keeps Ads Manager close enough to real time for weekly campaign reviews.
5. Test before you go live
Meta's Test Events tool, inside Events Manager, shows events as they arrive when you send them with a test code. Send a handful of known visits first. Confirm the event name, time and action source read correctly before switching to live sends.
6. Build a custom conversion and add it to reporting
Create a custom conversion from your visit event, then add it as a column in Ads Manager. You can now read cost per visit beside cost per booking, campaign by campaign.
What should you send to Meta, and when?
Start narrow. One clean visit event teaches you more than five noisy ones. Add events only when the first is matching well and your team trusts the numbers.
| Event | Where the data comes from | Matching data sent | When to send | What it tells you |
|---|---|---|---|---|
| VenueVisit (custom) | Guest WiFi login, consented guests only | Hashed email, hashed phone, event time, venue | Daily batch | Cost per visit by campaign |
| ReturnVisit (custom) | Second WiFi login within 30 days | Hashed email, hashed phone, event time, venue | Daily batch | Whether ads bring people back, not just once |
| Purchase (standard) | POS or EPOS record linked to the guest | Hashed email, value, currency, event time | Daily batch | Revenue attributed to ads |
| Schedule (standard) | Online booking system | Hashed email, event time, event ID shared with the pixel | Within the hour | Bookings recovered from browser data loss |
Two rules apply to every row. First, send only guests who gave ad measurement consent, and stop the moment they withdraw it. Second, when the pixel and the server both report the same web event, use the same event name and event ID. Meta uses that pair to deduplicate, so a booking is not counted twice.
The return visit event matters most to a CRM director. A first visit from an ad is useful. A second visit within 30 days shows the ad started a relationship your email and messaging program can build on. For the follow-up channel, compare costs in WhatsApp vs SMS for restaurant marketing: cost and reach compared.
Which measurement method fits your restaurant?
Server-side visit events are not the only way to measure paid social. The right choice depends on where your diners convert and what data you hold.
| Method | What it sees | Counts walk-in visits | Data you need | Setup effort | Who it suits |
|---|---|---|---|---|---|
| Meta Pixel only | Website events in the browser | No | Pixel on your reservation and menu pages | Low: one tag on the site | Venues where most covers book online |
| Pixel plus CAPI for web events | Website events, with browser losses recovered | No | Pixel, server access, shared event IDs | Medium: partner integration or developer | Groups with high online booking volume |
| CAPI with guest WiFi visit events | Web events plus consented in-venue visits | Yes, for consented WiFi guests | Consented login records with email or cell phone | Medium to high: consent review, hashing, daily send | Restaurants, bars and hotels with strong walk-in trade |
| Meta Conversion Lift study | Incremental visits caused by ads, via test and control groups | Yes, using the visit events you send | Visit events plus enough budget and volume for a test | High: planned test over several weeks | Groups testing whether paid social pays at all |
Use the table as a decision path. If fewer than half your covers book online, pixel reporting misses most of your results, so visit events come first. If you already send visit events and your finance team still doubts paid social, run a lift study. Attribution tells you who visited after an ad. Lift tells you who visited because of it.
Two worked scenarios
The figures below are illustrative arithmetic to show the method. They are not reported results from a named venue.
Scenario 1: a 12-site casual dining group running a lunch offer
Situation. The group spent $6,000 over four weeks promoting a weekday lunch menu on Instagram and Facebook. Ads Manager reported 40 online bookings, a cost of $150 per booking. The finance director asked for the campaign to stop.
What was done. The marketing team added a separate ad measurement opt-in to the WiFi login page. It then sent a daily VenueVisit event for consented guests and rebuilt reporting around a custom conversion. The next four-week flight ran with the same budget and creative.
Outcome. The group sent 1,900 consented lunchtime visit events. Meta attributed 310 of them to the campaign within a seven-day click, one-day view window. Cost per attributed visit came in at $19.35, against $150 per booking on pixel data alone. The campaign stayed live. The CRM team then used the ReturnVisit event to see that 70 of those guests came back within 30 days.
Scenario 2: a 150-room hotel with a public restaurant and bar
Situation. The hotel ran Meta ads for its restaurant and bar to local diners, not residents. It already ran the pixel and server events for bookings, but reported results had doubled overnight.
What was done. The team found its booking engine and its server integration both sent Schedule events with different event IDs. Meta could not deduplicate them. The team aligned the event IDs, then excluded hotel residents from the VenueVisit event by filtering logins against room-linked profiles.
Outcome. Reported bookings fell from 220 to 112 in the following month, matching the booking system's own count within 3%. Visit events now counted only non-resident diners, 640 in the month. The team could finally compare restaurant spend against local trade instead of a mix of residents and duplicates.
How do you know the Conversions API is working?
Check five signals in the first month, in this order.
Events received match events sent
Your daily count of consented visits should match the events Meta reports as received in Events Manager. A gap of more than 5% points to failed sends, rejected events or timing problems.
Event Match Quality is improving
Meta gives each server event a score out of 10 for how well its matching data identifies people. Adding a hashed cell phone number beside email usually lifts the score. Watch the trend week by week, not the first day's number.
Deduplication is clean
If pixel and server results both rose sharply on the day you went live, events are probably counted twice. Check that shared events carry the same name and event ID from both sources.
Cost per visit is stable
After two or three weeks, cost per attributed visit should settle within a consistent range for each campaign. Wild swings suggest batches are arriving late or irregularly.
Results hold up against a holdout
Attribution gives an ad credit for anyone who saw it and then visited, including regulars who would have come anyway. Run a simple test: pause ads to a comparable venue for two weeks and compare WiFi visit counts. For a rigorous answer, use Meta's Conversion Lift study.
What goes wrong, and how do you avoid it?
Most failures are process failures, not code failures. Here are the six that cost restaurant groups the most time.
- Sending data without valid consent. One bundled consent box for "marketing" will not stand up under CCPA/CPRA for ad measurement. Separate the opt-ins and store each choice with its timestamp.
- Counting the same event twice. Pixel and server events without matching event IDs inflate every number you report. Fix deduplication before you show results to finance.
- Letting batches go stale. Events that queue past Meta's time limit are rejected without appearing in reports. Automate the daily send and alert someone when it fails.
- Counting staff and residents as diners. Employees log in every shift and hotel residents log in daily. Filter both out, or your cost per visit looks better than it is.
- Treating every login as a visit. A guest who reconnects after lunch is still one visit. Send one event per guest, per venue, per day.
- Confusing attribution with cause. A loyal regular who saw your ad will be counted as an ad-driven visit. Use holdouts or lift studies before you move large budgets.
One more failure sits outside Meta entirely: a thin consented list. Visit measurement only works for guests who opted in. Treat opt-in rate at the WiFi login as a paid media metric, because it sets the ceiling on what you can measure.
Frequently asked questions
Does the Meta Conversions API replace the Meta Pixel?
No, Meta recommends running the Conversions API alongside the pixel, not instead of it. The pixel captures browser events in real time, while the server connection recovers events the browser loses and adds offline visits. When both report the same web event, send the same event name and event ID. Meta then counts it once. For walk-in visits, only the server connection applies, because there is no browser event to duplicate.
Is sharing guest WiFi data with Meta compliant with CCPA/CPRA?
Yes, provided you have a lawful basis, which for ad measurement is usually explicit consent. Tell guests in plain words that a coded version of their email goes to Meta to measure ads. Hash identifiers with SHA-256 as Meta requires. Stop sending the moment a guest withdraws consent. Ask your legal lead to review applicable state privacy rules.
Will this work with the WiFi hardware we already have?
Yes, Purple is hardware-agnostic and runs as a cloud overlay on your existing access points. It works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You do not need to replace hardware to capture consented login records. The visit data then flows into Purple Engage as guest profiles, ready to prepare for the Conversions API.
How is this different from using Mailchimp, Klaviyo or HubSpot?
The difference is where the visit data comes from. Mailchimp, Klaviyo and HubSpot send campaigns to a list you already hold. They do not record that a diner physically walked into your restaurant. Purple Engage builds the list from guest WiFi logins, each a timestamped, consented, first-party visit record. That record is what turns a Conversions API connection from web measurement into visit measurement.
Do we need a developer to set up the Conversions API?
Usually yes, for visit events, though the work is modest. Website events can often connect through a Meta partner integration with little code. Visit events need a scheduled job that reads consented login records, normalizes and hashes identifiers, and sends a daily batch. A developer, an agency or a CRM with a Meta connector can build it. Allow time for consent wording and data protection review alongside the build.
What match rate should we expect between visits and Meta accounts?
Expect Meta to match fewer visits than you send. Meta can only match people who hold a Meta account under the same email or phone number. Send both a hashed email and a hashed phone number where you have them, and normalize each carefully. Then watch the Event Match Quality score in Events Manager. A rising score over the first month shows your matching data is improving.
How soon will visit results appear in Ads Manager?
Visit events appear in Events Manager once Meta receives them, and Test Events shows them as they arrive. Attributed results build up in Ads Manager as each campaign's attribution window runs. With a seven-day click window, give a campaign at least a full week before judging cost per visit. Two to four weeks of daily sends gives a reliable view for budget decisions.