SeatGeek data extraction, deduplicated properly
SeatGeek aggregates inventory from other sellers, which means the same physical seat can appear more than once at more than one price. Counting those twice inflates supply and depresses your average. Handling it is most of the work.
| section | row | qty | price | notes |
|---|---|---|---|---|
| GA | - | 2 | $18.00 | Deal Score 92. |
| 204 | F | 4 | $33.00 | Deal Score 78. Merged, 2 candidates. |
| 111 | B | 2 | $57.00 | Deal Score 61. |
| 105 | J | 6 | $44.00 | Deal Score 84. |
| SIDE | 2 | 2 | $96.00 | Deal Score 40. |
Aggregation means supply is easy to overstate and price is easy to understate.
- ResolvedDuplicate seats merged on section, row, seat and quantity
- KeptEvery merged candidate retained, so a merge can be audited
- As publishedDeal Score stored as shown, not recalculated by us
Aggregated inventory double-counts if you let it
An aggregator's listing page is a union of several sellers' inventory. Some of that inventory is the same seat offered through different channels. Treated naively, the dataset says there is more supply than there is, at a lower price than anyone is paying.
- One physical seat can appear as several listings at several prices
- Fee structures differ by upstream seller, so identical seats show different all-in prices
- Deduplicating by price alone merges genuinely different seats and keeps genuine duplicates
- Deal Score is computed by SeatGeek against its own view of the market, and cannot be recreated afterwards
- Supply counts drive most demand models, so an inflated count corrupts everything downstream
Merge on identity, not on price
Duplicates are resolved on the fields that identify a seat rather than the field that prices it, and every merged candidate is kept in the delivery so a merge decision can be checked rather than trusted.
The same seat, listed more than once
Because SeatGeek pulls inventory from several upstream marketplaces, one seat can surface as two or three listings at different prices with different fee structures. A collector that treats each row as a distinct seat will report more supply than exists and a lower average price than the market has. We resolve duplicates on section, row, seat and quantity, and keep every candidate rather than silently dropping the ones we merged.
SeatGeek collection, field by field
The parts of SeatGeek that take real work, and how each is handled.
Seat-identity deduplication
Merging is done on section, row, seat numbers and quantity. Price is deliberately excluded from the match, because two different seats at the same price are not one listing.
Merge candidates retained
Every listing that was merged into a canonical seat is delivered alongside it. A deduplication you cannot audit is a deduplication you should not trust.
Deal Score captured as published
SeatGeek's own score is stored as displayed at collection time. We do not recompute or normalise it, because its value is that it reflects what the buyer was shown.
Upstream seller attribution
Where the source of an aggregated listing is exposed, it is recorded, which is what lets you see which channel is consistently cheapest for a given kind of event.
Fee handling per source
Fee components are kept separate per listing rather than blended, because on an aggregator the fee structure varies within a single event.
Full event and performer tables
Delivered as separate joined tables with stable IDs, so you can roll up by performer, venue or category without matching on display names.
Why teams ask for SeatGeek data
Accurate supply measurement
Any demand model that uses listing counts needs those counts to be right. Deduplication is the difference between a signal and a number that merely looks like one.
Channel price comparison
See which upstream seller is consistently cheapest for a category of event once fees are accounted for properly.
Deal Score research
Study how a published value score relates to what actually sells, using the score as it was shown rather than one reconstructed after the fact.
Consumer-facing price comparison
If you show shoppers a best price, duplicate listings and blended fees will both make that price wrong in ways your users will notice before you do.
One row per listing, per run
The listing table below is what our running ticket pipeline delivers, joined to an events table on event_id. Fields SeatGeek does not expose before checkout arrive null rather than estimated, and yours is whatever you sign off on before collection starts.
- marketplacestring
Which site the listing came from
- event_idstring
Joins to the event table
- listing_idstring
Stable per listing, so you can track one seat over time
- section_namestring
Section as the site labels it
- row_namestring
Row within the section
- seat_numbersstring
Specific seats where the listing exposes them
- ticket_quantityint
How many seats the listing covers
- value_scorefloat
The marketplace's own value rating, where it has one
- listing_notesstring
Delivery method, restrictions, obstructed view
- display_price_pre_checkoutdecimal
The price shown on the listing page
- all_in_price_pre_checkoutdecimal
Display price with fees folded in, where shown up front
- display_price_checkoutdecimal
Price carried through to the checkout screen
- buyer_fee_checkoutdecimal
Service fee, itemised
- other_fee_checkoutdecimal
Delivery and processing charges
- sales_tax_checkoutdecimal
Tax, where it is broken out
- all_in_price_checkoutdecimal
What the buyer actually pays
- cache_timetimestamp
When this observation was taken
The full event table, the delivery manifest and the collection record are on the ticket data overview.
What this pipeline has actually moved
This is a live event-pricing pipeline on TickPick, running continuously. Not a projection, and not a capability estimate. Figures are rounded and kept current rather than quoted to the digit, because the pipeline adds to them every morning. The same infrastructure and the same schema carry the other three marketplaces.
files_expected ✓ matched files_verified ✓ matched bytes_verified ✓ byte for byte checksums ✓ all pass errors [ ]
- An ordinary day
- 3M+ listings across 30,000+ events
- The busiest day
- 6M+ listings in a single delivery
- NFL season week
- 60M+ rows over 7 days
- World Cup window
- 5M+ rows over 5 weeks
- Super Bowl run-up
- 1M+ rows over 2 weeks
Sample data is available on request
What is above is a summary. Ask and we will show you the rest directly, on a call or a screen share: the run history, the manifests, and a working sample built from your own target events in the schema you want it in. That sample is yours to keep and to test against.
What you will never be shown is another client's delivered dataset, and that is the same undertaking we make to you about yours.
Asked before starting a SeatGeek project
We merge on the fields that identify a seat: section, row, seat numbers and quantity. Price is excluded from the match on purpose, because two different seats priced the same are not duplicates. Every merged candidate is delivered alongside the canonical record so you can check the decision instead of taking our word for it.
Yes, stored exactly as it was displayed at collection time. Recomputing it would defeat the purpose, since its usefulness comes from being the number the buyer actually saw.
Any events on the site: concerts, all major sports, theatre and comedy. Scope is normally set by category, performer or venue rather than by trying to take everything, which is both cheaper and easier to validate.
Our production ticket pipeline runs on TickPick, where the record is over 1.2 billion listing rows across 400 or more daily deliveries. SeatGeek uses the same schema and infrastructure. We say which marketplace the record sits on rather than blurring it, then build you a working sample from your own target events so you can judge the work directly.
Parquet over SFTP is the usual choice at this volume, and it is what our running ticket pipeline uses. CSV, JSON, a REST endpoint or a direct database load are all available. Every delivery carries a manifest listing expected files, verified files and byte counts.
Most projects need more than one marketplace
A price only means something next to another price. Each of these presents a different problem, and each page says which.
Send us three SeatGeek events
Name the events and the fields you need. You get a feasibility read, a proposed schema and a real sample pulled from your own targets, before any commitment.
No retainer required to find out whether your sources are feasible.