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

Recently we released the ability for users to hide and order facets at a category level (you can read more about that here). 

This allowed users to set category contextual facets for an improved end user experience, but it was not always obvious which facets were slotted already in the global facet configuration - until today! 

We have now released the ability for users to be able to identify which facet groups and facet options have a global facet configuration applied to them, indicated with the global icon. 

 In the example above “Discount” was locally slotted in spot 1 for this category, which pushed down the existing globally slotted facet groups.

We recently released Cognitive Embeddings Search which dramatically decreases the amount of zero-result queries and the manual effort needed to add synonyms and redirects to optimize low, or no result queries.

We’ve seen amazing results from this new capability in testing across our customer base: increased purchase conversion, increased autosuggest product selects and decreased the rate of search reformulation. 

In an effort to make search results more clear and obvious we’re excited to announce our latest capability - Cognitive Embedding Search in Interact within the Dashboard. 

Users will now be able to see what products in the result set are coming from Cognitive Embeddings Search, which are indicated with a unique icon. You’ll also be able to toggle Cognitive Embeddings Search on and off to preview the effect of it at the query level within Interact in the Dashboard. 

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

As part of our commitment to improve and optimize performance we're excited to announce that we’ve significantly improved performance of search for customers with the largest catalogs.

More specifically, the slowest 10% of queries (p90) saw a 10% improvement in response times, while the slowest 1% (p99) saw a 15% improvement in response times. 

For customers with catalogs of millions of items, the improvement was more than 50%! All of this means an overall improved experience for customers on your site, decreased time-to-checkout and higher conversion rates.

Changing search submits to search result views

Starting at the end of this week after business hours, we will communicate top search analytics in most cases in terms of result view events, rather than search submissions.

What are these events?

• Search submits are sent when users execute a search from the search bar (or select a search suggestion).
• Search result views are sent when users view a search page.

Why are we making the change?

We originally focused on search submits as they help to understand user search intent on a site or particular page (as opposed to inbound traffic). They can also be less prone to tracking errors due to their reliance on HTML form submissions.

Search result view events provide a picture of all traffic to the search page, whether it came from off-site, through the search bar, or links on-site. These events are what we use to analyze data science optimizations internally and align best to what customer merchant and product teams most commonly associate as a "search".

Are search submit events still displayed anywhere?

Yes! Search submissions are shown next to search result view events in all search interact pages. You can see these today for any interact page (accessible from the interact page here)

Search Click and Add-to-Cart Rates

We now communicate search add-to-cart rates (or ATCR) and clickthrough counts and rates over time in the search analytics overview page and search term detail pages.

Click and Add-to-Cart rates help understand how user behavior is changing over time at a global level, as well as for individual queries. One use case is to enable merchants to observe how their actions may be impacting user behavior on particular search terms.

To better serve our customers with millions of products in their catalog, we have increased the maximum number of results supported in search, browse and collections to 10,000 (from 999).

The previous limit of 999 was based on our research on user pagination depth (nearly zero conversions arise from pagination past the first few pages) and was designed to optimize for the fastest possible response times. By optimizing our core architecture we were able to increase the maximum results while preserving (and improving!) performance.

Users will now see ten times more results for a query without needing to filter down or sort the results. This encourages deeper discovery by paginating through a larger selection of products, facilitates longer infinite scrolls and can improve SEO with better crawlability of large category pages.

How we’re making Constructor Search better for your customers and for your bottom line.

As a Constructor Search customer, we know how much time you spend tinkering manually with zero-results queries, adding synonyms and redirects to capture users who might otherwise fall into a no results experience. To help this state of affairs, we have long leveraged our ML to generate synonyms before customers launch their search, automatically catch misspellings and more. To take these capabilities to the next level, we have built a more advanced zero-result algorithm -- Cognitive Embeddings Search -- into Constructor’s site search platform. 

Cognitive Embeddings Search transforms your product catalog into a “sea of stars,” where our machine learning and AI capabilities can return search results that are the closest neighbors to each query—virtually eliminating “no search results found” for good.

The best part? Cognitive Embeddings Search is included as part of the Constructor Search platform, and you can begin using it today by getting in contact with us through your Customer Success representative or through support@constructor.io!

Find out more about how this new addition to Constructor Search works here, and how it can improve revenue and your product discovery experience.

Overview

Constructor’s conversion optimization and discovery benefits are only as good as our uptime and performance. For this reason, we have a robust process of performance validation and monitoring. During the holiday season and the peak demand period of Black Friday and Cyber Monday, we increase our standards in all of these areas out of recognition that it is the most important selling period for many of our customers.

Survey of peak demand for 2020

In planning our preparations in the run-up to the 2021 holiday season, we looked back to daily and peak demand changes during the holiday season and also reviewed how our baseline traffic has increased in the time since then.

Last Black Friday our overall traffic increased 200% over daily baseline levels, and peaked at 500% of baseline. Not only did we maintain our 100% uptime, but performance during the peak demand periods actually improved relative to equivalent periods (due to changes in traffic patterns). Since then the system has already scaled without interruption or degradation for average daily traffic by over 383%.

Performance improvements over the past year

Over the past year we have worked continuously to drive even better performance and scalability, contributing to improved latencies and zero downtime. Some example projects and outcomes include:

• Optimized scaleout policies
• Introduced stand-by server pools
• Improved instance boot and data download time by ~300%
• Increased performance of personalization service
• Doubled performance of underlying search & browse servers
• Decreased index update delivery times
• Increased database read capacity

Scale-out performance testing

We have tested scaling to 2000% of current average daily traffic volume, while validating the continued performance of the following:

• Database connections 
• Monitoring infrastructure
• Networking infrastructure
• Response latencies @ median, 90th percentile, 95th percentile, 99th percentile
• Response latencies for each customer, and each product used by each customer
• Data ingestion SLA times

Chaos and anti-fragility testing

We also use chaos testing to validate that catastrophic failure of the following supporting infrastructure does not impact critical features (primarily search, autosuggest, browse, recommendations, collections request/response times):

• Disabled MySQL
• Disabled index builders
• Disabled personalization queues
• Disabled supplemental ranking engines
• Availability zone and data center failures

All of the above is in addition to the rigorous performance test and rollout plan we use for every release:

• Full test suite on every pull request (incremental code change).
• Production traffic replay for all deployment builds (multiple times a week).
• Rolling, risk-adjusted deployment procedures across worldwide data centers.
• Canary deployment for deploys touching critical path request/response lifecycle.
• Automatic build failures if sensitive thresholds on result quality, latency, memory consumption, CPU consumption and more are breached at any of these levels.

Standard on-call procedures

At all times we have multiple on-call schedules for the following teams:

• Front-end and client teams
• Data science and result quality teams
• Core platform and response performance  teams
• Each of these have multiple fallbacks and tiered escalation policies

Automated alerting

Alerting is automated across dozens of metrics to ensure we are aware of incidents within seconds. A few representative examples:

• Queuing times
• Per-service latencies
• Memory and CPU consumption

Special holiday on-call procedures

In addition, we take special precautions during peak holiday shopping periods:

• We will over-provision all infrastructure above and beyond typical scale-out policy.
• We double on-call rotation utilizing the above-mentioned automatic notification and escalation policies.
• The entire account and product team will be monitoring throughout the Black Friday / Cyber Monday period, with elevated focus for other holiday periods (such as Boxing Day).

Conclusion

At Constructor, we take uptime, performance, and service stability very seriously because the best conversion optimization and ML are moot if we don’t deliver fast and stable service consistently. The goal of this document is to provide our customers with a broad overview of our site reliability practices, as well as a specific view of our holiday readiness procedures. As always, please feel free to reach out to your Customer Success Manager if you have any further questions.

Facets are key to great search and browse experiences because they allow users to narrow their results to find the right product. To provide better insights into facet engagement, we recently released analytics for facet usage. Building on this recent release, customers can now take action based on those insights with Category Facet Configuration. 

For example, in your online grocery store you may observe usage of the “Price” facet significantly exceeds the "Brand" facet in the Beverages category, or that few users interact with the “Fat Free” Nutrition facet. Using Category Facet Configuration you can now move “Price” to the highest position and hide the “Fat Free” facet option in the Beverage category, completely independent of the existing global facet configuration. Seeing different trends in Frozen Food? No problem, you can set a custom facet configuration there too.

These new facet configuration capabilities supplement our existing dynamic facet ranking options, which rank facets based on those that are most common among the top ranking products for a given category. For instance on a cosmetics site, the Foundation page would have the facets associated with actual foundation products at the top of the page, such as “Formulation”, “Brand” and “Color”. In contrast, “Bristle Type” would be ranked lower because this is a facet associated with foundation brushes, which behavioral data indicate are not as appealing for users on the Foundation page.

Check out category facet configurations here.

We’ve delivered this feature for Category Browse based on traffic and customer demand, but we’ll be evaluating expanding to Collections and/or Search in the future. Reach out to feedback@constructor.io or your Customer Success Manager if you’d like to see this more broadly!