HubSpot–SeatGeek Integration Case Study: Buyer and Attendee as Separate Records for a Sports Property

Summary

Harbor City Athletic sells roughly 41,000 tickets a season across 22 home fixtures, through SeatGeek. Marketing held one record per purchase, which meant one record per buyer, and treated that record as the fan.

The engagement separated buyer from attendee, resolved identity before any sync, and joined attendance to the person who actually used the seat. Records marketed to who had never attended fell from 34 percent to 4 percent, renewal outreach reaching a season-ticket holder's actual attendees rose from 0 to 61 percent of seats, and duplicate fan records fell from 8,900 to under 400.

Background: The Buyer Is Not the Fan

A ticket purchase names one person. Four people sit down. For a corporate account holding a block, the buyer is an office manager who has never attended a fixture, and the fans are twelve employees the club has no record of at all.

Marketing had been built on the assumption that the purchaser is the audience. Every renewal campaign, every merchandise offer and every attendance-based segment was addressed to the buyer, and the people forming an actual relationship with the club were invisible. Haug, Zachariassen, and van Liempd (2011) separate the costs of poor data quality into the operational cost of working around defective data and the cost of decisions taken on it, and note that neither is ordinarily booked against data. A season of campaigns aimed at the wrong person is the second kind, and it appears on no report as a data problem.

Wand and Wang (1996) treat an information system as a representation of the real world and define a data quality problem as a breakdown in the mapping between the two. One record standing for four people is exactly that breakdown, and no amount of campaign tuning corrects a model that has the wrong entity in it.

The Audit

Three weeks against the portal, the ticketing system and two seasons of scan data.

Unreached attendees. 34 percent of records in the marketing database had never attended a fixture, and the club had no record for an estimated 61 percent of people who had.

Duplicates. 8,900 duplicate contacts, produced mainly by the same person buying under a personal address one season and a work address the next, with no shared key.

Attendance blindness. Scan data existed in the ticketing platform and had never reached the CRM, so no segment could distinguish a season-ticket holder attending eighteen fixtures from one attending three.

Corporate blocks. 240 corporate accounts held blocks averaging 11 seats. The club held one contact for each.

Identity Decided Before Anything Moves

Three record shapes were separated: the buyer who transacts, the attendee who occupies a seat, and the account that holds a block. A person can be all three, and the model has to permit that without collapsing them.

The join key is the SeatGeek user identifier, stored on a dedicated HubSpot property with unique values enforced. Where a ticket was transferred, the transfer target becomes the attendee on that ticket and keeps their own identifier. Matching runs on the key rather than on name or email, because email appears to be what produced the duplicates. Soh and Sia (2004) found that a gap between a package's assumptions and an organisation's structure can be closed only by changing the organisation, changing the package, or building at the boundary; a ticketing platform assumes a purchaser, and the third option is what allows a fan to exist alongside one.

Pipino, Lee, and Wang (2002) set out how data quality can be assessed in practice and give uniqueness a metric of its own rather than treating it as a by-product of careful work. Making the key explicit is what turned duplicate count into a weekly number rather than an impression.

The Build

Six weeks across four phases, using the SeatGeek Enterprise API, a matching pass run in the client's own warehouse, and a private HubSpot app for the write path.

Phase one, deduplication. The 8,900 duplicates were resolved against a survivorship rule agreed in advance, with a full export taken before any merge. Merging is permanent, and the export is the only undo that exists.

Phase two, identity. The SeatGeek identifier property was created and backfilled. Records with no identifier were left unmatched and counted rather than guessed at.

Phase three, attendance. Scan events are written to the attendee record, not the buyer's, as a count per season and a date of last attendance. The count is a property; the individual scans stay in the ticketing platform, because the CRM has no use for 41,000 rows it will never query individually.

Phase four, blocks. Corporate accounts were modelled as a company with attendee contacts associated to it, so a block is a relationship between records rather than a number in a field.

Outcomes

Unreached attendees. Records marketed to who had never attended fell from 34 percent to 4 percent.

Attendee coverage. The club now holds a record for 61 percent of seats occupied, against effectively zero before. The remainder are walk-up and resale transfers where no identity is captured.

Duplicates. 8,900 before, 380 after, with the weekly unmatched count holding under 60.

Renewal targeting. Renewal campaigns for corporate blocks now reach the attendees rather than the office manager, which was not previously possible at all.

Segment accuracy. Attendance-based segments became available for the first time, distinguishing an eighteen-fixture attendee from a three-fixture one.

Campaign efficiency. Email sent to records with no attendance history fell by an estimated 31 percent of total volume, measured against the prior season's sends.

What Resisted

Ticket transfer resisted. A ticket transferred the morning of a fixture changes who the attendee is after the record has been written, and the first implementation wrote the attendee once at purchase and never revisited it.

The mechanism was to treat attendance rather than purchase as the event that names the attendee. The record is written at scan, not at sale, which means it is late but correct. An earlier and wrong answer would have been worse than a later and right one, and stating that trade explicitly is what settled the design.

A second difficulty was organisational. Separating buyer from attendee doubled the visible contact count, and a database that grows by 60 percent overnight looks like a data quality failure on a report that counts records. Karimi, Somers, and Bhattacherjee (2007) found that a deployment becomes a capability only where its outputs enter the working routine of the people the process runs through, and the reporting had to be rebuilt around attendees before the model was left alone.

Limits

This does not prove attendee modelling suits every venue. Harbor City sells a high proportion of its inventory to corporate blocks and season-ticket holders, where buyer and attendee diverge most. A venue selling single tickets to individuals should expect the two to be mostly identical, and the added complexity largely unrewarded.

The design also assumes scan data is reliable. Where entry is not scanned, or is scanned in bulk at a gate, attendance is unknown rather than absent, and the model does not distinguish the two. That is a real limitation.

Figures are drawn from the client's ticketing and CRM reporting. No holdout was run, and the season included a change in email platform that may have affected engagement independently.

Conclusion

The integration is a modelling decision rather than a connector one. The purchase record was always available; what was missing was the recognition that it named one person and represented several.

The general form is that a transaction and a relationship are different objects, and a CRM storing only the transaction may be expected to market to whoever paid rather than to whoever cares.

References

Soh, Christina, and Siew Kien Sia. 2004. "An Institutional Perspective on Sources of ERP Package–Organisation Misalignments." Journal of Strategic Information Systems 13 (4): 375–397. https://doi.org/10.1016/j.jsis.2004.11.001

Haug, Anders, Frederik Zachariassen, and Dennis van Liempd. 2011. "The Costs of Poor Data Quality." Journal of Industrial Engineering and Management 4 (2): 168–193. https://doi.org/10.3926/jiem.2011.v4n2.p168-193

Karimi, Jahangir, Toni M. Somers, and Anol Bhattacherjee. 2007. "The Role of Information Systems Resources in ERP Capability Building and Business Process Outcomes." Journal of Management Information Systems 24 (2): 221–260. https://doi.org/10.2753/MIS0742-1222240209

Pipino, Leo L., Yang W. Lee, and Richard Y. Wang. 2002. "Data Quality Assessment." Communications of the ACM 45 (4): 211–218. https://doi.org/10.1145/505248.506010

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479

Conflict of Interest

RevOps HQ is a HubSpot Solutions Partner and was engaged and paid by the client described.

Acknowledgments

Prepared by RevOps HQ.