The challenge

A global online travel platform had been running Adobe Analytics via AppMeasurement for four years. The implementation covered flight search, hotel booking, and ancillary products across 18 report suites in multiple regions. Leadership had committed to AEP as the long-term data infrastructure — which required migrating to the Web SDK — but the analytics team could not afford reporting disruption during peak booking season. Any significant metric variance would immediately undermine trust in both the migration and the broader AEP investment.

Starting with a full implementation audit

Before writing a single line of Web SDK configuration, we conducted a complete audit of the existing AppMeasurement implementation. Every eVar, prop, event, and plugin was catalogued. We identified which variables were actively used in reports, which had been abandoned, and which were being used inconsistently across report suites.

The audit revealed significant technical debt — 14 custom plugins, several using deprecated methods, and a VISTA rule that transformed data in ways that were not fully documented. These became the first items addressed before migration began.

XDM schema design

Working with the client's analytics and engineering teams, we designed an XDM schema that mapped every active Analytics variable to an appropriate field — either through the standard web schema or the _experience.analytics namespace for direct eVar and prop mapping.

The schema design took three weeks, significantly longer than the technical migration itself. This was intentional. Getting the schema right before implementation prevented the need for breaking schema changes after data was already flowing into AEP.

  • Standard web fields for page URL, referrer, and device context
  • XDM ExperienceEvent fields for search events, booking steps, and conversion
  • _experience.analytics.customDimensions for all custom eVars and props
  • Custom field groups for travel-specific dimensions — origin, destination, travel class

Parallel tracking and validation

We ran both implementations in parallel for four weeks — AppMeasurement continuing to send to existing report suites, Web SDK sending to a parallel validation report suite. This gave us four weeks of side-by-side data to identify and resolve discrepancies before the cutover.

The most significant variance found during parallel tracking was in the visitor count — expected, due to the FPID cookie replacing the legacy s_vi. We documented this clearly for stakeholders so the change in unique visitor figures at cutover was expected rather than alarming.

Outcome

The full migration was completed in six weeks with metric variance under 2% for all key KPIs — page views, bookings, and revenue. The parallel tracking period gave stakeholders confidence before the cutover, and the AEP Web SDK implementation gave the engineering team a single tag to maintain across all 18 report suites rather than separate AppMeasurement configurations per region.