Wel­come to the Site­Cat­a­lyst Finance Fun­da­men­tals blog series.  In this series we will dis­cuss the imple­men­ta­tion basics and exam­ple analy­sis of each fun­da­men­tal solu­tion that Finan­cial Ser­vices cus­tomers should con­sider lever­ag­ing.  Stay tuned and please feel free to con­tribute your thoughts/experience as we dis­cuss each solution.

Once you’ve fig­ured out how users have made their way to your site, what they are look­ing at, and who those vis­i­tors are, the next thing mar­keters want to know about vis­i­tor behav­ior is “What are vis­i­tors look­ing for on my site?” Here is where track­ing inter­nal search comes into play.

Most sites have an inter­nal search box on their site (you can see the Dig­i­tal Mar­ket­ing Blog’s search box peek­ing out of the top right cor­ner of your screen). When the user per­forms an inter­nal search, the results that are returned are spe­cific to that web prop­erty. Track­ing inter­nal search per­for­mance will answer ques­tions such as:

  • What are vis­i­tors look­ing for on my site?
  • What are vis­i­tors look­ing for that my site doesn’t have?
  • How are users refin­ing their search terms over the course of a visit?
  • What search terms are lead­ing to conversion?

Basic Imple­men­ta­tion

Luck­ily, inter­nal search is fairly easy to track, and can often times be done with­out any inter­ven­tion from your site’s devel­op­ers. To suc­cess­fully imple­ment this fun­da­men­tal, you’ll need the fol­low­ing variables:

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

Cap­tur­ing the Search Term

Most search soft­ware (Google Search Appli­ance, Endeca, Adobe’s own Search&Promote, etc.) passes search term as part of the query string para­me­ter when the user per­forms a search. Cap­tur­ing the search term in the AppMeasurement.js (or s_code.js) is as easy as:

  • Using the get­Query­Param util­ity (the get­Query­Param plu­gin for those of you on H code) to read the value of the query string para­me­ter con­tain­ing the search term
  • Dedu­pli­cat­ing the search term to remove sub­se­quent searches using the get­Val­Once plugin
  • Set­ting the inter­nal search event using the Append to List plugin

Once all of that is said and done, your code will look some­thing 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 per­forms a search on your site, the code will exe­cute and the vari­ables will be set auto­mat­i­cally. Pretty easy!

Cap­tur­ing Searches with No Results

One of the more advanced inter­nal search imple­men­ta­tions is to cap­ture when a search returns no results, such as this search on the Dig­i­tal Mar­ket­ing Blog:

sv_internal_search_1

When the user per­forms a search that doesn’t return any results, we want to trig­ger an event to flag this search term in addi­tion to the items out­lined above. There are two ways of doing this:

  • Through a query string para­me­ter that indi­cates the num­ber of search results returned – read the value using Util.getQueryParam in the s_code file. If the value is 0, then trig­ger the event.
  • Mod­ify the search results page tem­ple to trig­ger the event at the page level when no results are returned. This might take some XML magic, so talk to one of your devel­op­ers if you have issues cap­tur­ing this.

Basic Report­ing

Once you’ve rolled the code above out to pro­duc­tion, you should start see­ing inter­nal search terms pop­u­lat­ing your eVar and prop report. To see the data, run the Inter­nal Search Term eVar report, and pull in the met­rics of Inter­nal Searches, Searches with No Results, and any down­stream suc­cess events of your choos­ing. You’ll end up with a report like this:

sv_internal_search_2

Our friends at the fic­tional Adobe Bank can already see sev­eral inter­est­ing things in run­ning just this sim­ple report:

  1. State­ments” is the most fre­quently searched for item. Are users hav­ing a hard time find­ing their online state­ments? Does putting a more promi­nent link on the account cen­ter help users find state­ments easier?
  2. Our top inter­nal search terms all return results con­sis­tently, which is good. Addi­tional analy­sis can be done to see which terms don’t return results, and make changes to the site to incor­po­rate that content.
  3. The “state­ment” search term has a very low new account appli­ca­tion com­ple­tion rate. Is this because users who are look­ing for a state­ment are already cus­tomers? Addi­tional analy­sis should be per­formed to seg­ment out cus­tomer traf­fic and see what prospects are look­ing for.

In our next blog post of this series, we will exam­ine advanced report­ing and analy­sis that can be done with inter­nal search data using pathing, SAINT, page names. Stay tuned!

Have a ques­tion about any­thing related to Site­Cat­a­lyst for the Finan­cial Ser­vices indus­try?  Do you have any tips or best prac­tices to share?  If so, please leave a com­ment here or send me an email at svertree (at) adobe​.com and I will do my best to answer it on this blog so every­one can learn! (Don’t worry – I’ll keep your name and com­pany name confidential).

0 comments