In order to continue to power best in class experiences in ecommerce, we are excited to release the ability to set contextually optimized facets for Collections! 

Building on top of our existing capabilities to control facets for category pages, merchandisers can now set Collection specific facets in the dashboard. 

Say you’ve got a Collection for summer essentials from top brands, but your brand facet is globally positioned in spot 6 across your site, you might want to bring it to the top so your site visitors can see the top brands easily, and quickly further refine for their favourites. 

Alternatively maybe you have a collection for an upcoming sale you’re running. You usually have a facet for “on sale” to allow for shoppers looking for a deal to better refine for marked down products, but in this instance everything is on sale so maybe you want to remove it to bring more contextually relevant facets to the top of the list. 

This can be found under the “Facets” tab within the dashboard as of today.

For more information, please connect with your Customer Success Manager or contact us through support@constructor.io.

The world of retail is a complex one and at Constructor we understand that you might have a physical presence that isn’t captured by “online only” platforms. That’s why we want to connect your offline physical world with your online virtual world so that you can take advantage of both in one place, and see the results in enhanced KPIs that consider your whole business, not just part of it. We’ve long offered the ability to send us data from what happens in-store, but it was never very easy to do. That’s about to change.

We’re proud to announce the release of our new Offline Purchases API that you can now use to capture all those offline sales and incorporate them into improved personalisation for your customers and KPIs for your business.

Using this API you can send us up to 100 purchase events in a single request, including prices, quantities, and store location details.

To log an event, send an authenticated request to:

The JSON payload contains the list of items that were purchased. For example, a customer purchased one item at $34.99 and two each at $17.99:

Note that the ui parameter is optional, so in the event you don’t have a way to identify the customer for a purchase, you can still send in the purchase event for the behaviour to be included in our KPI-optimised algorithms.

With this change, you’ll be able to take the rich set of interactions customers have in your physical stores and leverage them for an improved customer experience. Use cases include truly omnichannel personalization that lets a customer have a personalized experience online that learns from their preferences in store, better personalizing in-store experiences when searching on a kiosk inside a store, and improving the overall machine learning engine as a whole by informing the system of what types of products get bought in physical vs online contexts and what products that get researched online lead to purchases in the store.

For more information, please connect with your Customer Success Manager or contact us through support@constructor.io.

We’ve long provided multiple ways for customers to update their catalogue and ensure that we always have the most recent data with which to provide an amazing product discovery experience for end users. These methods include HTTPS (REST), FTPS, and a synchronous Items API (V1, also REST).

Now, we’re excited to tell you about our all-new asynchronous Items API (V2) that allows you to send in your updates and then check a Tasks API to get status updates on their progress.

The new V2 API has a number of benefits:

• Ability to send up to 1,000 entries in a single call, allowing for real time updates of many thousands of products per second.
• Extended open data structure for increased flexibility in the data you can send us and how it’s sent.
• Direct interoperability with the Constructor dashboard, so updates sent via the V2 API appear in the dashboard and are viewable and auditable in the Integration tab there so you can easily check what you’ve sent, when it was sent, and what its status is.
• Deterministic, FIFO processing, so updates are processed in exactly the order you send them.

For customers with systems that already send out regular product updates this will be the preferred method of integration since it will be easier and more efficient to connect to and develop against. We recommend that it is combined with a daily full catalogue sync via the HTTPS or FTPS methods.

Example request:

Sample item JSON payload:

Instead of needing to wait for the response to tell you when the update is successfully accepted, you will now receive a task ID in the response:

You can call the Tasks API with the ID to check the progress:

We also have an asynchronous V2 Variations API for variation updates, and PATCH methods for both APIs to allow you to send us just the fields that have changed.

For full documentation on these new APIs see here.

Stay tuned for DELETE methods for both APIs, coming soon!

For more information, please connect with your Customer Success Manager or contact us through support@constructor.io.

Products can be labeled as sponsored while creating slotting rules in the dashboard. The label will be displayed on the product card whenever the sponsored slotting rule is applied in search, browse, or autosuggest. 

Example product card with sponsored label preview in the dashboard:

Brand partners will often pay to have their products returned in top search results or in key positions on browse pages. Merchandisers have had success adding revenue streams by selling these product placements in search and browse results. Merchandisers need to make these product sponsorships transparent to shoppers and had to previously use a third party tool to place these labels on product results. Now when merchandisers create these sponsored rules, they can add in the sponsored label all in the Constructor dashboard.

Increased revenue, accurate transparency for shoppers, and ease for merchandisers all in one place!

The new sponsored label button is in slotting rule creation left menu.

Merchandisers can label products as sponsored from the searchandizing rules left sidebar where rules are normally configured. A new label icon is in the side navigation which toggles the “sponsored” label on and off when activated (see images below). When the icon is toggled on (blue), the product is now labeled as sponsored in the rule query or browse location.

For more information, please connect with your Customer Success Manager or contact us through support@constructor.io.

Our API documentation (retrieve rules example) has been updated with details on the labels fields and how it is returned in the new response. 

One of our key focuses is to ensure that the APIs customers use are always fast and efficient. To that end, we have introduced a parameter that will allow users of the search, browse and autocomplete APIs to specify which attributes are included in the variations response, enabling you to reduce the size of the payload and shave valuable milliseconds off your page load times. For users with slower connections (e.g. a cell phone with just one bar) that can mean results hundreds of milliseconds faster, the difference between now and an eternity in the world of ecommerce.

Want to display a price range on your products on your product listing page? No problem, you can add the variations_map parameter to your browse API request with the following JSON to only show an aggregated price range for all variation groups under each item (this example has a price field within the data object; your structure may be different):

Now instead of the entire variation object structure, you will receive the following in the response for each item:

There are many ways to customise these calls to get just what you need. Documentation for this new parameter can be found here.

For more information, please connect with your Customer Success Manager or contact us through support@constructor.io.

Facet Option Sort in the Dashboard

We’ve long supported the ability to configure Facet Option sorting using the API, and now it is available in the dashboard for all users to modify. 

There are three options available to sort facets at the option level, these include: 

• Query Attractiveness
• Alphanumeric
• Number of Matches

While we generally recommend that Facet Options are sorted by Query Attractiveness (default) to help ensure the most attractive option is surfaced, we know there might be times when a different configuration could make sense too. 

Maybe you want to set a heuristic with customers for specific facets so they can more easily find the option that best suits their needs. This could mean setting a size facet alphanumerically so all the numbers show in order, or maybe you want to clearly show customers how the results of a given query are spread across various brand options by ranking them by how many products are available from each brand, you could sort them by number of matches. 

This can be found in the Manage Facets section of the dashboard, within the Indexes tab.  

New Documentation

We also made some changes to the documentation available in the dashboard. Previously there was just one link to “Docs” which took users to docs.constructor.io which is primarily our API documentation which is more technically focused.

We also have more merchandiser focused documentation available throughout the dashboard from relevant touchpoints, but we’ve never provided a generic link into all of that documentation from one place - until now!

New in the header you’ll find that we’ve renamed our existing documentation link from “Docs” to “API Docs” to make it more clear what those are, and we’ve added a new link to our more business friendly documentation in the “Knowledgebase” link. 

As we continue improving product discovery by giving customers new tools and levers to pull, we’re very pleased to announce our new Product Launches functionality. This provides the ability to time the release of a product without worrying about waiting for a reindex to run, remembering to time an upload or configuring complicated rules right before the launch. All you need to do is set the date, and wait!

We know that there might be restrictions on when you’re able to show new products to your customers, whether they be for legal reasons, or because you want to make a big splash in the market with a timed launch. Now you can do this by including a release date and time on a product in your catalogue feed. Then when you run a search or browse query, that product will not be returned until the time is met.

For example, if you have an index that serves users in North America, and you want to time the launch of a product to midnight PDT on May 1st, simply set the following on the product in your catalogue feed:

As soon as the west coast reaches midnight, the product will be returned in search and browse queries.

In addition, we make it easy to check that the right date is set. This can be done by viewing the product in the Indexes tab of the Dashboard, or by overriding “now” in the API to see what the returned results will look like at some time in the future.

Continuing to ensure our services are resilient and easy to use is one of our commitments to our customers. 

Sometimes you just need to be able to quickly check if an API is responding, without implementing an expensive call. To that end, we have introduced a series of health check endpoints for our products. Now you can make a fast, lightweight call just to verify the status.

The following endpoints have been implemented:

• Search: https://ac.cnstrc.com/status/product/search
• Autocomplete: https://ac.cnstrc.com/status/product/autocomplete
• Browse: https://ac.cnstrc.com/status/product/browse
• Recommendations: https://ac.cnstrc.com/status/product/recommendations
• Collections: https://ac.cnstrc.com/status/product/collections
• Ingestion: https://ac.cnstrc.com/status/ingestion

If the API is up and running, you will get back an OK status message:

Further documentation on these endpoints can be found here:

• Search: https://docs.constructor.io/rest_api/search/queries#system-status
• Autocomplete: https://docs.constructor.io/rest_api/autocomplete_queries#system-status
• Browse: https://docs.constructor.io/rest_api/browse/queries#system-status
• Recommendations: https://docs.constructor.io/rest_api/recommendations#system-status
• Collections: https://docs.constructor.io/rest_api/collections/#system-status
• Ingestion: https://docs.constructor.io/rest_api/full_catalog#system-status

Merchandisers can now block products in search and browse results with a few simple steps in Constructor.io’s global searchandizing rule creation menu. 

Global blocklist allows for hiding products from results without needing to re-upload a full catalog. Use cases include quickly blocking products when there is a mistake in the catalog that leads to out-of-stock products returned in results or incorrect pricing. Additionally, products can now be globally blocklisted for a specific user segment, allowing for customizable results that meet targeted merchandising needs in business-to-business search. Finally, global blocklisting can allow adding products to the catalog in advance of launch and availability in results, a feature that will be improved upon in future releases.

Creating a global blocklist rule

Global blocklisting rules will remove the selected items from search or browse results based on the rule creation’s criteria. Global blocklist rules are created by inputting specific criteria, such as: selecting specific items to block, setting a start or stop time, selecting catalog attributes to block as a group, and/or setting the rule to apply to specific customer segments. 

Where to add the blocklist rule

Navigate to the searchandizing 'add rule menu' and click the 'add global' link at the bottom of the add new rule pop up. The option to create global blocklist rules is at the bottom of the global rule creation page, as seen above.

Types of Blocklist Rule Criteria

Specific items can be added individually to the global blocklist rule. Additionally, merchandisers can block entire groups of items by adding item groups based on catalog filters such as category, brand, or any other catalog attributes available. 

Specify blocklist rules to match time and segment needs

Once item criteria has been specified for a global blocklist rule, the rule can include specific start and stop time-boxing or be apply only to a subset of customer segments. For example, a rule could stay in effect until a designated product launch date whereupon the product is no longer blocked. Additionally, users have the option to set the rule for only a specific customer segment. Click ‘add’ and the new rule will apply across all search and browse results. 

As we continue to improve and enhance the tools available to make your users’ searches more effective, we have released the latest addition to Cognitive Embeddings Search. We now include an object in the search API response indicating how many of the products in the result set are delivered by Cognitive Embeddings Search (embeddings_match) and how many by our token-based KPI-optimizing search (token_match).

Read more about the response format here.

Now you’ll be able to further customize your experience for users. For example, you can add help text on your search page to let your users know that while they might not have received exact match results for their search, they are seeing results that are the next best thing. This lets you turn what could have been a lost customer into a purchase.

This capability is now enabled for all customers. If you are not using Cognitive Embeddings Search today and you’d like to learn more, please connect with your Customer Success Manager or contact us through support@constructor.io