Writing a Measurement Plan Before You Touch GA4 or a Tag Manager

I want to talk about the least glamorous thing I do for a hotel, which is also the thing that quietly decides whether everything else I do can be proven to work.

Before I open GA4. Before I touch Google Tag Manager. Before I add a single line of tracking to your booking engine. I write a document. It is a boring spreadsheet, and it is the single highest-leverage hour of the whole engagement. Because here is the dirty secret of hotel analytics: almost every property I audit has tracking installed, and almost none of it is usable.

The graveyard problem

Let me describe what I find when I log into a typical independent hotel’s analytics. There are 40-plus events firing. One is called click. Another is called button_click. A third is cta_click. A fourth is Book Now. A fifth is book_now_button. Three different people, or three different plugins, or three different freelancers over four years, each named the same human action a different way.

So when the owner asks me a simple question, “how many people started a booking last month and didn’t finish,” I cannot answer it. Not because the data isn’t there, but because it’s scattered across five inconsistent labels, two of which also fire on the contact page, and one of which a theme update broke in March and nobody noticed.

That is a graveyard. Events were buried with no headstones, and now we’re digging.

The fix is not a better tag manager. The fix is deciding, on paper, exactly what you will measure and exactly what you will call it, before anyone implements anything. That document is a measurement plan. Let me show you how I build one for a hotel.

Step one: map the booking journey as it actually is

I don’t start with events. I start with the journey, in plain English, from the guest’s point of view. For most independent hotels it looks roughly like this:

1. Someone lands on a page (homepage, a room page, a blog post, a local landing page).
2. They poke around (look at rooms, photos, the spa, directions).
3. They open the date picker and search availability.
4. They see rates and pick a room or rate plan.
5. They start checkout (guest details, card).
6. They book. Or they bail.

Every one of those steps is a measurement opportunity, and the gap between any two adjacent steps is a leak you can fix. The people who drop between “searched availability” and “saw rates” have a different problem than the people who drop between “started checkout” and “booked.” The first group might be hitting a rate that scared them. The second might be hitting a clunky payment form. You cannot tell those two failures apart unless you decided, in advance, to mark both moments.

This is also exactly where OTA dependence quietly grows. If your direct funnel leaks at the rate-display step and you never see it, the guest just opens a new tab and books you on an OTA at a 15 to 25 percent commission. You didn’t lose the booking, you lost the margin. I wrote about that math in more detail in the book-direct commission breakdown, but the measurement point stands: you can only plug a leak you can see.

Step two: design the event taxonomy

Now I turn each journey moment into a named event. And here is the rule that makes or breaks everything: I pick one naming convention and I never break it.

For GA4, I use lowercase snake_case, verb-then-noun, present tense, and I write events that describe the action, not the button. So not book_now_button. Instead select_room. The event is about what the guest did, not which pixel they touched. Here’s the core spine I use for a hotel booking journey:

Notice there is no click anywhere. “Click” is not a thing a hotel cares about. A click is a mechanism. A booking journey is made of intentions, and I name the intentions.

Parameters: the details that make events answerable

An event tells you what happened. Parameters tell you which one and how much. This is where most setups go thin, and it’s where the real reporting power lives. For search_availability, I attach parameters like these:

• check_in_date
• nights (a number, so I can average length of stay)
• num_adults and num_children
• is_flexible_dates (true or false)

For view_rates and purchase, I attach room_type, rate_plan (member rate, flexible, non-refundable), currency, and value. The day someone asks “are our non-refundable rates actually converting better, and for which room types,” I can answer it in two minutes, because I decided to capture rate_plan as a parameter a year earlier. If I hadn’t, that question is unanswerable and I’d be guessing.

Step three: write it down where everyone can see it

The measurement plan is a living spreadsheet, one row per event. My columns are always the same:

• Event name (the exact snake_case string)
• Trigger (the precise condition, in plain language)
• Parameters (name, type, example value)
• Maps to GA4 standard? (yes for things like purchase and begin_checkout, which GA4 has built-in meaning for)
• Mark as conversion? (only a handful should be)
• Owner (who implements and who validates)
• Status (planned / implemented / verified)

That last column matters more than it looks. An event isn’t done when it’s built. It’s done when someone has gone through a real booking, watched the event fire in GA4 DebugView with the right parameters, and ticked “verified.” I have lost count of how many “implemented” events turned out to fire twice, or fire on the wrong page, or pass the room name into the value field. The plan is the contract. Verification is enforcing it.

Step four: decide what counts as a conversion (and resist marking everything)

GA4 lets you flag any event as a key event. The temptation is to flag ten of them so the dashboard looks busy. Don’t. For most hotels I mark exactly two or three: purchase first, obviously, and usually begin_checkout as a strong secondary signal, sometimes a phone_call or a request_quote for properties that take a lot of bookings by phone.

Why so few? Because the moment everything is a conversion, nothing is. Your Google Ads bidding, your channel comparisons, your “which landing page actually drives revenue” reports all degrade when the conversion definition is mushy. A tight conversion list keeps your reporting honest, and honest reporting is the entire reason we’re doing this. This discipline feeds directly into the book-direct conversion work we do, because you can’t optimize a funnel whose finish line keeps moving.

A small illustrative example

Say a fictional 28-room boutique property runs the plan above for one quarter. They notice that search_availability fires healthily, but only a small slice of those guests reach view_rates, and the drop is brutal on mobile. Because they tagged nights as a parameter, they spot that the leak is worst for one and two-night stays around a local festival weekend, where a minimum-stay rule was silently blocking the search.

I want to be clear that those are illustrative numbers, not a promised result. But that is the kind of specific, fixable insight a measurement plan surfaces and a graveyard of click events never could. The fix there isn’t more marketing spend. It’s a rate rule. You only find it because you instrumented the journey deliberately.

How this connects to everything else

A clean measurement spine is the foundation under the rest of the work. When I’m trying to prove that local search and your Google Business Profile are sending booking-ready traffic, or that the content we publish is earning the kind of attention that turns into direct revenue, I need a purchase event I trust and a funnel I can read. Without it, every channel argues for credit and none of them can be settled.

It also matters for the newer stuff. Everyone’s asking whether they show up in AI search and answer engines now, and that’s a fair question. But the way you find out which content actually moves bookings, versus which just gets impressions, is the same clean conversion data. The measurement plan isn’t separate from your SEO and AEO work; it’s the scoreboard that tells you whether any of it is working.

The best analytics setup I ever built started as a boring spreadsheet that took an afternoon. The worst one I ever inherited started with someone enthusiastically installing tags on a Friday. Plan first. Tag second. Always.

Realistic timeline and what to expect

Writing the plan for a single property is an afternoon of focused work once the journey is mapped. Implementing and verifying it cleanly, with someone walking real bookings through DebugView, is usually a week or two depending on your booking engine and how cooperative it is with the data layer. Then you let it run. Trends in funnel drop-off and channel performance get genuinely trustworthy after a few weeks of clean data, and meaningfully actionable after a couple of months.

No part of this guarantees more bookings by itself. What it does is end the guessing. It turns “I think the website’s doing okay” into “we lose 30 percent of mobile searchers at the rate step and here’s the rule causing it.” That clarity is what lets every other dollar you spend on direct-booking work actually pay off, and it’s how you slowly shift the OTA mix back in your favor instead of flying blind.

If you want a second set of eyes on your current setup, or you’d like me to draft the measurement plan for your property before anyone touches a tag, book a free intro call and we’ll map your booking journey together. It’s the cheapest hour you’ll spend all year, and it’s the one the rest of the work stands on.