Conflict resolution for ranking rules

What is conflict resolution

Conflict resolution is the systematic process Bloomreach uses to determine which merchandising rules take precedence when there are conflicting settings. 

The system applies a logical hierarchy to ensure consistent, predictable results while maximizing the impact of your merchandising strategies.

When you create multiple ranking rules—such as boosting products globally while also applying query-specific customizations—the system automatically resolves any conflicts using established precedence principles. This approach allows you to build complex merchandising strategies without worrying about rules canceling each other out.

How conflict resolution works

Rule collection and sorting

The system gathers all applicable rules: those set broadly (account, site group, site) and those scoped to specific categories or queries. This includes both the rules inherited from higher levels and any customizations made at lower levels.

The pooled rules are then sorted by operation type (block, attribute include/exclude, soft/hard PID boost/bury, slot, and so on).

Handling of same operation types

Most operations of the same type (except slots/locks) are additive and can be merged. For operations that can’t be merged, the system follows specific logic based on each edge case. 

Handling of different operation types 

The system sorts merchandising operations in a specific order, regardless of rule dimensions such as scope (global or local), organizational level (account, site group, or site), audience, and schedule.

Handling of same operation types

Merging of same operation types

Most operations within the same type are additive. This applies regardless of where the rule was set (account or site level, category, or query scope).

Operations that can be merged are listed below:

• Attribute include/exclude

• Attribute soft boost/bury

• Attribute hard boost/bury

• PID boost to top

• PID bury to bottom

• PID block

📘

Note

The system doesn't merge slot operations at the same position and applies precedence. Check their edge case behavior. Slot operations with different PIDs at different positions merge.

Merging same operation types with different rule scopes

• Global level: “Attribute Exclude: color= black” 

• Local level: “Attribute Exclude: color= red” 

Result: Both exclude rules are merged into “Attribute Exclude: color= black or red”.

Merging same operation types at different organizational levels

• Account level: A global boost on products that are "new = true" at strength 20

• Site level:  A local boost on products that are "new = true" at strength 30

Result: The actual strength of the attribute boost applied is 50.

Edge cases for same operation types

When operations can’t be merged, they are treated as edge cases as follows: 

Same operation types with different time schedules

Only one rule is active at a time. Time-bound rules determine a rule's activity period without affecting its scope or area of effect.

Example

• All time: Boost PID 123 (Inactive)

• Schedule: Boost PID 123 between 12 a.m. and 1 p.m.

Result: The system boosts PID 123 between 12 a.m. and 1 p.m., even when the all-time rule is inactive. 

Same operation types with different audiences 

General audience rules continue to apply to users outside the targeted audience segments.

Example

• General audience rule: Boost "premium=true" products by 10 for all users.

• Mobile audience rule: Boost "premium=true" products by 20 for mobile users.

Result: Mobile users see premium products buried, while desktop users see them boosted. 

🚧

Important

The system doesn't establish hierarchy between different audience segments of varying specificity.

❗️

Known issue

Rules with an audience are not prioritized over rules without an audience. This will be fixed in a future release.

Same slot operations at different organization levels

This behavior applies to PID slot operations, such as locking in place or locking to a certain slot number. When the same slot is targeted at different organizational levels, higher-level rules take precedence.

• Account-level slot rules override site group rules.

• Site group slot rules override site-level rules.

Example

• Account-level rule: Assign PID 123 to slot 1

• Site-level rule: Assign PID 456 to slot 1

Result: PID 123 appears in slot 1 as the inherited account-level settings take precedence.

❗️

Known issue

When both single-query and multi-query rules are present at the same level, the system incorrectly applies the most recently edited rule, rather than following proper precedence. This will be fixed in a future release.

Handling of different operation types

When rules have direct conflicts with different operation types, the system processes merchandising operations in a specific order.

1. PID Block

2. Attribute Include Only / Attribute Exclude

3. Sequential lock

4. PID Slot (Lock in place and lock in position)

5. PID Bury/Attribute Hard Bury (100 strength) 

6. PID Boost to Top

7. Attribute Soft Boost/Bury (<100) + Numeric soft boost

8. Conditional slot 

📘

Note

PID bury and attribute hard bury have the same effect. Both these operations bury products at the end of the recall set with the same strength (100).

Multi-site accounts follow the above hierarchy. This operations hierarchy applies regardless of the rule’s organizational level (account, sitegroup, or site level), rule scope (global or local), audience, and scheduling. 

Review the example conflict scenarios below and their resolution based on the operations hierarchy.

Different operation types with different rule scopes

• Global level: Block PID 123 for all queries

• Query level: Boost PID 123 for search query “dress”

Result: Following the operations hierarchy, the system blocks PID 123, regardless of the global/local rule. 

Different operation types with different rule organization levels

• Account level: Boost PID 123 for all queries

• Sitegroup level: Boost PID 123 for all queries

• Site level: Bury PID 123 for all queries

Result: Following the operations hierarchy, the system buries PID 123, regardless of whether the rule is set at the account, site group, or site level. 

Different operation types with different schedules

• All time: Boost PID 123 for all queries

• Schedule: Block PID 123 between 12 a.m. and 1 p.m. for all queries

Result: Following the operations hierarchy, the system blocks PID 123 between 12 a.m. and 1 p.m. Note that whenever the scheduled operation is higher in the account/site group/site order, it is applied for the duration. 

Different operation types with different audiences

• All audience: Bury PID 123 

• Desktop users: Boost PID 123 

Result: Following the operations hierarchy, the system buries PID 123 regardless of the audience type.

Quick decision tree

When rules conflict, ask these questions:

1. Are they different operation types? → Operation higher in hierarchy wins.

2. Are they the same slot operations at different levels? → Higher level overrides.

3. Are they boost/bury/attribute operations at different levels? → They merge instead of conflicting.