Editor’s Note: This is a guest blog post by Eric Dodds, Head of Demand Generation at RudderStack.
A now distant memory: slow and rigid with messy data
I get a bit of “web PTSD” when I look back at the state of our website a year ago. I’ll give you a quick glimpse here, and I bet you’ll see what I mean.
Our primary marketing site was running on a bloated WordPress installation with a heavily modified custom theme. As you would expect, is was extremely slow. Our docs were running on a 3rd-party platform with limited analytics functionality and no options to optimize. We also had a smattering of landing pages running on Webflow because rolling out new pages or functionality in the WordPress setup was so painful. On top of all that, our infrastructure didn’t support a staging environment. Yikes.
But wait, there’s more!
The team that originally built the website had set up Google Analytics and Google Tag Manager, and like almost every implementation it had become messy. The data wasn’t right, and reporting required a bunch of manual copy/paste work. This was made worse by the data inconsistencies from forms running on the different platforms. Thankfully, we had instrumented our own product, RudderStack, from the beginning, but more on that later.
- Related: How WaveDirect Used Gatsby, Rudderstack, and Sanity to 4X Leads and Dominate Search Results
When we finally broke through the scrappy seed-stage phase and traffic started increasing, we found ourselves with slow, fragmented web infrastructure and an analytics setup that was untrustworthy and painful to deal with. We knew this wasn’t tenable.
Time for an overhaul: what we wanted in a high-performance web stack
To grow from Series A and beyond, we needed a strong web foundation, and I was tasked with overhauling our website. Speed was a top concern. We also wanted to consolidate platforms and remove as much bloat as possible. On top of that, we knew we needed a robust, reliable foundation for analytics. We were done with messy setups and messy data—we wanted a flexible system that didn’t lock us into third-party JavaScript.
First things first: solving for speed with Gatsby and publishing with Sanity
There was only one answer to dealing with bloat and speed: JAMstack. There are lots of JAMstack frameworks, so as we began our evaluation, we looked to one of our most trusted sources for technical information: our own users and customers. The RudderStack community had already gathered around Gatsby. In fact, a Gatsby plugin for the RudderStack JavaScript SDK already existed. The feedback we got validated the conclusion of our own research: Gatsby is awesome. The next thing to figure out was how to consolidate our three (three!!) separate web platforms into one and make it easy for people on the marketing and web teams to publish content.
We chose Sanity because:
- It integrates directly with Gatsby
- We wanted to invest in a code-driven approach to content
- it’s just a really great tool to use in general
Surprisingly, the most difficult part of this whole process was actually migrating the content itself, which required some brute-force copy/paste. On the technical side, though, it was smooth sailing. Our dev team was able to ship a completely new site in less than half the time our previous website redesign project had taken. And get this, it was the first time they had ever implemented Sanity.
Next: freeing ourselves from bad analytics and JavaScript jail
It’s hard to describe how much the team loved our new infrastructure…everything started moving faster. Unfortunately, some of the most problematic pieces of the puzzle were still rearing their ugly heads: Google Analytics and Google Tag Manager.
Google Analytics
Google Analytics is used almost ubiquitously for web analytics and, in many ways, it’s a great tool. But, as any web performance and analytics-minded users know, it causes some major problems.
Google Analytics gets blocked like crazy
As privacy controls continue to tighten, popular third party scripts are the first target of all sorts of blockers. Because Google Analytics is so ubiquitous, it gets blocked a lot. We did some benchmarking and found that using the RudderStack SDK proxied behind our own CDN delivered…wait for it…literally 100% more traffic than the Google Analytics script. 100%. Stop and think about that for a minute.
Google Analytics isn’t good at user-level data
Data loss aside, Google Analytics is also just bad for user-level tracking. Understanding the “happy path” through your website is key to optimization, but Google Analytics wasn’t built for flexible user journey analysis.
The Google Analytics script was heavy
Last but not least, it was painful to open the inspector and see the Google Analytics script bogging such a nice Gatsby site down. Suffice it to say, we knew Google Analytics just wasn’t going to work.
Google Tag Manager (is a giant hot mess)
The first time anyone uses Google Tag Manager it seems like an awesome tool. If you don’t care about web performance, it is kind of nice for implementing a few scripts and ad conversions. Cross any threshold of complexity, though, and you feel like Hansel and Gretel waking up from the sugar high, realizing they’re trapped inside of an evil witch’s house. Things get out of control fast:
- Tinkering with sequencing and delays is a nightmare
- Data layer variables always end up getting messy
- Even organizing everything in the UI is hard
And, of course, there’s the blocking and performance issue. If I sound salty, it’s because I gave some of the best years of my life to Google Tag Manager before I saw the light—give me some time to work through it. All that’s to say, Google Analytics had to go, and so did Google Tag Manager.
“I hate Google Analytics and Google Tag Manager too, but can I live without them?”
If you think you’re just stuck with Google Analytics and Google Tag Manager, you’re not alone. But take heart, I’m living proof that you’re not really stuck. At RudderStack, we got rid of them both, and it’s bliss. Our solution? RudderStack Cloud Mode. What’s that, you ask?
It’s pretty simple: instead of running all sorts of separate third-party scripts, you run one RudderStack SDK (via the handy Gatsby plugin) and send as much data as possible to downstream tools server-side.
The RudderStack SDK fully replaces all data capture from pageviews to any other kind of user event you want to track. The event payloads come in as raw JSON and are then automatically mapped to downstream destination APIs by RudderStack.
So now every time a page view happens on our site, we send that data point server-side, in real-time, to:
- Google Analytics (oh the irony!)
- Mixpanel
- Snowflake
- …and tons of other tools
RudderStack can also capture the events you instrument and send them as conversions to ad platforms (server-side or client-side, depending on the platform). All of this happens via the RudderStack Gatsby plugin. Good riddance Google Tag Manager!
It’s a wonderful life…and what’s next
Like any fast-growing company, there’s a lot to fix and optimize, but things are pretty dang good overall. Since we ripped our GA and GTM:
- We’re capturing all of our user data
- Any team can use any analytics tool they want, and we don’t have to deal with the pain of scripts slowing the site down
- We can deploy new pages and publish content faster than ever before
- Our devs are happy
Oh, and removing Google Analytics and Google Tag Manager from the site makes a HUGE difference in performance. Here’s a screenshot of some benchmarking I did with a vanilla Gatsby site for my talk at Gatsby Conf 2022.
What’s next?
Now that we aren’t wasting time dealing with painful web infrastructure with messy scripts and data, we can focus on the more important work of shoring up the lines on all things SEO. Thankfully the Gatsby community is amazing and we’ll have a huge running start with the Gatsby Next SEO plugin.