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 center, 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 2025–2026
The CDP architecture, with the reason for each decision written down
The obvious architecture does not work, and you have to measure it to find out. A journey writing to the profile leaves nothing in the data lake, so any state computed inside a journey needs nightly reconciliation to exist in SQL. Everything else follows: schemas, identity, and what persists where. With the reasons written down.
- Architecture
- AEP
- Data model
- Identity
-
Built 2025–2026
Identity resolution with Data Prep and Query Service
Identities resolved at ingestion with Data Prep and reconciled afterward through scheduled Query Service jobs. Duplicate profiles dropped by around 30% and unmapped emails went from 100% to under 50%.
- Data Prep
- Query Service
- Identity
-
Built 2025–2026
Consent from the event bus to profile and activation
A consent pipeline from Kafka into AEP, with a separate load for the historical state that already existed. Both cadences matter: consent arriving as streaming and consent entering through a bulk load have to end up meaning the same thing.
- Kafka
- AEP
- Consent
- Historical load
-
Built 2025–2026
App personalization with recoverable operational state
Personalization 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
-
Built 2025–2026
The campaign manager, inside AJO and without loops
The previous manager returned, in milliseconds, which incentive applied to each quote. Taking it apart showed a rules engine rather than a recommender, so Decisioning was not the answer for the first scope. The hard part was computing N incentives for N premiums with no loops in the expression editor.
- Journey Optimizer
- Kafka
- Migration
- Decisioning
-
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 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 2024–2025
Journey Optimizer Experience Decisioning in banking
Work on Experience Decisioning, the current decisioning capability in Adobe Journey Optimizer, rather than the Decision Management inherited from the earlier offer decisioning. The difference changes where an offer lives, how it is requested, and what the channel can decide in the moment.
- Experience Decisioning
- Journey Optimizer
- Banking
-
Built 2024–2025
Profile or context attributes: where each value comes from
Personalizing a send has two sources, and picking the wrong one is expensive. What the CDP already knows about the customer comes from the profile. What is only known at trigger time, and therefore cannot be anticipated, travels as a context attribute in the call itself. I defined which of the two feeds each value.
- Journey Optimizer
- Personalization
- Streaming API
-
Built 2024–2025
Retargeting with viewed offers kept in the browser
Retargeting offers without standing up a backend. The last ones the user viewed are kept in the browser, in a short queue fed by the card selection event. They come back with the next decisioning request, so the response does not repeat itself.
- Decisioning
- GTM
- Retargeting
-
Built 2021–2024
Adobe Target as a CDP destination, with audiences governed
Target not as an island but as a CDP activation destination with edge personalization. Publishing audiences from analytics has a cap and takes hours to become actionable, so the rule was written the other way around: audiences are created in the CDP and never in the personalization tool.
- Adobe Target
- Real-Time CDP
- Governance
- Activation
Frequently asked questions
We have the license and never launched. Is that normal?
It is the most common situation I see. The license brings the platform, not the use case: you still need the source, the data model, identity, and who operates it afterward. 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.