How TELUS moved 50% of its web traffic to Adobe Launch in a week

Summary

If you want performant applications for good SEO and customer experience, move to Adobe Launch (async). You’ll need to plan for it, bring a core analytics implementation team (platform devs, analysts and analytics devs) together for a hackathon, execute and be prepared to do some cleanup.

If you’re new to the TELUS Digital ecosystem, you likely won’t be familiar with our data stack; for a quick overview of that check out this post. 

It’s widely known that performant applications rank better on Google and intuitively, we know people don’t like to wait for websites to load. So from an analytics implementation perspective, what can we do to help?

How we work at TELUS Digital

At the moment, TELUS Digital consists of 450+ people, divided into 4 outcome teams and 2 enablements teams each with multiple squads spread out between Toronto and Vancouver. Each of those squads require data and analytics to be set-up in the applications they build in order for them to continuously iterate and measure their success. 

Within the TELUS Github, we have 886 repositories, with approximately 200 live applications (going by openshift analytics). Ideally, we would need to update all 200 repos in order to fully move our implementation over to a new tag management system. 

The push for optimization and performance

I think the real rallying cry behind the team’s performance push can be summed up with the Techcrunch headline: “Google will make page speed a factor in mobile search ranking starting in July.” When we looked at the core metrics that impacted page performance, we realized that we really needed to start to optimize or we’d end up losing the 14% of visits that our SEO brought to the site.

One of the first things we decided to tackle as the data platform team was the render blocking tag managers (DTM and Ensighten). Having had our hands tied when it comes to stopping our tag managers from being render blocking[1] you best believe we dove right into Launch when we saw it could run in async. 

Beyond the performance and SEO KPIs, we also wanted to simplify our analytics implementation inside of Launch and reduce the overall number of network calls going to Adobe. Less network calls equals less spend! 

P.S.: Josh Arndt, our Senior Tech Architect, recently wrote a blog post about how seriously TELUS takes website performance; it goes far deeper than I could ever go here so please check it out.

Planning and considerations

Given the scale of the task at hand, we decided to do what TELUS does best: Prioritize our work by looking at the customer experience and identifying where analytics could make a difference to the experience. 

From the analytics perspective we looked at what tag management system the pages had (Ensighten or DTM) and how much traffic they were getting. We also considered whether the page was a marketing page versus an authenticated My TELUS page as the complexity of marketing pages is miniscule in comparison[2]. 

Beyond that, we also needed to understand whether or not the pages had a dataLayer setup. To make matters a little more complicated, we also had to understand WHEN the dataLayer was being set[3] on the pages in order to avoid timing issues that revolved around our dataElement[4] change heavy setup. 

After some deliberation, we finally nailed down our plan. 

A week long hackathon where we’d focus our efforts on getting the highest trafficked pages that already had a dataLayer setup, moved over. We also decided that the lower complexity pages, would be prioritized in order to maximize our probability of success. 

The goal was to take the top 10 most trafficked pages by outcome team (4 outcome teams). Prioritize the overlapping top 10 pages overall to tackle them as a group and then come back to go through the previously compiled list individually ignoring already moved pages.

In terms of team, we had our favorite Adobe Consultant fly out & spend the week with us (a team of four). We also opened up the invite to four devs, one from each of the various outcome teams which meant we had technical insight into the application on hand itself.

The last part of the plan was the execution sequence:

1. Test the page against pre-set framework inside of Adobe Launch using the Launch Command chrome extension (this doesn’t test timing issues previously highlighted) 

2. Pull the app in question from Github and swap out analytics dev, staging and production scripts

3. Push to staging and test the changes in Launch for timing issues / conflict with other scripts

4. Push changes made to production in both the app & Launch

5. Test, test, test #RollBackCall.

Results & conclusion

By the end of the week we had consumed a pretty wide variety of food, plenty of drinks and moved a whopping 50% of our traffic touched a Launch backed page (visit based). 

While our original plan was to deliver the changes immediately, we decided to delay the last batch of application changes due to a high number of people going away for a long weekend! 

As you can see in the graph we continued to publish the following week and hit 54% before finally making our way to 60% where we stabilized for a while. At which point we iteratively went through three different iterations of Launch frameworks, each addressing a different variation of timing issue we uncovered.

For anyone looking at taking on the challenge, I highly recommend you do. We saw a huge performance boost of 15-18pts after cleaning up our implementation and optimizing the scripts executed on our business pages.

Although correlation does not mean causation, that isn’t going to stop us from correlating our improvement in SEO with the changes we made. 

All in all, we enjoyed our mini hackathon and ended up delivering some amazing results back to TELUS. 

For those of you who are wondering how we measure our application performance, you should check out Josh Arndt’s post on how we took Google’s open-source Lighthouse tool and made it our own. 

Do you think you have what it takes to be on #TeamTELUS? Apply today and reference this post in your application. Click here to apply!

Appendix:

[1] We previously tried to set Adobe’s Dynamic Tag Manager to async, the results? In short just don’t do it; most events & some page load rules break.

[2] Most marketing pages are backed by an app that doesn’t authenticate customers making it slightly easier to work with as APIs can delay data availability. Beyond that, we thought about user as well as system generated events (pro-active chat), the complexities they introduce. 

[3] We had to be careful of when the analytics library loaded, when the dataLayer was set & our rules were triggered (dataElement change / pageLoad type conditions in rules)

[4] A feature in Adobe’s Dynamic Tag Manager that allows you to trigger an event when a js function returns a value different to the one previously pooled.