Industry
Retail
Omnichannel CX and Intelligent Innovation – The Future of Retail
HIGHLIGHTS
- Efforts to use AI to upgrade retail businesses have yielded improvements, but conversations falter around return on investment. Turns out, the persistent obstacle is architectural and organisational, not technical.
- The question is not how to build any one capability but how to create a shared infrastructure that allows all the layers of monetisation to run on a common foundation, and how to organise accountability for the aggregate output.
- A shared foundation architecture ensures the required governance structures - model registries, audit trails, explainability layers - serve all three monetisation layers simultaneously.
On this page
The monetisation gap nobody talks about
Ask a roomful of retail executives whether artificial intelligence has transformed their business, and most hands go up. Ask how much revenue AI has generated in the past twelve months, and the conversation stalls. The boardroom becomes animated and then quiet, sometimes in the same breath.
The TCS Global Retail Outlook 2026, drawing on responses from more than 800 senior retail executives across 18 countries, quantifies the gap. About 85% of respondents have not begun implementing multi-agent AI systems. Only 24% use AI for autonomous decision-making. More than half still cite basic chatbots and virtual assistants as their leading initiative. These are organisations that have invested meaningfully in AI, not organisations that have avoided it.
In essence, the persistent obstacle is architectural and organisational, not technical. Retailers have built AI capabilities that were never designed to connect with each other and never assigned a clear commercial owner. The result is a set of sophisticated, siloed systems that operate in isolation and underperform as a whole. Consider the pricing algorithm whose recommendations are routed through a weekly email review, or the audience model whose output feeds a manual campaign setup that takes three days. The engine works. The plumbing does not.
There is already extensive writing on the individual components i.e., how to build a retail media network, how to deploy pricing AI, and how to create data products. This paper addresses different questions: why retailers who have invested in each of these capabilities separately still struggle to generate sustained returns from any of them, and what needs to change structurally. That question has acquired regulatory urgency - the EU AI Act enters its compliance phase in August 2026, coming up with obligations that cut across all three monetisation layers. How retailers respond to that deadline will be shaped, in large part, by whether they have already resolved the structural design problems described here.
Three monetisation layers, one structural problem
The phrase “monetising AI” conflates three commercially distinct activities, each with its own technology requirements, established practices, and in most retail organisations its own team, budget, and data platform.
The first layer is audience monetisation, which involves selling access to first-party customer audiences to brand partners via a retail media network.
The second is decision monetisation, involving internal value capture through AI-driven pricing, promotion optimisation, and margin management. This is enabled by closed-loop systems capable of autonomous action at a scale that manual processes cannot match.
The third is insight monetisation: packaging and licensing analytical insights to suppliers and brand partners. Though still the least mature layer for most retailers in the UK and Europe, it arguably offers the greatest potential—capable of generating recurring, high-margin revenue independent of advertising inventory or operational execution.
Layer |
What it is |
Revenue type |
Maturity |
Audience monetisation |
Selling 1st party customer audiences to brand partners via a retail media network |
External-Advertising |
Most established |
Decision monetisation |
AI driven pricing, promotion optimisation & margin management -systems that connect demand signals, competitor intelligence & inventory positions into a decision engine capable of acting not just advising |
Internal – margin capture |
Well understood |
Insight monetisation |
Licensing analytical insights – derived from customer & transaction data, shared to suppliers & brand partners |
External – recurring licensed |
Least mature – highest potential |
The structural failure is not within any single layer. It is between them. Each has been funded as a separate programme, built on a separate data platform, and governed separately. Three teams, three versions of what a customer is, three versions of what a transaction means.
The consequences are compound. A customer identity resolved for media targeting cannot be fed to the pricing engine without reconciliation. A product taxonomy used by the data team does not match the one used by merchandising. The same brand partner may receive an audience segment and a supplier insight product that describe the same customers in contradictory terms, an inconsistency that is difficult to detect and corrosive to trust. The question is not how to build any one of these capabilities but how to create the shared infrastructure that allows all three to run from a common foundation, and how to organise accountability for what they generate in aggregate.
The architecture for sustained monetisation
Despite serving different commercial outcomes, all three monetisation layers depend on overlapping data capabilities. The canonical definitions of a customer, a product, and a transaction underpin retail media targeting, pricing personalisation, and supplier insight products alike. One-time investment in these capabilities can help substantially reduce the incremental infrastructure cost of each additional monetisation layer. However, building these separately can mean the full cost is paid three times, with debt accumulating and requiring reconciliation throughout.
The shared foundation rests on three capabilities. First, data contracts - canonical definitions of customer, product, and transactions enforced consistently across all downstream systems. Without this, the brand partner who receives an audience segment from the media team and an insight product from the data team is comparing two descriptions of the same customers that do not align. Second, an event-driven streaming backbone - pricing decisions require near-real-time data; audience activation runs in minutes to hours; insight products refresh daily. A streaming backbone lets each layer consume from a single consistent source at its own cadence. Third, consent is wired directly into the data layer - under UK GDPR, each monetisation layer processes personal data for a distinct commercial purpose, and in a shared foundation, consent states travel with data and are enforced at the point of computation.
Building the foundation is necessary but not sufficient. A pattern visible across all three monetisation layers is arguably more expensive than any data architecture failure: the system was designed to inform, not to act. The pricing algorithm emails a spreadsheet. The audience model feeds a manual campaign setup. The insight analysis sits in a tool that the supplier’s commercial team cannot access. In each case, the AI output terminates at a dashboard, and a human process carries out the remaining work not by deliberate design but by default.
Closing this gap requires treating decision rights as architectural inputs, not governance afterthoughts. At what threshold does the pricing system execute autonomously rather than flag for review? Who can approve an audience segment for third-party activation without a manual sign-off cycle? These answers shape API design, workflow routing, and audit logging. Retailers who have made progress here share one discipline: they defined these thresholds before the platform was built.
Five design patterns emerge consistently from the implementation experience across UK and European grocery, fashion and general merchandise retail: the distinguishing features of programmes that scale commercially versus those that stall at pilot stages.
Pattern |
What it means in practice |
The shift required |
01 Canonical data entities |
One customer, product, transaction definition shared across media, pricing and inside layers |
from per team data models to single cross functional canonical contract |
02 event driven backbone |
single streaming source; each layer subscribes at its own cadence without separate ingestion pipeline |
from batch extraction per use cases to continuous event publication from one source |
03 governance for enablement |
governance designed to move data at commercial speed within regulatory boundaries |
from “should we share this?” to “how do we share this quickly and safely?” |
04 shared measurement stack |
separate attribution per layer; shared experimentation infrastructure, holdout groups and statistical controls |
from three incompatible methodologies to one credible framework a CFO can interrogate |
PS: The five patterns are not sequential. They are interdependent. Canonical data entities make the streaming backbone coherent. The streaming backbone makes consent enforcement tractable. Commercial ownership makes it all sustainable.
The fifth pattern is the most consequential and the most frequently underestimated: structural ownership of the AI revenue line. When AI-generated revenue is distributed across multiple budgets with no named owner, it lacks a commercial advocate when priorities shift. The retailers who scale past the pilot stage have typically created a distinct commercial function, not a steering committee, with a single individual measured on AI-generated revenue across all three monetisation layers. The data architecture and the organisational architecture must be designed together.
Acting now: Regulatory urgency and a pragmatic roadmap
The EU AI Act enters its compliance phase in August 2026. Algorithmic pricing, automated audience profiling, and derived data products all carry obligations around transparency, human oversight, and traceability. In a shared foundation architecture, the required governance structures are model registries, audit trails, and explainability layers that serve all three monetisation layers simultaneously. In a siloed architecture, each layer builds its own compliance infrastructure independently. Retailers who treat this deadline as a forcing function for structural decisions they have been deferring will be better positioned than those treating it as a documentation exercise.
The sequence below is not a calendar. It describes conditions. Data readiness determines how long each stage takes; the order doesn’t change.
Commerical foundation. A name's P&L owner is in place, measured on AI-generated revenue across all monetisation layers. One layer has been selected. Decision rights: the thresholds between autonomous action and human review are documented as architecture requirements before any technology choices are made. Common blocker: organisational ambiguity over who owns AI revenue in aggregate.
Data readiness established. A data maturity assessment has been completed. Canonical entity definitions – customer, product, transaction, agreed across all the business functions. The gap between the current infrastructure and what the chosen layer needs is documented and funded. Common blocker: customer identification fragmented across legacy systems; no event streaming capability.
Foundational operational. The shared data foundation is live for the first monetisation layer. The first autonomous commercial decision has been executed and is attributable. Returns are tracked against a baseline established before launch. Common blocker: governance gaps that leave the system technically capable of autonomous action but organisationally prevented from taking it.
Foundation extended. The shared foundation serves as the second monetisation layer. If that extension costs a fraction of the first build, the architecture is genuinely shared. If it costs roughly the same, the foundation was built for one layer, not three. Common blocker: foundation built for the first layer only, requiring reconstruction rather than extension for the second.
The UK and European retail market faces converging pressures: contracting margins, expanding regulatory requirements, and rising customer expectations. The technology is mature. What determines outcomes now is the willingness to treat data architecture and business architecture as a single design problem, and to move through these gates before the regulatory window closes.