Prestigia.com — Rebuilding the Data & Activation Stack of a Premium OTA

Premium online travel agencies live and die by the trust they can place in their own data. Bidding decisions on Google Ads run on conversion signals; CRM and retention programs run on customer histories; finance reconciles bookings against analytics every month. When the data is wrong — and at Prestigia it was wrong in two parallel systems at once — every downstream decision compounds the error.

This is the story of how we rebuilt the data and activation stack of Prestigia.com, a premium OTA headquartered in Gibraltar and selling primarily into the US market, over a focused multi-quarter engagement.

The state of play

When we audited the stack, two measurement systems were running in parallel and neither produced numbers anyone in the business trusted.

The first was a direct Firebase integration pushing events from the booking flow to Google Analytics. The conversion values it reported were systematically wrong: currency conversions were inconsistent, taxes and fees were treated unpredictably, and the confirmation event fired in ways that double-counted some flows and dropped others.

The second was a Google Tag Manager container with more than 140 active tags, grown organically over years with no governance and no documented funnel. Pixels from retired ad accounts were still firing. Tags listened on page events that no longer existed. The signal was buried under the noise.

The combined effect was that no one in the business — marketing, product, finance, executive — could confidently answer questions like:

• How many bookings did Google Ads actually drive last week, in real dollars?
• Which destinations convert best from search to booking?
• What share of revenue comes from repeat customers?
• Where does the funnel from hotel detail page to checkout actually leak?

Every dollar of paid spend was being optimized against fictional conversions. Smart Bidding was learning from inflated, inconsistent values. The CRM team was segmenting against incomplete customer histories. Finance was hand-reconciling the booking platform with the analytics platform every month, and the gap was widening.

Step 1 — Tracking plan before tooling

The first decision of the engagement was the most important one: we refused to start by touching the GTM container. The first three weeks were spent away from any tool, building a tracking plan rooted in the business. The deliverable was a spreadsheet that mapped every meaningful step of the OTA customer journey to a named event, with the dimensions and metrics each event needed to carry, reviewed and signed off by marketing, product, finance and the engineering lead before any code was written.

The plan covered the full funnel: search queries with destination/dates/occupancy, search results impressions, destination page views, hotel detail views, room rate impressions, refundable toggle interactions, room selection, guest info, payment method, booking confirmation with the full commerce schema, and the post-booking events — cancellation, modification, refund, no-show, check-in, check-out, review.

Each event was modeled to Google's e-commerce schema first — so GA4, Google Ads, Meta and Klaviyo could consume it cleanly with minimum custom code — then extended with the OTA-specific custom dimensions the business actually needed to slice on: lead time to check-in, length of stay, room nights, ADR, refundable flag, currency, destination type. The plan became the single contract between business, engineering, and measurement. Every subsequent debate about "what should this event carry?" was resolved by going back to it.

Step 2 — Rebuild the datalayer, then the tags

Once signed off, the implementation order was strict: datalayer first, then the tags that consume it. The development team pushed a clean, fully-typed datalayer to the codebase that emitted exactly the events from the plan, with exactly the dimensions defined. The Firebase direct integration was retired. The 140-tag GTM container was replaced with a new container containing 22 active tags, each one mapped explicitly to a documented event. Naming convention enforced. No legacy carry-over.

The new container is documented in the GTM workspace itself: every tag links to the relevant row in the tracking plan, every trigger references the canonical event name, every variable has a one-line description. When something changes, it is obvious what changed and why.

Step 3 — Server-side tracking and first-party persistence

For a premium OTA, the consideration cycle is long. A US customer browsing in January for a stay in May will return to the site five or six times before booking. Safari ITP caps client-side cookies at 7 days. Ad blockers and privacy extensions strip another layer of signal. Without server-side tracking, the long consideration cycle was being chopped into disconnected sessions, and the booker looked like a brand new visitor on the final touch.

We deployed a server-side GTM endpoint on a first-party subdomain. Conversion events route through the server container before fanning out to Google Ads (Enhanced Conversions), GA4, Meta CAPI, and the warehouse pipeline. Cookies are set server-side with HttpOnly and a first-party domain, extending persistence well beyond the ITP cap.

The net recovery, measured against the prior client-only baseline, was on the order of 25–35% of conversions that the old stack had been silently losing — a figure consistent with the public Meta and Google benchmarks for server-side rollouts on long-consideration verticals.

Step 4 — BigQuery as the single source of truth

The GA4 native BigQuery export was enabled from day one of the rebuild. On top of the raw export, we built a dbt staging and marts layer designed to give the business one number that everybody could agree on.

The dbt project does three things that the GA4 UI cannot:

• Schema normalization across legacy and new data, so historical comparisons are possible despite the cutover
• Reservation join — every session in GA4 is enriched with the confirmed booking value from the reservation table, in real dollars, post-cancellation. The number on the dashboard is the number on the bank reconciliation.
• Business marts — cohort retention by acquisition month, repeat-booking rate by destination type, channel-level ROAS reconciled against real revenue, funnel drop-off by step

The marts feed both the executive dashboard and the segmentation layer that drives Klaviyo. For the first time, the conversion number flowing into Google Ads matched the conversion number on the CEO's dashboard matched the conversion number in the Klaviyo segment definitions. Finance stopped reconciling by hand.

Step 5 — Klaviyo as a retention engine, not a broadcast tool

Prestigia owned a Klaviyo account but was using it as a newsletter tool — broadcast sends, occasional one-off campaigns, no lifecycle automation. With a clean event stream from the new datalayer and a warehouse behind it, Klaviyo could now operate as the retention engine the business actually needed.

We designed and built lifecycle flows specific to the OTA model:

• Pre-stay: booking confirmation → check-in countdown at T-14, T-7, T-3 days, with destination-aware tips and upsell offers (transfers, experiences, room upgrades)
• In-stay: arrival welcome with concierge-level local recommendations, mid-stay engagement
• Post-stay: review request timed for peak satisfaction, followed by destination-aware rebook offers at 30 and 90 days
• Cancellation handling: refund-detected events trigger automated suppression so refunders are not retargeted with paid ads, and a tactful win-back sequence runs 60 days later
• Win-back tiered: lapsed customers segmented by historical ADR and number of past bookings, with offers scaled to predicted future value

Warehouse-driven segments — RFM tiers, predicted next-booking month, preferred destination type, churn risk — flow back into Klaviyo via Reverse ETL, so the marketing team segments on real customer behavior rather than the limited signal available inside Klaviyo's own database. Klaviyo here also functions as a lightweight CDP for the engagement layer: the canonical user ID flows through the datalayer to the server-side container to BigQuery and back into Klaviyo, so the same person is the same person across every channel.

The retention impact, measured in repeat-booking rate over the first two quarters after the lifecycle engine went live, was in the range of +10 to +15% against the pre-engagement baseline.

Step 6 — Content and SEO/GEO via SurferSEO

A premium OTA competes on content as much as on inventory. Destination guides, hotel reviews, comparison content, and seasonal travel features are how the brand earns organic discovery and answers the long tail of high-intent search queries that paid media will never cover profitably.

In parallel with the data work, we deployed SurferSEO to audit and optimize the strategic content pages — destination hubs, top-tier hotel pages, and comparison content — and to scope a content production workflow that the in-house team could run continuously. The new datalayer captures the organic landing journey cleanly, so the impact of each content investment is now visible in BigQuery alongside paid performance.

This was a complementary work stream, not the centerpiece of the engagement, but it closed an important loop: high-intent organic traffic now lands on pages optimized for both search engines and conversion, and the downstream tracking captures that journey end-to-end.

What changed for the business

The hard outcomes are the four numbers at the top of this case study. The softer outcomes are the ones the team talks about internally:

• The Monday morning marketing standup stopped being a debate about which dashboard to trust. There is one number, and it matches the bank.
• Google Ads Smart Bidding is now optimizing on accurate, server-side conversion signals. CPA and ROAS have stabilized in a way that lets the team plan budget with confidence.
• Klaviyo went from a tool the marketing team felt guilty about under-using to one of the highest-ROI channels in the stack.
• Finance gained back the days every month it used to spend reconciling spreadsheets.

What we would do again, and what we would change

The single best decision of the engagement was the three weeks spent on the tracking plan before any code was written. Every subsequent technical decision was easier because the contract was clear. We will keep doing this on every comparable engagement.

What we would change: we would push harder, earlier, for a full freeze on ad-hoc GTM changes during the rebuild window. The team's instinct (and ours, honestly) is to keep shipping while the rebuild happens, and that creates noise in the cutover data that is painful to clean up in dbt afterwards. Next time: hard freeze, then ship.