Overview
This solution defines how HotelMap can measure event-related accommodation demand and hotel conversion performance with privacy-first data practices.
The objective is to identify attendees who are likely to require accommodation, then compare that population with those who complete a hotel booking.
What We Must Measure
| Metric | Definition | Purpose |
|---|---|---|
| Addressable market | Attendees likely to need accommodation (for example, non-local or long journey time) | Estimate hotel demand opportunity |
| Hotel capture count | Addressable attendees that complete a hotel booking through tracked channels | Measure conversion into booking outcome |
| Capture rate | hotel_capture_count / addressable_market_count | Primary commercial KPI |
Determining Non-Local Attendees
A binary non-local flag can be collected directly or inferred through coarse location signals. Travel time or travel band is more robust than pure distance because it better reflects real effort to attend.
| Method | Input | Precision | Privacy Footprint | Recommended Use |
|---|---|---|---|---|
| Direct declaration | Accommodation needed (yes/no) or journey 3+ hours (yes/no) | Medium | Low | Primary |
| Coarse origin inference | ZIP/postcode or city-country, mapped to travel-time band | Medium-high | Medium | Secondary |
| IP geolocation | Approximate network location | Low-medium | High | Fallback only |
Implementation Options
Preferred rollout model
Combine a short registration question with travel-time derivation from coarse location where needed. This balances actionable accuracy with low privacy overhead.
Capture Rate Formula
Core KPI for events with accommodation demand: measured against the addressable market, not total registrations.
const addressableMarketCount = nonLocalAttendeeCount;const hotelCaptureCount = bookedAddressableAttendeeCount;const captureRate = addressableMarketCount === 0 ? 0 : hotelCaptureCount / addressableMarketCount;Data Model Decisions
Keep operational data and analytics signals in separate layers so each dataset stays constrained to its purpose.
| Layer | Typical Fields | Retention Guidance |
|---|---|---|
| Operational registration systems | Name, contact data, ticket selections, payment and customer support details | Business and legal necessity |
| Analytics measurement layer | Anonymized event key, travel band, addressable flag, booking outcome, timestamp | Short row-level retention, aggregate long term |
Privacy and Legal Framing
The model can generally rely on legitimate interests when data is minimized, transparent, and proportionate. Consent may still be required for non-essential tracking in some implementations.
| Data Element | Typical Basis | Control Measure |
|---|---|---|
| Direct accommodation need field | Legitimate interests | Keep question narrow and purpose-specific |
| Coarse origin for travel band | Legitimate interests | Derive quickly and remove precise source values |
| Cookie or tag-based cross-site attribution | Consent (jurisdiction dependent) | Gate non-essential tracking and respect opt-out |