Customer Data Platforms: What Actually Works for Fan 360

Thomas Prommer Technology Executive & AI Strategy Consultant Connect on LinkedIn

Published: April 12, 2026

Updated: May 13, 2026

What a customer data platform actually is

I have built or overseen CDP implementations that processed more than 500 million customer records. The pattern is always the same: the company buys a CDP because marketing wants better segmentation, but the real value shows up when the unified data feeds pricing, operations, product, and executive reporting. If you think of a CDP as a marketing tool, you will underinvest in the data engineering and overspend on the activation features.

A customer data platform collects data from every system that touches a customer — ticketing, e-commerce, mobile app, website, loyalty program, POS, email, social, streaming — and resolves it into a single unified profile. That profile updates in real time and is available to any downstream system that needs it. The CRM stores what your sales team types in. The CDP stores what the customer actually does.

The distinction between a CDP and a data warehouse matters too. A data warehouse is optimized for analytics: batch queries, dashboards, historical reporting. A CDP is optimized for activation: real-time segmentation, personalization triggers, audience syndication to ad platforms. Most enterprises need both. The CDP feeds the warehouse, and the warehouse feeds the models that make the CDP smarter.

The Fan 360 model

In sports and entertainment, this unified profile is called Fan 360. The idea is simple enough: stop knowing someone as a ticket buyer in one system, a merch customer in another, a streaming subscriber in a third, and an anonymous app user in a fourth. Build one profile that captures the whole picture.

Here's what a real Fan 360 profile contains. The transactional layer is obvious: every ticket purchased, at what price, in what section, for which event. Merchandise orders. F&B spend at venues. Hospitality packages. Subscription payments.

Below that sits behavioral data, and this is where it gets interesting. Pages viewed on the website and app. Content consumed on streaming. Email opens and clicks. Time spent in venue via WiFi or beacon. Social interactions. Most organizations have this data somewhere. Almost none of them connect it to the transactional layer.

Then engagement data: loyalty tier, survey responses, customer service interactions, event check-in patterns, second-screen activity during broadcasts. And derived attributes: churn probability, lifetime value, price sensitivity, content affinity, next-best-action recommendations. The derived layer is where the CDP earns its keep, but it only works if the layers underneath it are clean.

The profile is only useful if it updates in real time. A fan who just bought a $300 ticket should not receive a promotional offer for the same event five minutes later. That sounds obvious, but it happens constantly when the ticketing system and the marketing platform are not reading from the same profile.

Why multi-brand operators get more from a CDP

This is the part I find most interesting, and it is underappreciated in the market.

A single-team franchise — say, an NBA team — has data from 41 home games a year, a team store, a mobile app, and maybe a streaming deal. That is a decent dataset for personalization within that property. But the ceiling is low because the behavioral surface area is narrow.

A multi-brand operator that runs properties across combat sports, wrestling, live entertainment, hospitality, and media has a fundamentally different data asset. The same fan might attend a UFC event in Las Vegas, watch WWE on streaming from their living room, buy a pay-per-view for a boxing card, stay at a partner hotel for a live experience package, and buy merchandise from three different brand shops. Each interaction adds signal. The composite picture is richer than anything a single property can build.

The advantages fall into three buckets.

The first is cross-property identity resolution. Match a UFC ticket buyer to a WWE streaming subscriber to an On Location hospitality customer, and you stop treating the same person as three strangers. You see portfolio-level lifetime value instead of property-level transaction value. That changes pricing, marketing allocation, and retention strategy in ways that matter at the P&L level.

The second is better models. More behavioral data means better demand forecasting, better churn prediction, and better recommendations. A model trained on a portfolio's data will always outperform one trained on a single property. That advantage compounds with every data source you add.

The third is portfolio-level personalization, and this is the one I think is most underrated. You can recommend a PBR event to a UFC fan based on overlap patterns that no single-property operator could ever detect. You can build cross-property bundles priced on actual willingness to pay. You can find fans who are high-value across the portfolio but dormant on a specific property, and bring them back with the right offer.

This is not theoretical. The operators that have built this capability are seeing 15-25% lifts in cross-property revenue and measurably lower churn on premium tiers. The ones who have not built it are still running separate CRMs for each brand and wondering why their personalization feels generic.

Identity resolution: the hard problem nobody talks about

Every CDP vendor will show you a clean demo where records match perfectly. In production, identity resolution is messy, and it is the single biggest determinant of whether your CDP delivers value or just creates a more expensive data silo.

The problem: the same person shows up differently in every system. Email address A in ticketing. Email address B in the merch store (because they used a different one at checkout). A mobile device ID in the app. A cookie ID on the website. A loyalty number at the POS. Sometimes two people share an account. Sometimes one person has four email addresses. Sometimes a parent buys tickets for the whole family under one name.

Deterministic matching links records when they share a known identifier: same email, same phone number, same loyalty ID. This is reliable but incomplete — it only works when identifiers are shared across systems, and many are not.

Probabilistic matching uses behavioral signals to infer connections: same device fingerprint, similar IP, overlapping browsing patterns, co-located transactions. This catches more matches but introduces false positives. Merging two people into one profile is worse than leaving them separate.

The practical approach: start with deterministic matching on your highest-confidence identifiers (email and phone), then layer in probabilistic matching with conservative thresholds and human review for edge cases. Set merge rules carefully. Decide whether a household is one profile or multiple. Build an unmerge capability, because you will get it wrong and you need a way to fix it without losing data.

If your vendor hand-waves this in the sales process — "our AI handles identity resolution automatically" — that is a red flag. Identity resolution is a data engineering discipline, not a checkbox feature.

CDP architecture in practice

A production CDP has four layers. The technology is mature. The challenge is integration and data quality, not architectural novelty.

Ingestion. Connectors pull data from source systems into the CDP. Real-time event streams (Kafka, Kinesis) for behavioral data like page views and app events. Batch connectors for transactional systems that sync daily (POS, legacy ticketing). Pre-built connectors for standard platforms (Ticketmaster, Salesforce, Shopify, Braze). Custom connectors for proprietary systems. The first 30 days of any implementation are dominated by this layer, because the data is never in the shape the vendor's demo assumed.

Identity resolution. The matching engine described above. This layer needs its own configuration, testing, and monitoring. Match rates, merge rates, false-positive rates — these are operational metrics that need dashboards and alerting, not a module you configure once and forget.

Profile store. The unified customer database. Typically a combination of a real-time key-value store (for sub-second lookups during personalization) and a columnar store (for analytics and segmentation). The profile schema defines what attributes you store, what you compute in real time versus batch, and how long you retain data. Privacy regulations (GDPR, CCPA, state-level laws) shape this layer more than most teams realize at the start.

Activation. APIs and connectors that push segments, audiences, and profile attributes to downstream systems. Marketing automation gets audience segments. The website and app get real-time personalization attributes. The analytics warehouse gets enriched profiles. Ad platforms get suppression lists and lookalike seeds. The dynamic pricing engine gets demand signals. This is where the CDP earns its keep — if the activation layer is weak, the unified profiles sit unused and the whole investment looks like a data warehousing project with a bigger price tag.

Vendor selection: what actually matters

The CDP market has consolidated. Twilio Segment, Treasure Data, Amperity, and Adobe Real-Time CDP dominate the enterprise tier. Kore Software (now Catapult), FanThreeSixty, and Braze (after acquiring SSB) serve sports-specific use cases. Snowflake and Databricks are pitching "compose your own CDP" on top of your existing data warehouse.

Having evaluated and implemented across most of these, here is what I think actually matters in the selection:

Identity resolution quality. This is the differentiator. Ask the vendor to run your actual data through their matching engine during the evaluation. If they resist, that tells you something.

Real-time activation capability. Can the platform push a profile update to your personalization engine within seconds of an event? Or is it batch-only with a 24-hour lag? The answer determines what use cases are possible.

Pre-built connectors for your stack. Every vendor has a Salesforce connector. How many have a Ticketmaster connector? An AXS connector? A venue POS connector? The fewer custom integrations you have to build, the faster you get to value.

Data team fit. Some platforms are built for marketers (drag-and-drop segmentation, audience builder). Others are built for engineers (SQL-based, API-first, infrastructure-level). Pick the one your team can actually operate. The best platform that nobody on your team can use is a worse investment than the adequate platform they can.

Do not pick based on the demo. Every CDP demo uses clean data and shows a magical unified profile in 30 seconds. Your data is not clean, your identity resolution will take months, and the demo skips every hard part.

The mistakes that keep fan data fragmented

I keep seeing the same patterns in failed or underperforming CDP implementations. All of them are avoidable if you know what to watch for.

Starting with too many data sources. The instinct is to connect everything at once. The result is a six-month integration project where nothing is fully working and the team loses confidence. Start with two or three high-value sources (ticketing, CRM, email), get the identity resolution right for those, prove value with a real activation use case, and then expand. Two sources well-integrated beats eight sources half-connected.

Underinvesting in identity resolution. This one is the most common and the most damaging. The vendor promises "90% match rates" in the sales cycle. In production, with your actual data quality, you get 60%. The remaining 40% are duplicates, phantoms, and mismatches that pollute every downstream system. Budget real data engineering time for identity resolution. It is not a configuration step. It is an ongoing discipline.

Treating it as a marketing project. When the CDP is owned by marketing alone, engineering gets involved too late, the data model reflects marketing's view of the customer (not the full picture), and operations, pricing, and product never connect their data. A CDP is data infrastructure. It needs engineering ownership from day one, with marketing as a primary consumer but not the sole stakeholder.

No defined activation use cases before implementation. "We want a unified customer view" is a vision, not a use case. Define the first three things you will do with the unified data before you start building. Example: real-time email suppression for recent ticket buyers. Personalized content recommendations on the app home screen. Dynamic pricing input based on customer lifetime value. If you cannot name the use cases, you are not ready to implement.

No ongoing ownership. A CDP is not a project with a ship date. It is a system that degrades if nobody maintains it. Data sources change schemas. New systems come online. Identity rules need tuning as the data grows. Match rates drift. Privacy regulations change. Assign an owner — a data engineering lead or a customer data team — who is responsible for the health of the platform after launch. If nobody owns it after the initial build, the data quality will visibly decay within twelve months.

Where to start

If you are a multi-brand operator or a mid-to-large sports and entertainment company and you do not have a CDP, here is the path I recommend.

Week 1-2: inventory your data. List every system that contains customer data. For each, document: what identifiers it stores, what events or transactions it captures, how data gets in and out (API, batch export, webhook), and who owns it. This inventory will be depressing. That is normal.

Week 3-4: define three activation use cases. Pick three things you would do differently if you had a unified customer profile. Make them specific and measurable. "Reduce duplicate emails by 30%." "Increase ticket upsell conversion by 15% using LTV-based targeting." "Suppress ticket offers to fans who already purchased for that event." These use cases will drive your architecture and vendor selection.

Month 2: evaluate vendors. Shortlist two or three. Run your actual data through their identity resolution engine. Ask for reference customers in sports or entertainment. Assess pre-built connectors against your stack. Price for three years, not one, because switching CDPs is extremely expensive and you need to make sure the year-three cost is sustainable.

Month 3-4: implement with two sources. Connect your ticketing system and your CRM first. Get identity resolution working for those two sources. Build your first activation use case. Prove value before expanding.

Month 5-12: expand and optimize. Add data sources incrementally. Connect e-commerce, mobile app, POS, streaming, loyalty. Tune identity resolution as the data grows. Build the next activation use cases. Start feeding unified data to pricing, analytics, and operations. This is where the Fan 360 vision starts to become real.