9.2 Offer Eligibility Rules, Constraints & Capping

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:

1. approved/usable lifecycle status;
2. current time within start/end dates;
3. membership in the decision's collection;
4. compatible representation for the placement;
5. audience or rule eligibility;
6. capping and other constraints;
7. 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:

1. confirm requested placement and representation;
2. confirm offer and decision lifecycle;
3. check start/end time;
4. verify collection membership;
5. inspect audience membership or decision rule inputs;
6. check every capping rule and event counter;
7. only then inspect priority/ranking.

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

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.