At Constructor, we always strive for transparent, Glass Box insight into reasoning behind our algorithms. With the latest update, we give you visibility into the impact made by Online LLM Filtering and Burying relevance models.

These models identify the true meaning behind a search query in realtime and analyze how relevant to that query is each particular item within the results. By burying or removing less relevant items, the models make search results cleaner, balancing relevancy and attractiveness and helping shoppers find what they need faster.

Until recently, these powerful AI models worked quietly in the background. Now, you have full visibility in the Interact section of the dashboard into when and how LLM models kick in to improve your search results:

• See when the model is active: LLM Filtering or Burying now appears in the Ranking Factors section of Interact.
• Understand the impact: View which specific items from your top results were removed or buried by LLM models for any search query.

How to Get Started

LLM Filtering and Burying models are available in A/B-test to all our customers. Once the feature is enabled for a particular index, simply navigate to Interact, enter a search query, and look for LLM Filtering or LLM Burying in the Ranking Factors section.

If you have questions about enabling LLM Filtering and Burying models or feedback on this feature, please connect with your Customer Success Manager or contact us through support@constructor.io.

We’ve introduced multi-layered conditions in pod rules setup. This gives merchandisers more granular control when defining the scope and application of a rule.

For example, merchandisers can set up a rule for “If Brand = Apple and Product Type = Smartphone” to boost Apple products within a pod.

Merchandisers can select up to 5 facets when setting up conditions for pod rules.

📍 Where to find it?

1. Navigate to Workspace → Recommendations → Add New → Recommendation Rule.
2. From there, select the pod(s) you want to set up rules for.
3. Select multi-layered conditions. 

If you have any questions or feedback on the updated feature, please connect with your Customer Success Manager or contact us through support@constructor.io

What’s new

Collections now include modification author tracking, so you can immediately see who last updated a collection — directly in the dashboard.

For each collection, you’ll now see:

• The name and email of the last person who modified it (when available)
• A “Using API” label if the most recent update came via the API
• A “-” if the collection was last updated before author tracking began (January 2026)

Availability

Available now for all Collections customers (included as part of Collections).

Why it matters

Collections are often managed by multiple merchandisers (and sometimes in an automated way). When something changes unexpectedly, figuring out who made the last edit — and how it happened — can turn into detective work.

With author tracking, teams can:

• Resolve questions faster by seeing the last editor at a glance
• Reduce back-and-forth internally (“Was this you or me?”)
• Spot API-driven changes immediately, so automated updates don’t look like mysterious human edits

Technical limitations

• Author tracking is available only for modifications made from January 2026 onward.
• We currently track only the most recent modifier (not the full edit history).

What’s new

With the recent launch of Audience Hub, Affinity, RFM, and Location segments are now available in Searchandising — expanding our Custom & Dynamic segments and upgrading how you target shoppers in rules and campaigns.

You can now pick segments based on:

• Affinity (what brands/categories/styles a shopper tends to prefer)
• RFM (purchase Recency, Frequency, and Monetary value)
• Location (geographic shopper segments)

As you select a segment, you’ll also see whether it matches the traffic volume you intend to target, so you can make confident, data-driven choices while configuring.

Why it matters

Previously, many merchandising strategies were applied too broadly (because the necessary segment wasn’t available in Searchandising or was hard to maintain), which could dilute impact and sometimes actively hurt performance when irrelevant shoppers see promoted items.

With Affinity, RFM, and Location segments:

• Target the shoppers your strategy is actually designed for, without relying on custom segment pipelines.
• Maximise incremental impact by showing promotions only where they’re likely to help.
• Avoid “segment guesswork” by checking intended traffic volume while you configure.

Example workflows

• Launch new arrivals to high-intent fans. Promote a newly arrived Nike drop only to shoppers with a strong Nike affinity, instead of pushing it to everyone.
• Run clearance with precision. Target sale campaigns to frequent buyers, or to shoppers whose recency is dropping (and may need a nudge).
• Localise merchandising. Highlight weather-appropriate or region-specific inventory to shoppers in the relevant locations.

If you have any questions or feedback on the new feature or the Constructor dashboard in general, please connect with your Customer Success Manager or contact us through support@constructor.io.

We are thrilled to announce the launch of Audience Hub, a new way within the Constructor dashboard to get a clear, centralized view of your shoppers and their characteristics at scale through segmentation.

Previously, segment data was fragmented and difficult to access, making it hard to grasp the size and opportunity each segment represented. Audience Hub solves this by bringing all your meaningful segmentation data into a single location, making it an easy starting point for understanding and further optimization.

Audience Hub Main Page

With Audience Hub, you can:

• Gain a deeper understanding of your users: See shared similarities across your users, such as affinity for specific brands (e.g., Nike) or locations (e.g., Canada). See top searches, items viewed, added to cart and purchased for each segment.
• Centralize and visualize all segments: Access a single source of truth for all user segments, including geo, device, customer provided and AI generated smart segments (such as Affinity and RFM).
• Identify high-impact opportunities: Understand the exact size and opportunity that various segments represent, making it easy to decide which ones are worth further review and action through onsite and offsite optimizations.

Segments Drawer within Audience Hub provides more segment details.

We’re excited to make this available now, and we’re just getting started with segments. Keep an eye out for more to come in this space.

If you have any questions or feedback on the new feature or the Constructor dashboard in general, please connect with your Customer Success Manager or contact us through support@constructor.io.

Integrations often require data that is used on a shopper-facing website or in merchandising rules, but shouldn't be visible to the public. For example, you might have different prices across regions. You can configure the price fields as Hidden and then, when you are making a request for a user in region 1, you retrieve the corresponding price via the query parameter  fmt_options[hidden_fields]=price_1  without exposing all the prices in the API response.

Previously, configuring a metadata field as Hidden (so it exists in the index but isn't returned in the response) required API intervention and was invisible in the dashboard.

With this update, you can now:

• Gain Visibility: See exactly which metadata fields are currently set to Hidden directly in the dashboard.
• Self-Serve: Toggle the Hidden configuration on and off without needing to reach out to dev resources and make API calls.

How to Get Started 

This feature is available now. Navigate to Workspace > Indexes > Manage Searchability & Displayability and choose a field to set up its Hidden configuration.

Important notice: Changes to metadata field configurations take effect in search and browse requests once Constructor rebuilds indexes. Rebuild duration will depend on the size of your data set, including items, facets, rules, and other indexed data.

If you have any questions or feedback on the new feature or the Constructor dashboard in general, please connect with your Customer Success Manager or contact us through support@constructor.io.

Bucketed numerical facets—like price ranges, dimensions, or review ratings—are a powerful tool to help  shoppers in their product discovery journeys. However, the raw values don't always look user-friendly.

Previously, customizing how the options of bucketed range facets appeared to shoppers required API intervention. Now, you can configure Display Names for these options directly in the dashboard. This allows you to:

• Add Formatting: Easily change 100-200 to $100 - $200 or 100cm - 200cm.
• Localize Language: Translate labels for different regions, such as changing "4 & up" (rating) to "4 & πάνω."

How to Get Started 

This feature is available now. Navigate to Workspace > Indexes > Global Facet Configuration and find a bucketed range facet to start customizing display names for its options.

If you have any questions or feedback on the new feature or the Constructor dashboard in general, please connect with your Customer Success Manager or contact us through support@constructor.io.

What’s new

Facet campaigns are here. You can now apply one set of facet rules — slotting and/or hiding facet groups and options — to many results pages at once, instead of configuring each page separately.

A single facet campaign can target a mix of:

• Search queries (e.g. “denim”, “running shoes”, “ground coffee”)
• Browse category pages (e.g. Shoes, Coffee, Skincare)
• Facet pages (e.g. “Size 7” Shoes, “Straight Leg” Denim)
• Collections (e.g. “Viral Hits”, “Kid’s Summer Shoes”)

Think of it as Searchandising Campaigns, but for facets: one place to define the order and visibility of your filters across a whole group of related pages.

Each facet campaign currently supports up to 100 queries and 100 browse/facet/collection pages (combined).

Why it matters

 Previously, keeping filters tidy and consistent meant repeating the same facet rules on every individual page:

• Hiding niche facet groups (like “Heel height”) on categories where they barely apply
• Reordering key facets (like “Brand” or “Sale”) across long trees of categories and collections
• Repeating the same updates every time your strategy changes

With facet campaigns, you:

• Configure once, reuse everywhere. Define facet ordering and visibility in a single campaign and apply it to all related pages.
• Keep filtering experiences clean. Hide facet groups and options that only matter to a tiny subset of items so shoppers aren’t scrolling through noisy filters.
• Stay consistent across parent and child PLPs. Align the filtering experience across a parent category (e.g., “Shoes”) and its children (e.g., “Boots”, “Heels”, “Sneakers”) without micromanaging each page.
• Move faster when strategy changes. Update a single campaign instead of revisiting dozens of PLPs when you change priorities (e.g. pushing “Sale” or your own brand to the top).

Example workflows

• Tidy up irrelevant facets at scale. A retailer only wants to show Heel height on women’s boots and heels—not on sneakers, kids’ sandals, or men’s trainers. They create a facet campaign, attach Shoes, Athletic Shoes, and Kid’s Summer Shoes pages and collections, and hide “Heel height” once. All included pages inherit the same tidy filter set.
• Promote own brand across a family of pages. A beauty retailer wants their own brand to appear first in the Brand facet on search results, “Makeup” categories, and “Viral Hits” collections. They add these contexts into a single facet campaign and slot their brand option to position #1—no need to repeat the rule per page.
• Align parent and child categories. A fashion retailer wants a consistent set of filters across Denim, Denim > Straight Leg, and Denim > Wide Leg, but with fewer facets on the narrower children pages. They build a facet campaign for all denim-related pages, then hide niche facet groups from specific sub-pages while keeping core filters aligned.
• Seasonal or promo-focused filtering. During peak season, a merchandiser wants the Sale, New in, and Sustainability facets to rank higher across key search queries, categories, and promo collections. They create a campaign, slot those facets near the top across all relevant contexts, and adjust positions from a single configuration when the season changes.

Learn more

• Create a facet campaign
• Configure facet rules

Constructor continues to make shopper discovery smarter and more intuitive. Our latest update introduces Discoverable Collection Items, a lightweight, API-first way to connect queries → collections → items, ensuring that seasonal or campaign-based products are surfaced at the right time and for the right searches.

What is it?

A new enhancement to the Collection Creation API allows customers to make items within a Collection discoverable for specific search phrases. This means that when a shopper searches for terms like “Sale,” “Holiday Deals,” or “Thanksgiving Sale,” the items from relevant seasonal or promotional collections (e.g., “Black Friday Collection”) can automatically appear in search results with no manual items association or merchandising rules required.

This feature gives merchants a lightweight, API-only way to directly associate search queries with entire collections of items, improving recall and discoverability while reducing manual merchandising overhead.

Note: This functionality is currently available only via the API, with dashboard and UI support coming soon.

Why this matters

Previously, there was no automatic link between seasonal or promotional collections and shopper queries:

• Items in those collections weren’t discoverable by campaign-related terms, since they often lacked explicit query associations or metadata.
• Merchants had to rely on manual rules to approximate this behavior, an inconsistent and time-consuming process, often without good item-level attribution for seasonal relevance.

With Discoverable Collections, Constructor bridges this gap, letting merchants efficiently map search phrases to collections so that the right items appear automatically when shoppers search for relevant terms.

How does it work?

A new optional parameter, discoverable, has been added to the Collection Creation API.
 When creating or updating a Collection, you can set discoverable: true and define phrases and match types similar to how redirects are configured.

Each discoverable configuration includes:

• match_type (string, default to PHRASE): The matching logic for the phrase.

  • "EXACT" – The pattern must exactly match the search query.
  • "UNORDERED" – All tokens in the pattern must match the query, but order doesn’t matter.
  • "PHRASE" – All tokens must match, but the query may include additional tokens.
• pattern (string, required): The phrase pattern that triggers item discovery.
  
  

By default, discoverable is false to preserve existing behavior.

Example Request

Below is a simple example of creating a discoverable Collection that associates its items with “sale” and “Thanksgiving sale” search queries:

curl -X POST https://ac.cnstrc.com/v1/collections \

  -H "Content-Type: application/json" \

  -H "Authorization: Bearer/Basic YOUR_API_TOKEN" \

  -d '{

    "display_name": "Black Friday Test Collection",

    "id": "bf25-cnstrc",

    "filter_expression": {

      "name": "group_id",

      "value": "all"

    },

    "discoverable": true,

    "matches": [

      {

        "pattern": "sale",

        "match_type": "PHRASE"

      },

      {

        "pattern": "Thanksgiving sale",

        "match_type": "PHRASE"

      }

    ]

  }'

In this example, items within the “Black Friday Test Collection” become discoverable whenever shoppers search for “sale” or “Thanksgiving sale.”

What problem does it solve?

The Discoverable Collections Items feature eliminates the need for complex rule management and inconsistent boosting strategies. By connecting queries → collections → items directly, merchants can:

• Automatically surface seasonal or campaign items for relevant search terms.
• Reduce manual merchandising effort while improving accuracy.
• Increase recall and relevance for high-intent seasonal queries.
  
  

Availability

The Discoverable Collections Items feature is available today via the Collection Creation API. Dashboard and UI support are coming soon to make discoverability even easier to configure.

For assistance or to learn more about setup best practices, please contact your Customer Success Manager or reach us at support@constructor.io.

Introducing a major update to API tokens that gives your engineering and admin teams precise, "least-privilege" control over API access.

The Challenge: The "All-or-Nothing" API Key

Previously, API tokens (now referred to as Legacy tokens) were company-wide, granting full read and write access to all Constructor endpoints across all your indexes. While powerful, this created potential risks. A leaked token technically, could expose all your data, and a simple misconfiguration in a script could accidentally apply changes to the wrong environment.

The Solution: API tokens with Custom Level of Access

Now, you can build API tokens with a specific, limited scope. When creating a new token, you can define:

• Indexes: Specify which indexes the token can access. This is perfect for isolating your Production, Staging, and Dev environments or managing different websites.
• Scopes: Select which API endpoints the token can use (e.g., searchandising.refined_queries, searchabilities,  synonyms).
• Permission: Define the permission level for those scopes: Read & Write, Read, or Write.
• Expiration Date: Set an optional expiration date. We recommend renewing API tokens regularly.

By limiting access to what is really needed, you reduce security risks if a token gets compromised and rule out the possibility of applying changes to the wrong environment.

Putting API Tokens into Practice

This new control allows you to securely manage complex, multi-team workflows:

• For Integration Scripts: Create an API token that has access only to scopes within the dev_index to test things before applying changes in production.
• For Regional Teams: Give your EU engineering team an API token that can Read & Write to all scopes only on the eu_site index, preventing accidental changes to the US site.

Better Together: API Tokens + Customizable User Roles

This update works hand-in-hand with our recent Customizable User Roles feature. Only users assigned with a role that has Manage API tokens permissions can set up API tokens. Users' ability to create API tokens is limited by their role permissions. An administrator can create tokens for any scope, but a user with a specific role (e.g., "US Merchandiser") can only create API tokens for the indexes and features they are already permitted to access. 

This ensures your permission model is consistent, from the dashboard UI right down to the API.

A Note on Legacy API Tokens

Your existing tokens (now labeled Legacy tokens in the dashboard) will continue to work without interruption. However, you can no longer create new tokens of this type. We highly recommend you audit your existing integrations and begin migrating to the new, more secure API tokens as part of your team's security best practices.

How to Get Started

This feature is now live for all customers. Administrators and users with the appropriate permissions can create new tokens by navigating to Integration > API Tokens in the dashboard.

For a complete, step-by-step guide, please visit our updated documentation: Generate and manage API tokens.

If you have any questions or feedback on the new feature or the Constructor dashboard in general, please connect with your Customer Success Manager or contact us through support@constructor.io.