There has been some discussion of “Analytics” vs/accompanied by “Implementor” skills in the web analytics industry of late. Given I am far from an expert myself, I’ve enlisted the POV of some clever folks to through in their 5 cents about the need for, or benefits of, implementation and technical skills for web analysts.

Thomas Bosilevac: I love it all
Mashable Metrics
@Bosilytics on Twitter

To paraphrase the Cluetrain manifesto:  “I am not a developer, or a programmer or a code monkey.  I am an analyst.”  That said I am a hell of a Geeky analyst, one that isn’t afraid of digging into some JS code, scraping page variables and utilizing server-side scripting.  However I would be quite depressed if that is all I did.  That said, the wonderful world of web analytics applies both to my left and right brain creating the dream correlation.

Web analytics tagging (ie. Implementation) is a fine art between assuring that data is passed to the reporting platform effectively but in a manner that will not shoot you in the foot later.  I have worked with some of the most talented developers out there, however, explaining that the event tag needs to only fire off on the INITIAL hit seems to pass clear over their heads.  The impact and significance of the matter might as well be the final Space Shuttle already in orbit.  Making a page work well is much different than assuring data is collected well.

For that reason I love my trade.  I get to discuss process management, KPI development and marketing scenarios with top brass at Fortune 100 companies during the day and staying up late assuring the landing page is using the correct eVars or doing server-side scripting to push initial cookie values out of a hit stream.  It is with this duality that each day is different and usually more interesting than the one before it.

Jenn Kunz: Know enough to work with each other

http://blog.implementalytics.com/
@Jenn_Kunz on Twitter

I do believe, like I suspect most people do, that ideally any analyst will have a good understanding of implementation and any implementer will have a good understanding of analysis. Do I expect an analyst to know the code? No. But a good analyst will know how cookies work and how they affect the data; what the difference is between the different types of variables and how to use them; what kind of configuration settings are available and when to change them. Since they are the ones IN the data, once they have an understanding of how things are set up, they are the most likely to come up with the kind of questions that make an implementation evolve into something better.

As for implementors- you can easily find implementers who have never done analysis. And it’s a shame, but that’s all the industry often expects of them: take a list of business requirements, turn it into a solution, see the code deployed, then wash your hands of it. But what the world needs is some sort of “uber-implementor”: a “tech guy” (or gal as the case may be)  who can tell you the best practices as well as technology limitations as you map out requirements, and who is involved beyond just the deployment of the code, all the way until after the end-users have done their first deep-dives in the reports. No one is going to know how to use those reports better than the person who created them.

Bryan Cristina:  The knowledge will benefit you

http://bryanalytics.blogspot.com/
@BigBryC on Twitter

I tend to avoid absolutes such as “need” when referring to someone’s skills. I think everyone is different and has their own strengths and weaknesses, so saying someone needs to have implementation skills to be hired might mean you miss out on an excel wizard or just an overall brilliant analyst.

I think Web Analytics involves a full process that begins with measurement planning and moves on to a tagging strategy, an implementation, report building/configuration of the analytics tool, to data gathering, then analysis, onto reporting, presentation, and finally helping facilitate a discussion on recommendations or changes that need to happen.

Implementation is just a part of the analytics process, but it still is an important, crucial part of the overall whole that I think someone would benefit from knowing. At times there are issues with data or a conclusion that doesn’t make sense other than realizing there is an implementation issue (or pick any point along the process). Are you willing to do a lot of unnecessary investigation with just the data you have, wasting precious time, and then finally having to ask someone that knows more than you about how the tags are implemented and how the data is being captured? Or would it be better to be able to identify the issue yourself, know how to fix it, and get it moving towards a resolution immediately? The more you know about the overall process, the more you’ll know where the issues can be, how to fix them, and can ultimately spend more time doing the right kind of analysis.

Michele Hinojosa:  Focus on your strengths

http://www.michelehinojosa.com
@michelehinojosa on Twitter

I won’t deceive anyone. My experience and skills rest far more on the “business analytics” side than on the “technical” side. Would I love to have the mad tech and implementation skills that some folks have? Sure. Do I fare okay without it? Most of the time.

I do agree with Tim Wilson about Analyst/Implementor skills being more of a spectrum. And yes, having skills that span both can be very valuable. (It’s safe to say that the more skills you can have in your back pocket, the better.) However, that doesn’t mean that if you are more “business analyst” or more “implementor” (aka focus more on one than the other) that you can’t have a successful career.

If you do tend to skew more to one side or the other, you likely will have good opportunities in a company with a larger analytics team, where you’re able to focus on your strengths. Someone who falls more in the middle, with a balance of both skill sets, might suit a “jack of all trades” role, where both skill sets are needed in the one resource.

As our field grows, and teams get bigger, I think we’ll see more specialisation – people focused on more specific skills. (After all, doctors aren’t surgeons and anesthetists and cardiologists and general practitioners. They specialise, but they do all have the same basic knowledge at the core.) My overall advice would be to do what you’re interested in. Doing what interests you means you’re more likely to excel at it, and add value to your company. If you love the business side, focus there. If you’re a code geek, focus on the technical side. That doesn’t let you off the hook entirely – you should still be learning what you can. You’ll want to know enough to work with your implementation or business-focused folks, understand what they’re doing and make the (informed) decisions they need from you. But ultimately, your time is well spent honing your strengths.

Lee Isensee: Titles don’t matter – the team is responsible together for success

http://www.omlee.net
@OMLee on Twitter

Having first started my career as an early practitioner, there really wasn’t the idea of implementation and it wasn’t until a couple years later that I understood why – I was consuming what I had in front of me and thought that it was the sky. Woah, information!

Since moving from a practitioner into the vendor realm I have changed my opinion substantially and believe that the solution is not as black and white as “analyst” or “implementer” but rather a unique combination of skills to meet the business requirements, technical requirements and on-going strategy of the customer.

Not once have I ever been in a situation, that resulted in true success, where the “implementer” did not have some level of engagement in the needs of the “analyst” and never have I seen the “analyst” truly believe that the “implementer” was not, at some level, invested in helping them get stuff done.

By creating isolated roles you are setting up your team for lots of finger pointing. Ultimately, your success will not be defined by who to staff on your team, but rather the building-out of your initial strategy, business requirements, technical requirements and phased expectations. It doesn’t matter what the titles, roles, experience, etc. are, rather it is the responsibility of the entire group to take ownership.