Hospitality & QSR
The guest scanned, ordered and paid. Your analytics saw none of it.
Hospitality runs on the phone in the guest's hand: QR menus, order-at-table, kiosks, in-room dining and apps. Browser tags miss guests with ad blockers and guests who decline cookies, Safari forgets returning guests after a week, and orders reach the warehouse in overnight batches. Datafly Signal collects every interaction on your own domain and streams it to your warehouse in seconds.
400 days
Guest ID lifetime
A server-set first-party guest ID that Safari keeps, across every venue on your domain
Seconds
Event to warehouse
Streamed into BigQuery, Snowflake or Databricks as it happens, not in tomorrow's batch
~6 KB
One collector
Replaces several vendor tags on menu and checkout pages, where venue Wi-Fi is slowest
250+
Destinations
Warehouses, streams, loyalty, CRM and ad platforms, configured rather than built
Why hospitality data arrives incomplete
Guests order in seconds, on their own phones, often on a single visit. Every gap in collection is a guest, an order or a drop-off that nobody sees.
Guests your tags can't see
Ad blockers stop tag managers and analytics tags before they fire, and guests who decline cookies drop out of the funnel. Drop-off rates end up measured on the guests who allowed tracking, not on all of them.
Returning guests look new
A QR scan on an iPhone opens in Safari, which deletes script-written cookies after seven days without a visit. A guest back next month, or ordering at a sister property, is counted as someone new, so frequency and loyalty are understated.
Orders arrive tomorrow
Ordering and POS data reach the warehouse through scheduled syncs, separate from guest behaviour. Nothing is live, the two routes are hard to join, and every new field has to be mapped through the sync first.
From QR scan to warehouse in seconds
Every step of the guest journey becomes an event, from the ordering app or from your back end, carrying the same guest ID and the venue it happened in.
01
Scan
page_view
Venue, outlet and table from the QR code
02
Browse menu
view_item_list · view_item
What guests look at
03
Basket
add_to_cart · remove_from_cart
What guests choose
04
Checkout
begin_checkout · add_payment_info
Where guests drop off
05
Pay
purchase
Confirmed by your back end
06
Fulfil
order_status
Accepted, ready, delivered
07
Return
same guest ID
Next visit, next property
Highlighted steps are sent server-side by your ordering platform or POS, so they are recorded even if the guest closes the tab.
One clean event stream, with the venue attached
One event model across every brand, property, outlet and channel. The ordering app already knows the venue, outlet and table from the QR code and includes them with each event; Datafly Signal adds location, device, consent state and a bot score on the server.
- Streamed to BigQuery through the Storage Write API, in tables and columns you define
- Unmapped properties land in a JSON column, queryable the moment the app sends them
- Browser events and server-side orders share the guest ID, so they join on one column
- Personal data hashed, masked or removed per field before anything leaves
- Six layers of bot filtering, so scraped menus never inflate the funnel
- Kafka before acknowledgement, per-destination retries and a dead-letter queue with replay
// Ordering platform → POST /v1/events, signed with HMAC
{
"type": "track",
"event": "purchase",
"anonymous_id": "gst_9f2c41d7e0b3",
"message_id": "order-118204-purchase",
"properties": {
"transaction_id": "118204",
"value": 46.50,
"currency": "GBP",
"payment_method": "apple_pay",
"service": "table_ordering",
// venue context, from the QR code
"brand": "Example Hotels",
"property_id": "LON-RIV",
"property": "London Riverside",
"outlet": "Pool Bar",
"table": "T14",
"country": "GB",
"items": [
{ "item_id": "M-2231", "item_name": "Club sandwich",
"price": 16.00, "quantity": 1 },
{ "item_id": "M-1180", "item_name": "Caesar salad",
"price": 14.50, "quantity": 1 },
{ "item_id": "D-0907", "item_name": "Sparkling water",
"price": 4.00, "quantity": 4 }
]
}
}Know the guest, not just the session
When ordering runs on a domain you own, one guest ID can follow a guest across every venue for up to 400 days. Where your agreements allow it, single orders become guest journeys: frequency, spend and preferences across a stay and across the year.
In-room dining, £46.50
Pool bar, £18.00, ordered at the table
Beach bar, first visit to this property
Restaurant, £62.00, third property this year
- Guest ID set by your own servers and read by Datafly Signal, or set by Datafly Signal through the same edge as the app
- Deterministic joins only: guest ID, hashed email, loyalty number or account ID. No fingerprinting
- A shared-device guard stops two guests being merged, and joins can require a consent category
- Real-time loyalty signals: a third order this stay, a first visit to a new property, a lapsed guest returning
Respect every choice, without losing the data you're entitled to
Datafly Signal never overrides a guest's choice. What changes is how much a refusal costs. With a browser analytics tag, a refusal usually means the guest is not recorded at all. On a platform you own, each use of the data is treated on its own terms.
Orders and payments
Recorded as part of the service
Your back end sends orders, payments and status changes server-side, because they are part of providing the service the guest asked for. No browser cookie is involved, so the banner does not decide whether an order is recorded.
Not dependent on the bannerFirst-party analytics
Your rules, per market
Datafly Signal runs in your cloud and shares nothing with a vendor for its own purposes, so your privacy team can treat first-party analytics on its own terms, under the rules that apply in each market.
Set by your privacy teamWhere consent comes first
Counted, not remembered
Events are recorded with a session-only ID and no persistent identifier. Every funnel step, drop-off and order is counted; the guest just is not recognised on the next visit.
Session-only IDMarketing and third parties
Only with agreement
Advertising platforms, and any feed to another company for its own use, receive only events from guests who agreed. The choice is applied per destination on the server, and a withdrawal applies everywhere at once.
Consent requiredYour privacy team sets the rules for each market; Datafly Signal enforces them in code and records every consent decision. Guest IDs are pseudonymous, not anonymous, and are handled as personal data.
Every order is a signal someone will pay for
Retailers have turned first-party purchase data into one of the fastest-growing channels in advertising. Hospitality holds the equivalent: verified orders at the point of purchase, with the context of where and when. Datafly Signal provides the controls to share and sell it safely.
Real-time data feeds
Each hotel brand, franchisee or client receives its own guests' events, live, in its own warehouse or stream. Mapped to its schema and property codes, governed field by field, and offered as a premium tier instead of scheduled exports.
Loyalty and CRM activation
Orders and guest signals sent in real time to loyalty, CRM and marketing platforms such as Salesforce Marketing Cloud or Braze, so a guest can be recognised and rewarded during the stay rather than after it.
Sponsored menu placements
Food and drink brands pay for featured placements in digital menus. Datafly Signal measures the closed loop (placement seen, item added, order paid) and returns conversions to the brand's own ad accounts, without a brand tag on your menus.
Each party can have its own workspace to see its feed and connect its own destinations from a list you approve. You decide what each party receives, nothing leaves without a rule that allows it, and usage is counted per party for billing.
What else changes
Problems in minutes
With events in the warehouse in seconds, alert when a venue's orders stop, payment failures rise or fulfilment times stretch, rather than finding out the next morning.
Menu and upsell performance
Views against orders for every item, add-on uptake, and menu changes compared across venues.
Smaller PCI DSS script scope
Fewer third-party scripts on ordering and payment pages narrows what PCI DSS v4.0 requires you to inventory, authorise and monitor (requirements 6.4.3 and 11.6.1).
Keep GA4 if it helps
Feed GA4 server-side for guests who agree, so marketing keeps its reports while the tag comes off the page.
Replay and backfill
Archived events can be replayed to a new destination, so a new client feed or table can start with history.
Your cloud, your regions
Single-tenant in your own cloud account, in the regions you need for data residency. Datafly never sees the data.
Frequently asked questions
- Does Datafly Signal replace GA4?
- It replaces the GA4 tag, not necessarily GA4. Datafly Signal becomes the complete record of guest behaviour in your own warehouse, and can send GA4 the same events server-side for guests who agree to it. Marketing keeps its GA4 reports, with better data, and the GA4 tag and tag manager come off your ordering pages. An existing GA4 event plan carries straight across, because Datafly Signal uses the same snake_case event names such as view_item, add_to_cart and purchase.
- How do orders from our ordering platform or POS get in?
- Your back end posts confirmed orders, payments, refunds and status changes to the server-side events API, signed with HMAC. Platforms that send webhooks (payment providers and many POS systems) can post to a webhook source with signature verification. Each order carries the same guest ID as the browser events, so behaviour and orders join on a single key, and a repeated message ID within 24 hours is never counted twice.
- How does the guest ID last up to 400 days when guests arrive from a QR code?
- A QR scan on an iPhone opens in Safari, which deletes cookies written by scripts after seven days without a visit. If your ordering app runs on a domain you own, your own servers can set the guest ID cookie when the menu loads and Datafly Signal simply reads it: a cookie set by the server that serves the page is not affected by that deletion. Alternatively, Datafly Signal sets the ID itself from a collection subdomain such as signal.yourdomain.com, served through the same edge as the app. Either way the ID lasts up to 400 days, the longest browsers allow.
- Can each hotel brand, franchisee or client receive its own data?
- Yes. Events are routed by rules (for example, client equals a particular hotel group) into a governed feed for that party, delivered in real time to its own BigQuery, Snowflake, Databricks, S3, Pub/Sub, Kafka or Event Hubs. Field rules decide what each party receives: allow order value and items, hash email, remove IP and table number, generalise location to city. Each party can have its own workspace to see its feed and connect its own destinations from a list you approve, and usage is counted per party for billing.
- What happens when a guest declines cookies?
- Datafly Signal never overrides the guest's choice; it changes how much a refusal costs. Orders and payments arrive server-side as part of providing the service, so the cookie banner does not decide whether an order is recorded. Where consent comes first, events can still be counted with a session-only ID and no persistent identifier. Advertising platforms, and any feed to another company for its own use, receive only events from guests who agreed, with the choice applied per destination on the server. Your privacy team sets the rules for each market and Datafly Signal enforces them.
- Where does it run, and who can see the data?
- Datafly Signal runs as a single-tenant deployment in your own cloud account, for example a Google Cloud project next to BigQuery, across three availability zones. Event data stays in your environment and Datafly never sees it. Identity data is encrypted at rest, every configuration change goes through draft, approval, publish and rollback, and single sign-on with your own identity provider is included.
Related
Data Warehouses
Stream governed guest events to BigQuery, Snowflake and Databricks in seconds, with no batch ETL.
Brand Workspaces
Give each hotel brand, franchisee or supplier a governed feed and its own workspace.
Safari ITP Recovery
A server-set guest ID that Safari keeps, so returning guests are recognised.
Mobile SDK
iOS and Android SDKs for guest apps, with the same identity as web ordering.
See every guest, every order, in real time
Find out how much of your guest journey your current tags miss, and what a complete, live record in your own warehouse makes possible.