Why travel activities data is an entity-resolution problem, not a scraping problem

Activities look simple until you try to combine them.

A tour appears to have a straightforward data model: title, description, location, image, price, rating and availability.

Then you integrate real supply.

An operator may sell:

• a public version of a tour;
• a private version;
• morning and evening departures;
• several languages;
• different pickup options;
• adult and child tickets;
• seasonal variants;
• special-event departures.

One marketplace may model these as product options.

Another may expose several separate listings.

The operator’s reservation system may represent them differently again.

At that point, collecting the pages is not the difficult problem.

The difficult question becomes:

Which records describe the same underlying experience?

Source identity and real-world identity are different

Suppose the same operator appears on three channels.

One listing is called Old Town Highlights Walking Tour.

Another is Historic Centre Guided Walk.

The supplier calls it Classic City Tour — 2 Hours.

Those may be the same activity.

Or one may include hotel pickup.

One may be private.

One may be a new version of the old product.

One may have a different itinerary even though the title is similar.

Matching only titles creates false merges.

Never matching across sources creates duplicates.

That is why activities data becomes an entity-resolution problem as soon as several sources are involved.

Product mapping is already a core TravelTech concern

GetYourGuide’s current connectivity model makes this explicit.

Its supplier documentation describes option mapping as linking a specific GetYourGuide option to the matching product or option in the supplier’s reservation system so availability, pricing and bookings reference the correct inventory.

See GetYourGuide’s guide to reservation-system connectivity and option mapping.

That requirement reveals the larger data problem.

A marketplace record and a reservation-system record are not necessarily the same entity.

They are different representations of an underlying product.

When several sources are involved, a useful canonical model might look like:

Operator → Activity → Product Variant → Departure → Availability → Price → Marketplace Listing → Review

The exact model varies by product, but the principle is consistent:

source identity and business identity must be separated.

Availability is not static product content

Another common mistake is treating availability like another field on the activity.

It behaves differently.

Viator’s current Partner API separates product-content ingestion from availability schedules. Partners that maintain local catalogs can ingest and update those streams independently, while the booking flow uses a real-time availability and pricing check for the specific product, option, date, start time and passenger mix.

See the Viator Partner API technical documentation.

GetYourGuide similarly uses reservation-system connectivity to exchange availability, prices and bookings.

Architecturally, this means:

Catalog truth and transaction truth have different freshness requirements.

A tour description can remain valid for weeks.

Tomorrow’s 14:30 departure may become unavailable in seconds.

The data model should respect that difference.

Pricing is not just price: 49

Activities can use:

• price per person;
• price per group;
• age categories;
• date-based pricing;
• seasonal pricing;
• promotions;
• time-slot pricing;
• different currencies;
• different rates for different product options.

GetYourGuide supports connected availability and pricing from reservation systems, and its documentation explains that product options must map to the correct external inventory. Viator’s real-time check can return a price breakdown for the actual traveler mix and product option being booked.

Flattening all of that into one number makes the dataset easy to store and hard to use correctly.

A canonical model should preserve the pricing dimensions the downstream product needs.

Reviews create another identity layer

Suppose several channels list the same activity.

Which reviews belong to the canonical experience?

If one listing is private and another public, should their ratings be merged?

If an operator changed the route but kept the listing, where does the historical review set belong?

If the activity exists in several languages, are those different products or variants of the same one?

There is no universal answer.

But there must be an answer encoded in the model.

Useful matching evidence can include:

• operator identity;
• geography and meeting point;
• duration;
• itinerary;
• start times;
• language;
• included services;
• ticket structure;
• photos;
• external product identifiers;
• reservation-system mapping;
• source provenance.

Entity resolution does not have to be perfect to be valuable.

It has to be explicit, observable and correctable.

Normalize once, consume everywhere

The downstream application should not need to understand every source’s quirks.

It should receive predictable entities such as:

activities · operators · options · availability · pricing · reviews · categories · media · locations · provenance

The data layer owns the source-specific mess.

The product layer gets a stable schema.

That separation matters even more when the same catalog feeds multiple consumers: search, recommendations, an AI travel agent, analytics, merchandising and booking.

Without a canonical layer, each consumer gradually rebuilds its own interpretation of the same raw source data.

A practical canonical model

A simplified version could look like this:

Operator

The business supplying the experience.

Activity

The canonical experience a traveler understands: the museum tour, boat trip, food walk or attraction visit.

Variant

A commercially meaningful version: private vs shared, language, pickup type, duration or itinerary variant.

Departure

A specific date/time or operating window.

Availability

Capacity or bookability for that departure.

Price

The applicable price structure and currency for the traveler mix or booking unit.

Listing

How a specific marketplace or supplier surface represents the product.

Review

Feedback attached to the appropriate listing or canonical entity, with provenance retained.

This model is not mandatory.

The point is that the normalized schema should reflect the travel business, not the HTML structure of one source.

Freshness should be field-specific

Not every field deserves the same refresh frequency.

Descriptions, photos and policies may change slowly.

Availability and price can change quickly.

Ratings and review counts can sit somewhere in between.

A strong pipeline treats freshness as a property of the data domain, not a single job schedule.

This is also why silent data-pipeline failures are dangerous: a pipeline can keep producing valid objects while one commercially important part of the object becomes stale.

Activities data gets harder when AI is added

A conversational interface makes entity quality more important, not less.

If a traveler asks:

“Find me a highly rated private food tour tomorrow afternoon under €100.”

the AI layer needs to know which listings are duplicates, what “private” maps to in the product model, whether the current price is per person or per group, and whether tomorrow’s departure is actually available.

That is why AI travel products need a reliable structured layer underneath them. We cover that in AI travel agents have a data problem before they have an AI problem.

Combining activity supply from several systems?

Integrality works on the layer between raw travel supply and a usable catalog: external collection, mapping, normalization, freshness monitoring and delivery.

If you have one destination, source or supplier integration where catalog quality creates disproportionate engineering work, show us that specific gap.