Insights from a web analyst turned software developer
In a previous life I was a web analyst for five years. There are times when I regret that my 18-year-old self doubted her abilities so much when confronted with a screenful of code; had I not, I might have jumped straight into development after university. However, I’ve come to appreciate that my background in analytics has provided me with a valuable niche at Softwire, enabling me to bridge two worlds that haven’t always seen eye to eye.
I’d be lying if I said I considered myself good friends with the developers I worked with during my time in analytics. I wouldn’t go so far as to say it felt like they were intentionally making my life difficult, but it certainly didn’t feel like they had any interest in making it easier.
Now that I’m on the other side and can see both perspectives, there are a lot of insights I can share about bridging the gap between these roles. I hope the takeaways will be helpful to anyone working across teams, regardless of what those teams are.
What is web analytics?
In my five years as a web analyst, I did all sorts of things:
- Worked out what sides people order with their pizzas so we could recommend the most popular options as last minute order additions in the checkout flow*
- Designed and ran A/B tests on websites (where we’d randomly show one of two versions of the site to users, to see which version encouraged users to spend the most money*)
- Made one too many PowerPoints (ultimately the cause of my demise as a web analyst)
*I will not be taking questions on the morality of these exercises at this time
It was a varied role, but everything I did had one thing in common: data. Data was the underlying factor behind every decision we made. To know how to improve user experience, we needed to understand:
- How users were interacting with websites and what content they were engaging with
- What was causing them to drop off halfway through a journey
- What pain points they were experiencing
It’s easy to assume that data is tracked and monitored as standard, and hence whenever something goes wrong, there will be someone there to help fix the problem.
When I’m on a website and I find something a bit annoying (like having to click through so many pages to check out that I ultimately give up), I like to imagine someone in a control room, surrounded by screens of data, suddenly noticing an alert: “UserX in London got to screen 8 out of 10 of the checkout flow before she gave up and decided not to order the tortilla style blanket to make herself into a human burrito.” And then a siren blares and all the UX designers and developers slide down a pole into the computer room and improve the checkout flow so I can disguise myself as a delicious Mexican dish to my heart’s content.
However, even something as seemingly straightforward as tracking checkout drop-offs requires coordination across multiple roles:
- Product owners ensure that analytics and data tracking are prioritised in the roadmap
- Developers build the necessary infrastructure to capture and provide the data
- Analysts visualise and monitor the data, identifying pain points and areas for improvement
Without this collaboration, even basic insights can be difficult to obtain.
Why can effective collaboration between developers and analysts be difficult?
Picture the scene:
Analyst’s To-Do List
- [Overdue] Provide feedback on the performance of the feature we launched last year
- Blockers: Waiting for developers to add a new data field to the database
Developer’s To-Do List
- [Overdue] New feature
- [Overdue] New feature
- Upcoming new feature
- Some request from the data analyst for a new data field for an old feature
Now imagine what they’re thinking:
Analyst: “I just need one data field! It should only take 5 minutes, why is this so difficult?”
Developer: “The new features are already overdue, and the analyst wants a data field for something we built a year ago. I haven’t touched that code in ages, and I’m pretty sure we aren’t even storing that data, so we’d have to figure out how to capture it first.”
It’s easy to understand both party’s frustrations. In my time as an analyst, I was constantly frustrated by needing seemingly small things from the developers in order to unlock huge chunks of work for me.
However, since I’ve become a developer, I’ve been able to appreciate all the reasons a ‘small change’ may not be so simple.
Every development workstream comes with logistical challenges – often inevitable, but manageable with careful planning:
- Prioritisation of work: Unless analytics is a business priority from the start, new feature development can seem more important than providing analytics
- Release schedules: Even if a code change takes only five minutes, for clients without modern CI/CD practices in place who need to follow scheduled release cycles, this change might not be able to be deployed for weeks
- Change freezes: Analysts tend to need the most data when major events occur, but major events often trigger change freezes to maintain site stability. This can prevent the release of tracking updates needed to answer critical questions
The biggest barrier to developers enabling analytics tracking is often that the foundations to provide a seemingly simple data point are not in place. For example, recently we implemented a bulk approval feature for approving multiple orders at once. When the analysts wanted to know how many orders were approved via the new bulk method, the developers could not give them this data, as the database only tracked that orders had been approved, but not how. To meet the analytics requirements after the fact, it ended up requiring changes across three codebases and coordination between two development teams.
How can we make everyone’s lives easier?
The best way for developers to not have to worry about analytics is by worrying about analytics.
Ey?
That is to say, if analytics is ignored when a new feature is being delivered, it will inevitably come back to bite the developers later.
In my team we’ve recently adopted a new approach towards analytics development. When implementing a feature, we do so in a ‘data-focused’ way – planning what analytical data points we should track at the same time as scoping out the development work by working with analysts upfront. In most cases, implementing tracking alongside development doesn’t add significant extra work and is far easier than trying to retroactively add it later.
This approach has helped us avoid awkward situations when key stakeholders want to understand how a new feature is performing. Instead of responding with, “We’ll tell you in six months once the tracking is set up and data has been collected,” we can provide insights right away. A great example was when a client asked for a development change to track the time between creation and approval of a certain type of order. We were able to let them know the data was already being tracked – it just needed to be pulled into a dashboard to make it visible.
On a more interpersonal note, it’s also made us much better friends with the analysts. Often when they ask us if certain data is available we can say ‘Yes!’, which makes them very happy. Back when I was an analyst, just getting a reply from a developer felt like a win, even if it was to say, ‘We’ll get to this in 3–5 working years.’ To have helped get our team to a place where we can respond to analysts quickly, and more often than not with good news, is something I’m immensely proud of.
This sounds great, how do I make sure my team are doing this?
No matter what your role on the team, you can play your part in ensuring that development and analytics go hand in hand – making life easier for everyone and building great products in the process.
Get the product owner on board
The product owner will generally be the person making the big decisions of what work to prioritise. If they’re on board with how important analytics can be, the rest should fall into place much more easily.
Hopefully, they won’t need much convincing, but if they do, spark their interest by showcasing some impressive dashboards or using data to tell a compelling story, if you have built a feature that tracks the data to do so. For example: “We noticed that it was taking an average of two days for orders to get approved. Since introducing the bulk approval feature, we’ve increased daily order approvals by 230%, reducing the average approval time to just four hours.”
Consider analytics when scoping out work for new features
When scoping a new feature, our team considers and creates tickets for the data that should be stored in our statistics database (which we use for queries and dashboard creation) and the events that need to be tracked in Google Analytics.
It’s not just down to the developers to think about these things – data analysts, designers, user researchers and product owners should all be feeding into these decisions.
Every project may handle data differently, so adapt this approach to suit your team’s workflow. If your team lacks the infrastructure for analytics, start by initiating a conversation around building it.
Foster open communication between analysts and developers
Ensure analysts are informed about what data is available and encourage them to share what additional data would be useful. This ongoing dialogue helps both sides stay aligned on data needs and capabilities.
In our team we do this by sending a regular update of the new tracking we’ve implemented and through shared slack channels where analysts can ask us questions.
Conversely, developers should engage with the outputs of the analysts’ work. It’s really fun to see insights about something you built that is getting used by people out in the real world. This might be by making sure you’re included in any regular reporting, attending meetings where analytical data is discussed (for us this is our fortnightly ‘Show and Tell’), or simply asking the analysts to share their findings with you.
Collaboration is key
It may sound cliché, but collaboration truly drives the best outcomes. Success is a shared goal, and the only way to reach it is by understanding and considering the needs of everyone involved. When I first started out in analytics, I didn’t understand why getting what I needed from developers felt so difficult. In hindsight, it wasn’t that anyone was being intentionally unhelpful, we just weren’t working closely enough to understand each other’s pressures and priorities. Taking the time to align on a shared goal, where analysts have access to the data they need, and developers have a process that delivers that data without adding extra workload, has been invaluable in building a better product for our users.
