9.3 Decision Policies, Ranking & Channel Integration

9.3 Decision Policies, Ranking, and Integration

Journey Optimizer currently exposes both legacy Offer Decisioning/Decision Management concepts and the newer Decisioning framework. The exam blueprint uses Offer Library language, while current product scenarios may mention decision items and decision policies. Do not combine their object names or assume every output works in every channel.

Legacy decision

A legacy Offer Library decision binds placements, collections, ranking, and fallback. Email authoring can use the supported offer-decision content integration to render the selected representation in that email placement. If a legacy decision used in a journey message changes, republish the journey as documented so the message incorporates it.

Legacy ranking commonly uses offer priority or a supported ranking formula. Higher numeric priority wins among eligible candidates. Eligibility, dates, compatibility, and caps are evaluated first.

New Decisioning framework

The newer framework organizes marketing offers as decision items in a catalog. A selection strategy combines a collection, eligibility, and ranking. A decision policy sequences decision items and/or selection strategies, defines how many results to return, and can include fallback.

Strategy order matters: groups are evaluated in their configured sequence. Authors can use priority, formula-based ranking, or supported AI ranking depending on configuration and entitlement. Treat ranking formulas as governed expressions and test null or missing inputs; do not paste unverified PQL examples from legacy material into a different editor.

Content Decision activity

The Content Decision activity on a journey canvas evaluates a new-framework decision policy and returns the selected items into journey context. Its output has a strict limitation: it cannot be used directly in native channel activities.

Supported downstream uses include:

• an Optimize condition that checks whether items were returned and routes the profile;
• a custom action that sends selected item data to an external system.

Therefore, a diagram showing Content Decision feeding offer variables directly into native Email, SMS, or Push is wrong. For native message rendering, use a supported channel authoring integration. Current Decisioning is available directly in supported email and code-based experience authoring, while legacy Offer Decision components use legacy decisions.

Ranking stages

Regardless of framework, reason in this order:

1. request defines surface/placement and profile/context;
2. collection supplies candidate items;
3. lifecycle, dates, and format compatibility filter;
4. eligibility and governance filter;
5. caps filter;
6. configured ranking scores the survivors;
7. requested number of top items is returned;
8. fallback is used if configured and no candidate remains.

Never state a deterministic tie-breaker unless the current feature documents it. Eliminate ties through priority/formula design where determinism matters.

Static personalization versus decisioning

Use ordinary personalization when the content rule is small and belongs to one message, such as greeting by loyalty tier. Use decisioning when a reusable candidate library needs dates, eligibility, capping, ranking, feedback, and selection across placements or channels.

A huge nested message condition that imitates an offer engine is difficult to govern. Conversely, creating a decision policy for two fixed sentences can be unnecessary overhead.

Consent and governance

Decisioning does not create universal permission to personalize. In legacy decision-scope/API use cases, personalization preferences are not automatically implemented merely because an offer was requested; Adobe directs practitioners to incorporate appropriate audience eligibility and a non-personalized fallback.

The newer Content Decision activity documents consent-policy controls only for organizations with relevant Privacy and Security Shield or Healthcare Shield capabilities, with policy updates taking up to 48 hours to apply. Data usage labels on profile, journey event, or offer schema fields can also create policy violations.

The safe design is explicit:

• define the marketing purpose;
• include consent/preferences in eligibility where required;
• provide a non-personalized fallback;
• apply DULE labels and policies;
• verify feature entitlements and propagation time;
• test opted-out, unknown, and ineligible profiles.

Do not claim that a request flag or datastream automatically solves all consent behavior.

Feedback

Decisioning quality and caps depend on proposition feedback. Capture decision/proposition identifiers and send display, interaction, and conversion events as required. A returned offer is not necessarily displayed. Separate request, proposition, impression, click, and conversion.

Integration checklist

1. Identify legacy Offer Library or new Decisioning.
2. Choose the matching authoring component/activity.
3. Verify representation or surface format.
4. Test eligibility, cap, ranking, and fallback.
5. For Content Decision, use output only in supported conditions/custom actions.
6. Implement consent and governance explicitly.
7. Collect feedback.
8. Republish affected content when the dependency requires it.