Conflict resolution for search and merchandising features

If you use API parameters in A/B tests, they override all dashboard rules. 

Example

You boost 10 products at the query level.  

A/B test with "disable boost" API parameter → All 10 products lose their boost. 

Algorithm rules 

The following resolution logic applies to algorithm rules created via Recall studio, including Loomi Search+ and customizations passed via frontend API calls.

Conflict behavior 

1. When multiple rules conflict, the system picks the most specific rule first. The system determines specificity in this order:

  1. query

  2. domain_key 

  3. view_id 

  4. request_type

  5. search_type

  6. widget_id

q=shirt gets priority over q=* (all queries). Customisation with domain_key=pacifichome overrides customisation with domain\_key=*. Similarly, view_id=fr gets higher priority over view_id=*.

If the customizations exist at the same level, the most recently updated one wins. 

  • Customization 1 has domain_key=pacifichome, view_id=fr, last_modified="16 june 2025"

  • Customization 2 has domain_key=pacifichome, view_id=fr, last_modified="17 june 2025")

Customization 2 wins over Customization 1.

2. The system combines all the winning customizations. If the same setting appears in multiple winning rules, the higher-priority one wins. Then the overall precedence order applies as follows. 

  1. Query specific dashboard customizations.

  2. API parameters passed directly on the front-end API call.

  3. Default algorithm settings for all queries.

Example

Suppose we have the following algorithm customizations:

  • Recall studio customization 1: q=Nike shoes, domain_key=pacifichome, view_id=FR, query.precision=text_match_precision, query.spellcorrect=off (updated June 15)

  • Recall studio customization 2: q=* (all queries), domain_key=pacifichome, view_id=, query.precision=category_precision (updated June 20)

  • Recall studio customization 3: q=*, domain_key=pacifichome, view_id=FR (updated June 18)

  • API parameter: q=*, query.precision=product_type_precision

  • Default settings: query.precision=text_match_precision, query.spellcorrect=term_frequency

Conflict resolution steps

Step 1: Resolve conflicts within Recall studio customizations

Specificity comparison with priority hierarchy (query > domain_key > view_id):

Customization 1 wins overall because it has the most specific query ("Nike shoes" vs "*").

Winning dashboard settings from C1 are query.precision=text_match_precision, query.spellcorrect=off

Step 2: Apply overall precedence order

  1. Dashboard (winner customization): query.precision=text_match_precision, query.spellcorrect=off

  2. API parameter: query.precision=product_type_precision

  3. Default settings: query.precision=text_match_precision, query.spellcorrect=term_frequency

Final configuration

  • query.precision=text_match_precision

  • query.spellcorrect=off

The dashboard's consolidated settings take precedence over the API parameter because the dashboard has a higher priority in the overall order.

Algo weight rules work the same as attribute operations, where you boost certain performance attributes, such as ATC weight, RPV, views, etc.

Here’s how they stand in the operations order:

  • Less than 100% strength: Move to the lowest level in the operations hierarchy.
  1. PID Block

  2. Attribute Include Only / Attribute Exclude

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

  4. PID Bury, Attribute Hard Bury (100 strength), Algo weights (100 strength) 

  5. PID Boost to Top

  6. Attribute Soft Boost/Bury (<100), Numeric soft boost, Algo weights (<100)

This feature slots products based on attributes instead of specific product IDs. Hence, PID slots override them in direct conflicts. 

  1. PID Block

  2. Attribute Include Only / Attribute Exclude

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

  4. Conditional slot

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

  6. PID Boost to Top

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

Dynamic categories work exactly like regular categories after they're created. All normal merchandising conflict resolution rules apply.

Operations applied to groups or to products within groups follow the operations hierarchy if there are conflicts among different operation types. 

Example

  • Global level: Block Group 1 for all queries

  • Query level: Boost Group 1 for search query “table”

Result: Following the operations hierarchy, the system blocks Group 1, regardless of the global/local rule scope. 

Suppose a setting is passed at various levels on the API and dashboard. Conflict resolution order works as follows:

  • API parameters passed directly on the front-end API call

  • Query override on the dashboard

  • Site-level rules on the dashboard

  • Site group-level rules on the dashboard

  • Account-level rules on the dashboard

Individual operations within segments follow the operations hierarchy for resolving direct conflicts. 

This feature locks products into specific sequence positions. Sequential lock operation overrides PID slots in direct conflicts.

  1. PID Block

  2. Attribute Include Only / Attribute Exclude

  3. Sequential lock

  4. PID Bury, Attribute Hard Bury (100 strength), Algo weights (100 strength) 

  5. PID Boost to Top

  6. Attribute Soft Boost/Bury (<100), Numeric soft boost, Algo weights (<100)