StubHub data extraction, with the fees reconstructed
The listed price on StubHub is rarely the price anyone pays. We collect the full listing table and carry the fee breakdown through to a true all-in figure, so a comparison against another marketplace actually means something.
| section | row | qty | price | notes |
|---|---|---|---|---|
| 156 | 12 | 2 | $41.00 | Instant download. |
| 119 | 8 | 4 | $76.00 | Mobile transfer. |
| 13 | 4 | 2 | $188.00 | Clear view. |
| 26 | 2 | 2 | $244.00 | Includes club access. |
| DUG3 | A | 4 | $612.00 | Limited view. |
Volume is the easy part on StubHub. Comparability is not.
- FeesBroken out per listing, never folded into one opaque number
- DepthThe full listing table per event, not the first page
- JoinsEvent, performer and venue IDs that survive a name change
Comparing marketplaces on the wrong number
Teams building resale or pricing tools usually start by scraping the number on the listing card. It is the easiest field to get and the least useful one to have, because each marketplace adds its fees at a different point and at a different rate.
- A listing that looks cheapest before fees regularly is not cheapest after them
- Fee rates vary by event, by seller and by delivery method, so a flat percentage will not fix it
- Inventory turns over quickly on high-demand events, so stale data misprices the whole event
- Event names differ between marketplaces, so matching on title alone silently mismatches events
- Listing pages paginate deeply, and stopping early biases every average toward the cheap end
Full depth, with a price you can compare
We collect the complete listing set per event and carry each fee component through as its own field. Events are matched across marketplaces on venue and start time rather than title, which is what makes a cross-site comparison hold up.
The displayed price is not the paid price
StubHub applies most of its fees late, which means a listing that looks cheaper than a competing site frequently is not. Any analysis built on displayed prices alone will reach the wrong conclusion, quietly and consistently. Our schema keeps the displayed price, each fee component and the resulting all-in figure in separate columns, so you can see the gap rather than inherit it.
StubHub collection, field by field
The parts of StubHub that take real work, and how each is handled.
Fee-adjusted true pricing
Display price, buyer fee, delivery and processing charges, tax, and the resulting all-in figure are separate columns. Where a component is not exposed before checkout, it is delivered null rather than guessed at.
Complete listing depth
The full table per event rather than the first page. Cheap seats are the easiest to collect and the least representative of what an event is actually selling for.
Cross-marketplace event matching
Events are keyed on venue and local start time, not on title. Two sites will describe the same concert three different ways, and title matching is where most cross-site datasets quietly break.
Seat-level detail
Section, row, seat numbers where exposed, quantity and split rules, so an analysis can distinguish between four singles and a block of four.
Seller and delivery signals
Delivery method, listing notes and restrictions, kept verbatim. These explain most of the price variance that seat location alone does not.
Any cadence you need
Daily is the usual baseline. Tighter windows around an on-sale or a high-demand event are routine, and we have run seven-day intensive collections producing over sixty million rows.
Why teams ask for StubHub data
True cross-marketplace price comparison
Put StubHub, TickPick, SeatGeek and Ticketmaster side by side on an all-in basis and see which is genuinely cheaper for a given seat rather than which merely looks it.
Repricing your own inventory
Sellers listing across several marketplaces need to know their position on each one, in the terms the buyer sees, updated on a schedule they can act on.
Demand and sell-through analysis
Watch listing counts fall across the run-up to an event to estimate demand curves per section, per venue, per artist.
Feeding a consumer-facing comparison product
If your product tells a shopper where to buy, the number it shows has to be the number they pay. That is a data problem before it is a product problem.
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 StubHub 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 StubHub project
Our production event-pricing pipeline runs on TickPick, where we have delivered over 1.2 billion listing records across 400 or more daily files. StubHub uses the same schema, the same validation and the same delivery mechanism on our side. We tell you which marketplace the record sits on rather than blurring it, then prove the capability the useful way: a working sample built from your own target events, before you commit to anything.
Yes, as separate fields rather than one blended figure. That distinction matters: a single all-in number is not auditable, and when a fee structure changes you want to see which component moved.
On venue and local start time, with performer as a secondary signal. Title matching looks fine in testing and fails in production, because marketplaces title the same event differently and both titles change over the run-up.
Every record carries the timestamp of the observation that produced it. On a daily schedule you see the state of the market at collection time each day; on a tighter cadence, more often. Nothing is backfilled or interpolated.
The events or categories that matter, how often you need them, and what the data is meant to tell you. The technical half is ours: how deep the listing pages go, how the fees behave, what changes when the site changes. Bring the question and the job gets done.
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 StubHub 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.