Accommodation guests who also visit the attraction
When do guests visit — during the stay or another trip?
Of the guests who bought a ticket: was it during the stay, on the same trip but other dates, or on a different trip altogether?
How soon after arrival do they visit?
Days between arrival and the visit. 0 is the arrival day, 1 is the next day. Anything beyond ±14 days is pooled.
By guest country
Where our guests come from and how likely each market is to visit. Ten biggest markets shown; the rest grouped as Other.
By arrival month
Does the visit rate change through the season?
Which tickets they bought
Of the guests who bought a ticket, how many bought each type. A guest can buy more than one.
Guests who cancelled — did they visit anyway?
Guests whose accommodation booking was cancelled: how many still bought a ticket, and how many visited in the week of their original arrival date.
Booking detail
By room rate type
Does the type of room rate make a difference?
By length of stay
Do guests who stay longer visit more often?
Room first, or ticket first?
For guests who visited on the same trip: did they book the room first, or the ticket first?
Data table (selected season) — all the numbers behind the charts
How to read this dashboard
What we are measuring. We have two separate systems — Net Affinity for accommodation bookings and Ticketsolve for attraction tickets — and no shared customer database. This dashboard links the two by checking whether the same e-mail address appears in both. The matching happens inside our data warehouse using anonymised (hashed) e-mails; the dashboard only ever shows counts, never names or addresses.
Where the guest list comes from. For 2025 and 2026 it is a one-off export of the booking system's guest list (Klaviyo) — the only place those guests' e-mails still exist — and it is not refreshed. From 2027 it is fully automated: every morning the accommodation bookings are loaded into BigQuery, an anonymised identifier for each guest is saved to a permanent archive before the booking system hides it, and the match against ticket buyers is recomputed. The tag under the heading shows which source the selected season uses.
Booking detail. Room rate, length of stay and booking order need the full booking record, which only the BigQuery source has, so those cards appear for seasons from 2027 onward.
The figures are a minimum. A match only happens when the same person used the same e-mail in both systems. If a travelling companion bought the tickets, or the guest used a different e-mail, we don't see it. The real share of guests who visit is higher than shown.
"During the stay" means the ticket was for a date between the day before arrival and the day of departure. The 2025–2026 export has no departure date, so for those seasons it means within seven days of arrival, which covers 95% of the visits we can date exactly. "Different trip" means the visit was in another year or more than a month away from the stay.
2027 shows bookings already made for next summer (mostly group blocks). Those figures will fill in as the season approaches.
Updating. The numbers refresh from the data warehouse each morning once the automated feed is switched on. Until then the dashboard shows the snapshot baked into the file (see the date at the top).