27600RE: [webanalytics] Tracking onsite search correctly with Omniture
- Feb 28, 2011Hi Dave,
You could try firing the "internal Search" event on the button
submission for your search box rather than on the results page.
However, if this code change is difficult I think looking at visits for
the onsite search term prop would give you a good proxy. Keep in mind
it wouldn't de-dupe customers that searched for the same query twice in
their visit. We track a bunch of different things related to onsite
search so maybe this can give you some ideas...
Searches and Zero results searches: 2 separate events
Search term: prop & evar
Result Count: Prop
Search Page: prop (eg. 1, 2, 3...this could help you determine how many
visits for each term get past Page 1)
Successful Search: event set onclick when customers click on a link
within the result set
Search Slot: eVar
Previous Search Page: Prop (we use the getPreviousValue plugin)
Anyone else out there have any good onsite search tracking tips?
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Dave
Sent: Monday, February 28, 2011 9:47 AM
Subject: [webanalytics] Tracking onsite search correctly with Omniture
We've recently implemented Zoom Search on our website, which is tagged
and tracked with Omniture tags, and I've been tasked with getting some
usable, actionable, MI from the the search tool.
I've successfully implemented the getQueryParam to pull the search
string into a prop (for counting) and an eVar (to track conversion), and
set an event "Internal Search" on the search results page. And
everything seemed fine, to start with.
However, I'm having trouble with the volume of searches. If a visitor
searches for "widget", and does not find what they want on the first
page with results 1-10, they then click 11-20. And, because it's the
same page which hosts the search results, the same URL loads, and the
event fires again - another search for "widget".
Is there an easy way to deduplicate the visitors who carry out a
multiple-page search, clicking from 1-10 to 11-20, then back to 1-10,
then 11-20 and 21-30. These people are easy to identify when they search
for "wigdet" or "very specific widget" but they're messing up my data.
Can anybody help, please?
[Non-text portions of this message have been removed]
- << Previous post in topic Next post in topic >>