How we used data to accelerate B&CE's business growth

Today, I want to talk to you about accelerating business growth with data and insight. It’s a really exciting case study for B&CE and their product, The People’s Pension. Now, if you’d asked me five years ago whether I would get really passionate about workplace pensions and financial products, I would have told you you’re having a joke, but this is something I’m really proud of and I’m really excited to share with you.

In RocketMill style, we do your brief in a tweet and B&CE’s brief when they came to us was to build a digital measurement solution that they could really trust, and it had to inform change across the entire business. But, most crucially, it had to be done quickly.

A little bit of context; B&CE are a financial company and they’re a provider of a product called, The People’s Pension, which is a workplace pension. For those of you who keep up with these things, the government has brought out a rule saying that all employers must offer a workplace pension, and there’s a deadline by which all employers must offer it.

This is rapidly going up and B&CE have been incredibly successful in capturing a large portion of the market, and as a result, they’re growing enormously quickly. Every time we go to their offices, they’ve gotten 15, 20 new people starting every single time. It’s unbelievable how quickly they’re growing, but with this growth comes certain growing pains, one of which has been data.

They’ve had lots of different products, lots of different websites and domains being set up. They’ve got lots of different sub-domains, where people can log in and manage their product. They’ve got different areas for employers and employees and financial advisors, and it’s all scattered all over the place. Over time, each time a new product is developed, there’s a new team that’s responsible for it and they set up their own measurement and someone else sets up their own measurement, and it’s ended up in this kind of big, big mess which we’ll come onto in a moment.

First, to kind of debug the problem that they had and get to the bottom of it, we carried out some stakeholder interviews, and the kinds of things that we were hearing was that they just don’t trust the data. There was a real hunger to use the data, but they just didn’t trust it. They didn’t know where to find the information they were looking for. There were too many different places to go and find it and a lot of them just weren’t finding Google Analytics useful. These are experienced people. They have some very, very experienced marketers there. They’ve got an incredible team of developers, but they just weren’t able to get the information they wanted.

If you’ve got a question, you need some data to kind of help your reasoning or come up with the optimal solution, they just weren’t quite sure, and as a result, that resulted in lack of trust. When you don’t trust the data, it’s next to useless. You really can’t make any powerful decisions with that. To solve this, we had to sit down and do quite a bit of thinking, but we also had to move very, very quickly.

We set some guiding principles. It had to have integrity. Everything we did had to make sure that the data is absolutely accurate. It had to be intuitive, so that people could be able to go into the accounts and they would just know by looking at the labels, looking at the names, that they would understand what the information they’re looking at means. It had to be easily maintainable. We don’t want to deliver a project and then find that it’s just got back into the same mess a year later because nobody was able to continue our work. We want to be able to develop this measurement platform for them, and part of that process is ensuring that their developers and their marketers can continue to use this platform we set up and continue to evolve it in an effective way.

Here’s the vision we came up with. One Google Analytics account, one global Google Analytics property, and very, very clearly labelled views to segment each of the different portions of their business, as well as a roll-up holistic view covering their entire business. There’s different views here that are applicable to lots of different stakeholders within the business.

Some background on this. Previously, they were using one Google Tag Manager container to try and measure the activity and to set up the tracking across all of their different websites, and there were five or six different domains and sub-domains going on, and as a result, every time they’d set up a rule in a container – so, for example, the URL contains “login/success” – they could never be quite sure that it was firing in the places that they thought it would be firing, because of different domains. You have to check all of the URLs every time to make sure it wasn’t firing.

To solve this problem, we separated things out into six different Google Tag Manager containers – one for each of the key sections of the website – and all of these different containers would then send information to the same Google Analytics property to consolidate it, but this separation is really important. It allows us to kind of logically separate the management of tracking for different areas of the website. Naturally, different areas are going to have very different tracking needs. There’s FAQ sections that were set up and then there’s also account log-in sections where people might manage their account. You have very different measurement strategies for being able to monitor what’s going on in these sections.

At the same time, we also needed to move quickly. Setting up six accounts is no small task. To do that, we did some planning and we first identified all of the global tracking functionality we wanted to have, so things like user ID’s, basic Google Analytics page views, tracking of JavaScript errors, things that are relevant no matter where you are on the website.

We set up tracking in just one of the containers, and Google Tag Manager doesn’t allow you to copy things from one container to another very easily, so instead of manually going through each one and setting up the same thing, we exported it and then we re-imported it as the global configuration. This gave us a really good foundation.

We’ve also shared with their developers some tips and tricks for being able to use the API, so if they ever make a global change, instead of manually going through and introducing the risk of human error, they can use the API now to pull tags and introduce them to other containers very quickly and smoothly. Doing this overall, I think saved probably about four or five days of time. It’s quite significant time-saving.

Finally, once we got this fantastic kind of global setup of tracking that we wanted all over the website, we then started adding business context. This is where the measurement gets really interesting, because we didn’t just want to know the number of page views and the number of events that were being followed. We wanted to understand real business information, the number of people who were going in and the number of employees who were actually activating their accounts and engaging with them online, the number of people who were opting out of auto-enrollment.

We wanted to understand financial information. We didn’t, at this point, didn’t even understand the revenues that were coming into the business through the enrollment fee for employers. We started introducing things like user ID’s so that we could potentially integrate some of the information of what users are doing online with the back-office systems. We started looking at collecting information around the forms. There’s lots of very complicated forms on the website for employers to enrol to this People’s Pension service, but they had no measurement around that. They didn’t quite understand and there was nobody analysing this data that was collecting in the CRM, so we started measuring some of that.

Finally, we also did quite an extensive training and support piece with their developers. So, as I mentioned, we didn’t want to go in and just deliver this fantastic, but rather complex setup; rather large setup. We wanted to teach them to maintain it themselves, so we went in and we showed them, here’s how you send information to the data layer and here’s how you use Google tag manager from a developer’s point of view, but then we also sat down with them and talked through how we would go through the debugging process. This is the Google Tag Manager debugger. We’d go through and say: “You know that code you’ve just written? Here’s what it looks like”. This has allowed them to get kind of actively engaged in the product. Every new piece, every new development they’re making, every new tool that they develop – and they’re doing a lot of them very, very quickly – they have this at the back of their minds, and they understand intuitively, where they need to build in measurement into their process. So, you have results. Very, very exciting.

We did manage to get to here, which is fantastic, but from this, we need results. We need insights. We need actions. And that’s what’s really important. Otherwise, this project is for nothing. So we built some beautiful real-time dashboards. We have power BI dashboards, as well, with some real business intelligence in there, but some of the feedback we’ve been receiving from the client has been absolutely fantastic.

So far, they’ve been able to introduce accurate forecasting. I think they got within three, four, five percent revenue figures. Using this data that we were collecting through Google Tag Manager, they were able to accurately forecast, they’ve back-dated it and tested it against what they actually got …very, very close. The data was accurate. They really trust the data now.

There’s lots of behaviour insights about how people are using the tool, using the platform. We now understand the number of users who are logging in. We understand cross-device usage because we’ve got user ID’s. We can see some amazing things. 7% of people are trying to reset their password, but 50% of those never actually get to the point of being able to log in again. There’s something wrong there. We also found that 60% of employers who were signing up to the tool, they get given a dropdown to say: “Describe what type of business you are”. 60% of employers were selecting “other,” which is immediately – if you think of psychology – it’s saying that the brand doesn’t recognise or isn’t tailored to support my business. There’s some ongoing analysis into what people would classify themselves as so that we can start using the types of language to describe the businesses that The People’s Pension works with much more effectively.

We have operational insights as well, so the developers are using this to identify JavaScript issues, to fix things very quickly, and things like the login password reset issues. There’s even potential, now we have the user ID’s, to go and merge back office data to bring the behaviour information we’re collecting through Google Analytics and merge it with the back-office information that they have in their databases for some very sophisticated analysis.

Thank you very much.