I'll admit now that I don't much care for Formula 1 motor racing. My brother-in-law is a massive fan, however, and on any given Sunday afternoon during the F1 season, he'll be watching it very closely while my mother-in-law puts the final touches on Sunday lunch. He's interested in the racing, following his favourite drivers and who's managed to execute the most daring overtaking maneouvre. Since it's on the TV, I'll end up watching it, and what I've found most interesting is the number of people in the team who support the driver. There's a whole squad of team members to carry out the tyre changes; refuelling; visor-wiping and so on, and another squad who spend most of the race time staring at computer screens and reports, studying them extremely closely. You'd think that having gone to the track for the race, that they'd want to watch it live, but no, they seem more interested in watching it on the TV, just like my brother-in-law and me.
I don't know exactly what they're monitoring, but I imagine there are sensors all over the car, reporting data on the car's tyre pressure and temperature; fuel load; the engine temperature; revs; speed and so on. Occasionally, the call goes out over the team radio, "You need to slow down and conserve fuel...", "Your engine is getting very hot, ease off and use fewer revs...", "Prepare for a tyre change...", "Your fuel load is fine, and you're gaining on the driver in front...", "Move over and let your team mate come past, he needs the championship points." Perhaps not the last one, but based on the screen-loads of data coming from the car, the support team are able to work out what's happening to the car, so that the driver can drive in the race.
So the call goes out, "Slow down, you're running hot and we need to get you into the pit lane." However, the driver is the one driving the car, and if he fancies his chances at a risky overtaking maneouvre, then he'll put his foot on the accelerator and get that little bit extra from the car to squeeze through on the exit of a bend. He risks overheating his engine, and possibly causing it to break completely, but he successfully overtakes his competitor.
Then the engine starts producing large clouds of blue smoke. The car starts to lose speed. It's a bit like a scene in Pixar's "Cars".
It rarely happens like this, from what I've seen. Everybody on the team wants the car to win, from the driver to the guy who stands in the pit lane and holds the stop-go lollipop, to the team manager, and everybody understands their role. If the screen-watchers see that the engine is running hot, then they have to decide how important this is - is it a show-stopper? - and then tell the driver. Ultimately, the decision lies with the driver on how to drive the car, and he hasn't got time to check all the data that the car is producing - he's the one holding the steering wheel, and he's the one with his foot on the accelerator.
Is web analytics like watching the speedometer but not having the steering wheel or the brake? As web analysts, we're responsible for reviewing the data being produced by visitors to our sites, but the task of editing a site and making changes usually falls to another team or a colleague with HTML, Java or programming skills. We can see how traffic, conversions and success metrics are changing, and we can set alerts and warnings when the figures start to move in an unwanted direction. We can send the messages to our colleague, but unless he (or she) understands what the warning means, and why it's being sent, and what to do about it, the colleague is unlikely to understand and acknowledge that action needs to be taken.
Yes, the F1 team have a few advantages to help them along: the data they have is immediate, and is understood by all the engineers (and the driver) in the team. For example, with oil temperature, there are agreed levels in place for the volume of oil and its temperature. Everybody knows what 'too hot' looks like, and they know what to do if the temperature starts to rise; the driver knows what this means and what to do about it. The team members also know what the risks are if the temperature continues to rise - will the engine start to burn oil, will the engine explode, or seize up? Is it a minor inconvenience as the cockpit temperature warms up, or is it a total show-stopper that might end the race completely?
Most web analysts don't have that level of success or failure hanging on their recommendations, but the whole team may miss out if a recommendation isn’t made. They may miss out on those incremental improvements that lead to further success, or they may let a poor-performing campaign run on for longer than it should. And the blame may not lie with the HTML team – although we may think it does, as they’re the ones who have built the site and are able to make the changes to it. The analyst spots a trend in the data, “This figure is going up week-on-week and that other figure is staying the same.” And? Or, as Avinash Kaushik puts it in his book, “So what?” Do we continue with the campaign? Do we increase our keyword bid? Do we change the page layout? It’s important – vital, even – that our data leads to a recommendation. We may not achieve the change we think is required, but without a recommendation in our insight, we’re not making it easy for the HTML to consider making the changes. What’s my recommendation? Identify the issue. Keep it brief. Make a proposal.
Does the F1 engineer come on the radio and say to the driver, “Your engine temperature has risen for the last three laps in a row, and your fuel consumption is below average.”? No, he says, “You’re overheating, slow down.” He identifies the issue, keeps it concise, and adds a recommendation for action. And now, having done that myself, I’ll stop.
I don't know exactly what they're monitoring, but I imagine there are sensors all over the car, reporting data on the car's tyre pressure and temperature; fuel load; the engine temperature; revs; speed and so on. Occasionally, the call goes out over the team radio, "You need to slow down and conserve fuel...", "Your engine is getting very hot, ease off and use fewer revs...", "Prepare for a tyre change...", "Your fuel load is fine, and you're gaining on the driver in front...", "Move over and let your team mate come past, he needs the championship points." Perhaps not the last one, but based on the screen-loads of data coming from the car, the support team are able to work out what's happening to the car, so that the driver can drive in the race.
So the call goes out, "Slow down, you're running hot and we need to get you into the pit lane." However, the driver is the one driving the car, and if he fancies his chances at a risky overtaking maneouvre, then he'll put his foot on the accelerator and get that little bit extra from the car to squeeze through on the exit of a bend. He risks overheating his engine, and possibly causing it to break completely, but he successfully overtakes his competitor.
Then the engine starts producing large clouds of blue smoke. The car starts to lose speed. It's a bit like a scene in Pixar's "Cars".
It rarely happens like this, from what I've seen. Everybody on the team wants the car to win, from the driver to the guy who stands in the pit lane and holds the stop-go lollipop, to the team manager, and everybody understands their role. If the screen-watchers see that the engine is running hot, then they have to decide how important this is - is it a show-stopper? - and then tell the driver. Ultimately, the decision lies with the driver on how to drive the car, and he hasn't got time to check all the data that the car is producing - he's the one holding the steering wheel, and he's the one with his foot on the accelerator.
Is web analytics like watching the speedometer but not having the steering wheel or the brake? As web analysts, we're responsible for reviewing the data being produced by visitors to our sites, but the task of editing a site and making changes usually falls to another team or a colleague with HTML, Java or programming skills. We can see how traffic, conversions and success metrics are changing, and we can set alerts and warnings when the figures start to move in an unwanted direction. We can send the messages to our colleague, but unless he (or she) understands what the warning means, and why it's being sent, and what to do about it, the colleague is unlikely to understand and acknowledge that action needs to be taken.
Yes, the F1 team have a few advantages to help them along: the data they have is immediate, and is understood by all the engineers (and the driver) in the team. For example, with oil temperature, there are agreed levels in place for the volume of oil and its temperature. Everybody knows what 'too hot' looks like, and they know what to do if the temperature starts to rise; the driver knows what this means and what to do about it. The team members also know what the risks are if the temperature continues to rise - will the engine start to burn oil, will the engine explode, or seize up? Is it a minor inconvenience as the cockpit temperature warms up, or is it a total show-stopper that might end the race completely?
Most web analysts don't have that level of success or failure hanging on their recommendations, but the whole team may miss out if a recommendation isn’t made. They may miss out on those incremental improvements that lead to further success, or they may let a poor-performing campaign run on for longer than it should. And the blame may not lie with the HTML team – although we may think it does, as they’re the ones who have built the site and are able to make the changes to it. The analyst spots a trend in the data, “This figure is going up week-on-week and that other figure is staying the same.” And? Or, as Avinash Kaushik puts it in his book, “So what?” Do we continue with the campaign? Do we increase our keyword bid? Do we change the page layout? It’s important – vital, even – that our data leads to a recommendation. We may not achieve the change we think is required, but without a recommendation in our insight, we’re not making it easy for the HTML to consider making the changes. What’s my recommendation? Identify the issue. Keep it brief. Make a proposal.
Does the F1 engineer come on the radio and say to the driver, “Your engine temperature has risen for the last three laps in a row, and your fuel consumption is below average.”? No, he says, “You’re overheating, slow down.” He identifies the issue, keeps it concise, and adds a recommendation for action. And now, having done that myself, I’ll stop.