Service
First production use case
I build one complete use case, from the agreed source through to an activation or journey that the team can operate.
What is included
- 01
Schema design and identity model for the agreed use case.
- 02
One ingestion flow configured and validated.
- 03
One audience activated to a destination, or a first journey when AJO is in scope.
- 04
Validation criteria and operational observability.
- 05
A runbook covering dependencies, monitoring, and recovery, plus a handover session for the internal team.
Diagram of the Adobe stack. On the left, five ways in: Web SDK through alloy.js, Edge Network in real time, Kafka as streaming, CRM and storage in batch, and Federated Audience Composition, which queries without copying the data. In the centre, Adobe Experience Platform: four applications, Real-Time CDP for segmentation, Journey Optimizer for journeys and decisioning, Customer Journey Analytics for analysis and Query Service for query and reconciliation, all resting on a shared foundation of XDM, identity graph, profile, Data Prep and consent. On the right, the destinations: email, push and SMS channels, ad platforms, commerce, and Adobe Target, which is not built on the platform but on Experience Cloud and receives audiences like an external destination.
Related experience and reasoning
-
Built 2024–2025
AEP architecture across several business lines
XDM model, identities, Web SDK, and offer decisioning for separate business lines on one instance. The first line is never the problem. The problem is keeping the second one from forcing a rewrite of the first.
- XDM
- Identities
- Web SDK
- Decisioning
-
Built 2025–2026
Identity resolution with Data Prep and Query Service
Events and loads from legacy systems were creating duplicate profiles. Identities were resolved at ingestion with Data Prep and reconciled afterwards through scheduled Query Service jobs. Duplicates dropped by around 30% and unmapped emails fell to less than half.
- Data Prep
- Query Service
- Identity
-
Built 2024–2025
The channel in AJO, with Pega untouched as the decision system
I coordinated the channel migration to Adobe Journey Optimizer without touching the decision system, integrating Pega with AEP and AJO, and consolidating more than 30 email campaigns. Changing channel and decision engine at once is the fastest way to lose track of what broke.
- AJO
- Pega
- Migration
- Banking
-
Built 2025–2026
App personalisation with recoverable operational state
Personalisation patterns in Adobe Journey Optimizer for the app, with the reconciliation needed to keep operational state auditable, recoverable, and transferable. Without that, a journey works until the first failure and nobody knows how to put it back.
- AJO
- Operational state
- Handover
Frequently asked questions
We have the licence and never launched. Is that normal?
It is the most common situation I see. The licence brings the platform, not the use case: you still need the source, the data model, identity, and who operates it afterwards. That is exactly what this engagement covers.
Why only one use case?
Because one complete case in production teaches more than five half-built ones, and it leaves the foundation the next ones reuse. Opening five fronts at once tends to end with five things that almost work and none running.
What happens when you finish? Are we left alone?
Handover is part of the deliverable, not a final email. It ships with operating documentation, recoverable state, and proof that your team can run the process without me. If that is not met, the work is not done.
What if we pick the wrong use case?
That is what the first workshop is for. The case is chosen by business value and by dependencies that can be resolved in time, not by which one looks best. A case that depends on data nobody has gets dropped before we start.
Does this fit your problem?
Send me the context and I will tell you whether this scope fits or a different starting point makes more sense.