ÃÛ¶¹ÊÓƵ

Transcript

Welcome to this demo of ÃÛ¶¹ÊÓƵ Commerce Live Search, powered by ÃÛ¶¹ÊÓƵ Sensei. Today, we’ll cover both the shopper experience on the storefront and the admin experience in the back office. We’ll begin the demo here in Luma, our B2C company selling consumer fitness apparel. Let’s jump up to the search bar and start to make a query for pants. As I make my query, I get results loading in real time in the Live Search popover widget. That widget can be restyled, branded, and updated to show or hide different data or attribute fields. Most of our Live Search customers really make that pop over their own. Live Search also has misspelling handling. So if I type in patans instead of pants, we’ll still return all of the pants’ skews. And that’s happening in real time as the shopper searches, and without any sort of did-you-mean disruptive prompt that takes the shopper out of their shopping experience. I can then go and continue to refine my query, and you can see results coming in, loading in real time, changing with each keystroke that I type, all in under 250 milliseconds. As you can see, the shopper gets feedback instantaneously as to whether or not they’re finding the products they need. Live Search can also support querying for specific configurations of products. So in this case, the products have different color variants, and I’m able to search and return the specific color-relevant results. One callout here is that while this instance doesn’t make use of customer group-specific pricing or shared catalogs for product visibility configurations, Live Search will honor these settings. So if you want to hide prices from logged-out or anonymous shoppers, or display the contract price or available product set just for a specific user, that would be reflected in these results. Let’s assume I’d like to check out more products, so I can hit the Enter or click View All, and I end up on the Product Results page. Here, we can see a few more controls for the result set. Chiefly, we get faceting running down the left-hand side of the page. These facets are built based on product attributes in the catalog that the merchant has specified as eligible for faceting, and then these are being returned by a combination of manual intervention and our ÃÛ¶¹ÊÓƵ Sensei AI, which we’ll show in just a bit when we get back to the admin section. These facets are intelligently ranked and surfaced for each individual query and result set. Intelligent faceting spares you from spending time on heavy-handed configurations that are commonly required in other solutions. As I start to select different filters, I can see my results refresh in real-time. The page does not have to reload, so I don’t have to wait for anything to repaint. Rather, it all shows within the context of my search results page. Let’s say this search is a little bit too specific. I can also individually remove the facet tags rather than clearing all, which are required by some other search solutions out there. I also have different sort controls, so I can change the sort order and get results re-ranked without a new full-page re-render. So that covers the broad strokes of the storefront experience. From there, let’s dive into the back office. The Live Search admin is incorporated directly into your ÃÛ¶¹ÊÓƵ Commerce admin. It lives under the marketing tab. Let’s check it out. The Live Search admin is arranged into a few simple tabs, which you can see across the top, including Performance, Faceting, Synonyms, Rules, GraphQL, and Settings. Let’s go through each starting with Performance. So up front we have Reporting, which includes key statistics and performance metrics around search. We can see top-line hero metrics such as number of unique searches, click-through rate, conversion rate, and zero results rate. And I should mention here that for the purpose of today’s demo, we’ve injected some mocked up shopper data into this environment, which is why you see data populated here. You can also see a date range and export to CSV for consumption by other BI, data visualization, or data manipulation tools. We can then go a bit deeper into Reporting with a few tables around the most popular unique searches, the most popular queries that returned no results within the catalog, and the most popular products returned based not on query term, but on products that were surfaced for completed searches. The export to CSV will include those tables of data as well, so you can dig deeper, analyze, and manipulate the data elsewhere. From there, we can move into faceting, where we can see some of our Sensei platform intelligence at work. In some search platforms, there’s a pretty lengthy process of defining the query terms or certain categories or products that trigger different facets to appear, and they get into category inheritance of facets and complex logical nested structures of how to display filters. We moved away from that to drastically simplify the experience for you as a merchant. Our facets break down into two categories, pinned and dynamic. Pinned is a facet that is determined by the admin to be applicable to every product on the site, and the pinned facet will always be returned in the explicit order defined here. So, for any query or a category page, these pinned facets, manufacturer, price, categories, and color, are always going to be the first four facets, as long as there’s a product on the page that has a value for one of these attributes, and they’ll always be displayed in that order. Generally, this would be used for things like price and category, so the shopper has a consistent experience, and facets aren’t jumping all over the place as they navigate the site. But because a great deal of product attributes would not be applicable to every product every time for every search, we also have dynamic facets. For dynamic facets, we’re selecting from a list of product attributes we’ve indexed from the product taxonomy, and we’re saying the product attribute should be eligible to be returned for a facet in any given search results or category page. Ultimately, whether or not dynamic facets are displayed in what order is being determined at the time of the query request by ÃÛ¶¹ÊÓƵ Sensei. To talk a little bit more about what Sensei is doing, it intakes the query in a complete view of the catalog, and it understands the specific view of products being returned in the query. Based on that, it determines what the most uniquely relevant product attributes are for that surface set of product results versus all the background of the total catalog. When Sensei does that calculation, it not only provides a determination of whether facets are applicable or relevant to the result set, but also provides a score for each facet to inform how to order them to provide the most impact for the shopper. So no matter where a shopper is going and what they’re searching for, we always provide a highly relevant ranked list of attributes for them to filter, and it saves you and your teams from having to go through and determine for every keyword which facets need to be displayed. Up next, let’s touch on synonyms. Synonyms allow you to map the potentially very large list of query terms that shoppers are throwing at your site to the products and product attributes that you’ve deemed searchable in your catalog. For example, let’s say you have a thousand pants, but a shopper queries trousers. None of those would get returned. So this is a way for you to go in and map those textual relationships. Here we have two types of synonyms, one-way and two-way. In a two-way synonym group, all terms are considered totally synonymous with each other. So we see in the top row for blue, going to aqua, turquoise, cobalt, ocean, sky, cyan, and coral. If any of those terms appear in a shopper’s query, products that contain any of those terms would be returned. That’s different from one-way synonyms, where we can see shirt expanding to sweatshirt. What that means is that if a query comes in for generic shirt, we would show them sweatshirts too. But if they search for sweatshirts, we would not show the results for just shirt. So this can be used as a lever to improve relevancy. Up next, let’s talk about rules. Here is where we get into our intelligent merchandising capabilities, including real-time personalization of search results by ÃÛ¶¹ÊÓƵ Sensei. This is our Merchandising Rules engine, which is a method to augment the returned product set for a given query for driving more attention to some products over others. So I can go in and specify what kind of search condition I would like to target for this specific rule. And here you can see I have a few different logical constraints for how I want to bound or scope this rule. For this, I’m going to select Search Query Contains. We’ll continue to use pants for this query. Then I see this preview screen load in on the right. Without selecting a ranking type, this is showing what the organic or purely textual relevance-based recall order is for a given query. I can also drag the results per row slider down to get an idea of what my first four to six products are in this configuration so I can understand what might show above the fold on mobile, for example. Then we can take a look at ranking types. Today we offer five ranking types that utilize ÃÛ¶¹ÊÓƵ Sensei in our understanding of Shopper, both at the individual user level and the aggregate shopping trends or behavior across the site. As we click through these algorithms, you’ll see the products jumping around. That’s happening because Sensei is re-ranking the product order in response to Shopper data based on events captured from the storefront. Starting from the top, we have Recommended For You, which is a personalization ranking type. This ranking type builds an individual understanding for each shopper based on affinities from shoppers with similar browsing and purchasing patterns. This personalization of search results rankings is happening one-to-one for each shopper as they’re engaging with your site in session. So if a new shopper who has no purchasing history lands on your site without an account and no track record, with each product they click, ÃÛ¶¹ÊÓƵ Sensei can build an understanding of what that shopper’s habits and interests are and then change the search results recall order to reflect that. And that will happen page over page. So as they browse more products on the site, even if they remain logged out or anonymous, we can increase our understanding and affect their merchandising in session. The next three algorithms, Most Viewed, Most Purchased, and Most Added to Cart, are essentially three different definitions of conversion or three different layers of the conversion funnel. As I go to Most Viewed, we can see again the products might jump around. So these would be products that get more clicks, all the way down to Most Purchased. And these are the products that most frequently get bought by shoppers on the site. If you wanted to optimize for a narrower definition of conversion for some queries and more general definition for others, you could do that. For example, if there’s a query that contained a lot of relatively new products, they might not have a lot of purchase data. So you wouldn’t want to arbitrarily punish those newer products that don’t have as much of a track record as longer lived SKUs. This provides that lever to pull to adjust how you want to define conversion in your search results. Then the last intelligent ranking type here is Trending, which is based on aggregate shopper behavior. This algorithm looks at relative sales velocity for each SKU over a selected period of time. We know that some product catalogs move faster than others, so there are three buckets or definitions for the lookback time period here. Finally, we offer None, which is just a way to continue to priorly use the textual relevance and not apply intelligent ranking models to the specific query. For this rule, let’s go ahead and say Most Added to Cart, and then we can add Events, which are manual overrides for specific products. For example, I can click and drag a specific product up so that the product will now appear pinned in the third position rather than the fifth position. You can see that adding a block into the Events section to show that the product was pinned into that position. I can delete that and the product will jump right back down to where it was. Finally, I can give the rule a name. Let’s call it Pants Merch, and I can give it a description or a note about what the rule is doing. And then if this is a temporary rule or promotion, for example, a re-ranking for seasonal items, I can set an active date range and the rule will automatically invalidate itself after some period of time. Rules will publish within about 10 to 15 minutes of that rule being created and would be reflected in the next query for whatever term I specified. Up next, we have the GraphQL tab. It’s basically API introspection. So I can test out for a given query, what does the query look like, and I can browse the full schema of the API. I can look at what I want to return, what makes sense for this specific query, and I can get any specific item returned. Finally, we have the Settings page. The only thing here is the price bucketing configuration. More specifically, this looks at how many selections there should be and what the range of those selections should be within the price facet. So that rounds out the Live Search admin. As a final highlight, the Live Search API is extremely fast and returns results that are extremely relevant. It’s very friendly to shoppers and provides ease of use to merchandisers with our Sensei capabilities, including AI re-ranking and intelligent vasseting. So that rounds out our demo of Live Search. Thank you for tuning in.