Everybody knows why your company has a website, and everybody tracks the site's KPIs.
Except that this a modern retelling of the story of three blind men who tried to describe an elephant by touch alone, and everyone has a limited and specific view of your website. Are you tracking orders? Are you tracking revenue? Are you tracking traffic? Organic? Paid? Banner? Affiliate? Or, dare I ask, are you just tracking hits?
This siloed approach can actually work, with each person - or more likely, each team - working towards a larger common goal which can be connected to one of the site's actual KPIs. After all, more traffic should lead to more orders, in theory. The real problem arises when people from one team start talking to another about the success of a joint project. Suddenly, we have an unexpected culture clash and two teams, working within the same business, are speaking virtually different languages. The words are the same, but the definitions are different, and while everybody is using the same words, they're actually discussing very different concepts.
At this stage, it becomes essential to take a step back and take time to understand what everyone means when they use phrases like, "KPIs","success metrics", or even "conversion". I mean, everyone knows there's one agreed definition of conversion, right? No? Add to cart; complete order; complete a quote, or a lead-generation activity - I have seen and heard all of these called 'conversion'.
When it comes to testing, this situation can become amplified, as recipes are typically being proposed or supported by different teams with different aims. One team's KPIs may be very different from another's. As the testing lead, it's your responsibility to determine what the aims of the test are, and from them - and nothing else - what the KPIs are. Yes, you can have more than one KPI, but you must then determine which KPI is actually the most important (or dare I say, "key"), and negotiate these with your stakeholders.
A range of my previous pieces of advice on testing become more critical here, as you'll need to ensure that your test recipes really do test your hypothesis, and that the metrics will test the hypothesis. And, to avoid any doubt, make sure you actually define your success criteria in terms of basic metrics (visits, visitors, orders, revenue, page views, file downloads), so that everybody is on the same page (literally and metaphorically).
Keep everybody updated on your plans, and keep asking the obvious questions - assume as little as possible and make sure you gather all your stakeholders' ideas and requirements. What do you want to test? Why? What do you want to measure? Why?
Yes, you might sound like an insistent three-year-old, but it will be worth it in the end!
Except that this a modern retelling of the story of three blind men who tried to describe an elephant by touch alone, and everyone has a limited and specific view of your website. Are you tracking orders? Are you tracking revenue? Are you tracking traffic? Organic? Paid? Banner? Affiliate? Or, dare I ask, are you just tracking hits?
This siloed approach can actually work, with each person - or more likely, each team - working towards a larger common goal which can be connected to one of the site's actual KPIs. After all, more traffic should lead to more orders, in theory. The real problem arises when people from one team start talking to another about the success of a joint project. Suddenly, we have an unexpected culture clash and two teams, working within the same business, are speaking virtually different languages. The words are the same, but the definitions are different, and while everybody is using the same words, they're actually discussing very different concepts.
At this stage, it becomes essential to take a step back and take time to understand what everyone means when they use phrases like, "KPIs","success metrics", or even "conversion". I mean, everyone knows there's one agreed definition of conversion, right? No? Add to cart; complete order; complete a quote, or a lead-generation activity - I have seen and heard all of these called 'conversion'.
When it comes to testing, this situation can become amplified, as recipes are typically being proposed or supported by different teams with different aims. One team's KPIs may be very different from another's. As the testing lead, it's your responsibility to determine what the aims of the test are, and from them - and nothing else - what the KPIs are. Yes, you can have more than one KPI, but you must then determine which KPI is actually the most important (or dare I say, "key"), and negotiate these with your stakeholders.
A range of my previous pieces of advice on testing become more critical here, as you'll need to ensure that your test recipes really do test your hypothesis, and that the metrics will test the hypothesis. And, to avoid any doubt, make sure you actually define your success criteria in terms of basic metrics (visits, visitors, orders, revenue, page views, file downloads), so that everybody is on the same page (literally and metaphorically).
Keep everybody updated on your plans, and keep asking the obvious questions - assume as little as possible and make sure you gather all your stakeholders' ideas and requirements. What do you want to test? Why? What do you want to measure? Why?
Yes, you might sound like an insistent three-year-old, but it will be worth it in the end!
No comments:
Post a Comment