here here here

title picture for article

Getting analytics into a dev sprint

It's a bit like inception, you need to get in their heads.

Web analytics want to have data layer pushes in the app. The web development team - whose job it is to make these changes - is under huge pressure, with their final sprints full of urgent fixes and loud stakeholders moving priorities around.

So it's inevitable sometimes that crucial measurement points fall out of the sprint and don't get to launch day.

This is so often the case in the web analytics business, that I'm not going to even address the "were analytics a priority from the start" question. Even if a KPIs, a measurement plan and docs were agreed early in the process, it often comes down to the last two weeks to implement and QA analytics in the site for the simple reason that many of the crucial processes to measure are still being finalised at that stage.

So how can we try to avoid this?

1. Patrons #

The most obvious thing you can do is to have one of the of those loud stakeholders in the process on your side. This means having a champion, a patron that will fight for your position in sprint grooming sessions. Don't assume that because you have a chummy relationship with the developers or the product manager that that is enough - they are often just foot soldiers in the battle of the priority lists and their protestations are often weak sauce.

They can take the fight for you

What you ideally need are big guns with responsibilities for the success of the project. Your team needs to find the people with the business goals of a successful launch - the Customer Experience heads, the Business Analyst leads, the people who will be called upon to prove and report on a professional and successful product. They can take the fight for you with just a couple of emails or Slack messages into the right team leads.

This is pitched as not only being able prove & celebrate a successful launch, but also to spot the (just as common) less successful ones early on and be able to tweak the way to a better product. It's not a good look to realise something was a dud only when the quarterlies come in. Good web analytics are the best way to optimise a short-term negative result into a long-term positive one and keep everyone in the group looking good in front of their boss. The more people know this, the more they'll fight for you.

2. Relationships #

Having said that you may need to go around the dev team, you also can't treat them like a service. If you have a poor relationship with the devs - you are not going to get the data you want.

You need to be able to have the dev team on your side and let them know that you're working towards the same goals, whether it be business (ie, revenue, customer satisfaction) or personal (ie, doing the job right).

Having experience yourself in website dev is not essential to talk to a dev team - although I admit I've found it very helpful (and I've leant on the "don't hold back, I'm also a front-end dev" line more than once). But by being able to show some knowledge of what single-page-application (SPA) frameworks are, what affects web performance, how to use CSS selectors or the "critical page load path" - or even just showing willing to meet in the middle by asking the dev team about such things - you'll get better response and results.

The other thing that dev teams love is documentation. If you can create a doc about what dataLayer pushes you need, why and when they should occur (important - should an event happen when a button is clicked, or when the resulting dialog appears?), they'll have an instruction set and also a way of estimating work to add to a job ticket.

Plus "It's in the docs" is the ultimate meeting shortener.

In my experience, good implementation documentation is never worth dropping when time is tight - it helps you focus better on what you want, helps implementation happen, and can then be tweaked to show the resulting analytics details (eg GA events) that analysts can then use to understand what happened and why.

What do you get out of all of this? A mutual respect helps the dev team know they aren't about to have jobs parachuted in that will block their sprint, slow the site down or make maintenance trickier. If you can work with them, they will much more likely assist you achieve your goals, and call on you when something changes in the future.

Don't take this as a purely affirmative relationship, either. As a "problem solver", I have a tendancy to bend over backwards, creating custom Tag Manager tags to fill gaps that a team is unwilling to implement in the simple dataLayer push. Remember that if a measurement point is not found worthy to prioritise in a dev sprint, it might also not be worth your time to find a workaround on the data engineering side either.

And if a dev team is really unwilling to schedule analytics before a launch, sometimes the lack of data to present to their bosses is the only thing that will get them to prioritise it in future sprints. As a colleague succinctly put it, "sometimes only a little pain works".

3. Negotiation #

When writing an implementation doc for a team, you'll rarely get it right the first time. Sometimes your mental model is different from the business model (or the app model), sometimes what you want is just not possible without lots of extra development work.

Being pragmatic means starting with an ideal situtaion, and then negotiating with the dev team to come to an agreement that leaves everyone satisfied.

To do that, you need to set expectations - state early on that you'll get some docs together, but that they're just "version one" and they'll be plenty of opportunity to revise them once the dev team has looked over them. They might decide that they need to negotiate the docs before sprint grooming (ie, they may feel the need to make serious changes that effect estimations). Or they might after a sprint has started (ie, it looks like just small changes need checking over) - so the negotiation might be with just the devs or their project managers too if it affects scheduling.

Negotiation has to take place in good faith

Negotiation has to take place in good faith, so if the dev team doesn't seem to understand why some measurements are requiring their time to work on, or web analytics don't believe that the dev team's work will give reliable readings, maybe you need a third party such as a product manager or team lead in the conversation anyway.

Starting with creating a "perfect world" instrumentation doc - where the ideal analytics events are listed without thought about the implemetation effort - is not just a theoretical starting point. Sometimes its easy to overthink what may be hard for the dev team to build, and miss out on potential signals that could be useful. As long as the dev team know it's starting at the top end of requirements and you're flexible, it's rarely a problem to start this way.

If you need a few points to give away as bargaining chips, try these:

// set this state once in the dataLayer early
'event' : 'app.setup',
'layout': 'mobile'

// ...instead of asking the app to find the layout state each time an event occurs:
'event' : 'app.addToBasket',
'value' : 99.99,
'layout': 'mobile'
// you can compromise on asking for a simple dataLayer push like:
'event' : 'cta1.click',
<!-- ...by instead asking for a markup change - normally quicker to implement by a dev team -->
<a href="/promo" data-track-click="cta1">Click me!</a>
<!-- now attach a trigger to the CSS selector [data-track-click="cta1"] -->

Try to make it clear what you're compromising on, none of your decisions are free of cost and others should be aware of that. And explain why you want each point of data, it often overlaps with what the dev team also want to know, and helps contextualize how much effort it's worth.

Conclusion #

If a lot of the above sounds like compromising, you'd be right. If it sounds a lot like business school politics 101 - you might be right. But it doesn't need to be so cynical, if we're talking about wanting to get the job done or having respect for your co-workers, there's no reason those two beliefs can't be held simultaneously.

What we're trying to do is to develop communications that don't just create short-term success, but long-term effectiveness - the more that both web analytics and web dev respect each other, the better the data will be to come from the products. And that was always the goal.