Tag: coveo for sitecore

Posted on

Duplicate Facet Value Coveo Dynamic Hierarchical Facet

Recently I bumped in to this issue escalated from our client side. It seemed although ML models are working way too hard. This is my first experience with Dynamic Navigation Coveo ML model which promises to understand what Facet values and Facets are important based on Analytics data captured. It comes in especially handy for top Facets that are frequently used or expected to be used on search page by most users to drill down to their search results.

We were using Coveo Dynamic Category Facet. As always Coveo does excellent job at documenting what this facet is all about and how you can configure it on Coveo for Sitecore. In our case, it was Coveo for Sitecore SXA. You can read more about this facet here.

Now working with Coveo Hive components all these years, I was 100% confident that I did not mess anything in there when the issue was brought to my attention. So, I decided since I am in fairly new territory with DNE ML model, I tried dropping that to see if issue disappears and yep it did indeed.

So, isolation is done, ML model is injecting that duplicate value, now the question really becomes why? Next step like always in debug mode of self, let us create a dummy page with a facet based on field of concern and reproduce on cloud search page. Did exactly that with help of Coveo technical contact and to our surprise, the duplicate value issue was not reproducible on cloud hosted search page on same facet type and same facet field with same ML model that was causing this issue on Coveo for Sitecore search page.

Hmmm??? Brain is going wild now? What could be it. It does not seem like ML model data is incorrect based on no replication scenario I explained above and neither seems to be index issue because well facet values on facet look just fine minus ML model. I was so confused!

I noticed that in debug mode, I saw ranking expressions being injected which definitely seems to be the culprit, but, was not sure why. Below is how ranking expressions looked like.

I started digging deep on something that I was hyper confident on – data source – piece by piece. Below highlighted caught my eye for sure.

Delimiting character can be different per Facet Datasource

I decided not to share my hunch with Coveo support team. I have tried sharing my hunches in the past with Coveo and Sitecore team on support issues and that ends up putting us usually on a different path may be because my hunches are not always the right ones. I usually try not to put words/thoughts on to some one who is looking at the problem to understand their perspective and fresh set of eyes with no pre conceived opinions. 🙂

I patiently waited for Coveo to get back to me on this issue I logged since I was going no where with issue on hand. They said the same thing that they were worried about the custom delimiter. To ensure ML model does not throw fits, we had to pass some custom advanced parameters on DNE ML Model. I added below to the model and voila…. No more dups. 🙂

 "commandLineParameters": ["--conf", "coveo.drill.hierarchicalFacetSeparator=:"  ]

This got me super curious and I wanted to see what else you can do in advanced parameters on ML model. Here is gold mine of good amount of samples. Funny news is none of the examples here could have solved our issue. Coveo promised they will update the documentation to reflect this hiccup. All set and ironed out!

I almost did a party dance. This resolve has gotten us the feature complete sign off. We are set to go live next week. Super excited!

Thanks to Coveo support team who really helped us get over this hump .

Posted on

Coveo SXA Facet Responsiveness

On recent adventure with latest and greatest of Coveo for Sitecore version as soon as we put together a dummy page to add couple OOTB Coveo components. We immediately noted that on mobile mode the facets were not grouping behind this button called ‘filters’ like it typically does on Coveo installations.

My first guess after looking at few things and trying to ensure I followed all the instructions provided in terms of placeholder hierarchy to follow to inject a Coveo Dynamic Facet is it has to do with SXA usage instead of native MVC Coveo for Hive renderings. Since Coveo mentioned many clients out there have used SXA, we were not worried to leverage SXA as that is direction on the instance we were working with.

I tried couple different things –

Placeholder hierarchy expected for

When none of the above worked it was time to loop in Coveo team for their input as this should work OOTB. I logged this Q&A on Coveo Connect and collaborated directly with my Technical Architect of Coveo and voila they suggested a very nice work around and Facets now collapse behind ‘Filters’ button and our team is super happy as we can focus more on data/content/index/relevancy instead of UI aspect that should be working with Coveo Platform.

Thank you Coveo team for your prompt responsiveness like always. Here is the link that has the concern and solution for those who stumble upon this issue. Hope this helps!

https://connect.coveo.com/s/question/0D76Q00000Cpeek/detail?s1oid=00D3000000007r2&s1nid=0DB0d000000fxdx&emkind=chatterCommentNotification&emvtk=2tNYr4lOQ.xL_jZ5HmzKHjjYk6gg8Nd7wO1ytVlSoEY%3D&s1uid=00532000006Jmya&emtm=1629724236181&fromEmail=1&s1ext=0

In a nut shell, we got to add coveo-facet-column to Sitecore column that contains Coveo facets.

Posted on

See the magic – Coveo Recommendations

If you have not gotten a chance to review my other posts that I wrote up based on our experience implementing Coveo recommendations from the scratch, I would strongly advise going through them first.

Post 1 – Was all about visual clues

Post 2 – The real deal

In this post, now that we have gotten all the set up done, I will focus on how to actually get some recommendations to show up to ensure we apply styles, test the filters out and basically yeah see a working version of recommendations. It was not actually that straight forward, but, thanks to couple hands and also huge thank you to @vbernard to help give some awesome tips that helped us force recommendations when everything else failed.

First, when we have the rendering up on the presentation on all our product detail templates where we wanted to show recommendations from Coveo, we started by visiting lot of pages that made sense to the user flow. I had couple of hands, no kidding here, so, basically I read few posts to understand how Coveo recommendations work internally, though it is a black box, it is fairly easy to understand the basic logic behind how it works. So, we attacked it in such a way that it is bent to give us some results.

This is what we did and it worked on our lower environment and started sending recommendations back, you can also choose to use your QA to fire off some tests and automated requests to do the same. We did a bit of both actually – manual go to set of links that emulated various levels of our product pages and an automated hit to several urls as well.

In a nut shell, Coveo recommendations looks for patterns based on history of the end user and suggests what might interest the user next based on the history and matches that it can find from the recommendations model. It is also important to ensure recommendations model has enough data by adjusting the training settings on the ML model. We tried couple different settings there and rebuilding the model after we visited bunch of pages, circling around the products we care about. Finally! We see the below on our recommendations component

We got lucky to be able to test this on lower environments due to multiple hands and effort by the team to emulate what we could, so, we can test it thoroughly with filters on hand. Oh! In regards to filters, we actually needed lot of context based filters, so, we approached this in two fold process –

  1. Adding a processor via config to coveoProcessParsedRestResponse, this essentially would add in some additional meta data per result that we need for queries and filters. There is some real good example and documentation loaded here . We followed similar path, but, added our own business logic to load context data needed on our filters
  2. Next up, we added a JS query filter as documented here and used a bunch of expression builders based on all the data we loaded either on processor or via the recommendations view such as current item ID or some miscellaneous information we needed per business requirements on what to show on recommendations and what not to.

Now, I am a true believer of back up plans, if our hardwork to emulate and get the recommendations engine to send us a few recommendations had failed, then, we would have applied styles and do other tests via a hack provided to us by @vbernard from Coveo. Here are the steps to make that work:

Step 1: Add a new pipeline

Step 2: Push some featured results to this pipeline

Ignore the cool stones and take a peek at the featured results

Step 3 : Now go back to ML models and add a recommendations model

Thats it! You should now see the recommendations forced and you would probably see the featured results on your recommendations. Do note though that you should start really small/basic on your view if you are trying to do this forced result approach. In our case, it was kind of hard to use this approach and test what we needed to as we really lean on context for most part. But, probably it might work on basic use cases.

Posted on

The Real Deal – Coveo Recommendations

In my last post, I focused on the visual clues. If you have not already, please read the first post on coveo recommendations here

In this post, we will focus on actual steps once you did decide that Coveo Recommendations will serve your requirement on hand. Coveo, as always does awesome job with the documentation on how to use recommendations by following the steps noted below. Since Coveo does such a good job at documentation, I am not going to repeat myself here and refer you all to check out this page here

Now to highlight our experience when we followed the steps noted on the Coveo documentation, we learned the below on each step along the way:

Step #1 – Currently, there is no way to actually see the page view events from Coveo Administrative tool, but, you have two check points to quickly note if page views are being captured. Quick screenshots below for reference

Step #2 & Step #3 : It is one of the most straight forward steps and after you quickly add the pipeline and model, you should be able to see them up on Coveo Administrative tool

Go to Models under Machine Learning section

Query Pipelines
You should be able to click on Pipeline, go to machine learning tab and click on edit for the model to see the settings on training set, that is one of the most important settings to ensure you set to appropriate values based on your data set.

Step #4 & Step #5: We figured that this is actually not needed in our case. It was working fine with out doing any additional set up, turns out this was just for sanity or may be older versions of Coveo for Sitecore, not sure. But, was not needed for us.

Step #6 : So, this step once we have our own datasource item, we added Coveo Recommendations to our presentation on all templates that needed to show this component. When we added this component, we could see a new call fire off on XHR requests that would go fetch recommendations. It also started maintaining history of the user views and sent that along with request. We encountered an error here because one scenario where special characters persisted in Title field of the page would cause server error as noted here . We submitted a PR for this scenario and the fix was included in latest release of JS framework

That is it and the last step was publish and we figured we should start seeing recommendations right away. But, it is not that simple. 🙂 In my next post, I will go over the various tricks we did to get the recommendations to show on our pages where we inserted this component.

Additional note here, we did want to show only product recommendations, so, to avoid additional filter additions in our case, we chose to add content type on our page views which we can then utilize on our filter on model to show only specific content type like below.

As you can see the specific filter allows you to pass in a string for content type which is actually set on Sitecore on the rendering properties for Coveo Page Analytics
This should be picked on datasource set on Coveo Page View Analytics rendering

Next up, I will share how we did the filters, forced recommendations, a quick tip shared by @vbernard when everything else fails on how to trick the system to actually send in some recommendations and any other issues we encountered while implementing recommendations using Coveo.

Posted on

Coveo new GUID generation issue

Thursday last week, one of my team member ran in to an issue which was preventing XHR request to fire off to Coveo and get the results back. He struggled to overcome the issue almost whole day long and at that time as his lead it became my responsibility to help solve the issue. I was actually quite doubtful about it and unsure if I could help solve or not, but, as a lead, rule is you can not pass on fear to your team, you have to no matter you feel pass confidence that – ‘Yes, we will get over this’. Challenge Accepted!

Here is a sneak peek of the issue. So, in older versions of Coveo and in more fond memory on Legacy framework implementation, each interface element had a unique ID that you would need to pass from presentation details via properties on your rendering. If you do not do much about it, a unique identifier will be generated when you create a new content item that has the presentation of Coveo embedded. With hive, it is actually not so different, pretty similar, only the properties are on data sources. The issue on hand is that, on the interface view HTML, the @Model.ID was actually coming back as ‘$GenerateNewUniqueID’ instead of DOM Element ID noted on presentation. You can see this below on the screenshot.

Error on JS for generating unique ID.

So, as with any issue, it becomes very important to replicate the issue on local especially when you can not get your brain juices flowing on call on tough problems like this. See the steps I did to crack this thing

  1. Why would Coveo not replace this in first place? It should automatically happen. My team mate stumbled upon few Q&A and checked the pipeline related that does this behind the scenes to ensure that is in place and hooked properly.
  2. We checked the presentation again very carefully and datasources to ensure DOM ID is present and is unique
  3. Ensure this is copied over properly to Final Layout on Sitecore as well and indeed there is a correct data source being passed in presentation.
  4. Then we ran an ugly experiment to actually replace standard value as it seemed like Coveo for some reason was taking that. No luck, still same issue.
  5. Re-installed Coveo For Sitecore package relating to our Sitecore version and published everything. Still Nothing!
  6. This was working just fine on our UAT server, so, just to try our luck ported over all packages from UAT related to bare bone Coveo templates, layouts, etc., Nope! Did not work.
  7. Ran out of all options!

One little detail from my team mate sparked an experience from the past. He said when he installed a package that has just one item while he was experimenting did something and though the XHR request was still having lot of issues, he could now see the ID replaced now. That reminded me that in the past when we ran in to weird issues where presentation was not updated even if the presentation did look right on Coveo end, an IIS Reset had solved all problems. Went ahead and tried that and knocked out browser cache just in case and boom, everything started working.

I should have probably done IIS reset first before trying anything, but, with more knowledge you gather you would want to explore that rather than blind belief that a restart or reset would solve things. 🙂

This whole debugging experience got me thinking if I was not a Software Engineer, I would have made one awesome FBI Agent for some reason. It almost felt like I was connecting from past and paying attention of little detail on hand to solve the issue. Quite a few memories of great crime investigation series flashed in my brain. lol

Posted on

Coveo and Sitecore Link Provider

links

My last post was a kick off a series of things to watch out for and pay attention to while implementing Coveo For Sitecore on a Multi-tenant/Multi-Site Sitecore instance.   This is a runner-up for my last post and part of same series.  Let me start this by saying, URL on search result is single most important entry point for your user to see detailed content around what they think is relevant.  To ensure this is rendered right every single time,  It is very critical that you know your Sitecore Link provider or Custom Link provider if any in and out on your Coveo For Sitecore installation.

There are few things that you will need to know in order to fine tune anything or in order to debug issues if any when you see things you do not wish to see in relation to Url’s either on Indexes or on your search page.  If you are lucky and do not have much of customization going in your Sitecore link provider, you should be fine doing nothing as Coveo fires off link provider at it’s two most important phases OOTB.

  1. Index Sync Process
  2. Displaying paged results on Coveo driven search page

Now, the most important thing to remember is that while Coveo does #1 noted above it calls Sitecore Link Provider in “shell” context while doing it’s best to load up UrlOptions object that is passed in as a parameter to Sitecore GetItemURL method of Link Provider with appropriate site details it could resolve the currently indexed item with.   Coveo has their algorithm that runs as part of ResolveItemSiteProcessor located in coveoResolveItemSite pipeline.  Below is the snippet of that processor located on Coveo.SearchProvider.Config

<coveoResolveItemSite>
<processor type="Coveo.SearchProvider.Processors.ResolveItemSiteProcessor, Coveo.SearchProviderBase" />
</coveoResolveItemSite>

If this processor is not working wonders for you, go ahead and remove this in your favorite custom coveo configuration file and add your own.   For curious brains,  I recommend changing your level of logging to DEBUG to understand what happens step by step while Coveo tries syncing your Index.    That was very insightful in understanding sequence of calls and pipelines that fire while Coveo is indexing or doing sync process.  But, do remember change that back to INFO after your appetite is satisfied. 😉

Now, for the last clue,  on #2 stated above when your Coveo Search Page renders your search results for a query, it calls Sitecore link provider again to get the click uri for each search result that goes with each search result.  Now, pay attention here, very important to know that the context site this call runs in is “coveorest”.  If your link provider is super awesome and written very well thought out, you will have no problems regardless on the context site the call is running in.  But, if your link provider is using context.site instead of using site info from UrlOptions or doing some thing really out of this world, you have to know these things to ensure you hit the gold.

Hopefully these tidbits will help you debug any issues while Coveo constructs the URL’s at indexing or run time.  If you have lot of shared content that does not reside under a specific site node, then, it is very hard to get the URL right at indexing time which is why it is even more important to focus on #2 to ensure the end user experience is seamless and correct leading them to correct site, language and context.

There, I gave away a hint, next up, I will be covering language related insights like fall back and localization in my next post.  That is all for now, tune in soon for more.  🙂