Tie internal search results to 0 search results

[Meghan_Powers]

Hello,
We capture free-text search terms in eVar33 - aka customers go to our internal search bar and type in something like "hondas" and that takes them to a search page with results.  We are interested in learning which internal search terms lead to 0 search results.  We fire both a prop23 = 0 as well as event58 when 0 results are returned.  Based on the sequencing of page load and rendering results, this is the order in which they currently display:  
Server call 1/hit 1 - capture internal search term in evar33
Server call 2/hit 2 - fire prop23 = 0
Server call 3/hit 3 - fire event58

When we look at evar33 with event58, we get lots of internal search terms that DO return results...the problem is that because evars are sticky, a customer can then go apply other search criteria after that, like a certain store, or exotic paint color to that, which would then return 0 results.  So their free text term could lead to results and then if they apply other criteria (through regular filters, not free-text evar), then they get event58.

Any recommendations on the best way to do this analysis?

Thanks!

[Jennifer_Dungan · Accepted solution]

I don't see why you need 3 server calls.. I can understand 2 (one for search submit, and one for Search Results page)... I don't know why prop23 and event58 are on separate server calls...

That said, in my implementation, I track both "Search Form Submit" and "Search Result Pages"... My eVar holding the search term is set to "HIT" level expiry.... and I capture the search terms on both the Search Submit, and on the Search Results page (since that information is available to me via the search query param in the URL).

I have 2 different events for "search" one is for the submit, and one is for the results pages (so that I can segment the data easily).

Then I track an eVar on the results page that holds the results returned (I have other eVars holding other search page relevant content, such as page number, results per page, sort order, filters in use, etc - All set to Hit Level expiry)

So when my search result page is loaded, I include on that page view all the relevant search results information.

In my reports, I can segment for "search result pages", and I can correlate my eVars in different combinations to see what is resulting in 0 results, and I don't have to worry about any "sticky" eVar expiries, because I am not using any retention. Each usage is fully independent of each other.

If the user applies filters, I treat that as a new "search submission" but I also have a dimension holding a basic lookup value about what search is being submitted (main search, refine search, etc).. This way I can also see initial main searches separately from refine searches.. 

[yuhuisg]

Not answering your question directly, but for prop23, instead of tracking the value "0", I would track the value "zero". This is because AA could treat "0" as false or null, resulting in it reporting "Unspecified" in prop23 instead of "0".

[Jennifer_Dungan]

Right, if Adobe and "0"... I track multiple items in a single eVar with | delimiters... but yeah.. if you are doing that on it's own, rewrite 0 to zero to be safe!

[Hemang35]

To analyze the internal search terms that lead to 0 search results, you can consider the following approach:

Set up a new eVar (e.g., eVar34) to capture the search term when there are 0 search results. When the search results are 0 (prop23 = 0 and event58 is fired), populate eVar34 with the same value as eVar33 (the search term).

javascript
if (prop23 === "0") { s.eVar34 = s.eVar33; }

Set the expiration of the new eVar (eVar34) to "hit" or "event". This way, it won't persist beyond the current hit or event.

In Adobe Analytics, create a report using eVar34 with event58. This will show you the internal search terms that lead to 0 search results.

By using this approach, you're capturing the search terms only when there are 0 search results, and you're not affected by the stickiness of eVar33, which can cause data inaccuracies when customers apply additional filters.

Once you have set up the new eVar and made the necessary changes in your code, you can analyze the data in Adobe Analytics and gain insights into which internal search terms lead to 0 search results.

[Jennifer_Dungan]

If s.eVar33 is being set on the "search submit", with a Visit level expiry, setting s.eVar34 = s.eVar33 won't work.... s.eVar33 will not have a value in the JS object... 

Adobe eVar expiry is all a backend process... a value is sent, and it will maintain that value in post processing until the expiry is reached or a new value is set. But when you look at your actual tracking, only the requests where the eVars are set will show values.. 

Example:

• Page 1 (search form is a part of the page, but not yet interacted with) - eVarX not set   - JS object empty, tracking empty
• Search Form submit, as the user starts a search, before leaving the page - eVarX is set with "value" (likely extracted from the search query input field), s.tl() beacon is sent (eVarX is part of the tracking call)
• Search Result Page is loaded (Page View) - eVarX is no longer set in JS, it's empty. The Page View tracking does not include eVarX (in the post processing, eVarX is part of the correlation values for this page view based on eVarX expiry policy)

If you try and use JS to set the value of eVarY to the same value as eVarX, you will just end up with no value.

Unless in Launch the eVarX Data Element has been set up with additional retention (which could also mess up trying to see the difference between instance of eVar and maintained eVar values - so this is something that must be done with care), the Data Element will be an empty value based on the fact that the search form is no longer on the page....

IF the search results have a search form on the page, and the value is maintained for the user to be visible for what they searched for, you don't need to set eVarY=eVarX..... you can just set eVarY (Hit Level Expiry) directly with the Data Element...

[victoria_paskannaya]

Hi! Do you want to capture no-result search events into AA immediately to reroute and trigger real-time events by other apps? I am surprised to see that an internal search tool you use does not automatically track zero search events.