Note: this article is relevant for you if you have ever, or are likely to participate in a bigger project that includes building the platform as well as deploying Analytics, Target, Audience Management, or similar tools. I think it is relevant for developers as well as project managers.
Often, we Analytics people are tasked with the deployment, maintenance, or clean-up of our stuff, Analytics stuff, on existing websites. Sometimes, we are riding along when the site is built. We love the latter! We feel appreciated when people listen to us at an early stage. We see it as a big opportunity, and we do our best not to mess up.
So how come that if I look back on projects like this, I pretty often feel that I did?
I think there is a cultural rift somewhere in those projects. I think we (Analytics/Target/Audience Manager folk) have to learn how to cross this rift. I think this is probably our second biggest challenge (after evangelising a generally and genuinely data-driven approach to everything).
Since you, dear reader, are by definition a developer (or a project manager who received this because a developer forwarded it to you), I will not write about that challenge. It is for us to manage. But I want to paint a bigger picture, illuminating how we see those projects. My hope is that while we start building the bridge on our end, maybe I can tell you where to start on yours. And at the very least, you might understand how we tick.
Projects are Projects
Most projects that build websites have two distinct phases: before go-live and after go-live. The time before go-live might be structured itself, maybe in an agile way, maybe into phases following the good old waterfall model. The go-live is the goal of the project, the end in pretty much every sense. Any work after go-live will likely be part of a new project.
If you have followed this blog, or maybe just read about the concept of a “data layer”, you’ll understand why we want to be part of the project during the pre-go-live phase: our work uses data that the site must surface, ideally into the data layer.
Which means that we would love to be able to define that data layer, contribute stories that do exactly that, and then be there when you — the developer — develops accordingly, to help you do it right.
I have mentioned before that when we define the data layer (or what we want to have in the data layer), we tend to overshoot. It makes all our lives easier later, we think.
Now this is important: not everything that we request for the data layer will necessarily be used for Analytics or Target or whatever else right away at go-live. Which means that some of those data layer-related stories have no direct justification on the business side.
That is totally ok. It is how we like to work.
As a result, two aspects of the project are maybe not quite what you’d expect:
- The acceptance criteria for “Analytics stories” do not neccessarily involve checking something in Analytics. It is entirely possible that we’ll look at the data layer, see something there, and go “yup, good, accepted”. And btw, if the project is ideal, this we would automate.
- We will sometimes request data that will have a ripple effect through the whole project. Sometimes we request data in some place that has to be generated elsewhere, then integrated over.
An example for the second aspect would be integrations between website, email-marketing tool, and Analytics. Some data from the email-marketing tool we need on the website, some has to be handed over directly.
Expect our stories to have an impact on your stuff!
That is precisely why we want to be on board, of course.
Our real work starts much later.
When the website has gone live, the developers have been assigned to other projects, and the project management has been through all of the closing activities, that’s when we typically start our work.
We might sit down with the business, look at the data we collect, and try to find hidden gems in it. We might run A/B tests, look at the results, and tune the site. We might start targeting specific audiences, or we might just add, maintain, and optimise our tracking.
All of this happens, must happen, after go-live.
I have seen project managers completely forget about this. I have seen project managers asking us to do all of that prior to go-live, which, frankly, we can’t do.
For us, the project is like building a house. You are the architects, builders, plumbers, electricians, and whathaveyous building it. The visitors of the site will live in it, and we, along with the business, visit frequently, to check on the inhabitants and try to make their lives better, or make them stay longer.
We also tend to come up with suggestions on how to extend the house, or maybe change it a little bit. Those sometimes spawn new projects, and then we’re proud, like parents.
At the point of go-live, the most important point in the project (and sometimes in life) for you and our other colleagues, champagne flows, speeches are made, Jira tickets are closed and everybody finally can get some sleep.
Well, we don’t feel that way. We sit nearby, watching the bustle and bedlam, and we can’t help feeling left out, a little bit.
At this point, nobody will listen to us when we point out that much is still to do. Sometimes even the project manager ignores us, and we end up not being able to work, because we have not been pencilled in at all.
The work we have done shows in the site, in the form of rudimentary deployment, and ideally a solid data layer. But all of that is pretty underwhelming.
As I said: it is up to us to work closely with you before go-live, work to get the best we can get by then. It is also up to use to keep reminding everyone that our work will just start.
I suppose we’re like the guys in the cutting room. Once all the actors and big-shots have left, they do their work, out of sight, somewhere.
But it is their (and our) work that will ultimately make or break the result.
Never forget that.