Configure an offer decisioning catalog and eligibility rules
Build a catalog of personalized and fallback offers, define profile-based eligibility rules, assemble those offers into decision scopes, and publish the decision for real-time delivery.
An offer decisioning catalog is the structured inventory of marketing messages a system can serve to a customer at a given moment. Configuring the catalog involves defining each offer's creative representations across channels (web image, email image, non-digital text), attaching date-validity windows, setting frequency caps, and linking eligibility rules that determine which customer profiles qualify. The output is a ranked, publishable Decision object that can be invoked in real time.
Key decisions include choosing the correct channel-placement combinations so creative assets render appropriately, writing eligibility rules that are precise without being overly restrictive, assigning relative priorities among competing offers, and providing a fallback offer that prevents a blank experience when no personalized offer matches. Practitioners also group offers into Collections to optimize the evaluation path, and they choose between static and dynamic collection strategies based on catalogue size.
Parallel viability: Offer Decisioning's real-time next-best-offer decisioning at the edge has no direct parallel in composable stacks. The closest analog is a custom ML model serving decisions via a Hightouch audience plus a message-routing tool, but this approach lacks the millisecond-latency guarantee and unified eligibility-rules engine that evaluate profile attributes and frequency caps in a single API call. Teams comfortable with eventual-consistent personalization can approximate the pattern; teams requiring sub-second, rules-based arbitration across many concurrent offers should treat this task as AEP-locked.
Side-by-side implementations
In Adobe Journey Optimizer's Offer Decisioning service, practitioners create Placements (channel × content-type combinations such as "Web - Image" or "Email - Text"), then build Personalized Offers with representations per placement, profile-attribute personalization tokens, and eligibility rules derived from AEP Segment definitions (e.g., XDM Individual Profile › Person › Gender). A Fallback Offer is added for profiles that match no personalized offer. Offers are grouped into a Collection and combined with placements into a Decision activity, which is saved and activated via the "Save and activate" action. The published Decision is then callable via the AEP Decisioning API or embedded in Journey Optimizer email/web actions.
Capability: Audience Segmentation
Parallel implementation not yet available.
In a composable stack, offer decisioning is implemented as a SQL ranking model in Snowflake: a dbt model joins the offer catalog table (Placements, Eligibility Rules, Personalized Offers, and Fallback Offers modeled as Snowflake tables) with the profile attribute table, evaluates eligibility criteria as SQL WHERE conditions, applies priority ranking with ROW_NUMBER(), and selects the winning offer per profile per placement. The output is a profile_offer_assignment table consumed by Hightouch to sync the winning offer as a profile trait to the destination. Frequency cap enforcement is a SQL counter (e.g., offers_sent_in_last_7_days) joined into the eligibility query. This pre-computation pattern covers the majority of batch-personalization use cases. Real-time edge evaluation — decisioning within the Edge Network call at sub-100ms, enforcing live frequency caps at the moment of page render — is AEP-locked and has no composable parallel without significant custom engineering.
Capability: Audience Segmentation
Pattern: AEP-as-Edge-Node
Task-level sources
- technical-training/module9/index.md
- technical-training/module9/ex1.md
- technical-training/module9/ex2.md
- technical-training/module9/summary.md
How is this implementation?
Sign-in-gated. Tomorrow morning's curriculum-ingestor consumes your feedback: "Inaccurate" queues the task for re-review, "needs update" queues it for a refresh, and "one vendor panel is wrong" re-drafts just that panel.