9.1 Decision Management Architecture & Offer Library Components

9.1 Decision Management and the Offer Library

AD0-E607 uses Offer Library and Decision Management terminology. Journey Optimizer also has a newer Decisioning framework with catalogs, decision items, selection strategies, and decision policies. This section teaches the Offer Library objects in the blueprint; Section 9.3 explains the integration distinction.

Placement and representation

A placement defines the location or content context where an offer appears, together with the compatible content type. Examples include an email hero image, email HTML block, web JSON placement, or text placement.

A representation is the offer content for a placement, potentially qualified by language. One offer can have several representations so the same business proposition can render in different supported placements. The engine can select only a representation compatible with the requested placement.

Do not use one arbitrary image for every channel. Define the placement and representation that fit the channel's format and authoring surface.

Personalized offer

A personalized offer is a candidate marketing proposition. It can include:

• start and end dates;
• one or more representations;
• eligibility through audience or decision rule;
• priority;
• capping rules;
• collection qualifiers;
• custom attributes for reporting or selection;
• governance labels and access controls where configured.

An offer outside its active dates, not approved/usable, ineligible for the profile, capped, or incompatible with the placement is removed from the candidate set.

Fallback offer

A fallback offer provides default content when no personalized offer qualifies. It has representations for placements but does not use the personalized-offer eligibility and constraint model. The purpose is safe, broadly suitable content.

Fallback does not compete in the normal candidate ranking. If at least one personalized candidate remains, ranking selects among those. If none remains, the matching fallback representation is returned.

The fallback should be genuinely appropriate for the audience and channel. “No discount available” or evergreen brand content is safer than a regulated or narrowly targeted proposition.

Collection qualifiers and collections

A collection qualifier classifies offers. A static collection contains offers selected manually. Its membership changes only when an author changes the collection.

A dynamic collection includes offers that match its qualifier rules. When an approved offer gains or loses the matching qualifiers, membership reflects the collection rule. Dynamic collection means rule-based membership, not that the offer creative rewrites itself at request time.

Use a static collection for a tightly curated promotion set. Use a dynamic collection when a governed taxonomy should bring current qualifying offers into the pool without manually editing the collection each time.

Decision

A legacy Offer Library decision brings the components together. For each requested placement it identifies a collection of personalized candidates, a ranking method, and a fallback. At runtime the engine:

1. matches the requested placement and representation format;
2. considers candidates in the configured collection;
3. filters by lifecycle/approval and active dates;
4. applies eligibility;
5. applies capping and other constraints;
6. ranks remaining candidates;
7. returns the selected compatible representation;
8. returns fallback if no personalized candidate remains.

This sequence is the best way to troubleshoot “why did I receive the fallback?” Start with placement compatibility, then lifecycle, dates, collection membership, eligibility, caps, and ranking.

Static versus dynamic

The blueprint can use “static versus dynamic offers” loosely. Separate three ideas:

• a manually chosen static collection versus a qualifier-driven dynamic collection;
• static authored representation content versus personalized content containing expressions;
• legacy Offer Library objects versus the newer Decisioning framework.

State which object changes dynamically. A dynamic collection does not automatically personalize the representation, and a personalized offer can still live in a static collection.

Worked example

A retailer creates an Email Hero placement that accepts HTML. Three approved personalized offers each have an HTML representation. Two are tagged “summer,” so a dynamic summer collection includes them. A decision uses that collection and an evergreen fallback.

For a profile, one summer offer is outside its dates and the other fails eligibility. The engine returns the fallback. Raising the expired offer's priority would not help because ranking occurs only after constraints.

Governance checklist

• Use clear names and qualifiers.
• Verify all required placement representations.
• Set dates in the intended time zone.
• Review eligibility and caps.
• Approve/publish objects in dependency order.
• Test eligible, ineligible, capped, and missing-representation profiles.
• Confirm fallback rendering.
• Collect proposition feedback needed for reporting and capping.