If you are searching for a side-by-side comparison of Google Analytics vs. Omniture, you are in way over your head. May I kindly suggest that you take a step back and read Web Analytics 2.0, this book will provide you with a solid understanding of web measurement.
I’m guessing by the time you get to the end of the book, you’ll no longer have the need to search for ‘Google Analytics vs. Omniture’.
As we advance in our careers, regardless of our chosen profession, our thoughts and ideas become more ridged. The more I learn about testing & optimization, there fewer possibilities there are in my mind. I was reminded of this today when the kids came bursting through my office door, grinning from ear to ear, “dad…..dad”, they said as they tried to catch their breath, “one of the houses down the street is for sale and we want to buy it and turn it into a club house.”
I smiled and almost blurted out “do you have any idea how expensive it is to buy a house?” but I caught myself as Suzuki’s words began to echo in my head “In the beginner’s mind there are many possibilities, in the expert’s mind there are few.”
They pulled a spiral bound notebook out of a backpack and began to flip through the pages. The notebook was full of plans for how each room in the house would be utilized, who would be welcome in the club house, and general club house rules. In the back of the book was a page devoted to revenue generation. “Sell bottled water to sweaty construction workers”, “Mow neighbor’s lawns”, and “buy stuff at yard sales to resell.”
In children’s minds there are many possibilities, they haven’t had the years of experience that has taught them to narrow their view of the world. My experience is not absolute, I’m not sure I know anyone’s whose is, therefore there will always be possibilities that my experience can not account for. Yet the more I learn, the fewer the possible ways there are to optimize a site. Experience tells me that X, Y, and Z are the best alternatives to test.
Next time you sit down to your next analysis or you are designing your next round of optimization tests, throw out your preconceived notions and view the world as a child would view it, there may just be a brilliant gem hiding in your beginner’s mind.
Recently, I sat down with the guys at Beyond Web Analytics to discuss the art of segmentation.
If you are into analytics and measurement, the Beyond Web Analytics podcast series is a must listen.
As many of you know, I recently stepped down from my position as Web Analytics Manager at Spark Networks to join Numeric Analytics. As I was beginning my transition, I was amazed at how much tribal knowledge was stuck in my head, it was the only place in the company that the knowledge lived. It quickly became apparent that I had failed at properly telling the story of web analytics.
So I started asking myself the question, why wasn’t I sharing my knowledge freely within the organization. Unfortunately, I don’t think I’ll ever come to an easy explanation as of why. Sure, I have a lot of excuses (I didn’t have time, there were too many people to share it with, my boss would think I was spending too much time talking and not enough time doing) but these are just that, excuses, and I can’t think of one legitimate excuse for why we shouldn’t be openly sharing our knowledge and if you tell me “we don’t want our competition to know our measurement secrets”, then I’m going to laugh in your face.
Whenever I hear of people closely guarding their web measurement strategies, I can’t help thinking about the Utah Jazz in the days of “Stockton to Malone.”
Every team knew that the Jazz were going to continually run the pick and roll with Stockton and Malone. If fact, I remember being at one game, watching John Stockton come down the court, holding up one finger, and all the opposing players starting shouting out “pick and roll, they are running the pick and roll”, yet they couldn’t stop it.
Did the Utah Jazz offensive system with Stockton and Malone work so well because their game plan was a closely guarded secret? NO! It worked, despite the fact that the other team, the announcers, the ball boys, and everyone else in the arena knew their plays. It worked because they executed to near perfection.
If you are not openly sharing your tribal knowledge, especially within your own organizations, I suggest your start asking the question ‘why’.
REMEMBER: Your game plan is worthless unless you can execute!
1. Save the Discover JNLP file to your desktop
2. Edit the JNLP file using your favorite text editor
3. Delete the ‘token’ argument
4. Insert a ‘password’ argument, below the ‘user’ argument, and enter your password
5. Save the JNLP file. Double click your desktop icon. That is all there is to it.
I was recently working on a project to optimize a landing page that was targeted at paid traffic. The test results didn’t reveal anything of much interest however I was able to uncover a hidden gem in the data.
By segmenting, by channel, the path behavior of visitors hitting the paid landing page, I discovered a large percentage of current members were coming back to the site from paid search.
Using Omniture Discover, I applied a simple segment that included visits where the campaign tracking code contained the word ‘ppc’.
I then applied this segment to a Next Page Flow report. Note, the intended call to action is “Register”.
Quickly, I noticed this odd behavior pattern. This page is targeted at non-members, why are so many members coming back to the site from paid search?
Have you ever watched your mom use the Internet? I have something I call the “Mom Principle”. When my mom wants to visit a website that she knows the URL for, she does this:
In fact, she is not alone, I have seen many MANY people use Google search as their own personal address bar. Could it be possible that visitors to this site are using the Mom Principle to access the site? The data suggests this may very well be the case.
We have already converted this visitor to a member, yet the better we are at keeping them around, the more expensive they become. Let’s suppose they come back to the site 5 times a week. Chances are good that they are taking the same steps to get to the site every time, search Google, click first link they see, which in this case is a paid link. Ouch!
What can we do about it?
Change Google
Perhaps we can test different copy on paid and natural links. Differentiate paid links, by making a stronger call to register for the site, from natural links that could ask current members to log in.
Change User Behavior
We could detect current members coming to our site from paid search and offer them advice on how to easily access our site, perhaps offering them a link to create a bookmark.
These are just some simple ideas I came up with between eating some pasta and playing Super Mario Bros. with my son, I’m sure you can come up with many more ideas to address the problem (if you come up with some good ones, please do share). However, any amount that we can move the needle will result in cost savings for the company.
It’s getting dark outside, do you know what your paid traffic is doing?
I’ve been offering some of my measurement and site optimization advice to my good friend Kevin Winzeler and as the winter olympics in Vancouver came to a close, it reminded me of a photo shoot I was honored to be apart of. I wandered around with a camera, shooting some behind the scenes footage, which I compiled into this short video sequence.
Check out his site, he is an amazing photographer.
Having been in the WA space for seven years now, both on the vendor side with Omniture and now on the client side managing a web analytics group, I have seen a broad spectrum of business requirements, implementations, reporting needs and analysis. I remember working with a major retailer and their massive pre-implementation documentation that outlined seemingly every link on their site, a credit card and financial services company had a wide range of requirements for every facet of their business, and a leading media company that was forging ahead as an early adopter of video tracking (long before the OMTR video tracking offering) and so forth. Though all of them had the common goal to augment their businesses with web behavioral knowledge, each had different ideas of what needed to be done first. Some argued that they should focus on one portion of their business as a pilot; others wanted everything ready to go live all at once. Many discussions (some of them louder than others) were had about which method of deployment and measurement would be more beneficial and valid arguments were made for either side. However, the greatest hindrance to success was thinking that the entire project (from business requirement collection >> implementation >> report distribution >> analysis) could be swallowed whole…one big gulp and then belch out results.
For all who tried to eat the proverbial elephant in one bite, it was a complex and frustrating venture. Implementations had dizzying logic to account for complicated scenarios and it was nearly impossible to validate completeness once in QA or in production. Each business pushed for their key reporting to be ready first, analysts were interpreting data incorrectly since they did not understand the context in which the data was collected etc. This of course led to great dissatisfaction for many and when the smoke cleared, all that was left was a massive, tangled ball filled with duct tape fixes and shortsighted solutions. It took months upon months to go back and straighten bent nails, re-hang doors sticking doors and touch-up painted walls in their house of analytics that was built in haste. Worse yet, the business had grown weary of the data that was being produced or the way it was interpreted. Even basic reporting was in doubt as many questioned the completeness of the implementation.
I understand that businesses live in a world where time is seemingly running at two-times the normal pace and I also understand the political nature behind priorities for projects. I realize that the business world is not a perfect world and therefore write the remainder of this article with the intended purpose of showing the value of advancing your analytic ball, ten yards at a time (apologies to those who don’t know the game of football very well).
In football, fans love to see exciting plays: The Hail Mary, Flee-Flicker, Double Reverse and kick returns for touchdowns. There is nothing exciting about a four yard run off-tackle. A slant pass to the slot receiver for seven yards doesn’t raise people out of their seats. But from a strategy standpoint, there is nothing more frustrating for defensive players and coaches than playing against on offense who can consistently move the ball down the field…one first down after another. In your web analytic practice, how well are you advancing the ball? How many projects do you start and actually complete fully? When your projects are complete, are they everything you envisioned before you started? What is the project lifecycle from business requirement to implementation to reporting to analysis?
So many companies that I have worked with don’t want to hear about four yard plays, they want every play to be a long pass. They want to know “everything about everything”, they want to know how many people with blue eyes were standing on one foot when they opted out of a purchase flow. What do you do about that? When I get a request for “tracking” and the request comes with no requirements or the all encompassing “I need to know everything about everything” request, I know that zero thought has been put into the reporting of the project and therefore, I must step in and manage the game.
When I look at everything on my Work Stack, it would be very easy for me to get discouraged. Every play call from the sideline seems to be a post pattern 30 yards down field. However, I have no problem making a few audibles at the line of scrimmage. Here are three things that have helped me move our analytic practice consistently forward that may be of service to you:
• Implementation completion: This is your foundation! How confident are you in your implementation from pageNames to merchandizing eVars on a scale of 1-10? If you are not at a 9-10, you are not in a good place. Take some time to review your implementation and document the hell out of it. When analyzing your data, any doubt about how it was produced is a showstopper. I highly suggest you leverage an automated service to crawl your site(s) to provide you reporting on which pages have outdated code, variables and logic. The best solution for the money that I have seen is from ObservePoint.
• Ambiguity has no place in requirements: Never accept the phrase “need tracking” as the sole requirement from the business. At the end of the day, when the business comes back and asks pointed questions (which they will), you will be responsible to point them to the answers. I suggest that you kindly reply with some “base metrics” that will be available with your current implementation but put the onus back on the business to define specific reporting/analysis requirements. Nothing will derail your data reputation faster than being able to only answer 30% of the questions that are sure to come. Additionally, every project will seemingly drag on and on, as you have to repeatedly update your implementation to answer the requirements that trickle in over time.
• Help the business understand the value of the four yard run on first down: When you get a project of sizable proportion, with requirements so complex that you don’t even know if its possible, take the time to break the request down into controlled, manageable parts. The goal is still to score a touchdown, but explain the value in doing it with a series of high percentage plays. For example, make sure the base metrics are implemented correctly first, then move to interaction tracking, events and eVar expiration. Once those are confirmed to be implemented and reporting correctly, move to correlations/sub-relations, classifications and automated report delivery. Architect a design solution that shows the business milestones and what will be available at each, let the business see that even though the progress is methodical, it will lead them to exactly what they are hoping for, a touchdown!
If you haven’t heard of Visual Website Optimizer then I suggest you go check them out now. Do it. Go! Check them out, then come back and read the rest of this post.
Visual Website Optimizer (VWO), currently in beta, is poised to be a real player in the optimization space. Their elegant design and drop-dead simple approach to designing, launching, and monitoring tests is just sexy, I don’t know how else to describe it.
I have been part of the beta team testing VWO for over a month now and, as you can probably tell, I am impressed. So impressed, that I wanted to pull my VWO data into Omniture SiteCatalyst and Omniture Discover to extend the value of the product even further.
The integration between VWO and Omniture was super simple.
Step 1: If you haven’t already done so, designate one of your Custom Conversion variables as your optimization tracking variable.
Step 2: Copy the following code snippte and paste it into the doPlugins section of your s_code.js file.
var _combination = _vis_opt_readCookie(‘_vis_opt_exp_’+_vis_opt_experiment_id+’_combi’);
if(typeof(_vis_opt_comb_name[_combination]) != “undefined”){
s.eVar1= _vis_opt_experiment_id + ‘:’ + _vis_opt_comb_name[_combination]
}}
Step 3: That’s it!!!
NOTE: Using a similar approach, you can very easily integrate VWO with Google Analytics using ‘pageTracker._setCustomVar’.
I’m running an A|B test on the ‘Contact Jason’ section of my blog.
I’m testing if it’s best to show a photo of me or to show an icon of a telephone. When the integration code executes, my conversion variable is populated with the following:
s.eVar1=”Contact Icon:Photo”
‘Contact Icon’ is the site section that I’m testing and ‘Photo’ is the treatment version. For reference, you can see these values inside the details section of your test within VWO.
Although Visual Website Optimizer is still in it’s infancy, I see good things in their future. They really seem to value customer engagement and their product is sexy as hell.
P.S. I have a few beta invites to VWO, if you are interested, email me via my contact form.
Avinash Kaushik
Crepuscular Light
Kevin Rogers
Pritesh Patel
Rudi Shumpert
Omniture Image Request Length
Last week I saw several Tweets about the best way to determine the Omniture Image Request length. I’m not sure this is the “best way”, but this is a simple bookmark that I created to return the size of the request being sent to Omniture.
javascript:alert(eval('s_i_'+s.visitorNamespace+'.src.length'));NOTE: This code only works for ‘H Code’ using the standard ‘S Object’.
The bookmark is used in the same way that your standard Omniture debugger is used. To add this bookmark.
1. Using any webpage, create a new bookmark.
2. Edit the bookmark you just created.
3. Delete all the text from the URL field.
4. Paste the above code into the URL field.
5. Click ‘ok’
Now you can simply navigate to any of your site page and click the bookmark:
Why is this important?
It used to be that a long URL was only a problem for sites with big shopping carts, today that is no longer the case. With companies becoming more sophisticated in their web analytics practice, they are capturing and sending more and more information on every page view.
That information is sent to your analytics provider, in this case Omniture, via a URL. Each browser has a set limit for how long a URL can be and the lowest common denominator seems to be Internet Explorer at 2083 characters. That means, if you are sending large chunks of data to Omniture, over 2083 characters, there is a chance that some of that data will be lost.
Let’s take it a step further.
The above code is simply a snapshot in time. As web pages are dynamic, so are web site visitors. Perhaps, depending on who I am, what I’ve done before, if I’ve logged in to the site or not, there may be more or less information to send about me. The bookmark gives you an idea but to get the full picture, we will need to capture and report on this data within Omniture SiteCatalyst.
Here is how I deployed the tracking for this blog:
1. Added a block of code, AFTER, my standard Omniture page code. This block captures the current page name and image request length and writes the values to a cookies.
2. Added a block of code to my s_code.js file, in the s_doPlugins function, to read the cookie and write the values to two custom insight variables.
if (s.c_r('omtrLen')){ getOmtrLen = s.c_r('omtrLen'); var mySplitResult = getOmtrLen.split(":"); var myPageName = mySplitResult[1]; var myImageLen = mySplitResult[0]; s.prop6 = myPageName; s.prop7 = myImageLen; }3. Created a 2-Item correlations between my two (page and image length) Custom Insight variables.
NOTE: I am capturing page name in a Custom Insight as I am calculating the length of the image request length AFTER the omniture code has executed. So, my two options are 1) pass the values on the next page, similar to how ClickMap works or 2) on the same page using a Custom Link call (costing me more money) but in either case, I’ll need to rely on capturing the page name in a variable other than s.pageName.
Now you can analyze your data. Here are a few ideas:
1. Run the “Page” report (in my report suite this is prop6) and pick a high volume page. Break the page down by “Image Length” and look for values > 2083
2. Run the “Image Length” report and look for vlaues > 2083 and break them down by “Page” to find the offending pages.
3. If you have a large number of entries and this is a report you will run on say a monthly basis, it may make sense to classify your results. I’m classifying my data into three buckets. This is easy to do by exporting Image Lengths and assigning the buckets using a simple Excel Worksheet.
Bucket 1 (<=1800): SAFE
Bucket 2 (>1800 and =< 2082): WARNING
Bucket 3 (>= 2083): ERROR