Adobe Experience Cloud consulting – full-stack, hands-on
AEP schemas, identity graph, Real-Time CDP segments, AJO journeys – plus federated integration of your warehouse and lakehouse landscape via Federated Audience Composition instead of data copies. One stack, cleanly wired and auditable in regulated environments. If you need the fundamentals first: What Omnichannel Really Means – for Four Roles in the Company.
Core competencies
My focus areas – where pharma, medical and finance gain the most leverage.
Data Insights & Audiences
Adobe Experience Platform
The data foundation: schemas, identity, governance – the basis for every connected journey.
Real-Time CDP
Consolidated HCP/HCO profiles with consent – activatable in real time across all channels.
Customer Journey Analytics
Cross-channel analysis of real journeys instead of isolated channel reports.
Customer Journeys
Adobe Journey Optimizer
Orchestration of trigger-based, personalized journeys in real time.
Adobe Campaign
Cross-channel campaigns for complex, multi-stage communication.
Content & Commerce
Adobe Experience Manager
Web & content (Sites, Assets/DAM) as a scalable, MLR-compliant content foundation.
Marketing Workflow
Adobe Workfront
Planning, prioritization and approval workflows – the process layer where MLR reviews live.
Structured along the four areas of the official Adobe Experience Cloud architecture.
Architecture in detail
How the real-time profile is built
Not a buzzword but a precise mechanism – four steps from raw data to an activatable identity.
XDM schema & identity fields
Schemas define the data language. Fields like CRMID, email or ECID are marked as identities – the basis of every graph.
Identity Graph
A login event carries two identities – person (CRMID) and browser (ECID). Identity Service links them across devices:
{CRMID:ABC · ECID:456}
Real-Time Customer Profile
Profile fragments from all sources are merged along the graph via merge policy – attributes, behavior, identities, consent.
Activation with governance
Segments stream into AJO, web personalization and destinations – DULE labels and policies check every marketing action before delivery.
Mechanics as per Adobe Experience Platform documentation (Identity Service, Real-Time Customer Profile, Data Governance).
Reference setup
What this looks like in a regulated enterprise
Your systems on the left, the data and identity layer in the middle, orchestrated channels on the right – with insights flowing back.
← Swipe sideways to explore →
How to read it: your data flows into the platform on the left, is linked into profiles via the identity graph and delivered as journeys on the right – insights flow back into your warehouse at the bottom.
Architecture logic: DATA → INSIGHTS → ORCHESTRATION → ENGAGEMENT
following the official Adobe Experience Cloud architecture blueprints
Full-stack coverage
Beyond that, I work across the entire stack: Adobe Analytics, Adobe Target, Adobe Workfront, Adobe Mix Modeler, GenStudio / Firefly Services, plus Adobe LLM Optimizer for visibility in AI answer engines (GEO). And the data layer doesn’t end at the cloud boundary: I connect Snowflake, Databricks or BigQuery federated – zero-copy instead of sync jobs.
FAQ
Frequently asked questions
Who is Adobe Experience Cloud worth it for?
For companies that need to orchestrate many channels, strict approval processes and growing data volumes – typical in pharma, medical and financial services. What matters is less the size than the complexity of the journeys.
Do we have to adopt the full stack?
No. The architecture is modular: Adobe Experience Platform as the data foundation, with only the building blocks your use case needs on top. Expansion follows pilot results, not the price list.
How fast does the first productive journey go live?
After the assessment we start with a tightly scoped pilot use case. First journeys typically run before the full build-out is complete – ROI becomes visible via dry-run forecasts before major investment.
Does this replace our IT or our agency?
Neither. I work with your IT on the architecture and enable your marketing to run things themselves. Knowledge stays in-house – that’s the difference from a black-box agency.
Architect and campaign engineer across the Adobe stack
Two jobs, one person. The architecture decides what the stack can do. The campaigns are what actually goes out. In most setups those sit in separate teams, and half of it gets lost in between.
What the architect decides
There are not many of these decisions, but they are expensive when they go wrong – and some of them cannot be reversed afterwards.
- Adobe Experience Platform, XDM. A schema’s class and primary identity are set at the first production load and are effectively fixed after that. Documented in part 1 of the series, with the Adobe source.
- Real-Time CDP. Whether an audience evaluates continuously or falls back to batch depends on the rule, not on the licence tier. The interface does not tell you which one you got.
- Identity Graph. Fifty identities per graph. The fifty-first deletes the oldest, with no error and no warning – the profile drops out of segmentation silently.
- Adobe Journey Optimizer. Where consent is actually enforced, as opposed to where it is merely labelled on a field. That is an architecture question, not a campaign question.
- Adobe Campaign. Does it stay the system of record for transactional sends, or hand that to AJO? This one decision sets your migration path for years.
- Customer Journey Analytics. The stitching field. Choose it wrong and it is not the next report that is wrong, it is every report, retroactively.
- Adobe Analytics. Migrate or federate – and who owns the historical data while both run in parallel.
What the campaign engineer builds
The architecture is only half of it. I build the campaigns myself, not just the foundation underneath – and the daily work looks like this:
- Journeys and campaigns that are still readable at the second release, because somebody else has to take them over.
- Templates and fragments that go through MLR once instead of twelve times.
- Audiences that demonstrably do what the ticket says, and that can be checked against it.
- QA before the send: test profiles, simulation, and the question of who actually signs it off.
- Handover to your in-house team, documented, so the dependency does not sit with me after the project.
When you do not need this
- The stack runs, the schemas are settled, and you need more throughput. That is a capacity problem, not a consulting one – an agency with a team is the better answer.
- The open question is the licence negotiation with Adobe. That is worth a week of requirements work, not more.
- You are still selecting a platform and Adobe is not yet decided. Then the first question is not how the stack gets built, but whether it should be this one.
If you are at a point where the architecture decision and the build belong together, write to me and we will look at your stack.