default variables: Support Search Data
StephenGWills - October 24, 2007 - 15:46
| Project: | Omniture Integration |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Taken from http://drupal.org/node/182201
5) We also need to capture search data, search term and # of search results.

#1
Can you provide more details on how this should work?
I.e. if search module is enabled and a user searches for "foo" and that returns 20 results then what variables should be populated with what data?
#2
Generally speaking we set two s.props as search variables, like this:
s.prop1="foo"
s.prop2="20"
Note if search returns zero results then s.prop2 needs to be set as s.prop2="zero" not s.prop2="0".
Note that some Omniture customers may not be using s.prop1/2 for search, really any s.prop will do. But the best practice is s.prop1/2.
It may be safe to assume that most customers are using s.prop1/2.
It is also recommended to set s.events="event1" whenever s.prop1 is populated, but this is specified in the s_code.js file. So we don't need to worry about it in the module.
#3
Well, yes, as you point out this is not standard. The one implementation that I've done had different values in the prop1/prop2. Though it might be a nice addition there to have those values.
We could build these up at the beginning of the variables list and then let them get overridden later by other variables.
Steve? Thoughts?
I'm naming a few of these issues "default variables: " because I think it makes sense for the module to "just work" out of the box.
#4
We could also just allow an admin to specify which props to use for search results in SiteCatalyst Admin. I think you have a good thing going by assigning a specific variable to a taxonomy term.
#5
Now that's brilliance. So, we'll have a section for searches that will be disabled unless search module is enabled. Then we'll have two text boxes that default to blank. In your case you'd fill it in like this:
"search term variable" [ s.prop1 ]
"search results variable" [ s.prop2 ]
#6
Perfect. This is also what I am thinking for common Drupal events.
#7
Allowing the admin to map a value to each field is a great idea. Each Site Catalyst implementation is going to be unique...and may need to match an existing corporate outline so that their Global Rollups (combined values for all of an accounts report suites) make sense.
Would Drupal allow modules to report to the Omniture Module which values were available for recording? For example, could the search module report to the Omniture module that it had values such as #results returned, current page #, search term...available for recording? Or instead of only allowing predefined values to be set to each of the prop and eVar variables could a textbox be provided for custom php or javascript? Just some ideas...