In-site Testing and SEO
POSTED BY: Craig ScribnerPOSTED ON: Feb 15, 2008 5:58:09 PM
Through this association, I met a woman who is one a team of thirty people who work on her company's analytic testing and web optimization program. A group of analysts, a group of developers, and people doing other stuff. Maybe that's no surprise to you, but I almost fell out of my chair. For three years, I have been the single point of administration, implementation and analysis for all our web tests. A one-man shop.
That's not to say nobody else wants to test things on the site. People continually bring me ideas or mocks, and here's my process:
- Put together a business case. Most of the time marketers who bring me ideas haven't drilled into the numbers to see what kind of proclivities our site users have, or what kind of lift we can hope for in a best-case scenario. Assuming this proposal makes the cut, I will then...
- Put on my analytics administator hat. I decide which variables to use to deliver all the KPI's I want. That usually means mimicking the same values into three or four different variables, so I can pull pathing reports as well as same-visit and latent conversion reports.
- Put on my web developer hat, and modify the existing page so it becomes a test page. This part is the purpose of my post, so I'll go into details later.
- Push the test out to our QA server, and test myself.
- Push the page to production, and then watch my little garden grow.
The problem with testing in-site pages is the risk you run to your SEO rankings, which are paramount in my company. They put the bread on each employee's table. So diverting half of a page's traffic to a different URL doesn't fly around here.
My solution has been to have both the control bit and the variation(s) I'm testing on the same page, inside <div> tags that are hidden by default. Then I have some javascript that reads a cookie to see if this visitor's already been randomized into a group, and if not, puts them in one. Each group will see their own variation no matter how many times they re-render the page (the corresponding <div> is displayed and the other ones hidden based on the cookie value).
Sorry about all the technical mumbo-jumbo, but this whole post is to say that I finally had a break-through on this front. I composed a template for Marketing or whatever dept wants to bring me a test that will put all of the coding & testing onus back on them.
It only took me a couple of hours to give them all the Javascript snippets with instructions on how to get the variable names, test names and numbers, and what to do with them. It's as straighforward as a search and replace they can do with those pieces, but then it's their job to test the page to make sure it's ready to push before it comes my way.
No more will I have to take two or more html pages--usually coded by different designers--and try to make them play nice together. That chore has been something that's really impaired my ability to maintain as many concurrent tests as we can really handle.
And who knows? Maybe relinquishing control over everything analytics is my first step towards creating a team of 30 people all devoted to optimization!
Keywords: testing seo


Nice workaround....
Actually; I think there is much to be said for being a 'one-stop shop'..have far more hands-on experience to offer.
Lucie
Posted by: Lucie F | April 05, 2008 at 12:20 PM