Integrating Voice of Customer (VOC) and Web Behavioral Data

Getting Really Fancy: Full Integration of Behavioral and Online Survey Data

In my last post on this topic, I showed how to capture all of the data from survey responses in a dedicated report suite that only contains survey information. It takes quite a bit more work, but there is a way to effectively integrate ALL of the survey data with the behavioral data. This is the ultimate in survey integration.  In this post, I’ll show how you can take a simple tool like QuestionPro and achieve complete, near real-time integration with Omniture.

The dedicated report suite to save survey data was originally Jesse Gross’ suggestion and it’s pretty clever. But I think it’s annoying that you can’t have all of the survey data integrated with the online behavioral data with this method. Fortunately, there’s a way to do that as well. With the Omniture API very much on my mind, I dreamed up the strategy I'm going to describe here. And while it might be overkill in some cases, it really does provide a best-of-all-worlds level of integration.

It’s easy enough to capture the information from multiple survey responses in a web analytics variable – you can simply concatenate them into a string. Since the QuestionPro language just substitutes custom variables wherever they are found, you can build a javascript line that looks like this:
s.prop6 = “Q1:{customVar1}^Q2:{customVar2}^Q3:{customVar3} etc.

If you’re using this method, you can string many values together (it’s best to use just the numeric response values) into a single variable. You might end up passing something like this:

s.prop6 = “Q1:3^Q2:6^Q3:0^Q4:10^Q5:1^Q6:Yes^Q7:0^Q8:^Q9:7^

In Omniture, props and eVars have a 100 character limit. So if you assume that each numeric response can take a maximum of 6 characters, you can store 16 questions in a single variable. That means you could capture most online surveys with 3-4 variables.

You’re probably thinking that capturing the responses in string values like this may be clever but not very useful. It would awfully hard to use data stored in this fashion. And you’d be right. But there’s a way to solve that problem too.

In Omniture you can use a tool called SAINT to lookup and translate values. You can even create multiple SiteCatalyst interface variables from a single string value. In other words, you can use SAINT to change a string like the one above into 9 different named variables in the interface, with each response translated into the correct survey equivalent. All you need to do is build a SAINT table with the translations.

When I first thought of this idea I imagined that we could simply generate a SAINT table for every possible survey combination. A quick look at the client’s surveys quashed that notion. Consider a block of six 1-10 “How satisfied are you with…” questions: this yields fully a million possible combinations. A full survey would have many more possible answer combinations than could ever be captured in a simple lookup tool like SAINT.

But here’s the thing – we know that in the real-world the number of combinations must be much smaller for the simple reason that even if every single survey is completely unique (as may be the case) we are only surveying thousands or tens of thousands of visitors. There simply can’t be more instantiated combinations that there are respondents.

So here’s where the API comes in handy. Omniture now provides an API for both Reporting and SAINT. You need to use both to implement survey tracking on all questions.

The idea is startling simple. Using the API, your application reads the string values actually instantiated in each s.prop variable. It parses the string values and builds a SAINT table that translates every unique combination actually stored. It then uses the SAINT API to submit the updated table. The result: an automated system that translates the values of every survey question into something that is easily human readable.

Now I’m not going to pretend that writing an API application like this is anything like as easy as the basic integration of a small set of VOC questions into your report suites or even the capture of the entire survey in a dedicated survey report suite.

As I said in my last post, building any application is going to take a pretty decent amount of work – this is really a pretty simple application but it is still an application. Keep in mind, however, that this method will give you full, complete integration of the survey data into your existing analytics tool.

That seems like it might be a worth enough to make the effort worthwhile!

Comments

[Adam Greco]

Interesting concept...A few misc. items to keep in mind...First, Omniture SiteCatalyst eVars can actually hold 255 characters now (vs 100 in the old days). This may allow you to store more questions in fewer variables. Second, you might want to consider using the Products variable which can store multiple values vs. an sProp or evar. Another idea worth exploring is to pass the survey question as a variable and use a Counter eVar or an Incrementer Event (set in the Product string) to capture the question answers (if you want to add up the scores). I have not tried these myself, but wanted to throw them out there as ideas to explore...Thanks!

[Eden]

It would be great if SurveyGizmo would create a merge code like [question("time taken")] or [page("time taken")]I'd like to know how many sedoncs a survey respondent spends on each question or page, not just the total survey time taken.Inserting a survey time taken merge code on an earlier page in the survey does not record this in a static way. It changes dynamically as the user continues through the survey, and ends up in the data report being the same number of sedoncs for the whole survey.Also if a user stops taking the survey, but then returns later to resume answering questions, does the timer stop and then re-start, or keep going in the meantime?Michael Scarce on Thu, Apr 28 11 at 2:50 pm