Tracking Internal Search

We have explored a lot of basic techniques and fundamental principles of web analytics and Adobe Analytics specifically. I guess it is time for a practical tip. Read the following, understand it, then take it to your friendly marketer and see what she says. She might be positively surprised!

Internal Search

Most web sites have an internal search. I’m talking about that box in the top right corner that allows visitors to type search terms and that usually links to a result page with products, articles or links that match those terms.

Your friendly marketer usually wants to know what terms people typed in and whether they got any results or not.

Makes sense: when visitors type search terms, they’re basically telling your marketer what they are looking for. Free marketing. Would be a crime not to analyse that! And the merchandising or content teams can look at the terms to decide where to go as well.

So far so good.

Check

Let’s check whether your site is currently tagged up for that.

Go to the site, type a search term, hit enter and wait for the results page to load. Then look at the tracking using your favourite debugger. Check the “variables” that are being sent.

Do you see an event? What about if you search for something that doesn’t have results? Do you see two events? Good.

Is there an eVar that sends the search term? Good.

Most sites have these basics covered.

Let’s move further.

Click-through Rate

An interesting aspect of a search results page: how many people click on which results? Interesting but rarely tracked.

Adam Greco (who else?) has written a blog post on Internal Search Click-through & Exit Rates, which you can read (I’ll wait for you here) to understand the basic idea.

In order to implement this, we need one more event.

Now this new event (Adam calls it “Internal Search Results Clicks”) should only be sent when a visitor clicks on a search result (see Tracking Links & Actions). It should also only be sent once per search result, so it doesn’t overinflate the numbers.

Funny enough: this is all we need in terms of implementation!

Your friendly marketer would create two calculated metrics as per Adam’s post: “Internal Search CTR %” and “Internal Search Exit Rate %”.

This is fairly easy to do yet I don’t see many people do it. You can see it as an opportunity! Prepare your end — make sure you know how to implement it and when you can push it live, then go to your friendly marketer and tell her about it. Show her Adam’s article, she’ll understand.

Notes

I would absolutely follow Adam’s advice and implement two events!

While the first one only fires once per search and search result and therefore allows your marketer to analyse the individual results, the second one fires on every click on a result.

Firing on every click on any results will let your marketer evaluate how “engaged” visitors were in correlation with search terms.

Example: people looking for “ipad” might have clicked on two or three results mainly: iPad Mini, iPad and maybe Nexus 7. Your marketer can look at the first event and deduct that currently, the iPad Mini is popular for this search term.

On the other hand, when comparing the second event (i.e. all clicks on results) between search terms “ipad” and “android”, your marketer might find that people looking for one might be looking at a lot more results overall then those who search for the other.

The search terms are in an eVar. That means your marketer can use all sorts of metrics to analyse them: Searches, Internal Search Results CTR %, Cart Adds, Checkouts and Purchases. Or maybe Searches, Internal Search Results CTR %, Blog Article Views. Or Searches, Internal Search Results CTR %, White Paper Downloads.

If you integrate offline data, you might even get something like this:

[Screenshot]
Internal Search Terms Report with added Metrics
If there is one thing you do today, do this! Your marketer will thank you.

6 thoughts on “Tracking Internal Search

  1. Bijan

    Hi Jan,
    again a good one.
    I also prefer to put the searchterm into a prop with pathing enabled to get the prev & next flow beside the hard facts…

    Like

  2. Pingback: Real Time Reports via the Reporting API | Web Analytics for Developers

  3. Pingback: Tagging Forms (w/o Losing Money) | Web Analytics for Developers

  4. Going through your whole blog and it’s a huge help!

    Would you suggest setting events for “successful search” and “unsuccessful search” or just “search” and “unsuccessful search”. Thanks

    Like

    1. Hi Tom,

      That depends.

      Having two events allows you to run a report that shows all searches that were not successful, which can be a useful report. If you do that, I’d probably use “search” (including the unsuccessful ones) plus “unsuccessful search”. I can’t of the top off my head think if a report that would use “successful search” and still be easily explainable.

      The real alternative would be to use a single event and a prop or eVar that stores the number of results. That prop/eVar can be classified (it must! numbers in dimensions are ugly) and you can break your search report down by it.

      Or, do both, two events and prop+eVar.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s