Data methodology
How event data reaches TicketsAtlas: ingestion, entity resolution, source conflicts, page eligibility and updates.
How a listing becomes a page
Ingestion
Event records are fetched from third-party providers and stored exactly as received, before any interpretation. Keeping the original payload means a mapping mistake can be corrected later without re-fetching, and that what a source said is always recoverable.
Normalisation
Each record is translated into a provider-neutral shape. Names are carried verbatim at this stage — “Oasis”, “OASIS” and “Oasis Live” stay distinct — because deciding they are the same thing is a separate judgement that should be made with evidence.
Entity resolution
Records are matched to canonical artists, venues, cities and events. Where the evidence is not strong enough to merge two records confidently, they are left unmerged and flagged. An incorrect merge destroys information that cannot be reconstructed, so the system is built to decline rather than guess.
Source conflicts
When sources disagree about a field, the winner is decided by how authoritative each source is for that kind of fact — a ticketing platform is definitive about on-sale status and weak about an artist’s history. Losing claims are kept, so a better source or a corrected weighting can change the answer without re-ingesting anything.
Page eligibility
A page is published only when the underlying entity has enough sourced information to be useful: required fields present, real relationships, and more than one thin listing behind it. Pages that do not clear the bar are not created, and each decision records the reason.
Composition and linking
Published pages are assembled from stored facts, and connected to each other through recorded relationships — an artist to the cities they play, a venue to the acts booked there. Links come from those relationships, not from keyword matching.
Updates
The pipeline re-runs as sources publish changes. A page records when its content last changed, and that timestamp moves only when something actually changed — so a date on this site means what it says.
What we do not do
- We do not generate descriptive prose about artists or venues. Where a page has little to say, it says little.
- We do not estimate prices, attendance, capacity or popularity, and we do not present an absent value as a zero.
- We do not publish a page for every possible combination of entities. Combination pages exist only where there is a real, repeated relationship behind them.
Corrections
Because every fact is stored with its source, a correction is traceable to the record that produced it. Where a provider corrects its data, the change flows through on the next update. Where a fact is wrong at the source, it needs correcting there to persist — otherwise the next refresh restores it.
More about what the site publishes is on the about page.