The right experience. In the right context.
Reusable audience rules, reader-data services and commercial experiences across web and app.
- THE WORK
- Hands-on platform engineering, architecture and technical leadership
- PROJECT CONTEXT
- Established platform estate
Partner-led Telegraph work, 2017–present
01 / The business problem
Reader engagement sits at the intersection of product, commercial goals and engineering. A paywall, newsletter prompt or subscription message needs to appear in the right context and coexist with the rest of the page. Product teams need reusable ways to introduce those experiences without each campaign becoming a separate application.
This partner-led work at The Telegraph includes the framework behind audience-driven activities and shared reader-data capabilities. Together, these demonstrate the other side of the digital publishing business: supporting the relationship between the publication and its readers.
02 / What we built
Audience rules and activity delivery
The martech framework evaluates audience specifications against visitor, content and profile context. Matching activities can then load and initialise on the appropriate web or app surface, including paywalls, messages and prompts.
Reusable commercial integrations
Shared services and components support identity, checkout, newsletters and offers. Common activity contracts separate the logic deciding when an experience is eligible from the interface that presents it.
Dynamic reader-data capabilities
The reader-data service supports authenticated access to data stored by user and path, backed by MongoDB and Redis caching. This gives products a reusable API for evolving preferences and other reader-specific state.
A closer look
From reader interest to a subscription
The public Telegraph subscription journey, captured September 2026. This shows the commercial context for the shared identity, offer and checkout integrations described here; current offers and presentation can change.
How the pieces fit
- 01
Understand context
Visitor, content and profile rules
- 02
Deliver an experience
Eligible activities across web and app
- 03
Support the journey
Shared identity, newsletter and commerce integrations
03 / Decisions that mattered
Separate targeting from presentation
Eligibility belongs in audience specifications. Keeping the visual activity focused on its own interaction helps reduce duplicated targeting logic and makes the reason an experience appears easier to follow.
Protect the shared contract
A common initialisation contract lets activities live within a larger delivery framework. Changes need to respect both web and app runtimes, including older paths that still serve a purpose.
Give evolving data a reusable API
A path-based data interface allows reader state to evolve without requiring a new bespoke endpoint for every field. Authentication, caching and update behaviour remain central responsibilities of the service.
04 / What this enabled
- A shared mechanism for evaluating audiences and delivering relevant commercial experiences.
- Reusable integration points for identity, newsletters, offers and checkout-related journeys.
- Authenticated reader-data access with caching and update handling.
The audience framework and reader-data service are separate parts of the wider Telegraph platform estate, each with its own delivery and integration responsibilities.
05 / Technical detail
The martech estate contains separate audience definitions, activity implementations, shared components and service wrappers. It evaluates context and dynamically initialises matching activities. The dynamic user-data service is a separate API with authenticated read/write paths, MongoDB storage and Redis caching. Each service has its own integration contract and operational responsibilities.
Engineering and platform work undertaken by Oliver Edgington at The Telegraph.
A similar challenge?
If customer journeys and commercial experiments have become a collection of one-off integrations, we can help build reusable foundations. That includes the data services, targeting rules and delivery contracts needed to keep product changes manageable.
Talk to us about your project
