Welcome to the SiteCatalyst Finance Fundamentals blog series.  In this series we will discuss the implementation basics and example analysis of each fundamental solution that Financial Services customers should consider leveraging.  Stay tuned and please feel free to contribute your thoughts/experience as we discuss each solution.

Once you’ve figured out how users have made their way to your site, what they are looking at, and who those visitors are, the next thing marketers want to know about visitor behavior is “What are visitors looking for on my site?” Here is where tracking internal search comes into play.

Most sites have an internal search box on their site (you can see the Digital Marketing Blog’s search box peeking out of the top right corner of your screen). When the user performs an internal search, the results that are returned are specific to that web property. Tracking internal search performance will answer questions such as:

  • What are visitors looking for on my site?
  • What are visitors looking for that my site doesn’t have?
  • How are users refining their search terms over the course of a visit?
  • What search terms are leading to conversion?

Basic Implementation

Luckily, internal search is fairly easy to track, and can often times be done without any intervention from your site’s developers. To successfully implement this fundamental, you’ll need the following variables:

  • Internal search term – prop with pathing enabled and eVar set to visit expiration
  • Event for searches
  • Event for searches with no results (optional)

Capturing the Search Term

Most search software (Google Search Appliance, Endeca, Adobe’s own Search&Promote, etc.) passes search term as part of the query string parameter when the user performs a search. Capturing the search term in the AppMeasurement.js (or s_code.js) is as easy as:

  • Using the getQueryParam utility (the getQueryParam plugin for those of you on H code) to read the value of the query string parameter containing the search term
  • Deduplicating the search term to remove subsequent searches using the getValOnce plugin
  • Setting the internal search event using the Append to List plugin

Once all of that is said and done, your code will look something like this:

s.eVar1=s.Util.getQueryParam("q"); // capture search term
if (s.eVar1){s.eVar1=s.getValOnce(s.eVar1,'s_v1',0);} // deduplicate search term
if (s.eVar1) {
    s.prop1="D=v1"; // copy search term into prop
    s.events=s.apl(s.events,"event1",",",2); // trigger event

When the user performs a search on your site, the code will execute and the variables will be set automatically. Pretty easy!

Capturing Searches with No Results

One of the more advanced internal search implementations is to capture when a search returns no results, such as this search on the Digital Marketing Blog:


When the user performs a search that doesn’t return any results, we want to trigger an event to flag this search term in addition to the items outlined above. There are two ways of doing this:

  • Through a query string parameter that indicates the number of search results returned – read the value using Util.getQueryParam in the s_code file. If the value is 0, then trigger the event.
  • Modify the search results page temple to trigger the event at the page level when no results are returned. This might take some XML magic, so talk to one of your developers if you have issues capturing this.

Basic Reporting

Once you’ve rolled the code above out to production, you should start seeing internal search terms populating your eVar and prop report. To see the data, run the Internal Search Term eVar report, and pull in the metrics of Internal Searches, Searches with No Results, and any downstream success events of your choosing. You’ll end up with a report like this:


Our friends at the fictional Adobe Bank can already see several interesting things in running just this simple report:

  1. “Statements” is the most frequently searched for item. Are users having a hard time finding their online statements? Does putting a more prominent link on the account center help users find statements easier?
  2. Our top internal search terms all return results consistently, which is good. Additional analysis can be done to see which terms don’t return results, and make changes to the site to incorporate that content.
  3. The “statement” search term has a very low new account application completion rate. Is this because users who are looking for a statement are already customers? Additional analysis should be performed to segment out customer traffic and see what prospects are looking for.

In our next blog post of this series, we will examine advanced reporting and analysis that can be done with internal search data using pathing, SAINT, page names. Stay tuned!

Have a question about anything related to SiteCatalyst for the Financial Services industry?  Do you have any tips or best practices to share?  If so, please leave a comment here or send me an email at svertree (at) adobe.com and I will do my best to answer it on this blog so everyone can learn! (Don’t worry – I’ll keep your name and company name confidential).