ExamFinch.com My Study

Study guide

9.2 Offer Eligibility Rules, Constraints & Capping

Practice this exam

Adobe Certified Professional - Adobe Journey Optimizer Business Practitioner AD0-E607

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Structure & Journey Fundamentals

1.1 AD0-E607 Exam Logistics, Scope, and Adobe Journey Optimizer Architecture 1.2 Journey Lifecycle States and Canvas Management 1.3 Unitary Journeys vs Business Journeys

2 Chapter 2: Journey Triggers & Event Modeling

2.1 Audience-Based Entry with Read Audience & Audience Qualification 2.2 Unitary Event Triggers & Schema Requirements 2.3 Business Events & Audience Broadcast Execution

3 Chapter 3: Journey Orchestration, Timing & Logic

3.1 Condition Activities and Branching Logic 3.2 Wait Activities and Timing Modulation 3.3 Action Nodes and the Jump Activity

4 Chapter 4: Journey Testing, Execution & Operational Reporting

4.1 Validation, Simulation, Test Mode, and Dry Run Execution 4.2 Live & All-Time Reporting Dashboards 4.3 Error Handling, Discards, and Operational Governance

5 Chapter 5: Multi-Channel Content Design & Personalization

5.1 The Email Designer & Multi-Channel Canvas Structure 5.2 Personalization Syntax & Expression Editor 5.3 In-App Messaging & Web In-Browser Delivery

6 Chapter 6: Reusable Assets, Fragments & Content Experiments

6.1 Visual Fragments vs Expression Fragments 6.2 Assets Essentials Management and Content Templates 6.3 Content Experimentation and Pre-Deployment Proofing

7 Chapter 7: XDM Schemas, Ingestion & Real-Time Customer Profiles

7.1 Experience Data Model (XDM) Foundations for Journey Optimizer 7.2 Datasets, Profile Enablement & Ingestion Troubleshooting 7.3 Real-Time Customer Profile & Profile Merge Policies

8 Chapter 8: Identity Resolution, Segmentation & Data Governance

8.1 Identity Service, Namespaces & Identity Graphs 8.2 Segmentation Methods: Streaming, Batch, Edge & Sequential Logic 8.3 Data Usage Labeling & Enforcement (DULE), Consent, and Privacy

9 Chapter 9: Decision Management, Offer Rules & Ranking Policies

9.1 Decision Management Architecture & Offer Library Components 9.2 Offer Eligibility Rules, Constraints & Capping 9.3 Decision Policies, Ranking & Channel Integration

9.2 Offer Eligibility Rules, Constraints & Capping

Key Takeaways Explain This Topic AI

Eligibility can use AEP audience membership or an on-demand decision rule; the latter evaluates supported profile/context data at decision time.

Offer dates, lifecycle state, placement compatibility, eligibility, and capping filter candidates before ranking.

An offer can have up to 10 capping rules, and reaching any one of multiple caps stops further presentation under that rule set.

Capping can apply across all users or per profile, reset by frequency, and apply across all placements or separately per placement.

Decision, click, impression, or configured custom events can increment caps, but non-decision feedback must be collected correctly.

Last updated: October 2026

9.2 Offer Eligibility, Constraints, and Capping

Decisioning first determines which offers may participate, then ranks the survivors. This order prevents a high-priority offer from bypassing dates, eligibility, or caps.

Eligibility methods

A personalized offer can use an Adobe Experience Platform audience as eligibility. Membership is calculated by the audience's evaluation process. This is useful when the rule is shared across activation and when its batch, streaming, or edge timing is acceptable.

A decision rule evaluates supported data at decision time for the current profile and context. It is useful for reusable on-demand logic. A rule is still limited to fields exposed to the decisioning framework and cannot perform arbitrary Data Lake SQL joins.

Choose audience eligibility when managed membership is the business object. Choose a decision rule when the decision should evaluate supported current inputs on demand. Do not promise instantaneous freshness; Profile and context must first be available to the engine.

Candidate filtering

For each offer, verify:

  • approved/usable lifecycle status;
  • current time within start/end dates;
  • membership in the decision's collection;
  • compatible representation for the placement;
  • audience or rule eligibility;
  • capping and other constraints;

ranking priority or formula.

If any filtering stage fails, the offer never reaches ranking. A high priority number only matters among remaining eligible candidates. Higher numeric priority ranks ahead in the legacy Offer Library, but do not invent a tie-breaker; remove ambiguous ties or test documented behavior.

Capping rules

Capping limits how often an offer can be presented or acted upon. Journey Optimizer allows up to 10 capping rules for one offer . A rule defines:

  • the event counted;
  • whether the cap applies across all users or to one profile;
  • the maximum count;
  • reset frequency;

whether the cap is across all placements or separately per placement.

If an offer has several caps, reaching any one relevant threshold can stop the offer. For example, “five per profile per week” and “100,000 total” protect both individual fatigue and campaign inventory.

Capping events

Supported capping events include:

Decision event: the offer was proposed; this is the default.

Click: the person clicked the offer.

Impression: the offer was displayed; supported for inbound channels.

Custom event: a configured XDM event, such as checkout or redemption.

Except for the decision event, feedback may not be collected automatically. The implementation must send the correct experience event and schema field group so the counter increments. If a web banner appears on every refresh despite an impression cap, missing proposition-display feedback is a prime suspect.

For email, offer counts can increment at preparation time even if the email is not ultimately sent. Interpret caps according to the configured event and channel, not a vague idea of “seen.”

Profile versus global

A per-profile cap limits exposure to one person. A global cap limits the total across all users. The latter can manage finite inventory or contractual exposure.

Across-placement capping combines presentations of the offer in all its placements. Per-placement capping maintains separate counts, such as two email and two web presentations. Pick the scope that matches the business promise.

Capping counters reset according to frequency. Adobe also documents lifecycle reset behavior tied to offer expiration and long-term duration. Changing approved offer dates can affect per-profile counters, so review impact before editing dates.

Date and time

Offer start and end are evaluated using configured time behavior. Confirm the author's current time zone display and the actual desired instant. Test just before start, at start, just before end, and after end.

An expired offer falls out before ranking and may cause fallback. Extending dates on an approved capped offer is not always a harmless metadata edit.

Troubleshooting fallback

If fallback appears unexpectedly:

  • confirm requested placement and representation;
  • confirm offer and decision lifecycle;
  • check start/end time;
  • verify collection membership;
  • inspect audience membership or decision rule inputs;
  • check every capping rule and event counter;

only then inspect priority/ranking.

This sequence avoids “fixing” priority when the candidate was never eligible.

Tip

Eligibility answers may this profile receive it? Capping answers has it already been presented or acted on too often? Ranking answers which remaining candidate wins?

Cap calculation example

Suppose an offer has a per-profile cap of two decisions per week across placements and a global cap of 10,000 decisions. A profile receiving one web and one email decision has exhausted the personal cap even if the global counter is low. Changing the scope to per placement would produce separate web and email counters, a materially different customer experience.