ga 4 migration

STR Direct Booking: Ga 4 Migration Playbook 2026

Posted on May 23, 2026

Hero

You log into GA4, open the default reports, and still can't answer the questions that matter.

Which channel drove direct bookings last month? Which property pages create inquiry intent? Did your paid search traffic improve booking quality, or just inflate sessions? For many short-term rental managers, the Universal Analytics sunset forced a setup, but not a working analytics system.

That's why GA4 migration is still a live project for STR brands. Google's cutoff wasn't gradual. Standard Universal Analytics properties stopped processing new data on July 1, 2023, and historical access was removed on July 1, 2024, according to Google's Universal Analytics sunset documentation. UA data also wasn't automatically transferred into GA4. If you didn't archive the old environment and design the new one properly, you didn't migrate. You replaced one login with another.

For direct booking teams, that distinction matters. A default GA4 property can tell you activity happened. It usually can't tell you whether your website is creating profitable guest intent. STR websites have a different job than a generic brochure site. They need to track property discovery, rate-checking, booking engine handoffs, inquiry submissions, phone clicks, and confirmed reservations across domains and devices.

A solid GA4 setup for hospitality doesn't start with reports. It starts with a measurement plan built around booking outcomes.

Why Your GA4 Migration Isn't Really Finished

The most common post-migration problem isn't missing code. It's false confidence.

A lot of STR managers technically “moved to GA4” when they installed a base tag and saw pageviews coming in. Then reporting day arrived, and the property manager, marketing lead, or agency opened GA4 and found a mess of generic events, unclear conversions, and channel reports they didn't trust. That's not a finished migration. That's an incomplete implementation.

Default GA4 doesn't answer direct booking questions

GA4 gives you a framework. It doesn't know your booking journey.

If you run vacation rentals, your website probably includes several high-intent actions that need deliberate tracking:

  • Availability checks: Guests compare dates before they commit.
  • Inquiry submissions: Many luxury, group, and extended-stay bookings start with a lead rather than an instant reservation.
  • Click-to-call actions: Phone calls often signal high-value booking intent.
  • Booking engine transitions: If the reservation flow moves to a separate domain, attribution can break fast.
  • Property-level engagement: Not all listing pages create the same quality of demand.

Without that structure, GA4 becomes a log of activity instead of a decision tool.

Practical rule: If your GA4 property can't show the path from landing page to booking intent, your migration is still in progress.

The real migration is analytical, not just technical

The hard part of GA4 migration for STRs isn't placing the tag. It's rebuilding the logic behind your old decision-making.

Universal Analytics was used to answer a handful of business questions, even if those using it didn't realize it. Which campaigns drive direct bookings? Which pages move guests deeper into the funnel? Which devices or locations convert poorly? GA4 can answer those questions, but not with a one-click import because the old data model is gone and the new one works differently.

That's why the useful frame isn't “Did we switch?” It's “Did we rebuild a trustworthy measurement system for direct revenue?”

If the answer is no, that's normal. It also means you still have meaningful work to do.

Audit Your Old Analytics to Define New Goals

Many teams start GA4 migration by trying to recreate every old report. That's a mistake.

Universal Analytics was full of reports that nobody used after the first month. What matters now is identifying the small set of questions that influenced marketing spend, website changes, and booking decisions. Your audit should be selective and blunt.

A person analyzing UA reports and planning GA4 goals on a drafting table to improve digital analytics.

Audit decisions, not dashboards

Open whatever historical material you still have. That might be exported UA reports, agency decks, Looker Studio dashboards, or spreadsheet snapshots. Then ignore the vanity metrics and ask:

  1. Which report told us where direct bookings came from?
  2. Which report showed whether property pages were doing their job?
  3. Which conversion actions did we optimize against?
  4. Which campaign tags or traffic sources did we trust enough to use in budget conversations?
  5. Which pages consistently introduced qualified guests into the funnel?

That exercise usually shrinks the migration scope fast. Most STR brands don't need every legacy view rebuilt. They need a reliable way to track channel performance, property-page engagement, lead generation, and booking completions.

Accept that metrics won't match cleanly

One reason this audit matters is that GA4 and Universal Analytics don't measure behavior the same way. iCrossing notes that the measurement models are inherently different, with typical variances under 10% for pageviews and users, but 15% or more for sessions when comparing the two systems, as explained in their GA4 migration guide. If you try to force a one-to-one rebuild, you'll spend weeks chasing “discrepancies” that are structural differences.

That's why I advise STR teams to write a short migration brief before touching tags or reports.

Use something like this:

  • Keep: Reports that directly affected pricing, paid media, SEO, content, or booking UX decisions.
  • Drop: Reports nobody used to make a decision.
  • Rebuild differently: Anything based on sessions, goal completions, or old attribution logic.
  • Clarify ownership: Decide who owns event definitions, who validates them, and who signs off on conversion reporting.

The right output from this audit isn't a list of old reports. It's a shortlist of business decisions your new setup must support.

The shortlist most STR managers actually need

For most vacation rental brands, the core reporting set is small:

  • Channel to booking report: Which sources produce reservations or qualified leads.
  • Landing page effectiveness report: Which pages pull guests into the booking journey.
  • Booking funnel report: Where intent drops between property view, availability check, booking start, and confirmation.
  • Lead quality report: Which inquiry sources result in real sales conversations.
  • Property-page comparison report: Which listings underperform despite solid traffic.

If you can define those clearly, your GA4 migration stops being abstract and starts becoming useful.

Create Your STR Measurement Plan

For GA4 to make sense, stop thinking in terms of old “goals” and start thinking in terms of events tied to guest intent.

An STR measurement plan should describe what a guest does, why it matters, and what data needs to be sent with that action. This isn't paperwork for its own sake. It's the blueprint that keeps your developer, marketer, and reporting owner aligned.

Think in guest actions, not generic events

A vacation rental funnel usually has clear milestones:

  • a guest lands on a property page
  • checks dates or rates
  • opens the booking engine
  • submits an inquiry
  • clicks to call
  • completes a reservation

GA4 is built around events and parameters, so each of those actions should be defined explicitly. If you skip this planning step, your property fills up with vague event names that nobody understands six months later.

Here's a practical mapping model.

UA Goal to GA4 Event Mapping for STR Websites

User Action on STR Site Universal Analytics Goal (Old Way) Recommended GA4 Event (New Way) Important Parameters to Send
Guest views a property detail page Destination goal or pageview-based reporting view_item or custom property-view event property_name, property_id, page_type
Guest clicks Check Availability Event goal begin_checkout property_name, property_id, stay_dates if available
Guest starts booking engine flow Destination or event goal begin_checkout or booking-start custom event booking_engine, property_id, page_location
Guest submits an inquiry form Form submission goal generate_lead property_name, property_id, lead_type, form_name
Guest clicks phone number Event goal custom call-click event property_name, property_id, contact_method
Guest reaches booking confirmation Destination goal on thank-you page purchase transaction_id, value if available, property_id, booking_type
Guest signs up for email offers Event goal sign_up signup_location, audience_type
Guest clicks a promotional banner Event goal select_promotion promotion_name, creative_slot, property_id if relevant

Keep the naming clean

The best event plan is boring in a good way. Names should be stable, readable, and consistent across properties.

A few rules work well:

  • Use recommended GA4 events where they fit. generate_lead, purchase, and sign_up are easier to work with than made-up alternatives.
  • Reserve custom events for actions GA4 doesn't describe well. Phone clicks are a good example.
  • Send useful parameters. Property ID, page type, booking engine name, and lead type usually matter more than decorative metadata.
  • Document trigger conditions. “Generate lead” should mean one thing, not three different form outcomes.

If you're tightening campaign attribution at the same time, review how UTM links work for cleaner campaign tracking. Poor tagging upstream creates messy GA4 reports downstream.

Focus on direct booking leverage

Not every interaction deserves equal weight. For STR managers, the high-value tracking points are the ones closest to revenue.

I prioritize four categories:

  • Discovery events: property views, landing-page entries, search interactions
  • Intent events: availability checks, booking engine clicks, inquiry starts
  • Lead events: inquiry submission, phone click, quote request
  • Revenue events: completed bookings and confirmed reservation value when available

Build the plan around moments that change a marketing decision. If an event won't influence spend, content, or UX, it probably doesn't belong in the first version.

That restraint matters. A lean event model is easier to implement, easier to validate, and far more useful in reporting.

Implement Tracking via Google Tag Manager

Once the measurement plan is done, Google Tag Manager becomes the control room.

For most STR sites, GTM is the cleanest way to deploy GA4 without hard-coding every event into the website. It gives you one place to manage the core GA4 configuration, event tags, triggers, and testing workflow. It also reduces the odds that marketing, development, and paid media teams all create competing versions of the same tracking.

A hand-drawn illustration depicting the Google Tag Manager and Google Analytics 4 integration process on a digital tablet.

Start with the base GA4 configuration

Before building custom events, confirm the basics:

  • Install one GA4 configuration tag: Use the correct Measurement ID from your web data stream.
  • Fire it on all pages: Limit exceptions unless you have a documented reason.
  • Check the data stream in GA4: Make sure hits are arriving before adding complexity.
  • Use GTM preview mode: Test every step before publishing.

If your setup is messy and multiple scripts have accumulated over time, this is also a good moment to address fragmented data for D2C with a cleaner GTM governance process. That advice applies well to hospitality sites with layered plugins, booking widgets, and campaign scripts.

Build one critical event first

For STRs, I usually start with either generate_lead or the booking-start event. Both represent clear commercial intent.

A simple inquiry form implementation in GTM looks like this:

  1. Create a GA4 Event tag.
  2. Set the event name to generate_lead.
  3. Add parameters such as property_name, property_id, and form_name.
  4. Create a trigger based on the form submission success state, not just a click.
  5. Test the submission in GTM preview and verify it appears in GA4 Realtime.

That last point matters. A button click trigger is often too loose. If the form fails validation but the click still fires, your lead count becomes inflated.

For teams that need a refresher on deployment basics, this walkthrough on tracking code for Google Analytics is useful background before deeper GTM work.

A practical STR example

Click-to-call tracking is a good second implementation because it's common and easy to misuse.

If your property page includes a clickable phone link:

  • use a Just Links trigger in GTM
  • narrow it to links beginning with tel:
  • add conditions for property page templates if needed
  • send a custom GA4 event such as call_click
  • include parameters like property_name and page_location

That gives your team a cleaner view of which listings generate high-intent phone traffic.

A visual walkthrough can help if your team is building tags internally:

Validate before you trust the numbers

This is the part many teams skip, and it's why reporting breaks later.

Independent migration guidance recommends running UA and GA4 in parallel for about 1 to 2 months to validate implementation, especially for booking funnels and lead events, as noted in this Google Analytics vs GA4 migration guide. The point isn't to make the numbers match exactly. They won't. The point is to confirm that directional trends, conversion triggers, and attribution paths are behaving as expected.

Use a validation checklist:

  • Check page coverage: the measurement ID should fire on every core page type.
  • Confirm event logic: events should trigger on success conditions, not hopeful interactions.
  • Walk the funnel manually: property page to availability to booking engine to confirmation.
  • Verify source data: make sure tagged campaigns appear correctly in acquisition reporting.
  • Review with the booking team: they often spot mismatches faster than marketers do.

Good GA4 implementations are tested like product features. They aren't “done” because tags were published.

Configure Key Settings for Booking Data

Even with the right tags in place, the GA4 property itself still needs configuration. Failure to complete this process often results in many STR teams leaving money on the table.

The biggest issue is that GA4 ships with defaults that don't reflect hospitality buying cycles. Vacation rentals often involve repeat visits, longer consideration windows, and seasonal comparisons. If you leave the property untouched, reporting gets shallow fast.

A hand-drawn illustration depicting GA4 configuration settings, a booking calendar, house icon, and access key.

Change retention before you forget

One of the first settings I change in every new property is data retention. GA4's default retention for user-level data is 2 months, and migration experts recommend extending it to 14 months, as covered in this GA4 migration guide from DashThis.

That's a practical requirement for STR businesses. You need enough history to compare peak season to peak season, shoulder season to shoulder season, and long-window booking behavior over time. Two months won't help you analyze year-over-year direct booking patterns.

Mark the right events as conversions

Inside GA4, not every event deserves conversion status.

For most STR operators, the shortlist usually includes:

  • purchase: confirmed reservation completion
  • generate_lead: inquiry form completion
  • booking-start event: only if your team actively optimizes mid-funnel intent
  • selected phone lead event: if phone bookings are a core sales path

Keep the list tight. If everything becomes a conversion, nothing is prioritized correctly.

Fix cross-domain tracking early

A large share of vacation rental sites send users to a separate booking engine domain. If cross-domain tracking isn't configured properly, GA4 may treat the booking step as a new session or misattribute the conversion. The result is familiar. Direct traffic looks inflated, referral exclusions get messy, and channel quality becomes hard to trust.

Review these items carefully:

  • Your main website domain and booking engine domain
  • Unwanted referrals from payment or booking platforms
  • Whether session continuity persists through reservation completion
  • Whether confirmation events fire on the final domain

This is one of the first things I test manually with a tagged visit.

Booking data gets distorted fastest at the domain handoff. If attribution looks strange, start there.

Link the rest of your stack

GA4 works better when it isn't isolated.

Connect the property to:

  • Google Ads so imported conversions can support bidding and campaign evaluation
  • Google Search Console to connect landing-page performance with search behavior
  • Google Tag Manager for cleaner maintenance and event governance

Then verify that the booking confirmation and lead events appear in GA4 before changing any ad platform dependencies. Don't let Google Ads optimize against an event you haven't validated inside Analytics.

Build Your New STR Reporting Dashboards

Once the setup is stable, significant value emerges in reporting. At this stage, many teams fall back into old habits and try to copy UA layouts. Don't.

Copying UA settings into GA4 creates bad data decisions because GA4's event-based model changes attribution logic, which is why STR brands need to rebuild funnels and channel reporting carefully, as explained in Plausible's comparison of UA and GA4. The smarter move is to build reporting around the commercial questions you need answered now.

A professional analyzing hotel data metrics on a digital dashboard to generate actionable business insights.

Three dashboards that matter

Inside GA4 Explore, I'd build these first:

  • Booking funnel exploration: Start with property page view, then availability check, booking start, lead submission, and purchase. This shows where intent leaks.
  • Channel performance report: Compare source and medium against lead and booking events so direct bookings aren't judged on traffic alone.
  • Landing-page report: Rank property pages, area guides, and blog content by generated leads and bookings, not just entrances.

For teams refining interpretation skills, this guide to effective website traffic analysis is a useful companion to dashboard work.

Keep the analysis tied to action

A dashboard is only useful if someone can change something because of it.

If a landing page drives traffic but no booking intent, rewrite the page or improve its calls to action. If paid social generates inquiries but paid search generates purchases, adjust budget by funnel role instead of forcing every channel to do the same job. If one property gets traffic and phone clicks but few reservations, inspect rate presentation, fee clarity, and booking friction.

If you want a broader framework for reviewing traffic quality after the migration, this practical guide on how to analyze website traffic fits well with an STR reporting workflow.

The best GA4 dashboards for vacation rentals aren't broad. They're opinionated. They tell your team what to fix next.


If your STR brand wants a stronger direct booking engine, hostAI helps tie the whole picture together, from website experience and email marketing to paid acquisition and conversion-focused growth systems built for vacation rental managers.

Get a Free Demo

Join other leading STR brands in leveraging the power of AI to boost your direct bookings.

Go Live the Next Day