How Fanatics quantified its data platform value and got the board to care

Fanatics, the licensed sports merchandise giant that has expanded into trading cards and sports betting, was not struggling to get data projects funded in the abstract. The harder problem was familiar to any CDO who has sat in a budget review: the board understood that data mattered, but they evaluated the data platform the same way they evaluated a server rack, as a cost to minimize rather than a capability to invest in. By 2025, with the company operating across three distinct business verticals (e-commerce, Fanatics Collectibles, and Fanatics Betting and Gaming), the sprawl of data pipelines, transformation layers, and reporting inconsistencies had become a genuine operational liability. The question was not whether to modernize, but how to price the value of doing so in terms a CFO would sign off on.

What they did

The data team's first move was to stop defending the platform on technical grounds. Architecture diagrams do not win budget battles. Instead, they mapped every data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → to a revenue-generating or cost-reducing business process, and asked a simple question for each: what breaks, slows down, or costs more if this data product is unavailable or wrong?

That diagnostic produced a prioritized list of business-critical data flows, and it immediately reframed the conversation. The platform was not an IT expense. It was the thing keeping personalization models running during peak sale events, keeping inventory signals accurate across warehouse partners, and keeping odds calculation in the gaming vertical compliant with state-level reporting requirements.

On the transformation side, Fanatics adopted dbt (developed by dbt Labs, a commercial vendor with an obvious interest in this framing) to centralize and document their transformation logic. According to dbt Labs' own published materials, the pattern of separating compute platform decisions from transformation logic decisions is one that many organizations conflate, leading to duplicated work and opaque cost attributionattributionA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results.View full definition →. Fanatics used this architectural separation to build cleaner cost accounting: Databricks handled compute, dbt defined what the data meant and what got rebuilt when. This separation made it possible to measure, for the first time, which models were expensive to run and which downstream consumers actually used them.

The second structural move was implementing dbt's incremental build approach, which rebuilds only the models affected by upstream changes rather than reprocessing full datasets on every run. According to dbt Labs (a vendor, so treat these figures as directional rather than independently audited), Fanatics cut warehouse compute meaningfully using this method. The company itself has not published a specific percentage reduction publicly, so any precise figure would be speculation. What is verifiable is that compute cost reduction became a line item in the ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition → case, not a vague engineering benefit.

The third move was the one that mattered most politically: translating data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → failures into revenue terms. The team calculated the cost of a bad recommendation model during a major drop event (when a limited-edition jersey or trading card releases and drives high traffic), expressed in abandoned carts and lost conversion. They also calculated the cost of delayed inventory sync, expressed in oversell incidents and the customer service overhead they generated. These were not theoretical numbers. They came from incident post-mortems that the team had been running for two years but had never aggregated into a business case.

The results

Fanatics has not published a single consolidated ROI figure for its data platform, and any article claiming otherwise would be inventing it. What is documented is the following: the compute reduction from incremental model builds was substantial enough that it was cited as a business justification for the architectural approach (per dbt Labs' published case study materials, which again carry vendor bias). The data team moved from quarterly budget negotiations to a standing annual allocation, which is itself a governance outcome. When the budget conversation shifts from "justify this again" to "here is your baseline plus growth," the internal case has been made.

The gaming vertical case was the clearest win. Regulatory reporting in sports betting requires accurate, auditable data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition →. The investment in dbt's documentation layer, specifically the automatic generation of data lineage graphs and model-level descriptions, reduced the time required to respond to state regulatory audits. The time saved was priced against the hourly cost of the legal and data engineering staff involved. That number, presented to the board, was concrete and defensible.

What transfers

The Fanatics approach distills into four replicable decisions, though each requires calibration for your own context.

First, build your ROI case backwards from incidents, not forwards from capabilities. The most credible numbers in Fanatics' internal presentation came from documented failures, not projected gains. Every CDO has incident logs. Most have not aggregated them.

Second, separate compute costs from transformation logic in your architecture, not for its own sake, but because it enables cost attribution. You cannot prove ROI on something you cannot measure. The dbt-plus-cloud-compute pattern (again, dbt Labs is a vendor with commercial interest in promoting this) creates the accounting clarity that makes board conversations possible.

Third, price governance outcomes in staff time, not in abstract risk. Regulatory readiness, audit response time, and data quality SLAs all have labor costs attached. Those costs are already in the P&L. The question is whether they are attributed to data infrastructure or buried in departmental overhead.

Fourth, recognize where Fanatics' situation differs from yours. They had a forcing function: three business verticals with genuinely different data models, a live gaming product with regulatory exposure, and enough engineering scale to implement and maintain a modern transformation layer. A mid-size financial services firm or a healthcare system may have the regulatory exposure but not the engineering depth. In that case, the build-versus-buy calculation on the transformation layer changes, and so does the timeline for producing credible ROI numbers.

The board does not need to understand dbt or Databricks. They need to see a table that shows what data failures cost, what the platform investment costs, and what the delta is. Fanatics got there by treating incident history as financial data. That is the method worth copying.