Privacy-First Hotel Capture Measurement Plan

Section 01

Project Overview

Project Magee is HotelMap's robotics project focused on the event attendee and, most precisely, the non-local event attendee who is going to require accommodation during an event. The name Magee refers to the MAGS entity — the system intelligence that operates in the background of all HotelMap tracking and reporting infrastructure.

The project spans the full lifecycle of the attendee: from the moment they commit to attending an event, through weeks or months of pre-event marketing, to the point at which they either book their hotel through the official HotelMap channel or they do not. Everything Magee builds serves that final binary outcome — and that outcome is an opportunity, not an inevitability.

Identify non-local attendees

Classify registered attendees as local or non-local using a layered signal framework — address geocoding, IP geolocation, and browser timezone comparison — with weighted confidence scoring.

Track across the pre-event window

Maintain persistent identity across sessions that may be weeks apart, using email-tokenised links, URL parameter passing, first-party cookies, and probabilistic fingerprinting as a last resort.

Observe hotel-related behaviour

Record every meaningful interaction with hotel marketing: email opens, link clicks, hotel page views, search events, and booking completions. Build a timestamped behavioural record per registrant.

Record and attribute hotel bookings

Match each completed booking back to the originating registrant record. This is the closure event that determines whether the attendee was captured, at what point in the funnel, and via which channel.

Section 02

The Optimised Capture Opportunity

Every other channel in hotel marketing competes for the attention of people who might want to travel. OTAs, search ads, and display campaigns all target people in an undecided state — browsing, comparing, not yet committed. The event housing context is categorically different. The travel decision has already been made. The attendee has paid their registration fee, confirmed a date, and committed to being at a specific location. They need a bed. The question is only whose bed.

This is not a customer acquisition problem. It is a routing problem. HotelMap is the official channel — already known to the attendee, already in their confirmation email, already endorsed by the event they trust. The friction that stands between HotelMap and the booking is not disinterest. It is inertia, price perception, and a booking experience that is not fast or compelling enough to win before the attendee goes elsewhere.

The commercial reality

The event organiser sold the ticket. They created the reason to travel. The non-local attendee paid to attend and will book a hotel regardless — that is not in question. The only question is which booking channel captures the commission. At an event with 10,000 attendees, 8,000 of whom are non-local, a capture rate of just 50% generates approximately £300,000 in hotel booking commission. That money exists. It is being spent. Right now it flows to OTAs and direct hotel websites. Every percentage point of capture rate improvement is a direct transfer of that revenue to the event organiser and HotelMap.

Metric	Value	Note
Total attendees	10,000	Representative major professional event
Non-local attendees	8,000	80% requiring accommodation — all booking a hotel somewhere
Bookings at 50% capture	4,000	Half the non-local audience routed through the official channel
Commission at 50% capture	£300K	Revenue that exists regardless — the only variable is who captures it

These attendees are booking their hotel either way

This is not a question of whether the hotel gets booked. It will be booked. The non-local attendee needs a bed. The commission — roughly £300,000 at the figures above — is not at risk of disappearing. It is at risk of going to Booking.com, Hotels.com, or a direct hotel website instead of through the official event channel. Solving the capture problem does not create new demand. It captures demand that already exists and that the event organiser's own marketing created.

Official system bookings

48%

Of non-local attendees book through the official housing system — industry baseline (Kalibri Labs / PCMA, 2M+ records)

In-block, wrong channel

23%

Stayed at block hotels but booked through another channel — reachable audience

Price perception gap

39%

Believed official rates were more expensive — a communication problem, not a pricing problem

Cart abandonment open rate

70%

Email open rate for hotel cart abandonment sequences — exceptional engagement

Revenue framing — what closing the gap means

The gap between the current 48% capture rate and what is achievable translates directly and calculably into revenue. Based on 5,000 non-local attendees at a representative professional conference, average nightly rate £175:

Scenario	Capture rate	Bookings captured	GMV (2 nights, £175/night)	Commission at 10%
Current baseline	48%	2,400	£840,000	£84,000
Improved — conservative	58%	2,900	£1,015,000	£101,500
Improved — target	68%	3,400	£1,190,000	£119,000
Opportunity per event (baseline to target)	+20pp	+1,000 bookings	+£350,000	+£35,000

The 23% is the most efficient target

Converting the in-block, wrong-channel attendees requires no change to pricing, no new hotel inventory, and no changes to the event programme. It requires only a clearer, faster, more compelling booking experience that is presented at the right moment. This is the primary design target for the Magee experience layer.

Section 03

Registration — The Starting Gun

Registration is the moment an attendee commits. It is also the moment at which HotelMap must first act: classifying the registrant as local or non-local, assigning a persistent identifier, and firing the first hotel communication while intent is at its highest. Everything that follows depends on the quality of what is captured here.

The multi-system registration problem

A single event rarely runs on a single registration system. The most common architecture separates visitors from exhibitors, each with their own platform, data schema, and registration journey. Exhibitors may be registered months before the event opens to visitors. They often register multiple people under a single company booking. Their profile data — including contact names, company address, and attendance days — arrives through an exhibitor management system that has no connection to the visitor registration platform.

System A

Visitor registration

Typically Cvent, Eventbrite, Bizzabo, or a bespoke event portal. Visitors self-register individually. Produces a clean individual record with personal contact details. Registration often happens closer to the event date.

System B

Exhibitor management

A separate EMS (Exhibitor Management System) handles stand bookings, badge allocation, and personnel registration for exhibiting companies. Records arrive as bulk company submissions. A single company may register 20 staff. The company address — not the individual's home address — is often the only location data available.

System C

Badge and access control

Some events use a third system for on-site badge printing and access scanning. This system may hold the definitive list of who actually attended versus who registered. Post-event, this data can validate capture rate calculations against real attendance.

System D

Abstract and speaker systems

Conferences with submitted content (papers, talks, workshops) often use a fourth system for speaker management. Speakers are typically non-local and high-value guests whose accommodation is sometimes comped by the organiser — but they still represent an opportunity for additional room nights for accompanying guests.

Normalisation is a prerequisite for everything downstream

Before Magee can classify, track, or communicate with any registrant, all registration sources must be normalised into a single schema. A visitor record from Cvent and an exhibitor record from an EMS must produce identical-format Magee registrant records with the same required fields. This normalisation layer must be built for each event's specific integration, and the field-mapping must be validated before any marketing activity begins.

Data we must capture at registration

Not all registration systems collect all fields. The following table defines required versus ideal fields for Magee classification and communication. Where a field is absent, Magee uses the next-best signal in its hierarchy.

Field	Required for	Visitor systems	Exhibitor systems	Fallback if absent
Email address	Identity anchor, tokenised links, SHA-256 hash	✓	✓	None — required
Home postcode / ZIP	Primary location classification	✓	✗	IP geolocation at registration
Country	International classification, currency	✓	Partial	IP geolocation country field
Company address	Exhibitor location proxy	✗	✓	IP geolocation
Attendance dates	Pre-populate hotel search dates	Partial	Partial	Default to full event duration
Job title / seniority	Segment by likely spend and decision-making authority	Partial	✓	Omit from segmentation
Language / locale	Email language selection, UI localisation	Partial	✗	Browser Accept-Language header
Registration IP address	Location classification, VPN detection	✓	✓	Captured server-side regardless

The reg_id — the anchor for everything

At the moment a registration record is normalised into the Magee system, a reg_id is assigned. This identifier is immutable, event-scoped, and becomes the primary key across every subsequent system touch: email sends, hotel page views, search events, booking completions, and post-event reconciliation. Nothing in the Magee stack operates without it.

Registration ingestion flow for reg_id assignment

Magee registrant field	Definition
reg_id	UUID assigned at ingestion; immutable primary key
email	Raw email plus separate SHA-256 hash for identity-safe joins
event_id	Scopes all downstream activity to the relevant event
attendee_type	visitor \| exhibitor \| speaker
location_raw	Postcode, company address, or country source field
is_non_local	Boolean derived from location classification
distance_km	Geocoded distance from attendee location to event venue
confidence	Classification confidence score from 0.0 to 1.0
locale	Language tag used for communications and UX copy
registered_at	Registration ingestion timestamp

Exhibitor value — often underestimated

Exhibitors are typically a smaller population than visitors but their accommodation needs are more complex and higher value. A company sending eight staff to a three-day trade show needs eight rooms for three nights. The booking may be made by a travel manager rather than the individual attendees. Magee must accommodate bulk booking flows and company-level communication in addition to the individual attendee flow.

Section 04

User Journey Intelligence

Knowing that 52% of non-local attendees do not book through the official channel is the beginning of the insight, not the end of it. To improve the capture rate systematically, we need to understand where in the journey people leave and why. This section defines the signal architecture, the analytical methods, and the specific behavioural questions that Magee is built to answer.

What to track — and what not to

The temptation in journey tracking is to record everything. The problem is signal density without signal quality. An attendee who scrolls through 40 hotel cards on a mobile device generates hundreds of events that tell us very little about why they did not book. What we need is a concise, structured set of events that map directly to the questions we are trying to answer about capture rate.

✓

Funnel stage transitions

The movement from one stage to the next — registration confirmed, hotel page first viewed, search executed, hotel detail viewed, booking initiated, booking completed. These are the nodes between which leakage occurs. Every transition has a timestamp, a channel attribution, and a reg_id.

✓

Explicit friction signals

Form abandonment at the search step, hotel detail exit without booking initiation, booking form abandonment at payment. These are qualitative signals that require session replay tooling alongside the quantitative funnel data.

✓

Search parameters

Every hotel search records the check-in date, check-out date, guest count, and whether the dates match the event dates. Wrong dates indicate a UX failure in date pre-population; low guest count may indicate we are showing the wrong room types first.

✗

Passive scroll and hover events

Scroll depth and hover events on hotel listing cards generate high data volumes with low analytical value for capture rate improvement. Collect these via session replay tooling (which samples sessions) rather than tracked per-registrant in the Magee event pipeline.

Friction identification — where and why people stop

The funnel has a small number of high-leakage points. Identifying them requires two complementary approaches: quantitative funnel analysis to find where the drop-off occurs, and qualitative session replay to understand why. A hotel detail view to booking initiation rate below 8% is a strong signal that the hotel presentation — price display, room type clarity, availability messaging — is creating hesitation.

Funnel leakage profile (illustrative)

Largest absolute loss: Hotel page → Search executed (900 attendees). Largest relative loss: Hotel detail → Booking initiated (51% drop).

Session replay tools (Microsoft Clarity is free and sufficient for most events; FullStory and Hotjar provide more analytical depth for high-traffic deployments) record anonymised screen interaction. They reveal behaviours that funnel analytics cannot. Three specific session signals are particularly diagnostic:

Rage click

Unresponsive element frustration

Repeated rapid clicks on a single element indicate the user expects it to be interactive and it is not responding. Common in hotel booking: clicking on a price not linked to a booking flow, or a map that does not load on mobile. Each rage click cluster is a candidate UX fix.

Dead click

Mismatch between affordance and function

A single click on an element that has no action. Common with hotel card images (users expect them to open a gallery) and star ratings (users expect them to open a filter). These indicate missing features that the user considers obvious.

Form hesitation

Cognitive load at input fields

A long pause before or during completion of a form field indicates uncertainty. In the hotel search form, hesitation most commonly occurs at the date picker and the guest count field. Both are solvable with better defaults and helper text.

Comparison looping

Decision paralysis on results page

Users who repeatedly cycle between two or three hotel options without committing are experiencing choice difficulty — usually because the differentiating factors between options are not clearly visible at card level.

Repeat visit behaviour

The majority of event hotel bookings do not happen on the first visit to the hotel page. The attendee arrives after the registration confirmation, sees the hotels, may even search — and then leaves without booking. They return later, often prompted by a follow-up email. Understanding this consideration cycle is essential to timing the retargeting sequence correctly and to evaluating the true value of each marketing touchpoint.

Sessions before booking

2–4

Median number of hotel page visits before a booking is completed

Consideration window

3–14 days

Typical gap between first visit and booking — varies by event lead time

Return channel

~60% via email

Of return visits originate from a follow-up email link rather than direct navigation

Date search patterns

Date search errors are one of the highest-frequency, most fixable causes of failed bookings. When an attendee searches for the wrong dates — most commonly searching a single night when the event runs for three days, or searching the wrong month — they will either see no results, see poor availability, or book a hotel for the wrong period entirely and cancel later. All three outcomes damage capture rate.

The correct default dates for a hotel search are: check-in on the evening before the first event day, check-out on the morning of the day after the final event day. These defaults should be pre-populated from the event data, not left to the attendee to fill in.

Metric	What it reveals	Action if elevated
% of searches using default dates	How many attendees accept the pre-populated dates without changing them	If low (<50%), the defaults are wrong or not visible enough
% of searches for wrong month	Date entry errors — searching November for a December event	Add event date confirmation prompt before search executes
% of searches for 1 night vs event duration	Partial stay intent — some attendees attend only one day	Show event schedule in search to help attendees choose their days
Extended stay rate	Attendees adding nights before or after the event	Opportunity: promote extended stay options and local attractions
Search refinement rate	How many attendees change their dates after seeing results	High refinement = results are not meeting expectations at initial dates

Speed to book — minimising cognitive load

The fastest path from registration to confirmed booking is the highest-converting path. Every additional step, every additional decision, every additional screen is an opportunity for the attendee to be distracted, interrupted, or simply to decide they will do it later. Later very often becomes never.

The optimal hotel booking flow for an event attendee who arrives via a registration confirmation email contains three steps: a search results page with pre-populated dates and guest count; a hotel detail page with the room type, price, and a single clear call to action; and a payment and confirmation screen.

Metric	Target	Intervention if off-target
Time from registration to first hotel page view	<24 hours median	Redesign confirmation email hotel CTA — prominence and placement
Time from first hotel page view to booking	<7 days median	Review the Day 2 follow-up email — is it reaching non-converters?
Time spent on search results page before clicking through	<90 seconds median	Too long: too many options, poor sorting; too short: bad results, bouncing
Time from booking initiation to confirmation	<4 minutes	Payment form friction — reduce required fields, add saved payment options
Booking form completion rate	>80%	If below 80%, add form analytics to identify the specific abandonment field

Section 05

Testing — Meaningful, Scalable, Actionable

The capture rate can only be improved systematically if changes are tested rather than assumed. But event housing has a structural challenge that most digital testing frameworks are not designed for: per-event sample sizes are small, test windows are short and non-repeating, and the audience is a single cohort — you cannot run the same person through two different booking experiences simultaneously.

The sample size problem

A typical event may have 1,000 non-local attendees. To detect a 5 percentage point improvement in booking conversion (from 48% to 53%) at 80% statistical power and 95% confidence, the minimum sample size is approximately 900 per variant — very close to the entire non-local population of a typical event. There is no room for multiple variants, and the test will have weak power to detect smaller effects.

Do not run underpowered tests and act on the results

A test with 200 people per variant that shows a 6 percentage point difference has a confidence interval wide enough to include zero effect. Acting on an underpowered result is as likely to move the capture rate in the wrong direction as the right one. Use the cross-event pool approach below for reliable results.

Cross-event test pools

The solution to small per-event samples is to run the same test across multiple events simultaneously, treating all non-local attendees across the pooled events as a single experimental population. This requires a consistent test variant assignment mechanism — assign by a hash of reg_id so the same attendee always sees the same variant if they attend multiple events during the test window — and a consistent outcome definition across all events in the pool.

Test type	Suitable for	Assignment method	Risk level
A/B — single variant	High-traffic events or cross-event pools. One change at a time.	Hash of reg_id — 50/50 split	Low
Email sequence holdout	Testing full email cadence changes — withhold a sequence element from a control group	Random 20% holdout assigned at registration	Low–medium
Multivariate	High-volume events only. Testing combinations of UI changes simultaneously.	Fractional factorial design	Medium
Holdback / shadow	Measuring the effect of a complete new feature vs the absence of it	10% holdback group sees previous experience	Medium
Sequential / Bayesian	Ongoing optimisation with continuous result monitoring and early stopping	Bayesian posterior update as data arrives	Requires statistical expertise

Recommended

Testing philosophy — small, fast, and cross-event

The temptation is to wait for a large event to run a proper test. But a large event that goes badly because of a poor variant is a costly mistake, and the delay waiting for the right event means months of forgone learning. The better approach is to run small, well-scoped changes across many medium-sized events in a cross-event pool. Accept directional results initially. Confirm with higher-powered replication on larger events. Move quickly, record everything, act only on what is significant.

Section 06

Attendee Identification

Before Magee can track an attendee or work to convert them, it must first answer the foundational question with reasonable confidence: is this person non-local? Do they live far enough from the event venue that they will need accommodation?

The identification framework combines three signal types, each assigned a weight that reflects its reliability. The combined score produces a classification with an associated confidence level.

0.5

Registration address or postcode — weight 0.5

The gold standard when available. Geocoding APIs convert addresses to coordinates for Haversine distance calculation against the venue. Accurate to within 0.5% of true geodesic distance. When an attendee provides a full address at registration, this single signal is usually sufficient for classification.

0.3

IP geolocation at registration — weight 0.3

Country-level accuracy of 97–99.8% and city-level accuracy of 66–90% depending on provider. Key limitations include mobile and CGNAT networks, corporate VPNs that show headquarters rather than the user's actual location, and growing VPN adoption. Useful as a corroborating signal and fallback when address data is not available.

0.2

Browser timezone comparison — weight 0.2

Comparing the IP-derived timezone against the browser-reported timezone. Works across all browsers, requires no consent, and cannot be blocked by extensions. Best used as a tiebreaker — a registrant whose browser reports a timezone different from the event venue's timezone is almost certainly non-local.

Distance from venue	Classification	Action
0–50 miles / 0–80 km	Local	Excluded from capture rate audience
50–150 miles / 80–240 km	Likely non-local	Enters capture rate audience, moderate urgency
150+ miles / 240+ km	Definitely non-local	Enters capture rate audience, high priority
International	International	Enters audience, flag for currency and arrival day logic

Section 07

Location Detection Research

Before building the identification layer, HotelMap conducted a deep engineering review of every available technique for determining a web user's true location — including VPN detection and bypass, cookieless identification, browser fingerprinting, and their legal status under GDPR and ePrivacy. The full research document covers the complete technical landscape in six sections.

Technique	Resolution	Consent needed	Reliability
Registration address / postcode	Street level	No (provided at registration)	Very high
IP geolocation (MaxMind / IPQS)	City level	No (legitimate interest)	Good (66–90% city)
Browser timezone	Country / region	No	High
JA4 TLS fingerprinting	Device / browser	No (server-side)	High — cross-browser stable
Canvas / WebGL fingerprinting	Device	Recommended	Degrading on Safari / Firefox

Recommended

Recommended detection stack

MaxMind GeoIP2 as a self-hosted MMDB for baseline geolocation at approximately £25/month, with Spur.us or IPQualityScore for enrichment on VPN-flagged traffic. Fingerprint Pro at £79/month as a probabilistic last resort. Total cost at moderate traffic volumes: under £200/month.

Section 08

The Tracking Journey

The pre-event window between a registrant committing to attend and the event starting can span weeks or months. During that time Magee must maintain a persistent, enriched record of each non-local registrant without relying on third-party cookies, which are blocked on Safari and partitioned on Chrome and Firefox.

Registration

Attendee registers. Classification runs. reg_id assigned.

Confirmation

Email sent with tokenised hotel CTA. Highest-conversion moment.

Nurture sequence

Timed email cadence with rate urgency and availability signals.

Hotel engagement

Page views, searches, cart interactions recorded against reg_id.

Booking

Booking completion matched to registrant. Capture rate increments.

Identity resolution hierarchy

Email retargeting cadence

Timing	Email type	Content strategy
Immediately post-registration	Confirmation + hotel CTA	Highest-conversion moment. Embed hotel booking as an integrated step.
24–48 hours later	Complete your stay	Feature top three hotels by proximity and value. Include rate comparison.
One week post-registration	Rate urgency	Real-time availability data. 'Rooms filling up' with accurate inventory signals.
Two weeks before event	Last chance for group rate	Countdown timer. Social proof: number of attendees who have already booked.
One week before event	Final reminder	Remaining inventory, urgency messaging, any open cart from prior browsing.
Day of cutoff	Urgency close	Book today or lose the group rate. Clear single call to action.

Section 09

Analytics Architecture

The reporting layer is the first deliverable in the Magee build sequence. The analytics architecture records all attendee interactions with reg_id as the primary key, stitching sessions server-side regardless of the browser's cookie and storage policies.

event_registration_complete

Attendee registration event captured.

event_id
reg_id
is_non_local
distance_miles

hotel_page_view

Initial hotel journey engagement.

event_id
reg_id
source
session_number

hotel_search

Search intent and stay dates recorded.

event_id
reg_id
checkin
checkout
guests
dates_match_event

hotel_booking_complete

Conversion and revenue event.

event_id
reg_id
hotel_id
booking_id
revenue
nights

Derived Metrics

Server-side KPIs from the stitched event stream.

capture_rate
time_to_booking
touches_before_conv
revenue_per_attendee

Section 10

Legal Compliance

IP addresses are personal data under GDPR, confirmed by CJEU rulings. The EDPB Guidelines 2/2023 (finalised October 2024) clarified that ePrivacy Article 5(3) applies to device fingerprinting, tracking pixels, IP-only tracking, and URL tracking. The Magee architecture is designed from the ground up to operate within these constraints using a tiered consent model.

No additional consent needed

Legitimate interest covers: IP reputation lookups, ASN classification, timezone and language mismatch detection, HTTP header analysis, and server-side TLS fingerprinting. Passive, server-side techniques that do not access device storage.

Consent recommended or required

Accessing terminal equipment requires consent under ePrivacy: WebRTC leak detection, canvas and WebGL fingerprinting, DNS leak detection, and device fingerprinting for cross-session tracking. The UK ICO labelled fingerprinting for advertising purposes as irresponsible in December 2024.

Explicit consent always required

The HTML5 Geolocation API triggers a browser-enforced permission popup and always requires explicit informed consent. GPS access and any persistent cross-site tracking fall into this tier.

Data controller relationships

The event organiser acts as Data Controller. HotelMap acts as Data Processor under a DPA. Hotels act as separate Data Controllers once bookings are made. Registration forms must include clear privacy notices covering the data flow from registration through to hotel booking. A DPA is required between the event organiser and HotelMap before any data processing begins.

Build on email-tokenised links, not fingerprinting

Email-tokenised links and URL parameter passing are not only more reliable than fingerprinting — they are also the most privacy-compliant method available. They require no consent beyond the event registration itself, work regardless of browser privacy settings, and satisfy the data minimisation principle. Server-set first-party cookies provide the fallback layer. Device fingerprinting is a last resort, used probabilistically with appropriate consent framing, never as the primary identification mechanism.