Adobe Journey Optimizer Partners

The constraint is upstream of the canvas

Every journey depends on three things being true: the triggering event arrives within the latency the journey assumes, the profile attributes referenced in conditions are populated and current, and the identity used to address the person resolves to a valid channel address. Any journey design can be drawn on a whiteboard. Only some can be built, and which ones depends entirely on those three facts. An abandoned-basket journey is trivial if basket events stream in within seconds and hard to the point of pointlessness if they arrive in an overnight batch.

Ask for a data readiness assessment as an early, separately identifiable deliverable: for each event the journeys depend on, its source, its latency, its completeness and its identity coverage; for each profile attribute, where it is mastered and how often it refreshes. This document is what turns an aspirational journey map into a buildable specification. It also tends to reveal that the first phase should be one or two journeys built on solid data rather than a dozen built on hope.

Journey architecture and how it fails

• Unit versus business events — one is triggered by an individual's action, the other by a broader occurrence, and choosing wrongly forces a rebuild.
• Entry and re-entry rules — whether a person can be in a journey twice determines how often someone receives a duplicate message.
• Wait steps and profile drift — a person's attributes can change during a long wait, so conditions must be re-evaluated at the point of send.
• Frequency capping across journeys — independent journeys will collide unless capping is configured centrally from the start.
• Error and timeout paths — every external data call in a journey needs a defined behavior for when it fails, or people fall out silently.

The mobile channels carry hidden engineering work

Email is largely configuration. Push, SMS and in-app messaging are not. Push requires the Adobe mobile SDK integrated into your application, credentials and certificates registered for both Apple and Android, device tokens flowing into the profile, and a release cycle through the app stores for anything that needs a client change. In-app messaging requires the SDK to define where messages can appear inside your application and how they interact with your existing navigation and modals. SMS requires a provider integration, number provisioning, consent capture that meets the rules of each market and handling for inbound stop keywords.

Scope that engineering work explicitly and schedule it against your application release calendar rather than the journey build. It is common for the journeys to be ready weeks before the app update that makes push usable, which is an avoidable and fairly expensive kind of waiting.

Ask specifically who does the in-application work and who owns the SDK version going forward. A mobile SDK that is never upgraded becomes a compatibility problem at the next operating system release, and the team that integrated it has usually moved on. Agree that ownership at the start, along with how a test push is verified on real devices before a campaign goes to your full base.

Decisioning and offers

Journey Optimizer includes a decisioning capability that selects which offer to present to a given person from a catalog governed by eligibility rules, ranking and capping. It is genuinely useful when you have a real catalog of competing offers and rules about who may receive what. It is substantial overhead when you have four promotions and no conflicts, because you are maintaining a decisioning model to answer a question a simple condition could answer.

Be honest about which situation you are in. If offers are in scope, ask how the catalog will be maintained and by whom, how eligibility rules are tested before they go live, and how capping interacts with the frequency rules already applied at journey level. Ask also how you would tell whether decisioning is choosing well, because without a holdout or a comparison you have an automated allocation that nobody can evaluate and nobody can defend at renewal.

Authentication and IP warming are not afterthoughts

Sending well is a technical discipline that starts weeks before the first campaign. You need sending domains configured with the right authentication records, so that receiving mailbox providers can verify the mail genuinely comes from you, and a policy record that tells them what to do with mail that fails. Getting these wrong does not usually produce a visible error; it produces quietly worse inbox placement, which is much harder to detect and much slower to repair.

If you are moving to new sending addresses, those addresses have no reputation and must be warmed: volume increased gradually, starting with your most engaged recipients, over a period of weeks. A migration plan that schedules full production volume on day one from cold addresses will generate throttling and bulk folder placement across major providers, and recovering from that takes longer than the warming would have. Ask for the warming schedule as a dated plan with volumes, not as a principle that everyone agrees with.

What to monitor from the first send

• Placement, not just delivery — accepted by the receiving server and landing in the inbox are different outcomes.
• Provider-level breakdown — reputation problems usually appear at one major mailbox provider first, and an aggregate rate hides that.
• Bounce classification — hard bounces must suppress permanently, and soft bounce patterns are an early warning sign.
• Complaint feedback loops — registered feedback loops turn spam reports into suppressions instead of silent reputation damage.
• Engagement-based sending — long-term unengaged recipients should be reduced or stopped, because continuing to mail them costs you placement for everyone else.

Rationalise campaigns, do not transcribe them

The default migration approach is to inventory the existing campaigns and rebuild them in the new tool. This is the most expensive available option and it usually reproduces years of accumulated cruft. Most established marketing estates contain sends that overlap heavily, sends that exist because someone asked once in a previous year, and sends whose audience has shrunk to a handful of people. Rebuilding those faithfully means paying to carry them forward and then paying again to maintain them.

Insist on a keep, merge or kill decision for every existing campaign, made against its actual volume and measured contribution, before any rebuild work starts. This is uncomfortable because it requires owners to defend their sends, but it typically removes a substantial share of the migration scope. It also means the journeys you do build are designed for how the new tool works rather than shaped by a legacy tool's constraints, which is most of the value of moving in the first place.

What changes for the people running campaigns

Journey Optimizer changes the daily work of a marketing team in ways that are easy to underestimate. Audiences come from the unified profile rather than from lists built in the tool, which means the person who used to control their own segment now depends on the profile being right and on governance policies allowing the use. Journeys run continuously rather than as scheduled batches, so the rhythm shifts from planning sends to monitoring live flows. Errors surface differently and require different diagnostic habits.

Budget for this explicitly. Ask what the operating model looks like after go-live: who builds journeys, who approves them, who reviews performance, and what a person needs to know before they are allowed to publish something that reaches customers. Ask for training that is delivered against your own journeys and your own data rather than generic product material, because the questions that matter are about your schema and your governance rules.

Programs rarely stop at one product. Buyers hiring for Adobe Journey Optimizer often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Campaign partners , or review the whole Adobe landscape before committing.