Automate a tedious marketing task: creating UTM-tagged links at scale
Tagger is a tool I created to build UTM-tagged links in bulk. It is personal project that arose from a need when I was leading the digital marketing team at The Citizens Foundation (TCF), and became a way for me to get some experience with modern front-end development tools including ReactJS, NextJS, NodeJS, NoSQL, and deployment pipelines.
The app is not viewable online. You can view further screenshots and details below or view the source code on my GitHub page.
You can also see some of my other design work at TCF.
Features
Select the required websites and platforms to automatically create uniform, well-formed, tagged links.
See a list of all the generated tags to quickly copy or download as a CSV.
Make customized branded shortlinks using the Bit.ly integration
In-place prompts to guide users and prevent errors
Protected by user accounts and activity logs
Built using NextJS, NodeJS serverless functions and deployed via GitHub and Vercel
Background
A significant portion of any digital marketer’s job is dedicated to analytics and attribution, and UTM links play a huge role in allowing marketers to track the ROI of their efforts. Unfortunately, UTM tags can be finicky, and creating and tracking them at scale is a cumbersome job.
Data overload
According to research by Salesforce, on average marketers utilize about 8 different marketing channels. However, digital platform landscape becomes more complex when you consider the different platforms within each channel.
For example, though social media is considered one of those channels, it can consist of any number of platforms like Facebook, Instagram, or Twitter, and depending on the type of business, it may include any number of additional platforms like WhatsApp or Reddit, etc. When creating a new post that’s going out on all platforms with a UTM-tagged tracking link, one might be creating dozens of links for each platform and each channel. Because of this only around 30% of marketers report being confident in the accuracy and usefulness of their analytics data.
In our case, in addition to the social media platforms, we had several unique domains to consider. I’ve written more about why this was needed because of how the organization was set up in a separate post, but essentially each link would usually be created for 5-6 different websites to be used in different countries.
Strict UTM link requirements
Each UTM-tagged link is unique, but in order to be useful, needs to follow some sort of naming scheme. For example the utm_campaign parameter can consolidate different marketing campaigns across time and different channels, or the utm_source parameter can be used to help Analytics auto-identify a source as social media or email, etc.
Further, UTM tags are case sensitive, so a link tagged under a campaign of EducateAChild is recognized as entirely different to EducateaChild.
Cross-team collaboration and skills
This becomes an even bigger challenge when you have a team of marketers creating and maintaining these links, as we did at TCF. Every marketer has their own strengths, and painstakingly ensuring accuracy of analytics data is not everyone’s cup of tea nor responsibility. However marketers are nothing if not collaborators, so it was clear that some kind of automation would be useful in this situation that would allow team members of varying skills to be able to contribute to the attribution of their efforts.
Prototyping with Excel formulas
If you search online for ‘UTM link builder’, you will see dozens of excellent Excel or Google sheets shared by marketers online that can help automatically create tagged links using combinations of CONCATENATE and IF formulas. The first incarnation of Tagger at TCF was such a sheet I created based on a few such references found online, and customized based on our team’s requirements such as the domain names we used, suggested campaign names, removing tags we did not use, etc. This sheet was shared across the organization and used by employees and volunteers at TCF around the world.
However at the end this was essentially just a Google sheet and problems arose that only came to light when our central team would periodically pool analytics data to make sense of it all.
Errors such as capitalizations, spaces, varying case, switching the source and medium, and sometimes errors in the cell which housed the formula would create different links – while they worked and were logged in our Analytics, because of these minor differences they were skewing our data in unexpected ways that took too much time to dig into and explain.
Building Tagger
Tagger was first and foremost a personal coding project. I had the problem described above in my mind when I began coding, but there was no formal list of specifications or requirements I was aiming to meet, other than:
- A form to enter the UTM parameters
- A way to select which sites and which platforms where the links would be used
- A script to automatically generate all the required links and display them in a table
- Integration with link shortening service (in our case bit.ly)
- A login system to track and maintain a history of created links (primarily to secure the branded shortlinks)
Designing to Prevent Errors
Throughout the design process I had some of the problems we had encountered in mind. The app needed to be simple to use and understand, and built to prevent as many data entry errors as possible.
The
Learning NextJS, NoSQL, Serverless Functions, and Deployments
In addition I had a goal of improving my understanding of JavaScript and to learn some modern front-end development tools along the way. Version 0 was what can be termed an MVP, using simple JavaScript, and it had all the features except no. 4 & 5 above.
My next step was to scaffold with ReactJS, and I settled on using Firebase Cloud Firestore and Authentication as the backend. For the integration with Bit.ly, I had to rely on building an endpoint using NodeJS so that I could protect the API keys as well as implement some sort of rate limiting.
In the process I found NextJS and found that it provided easier ways to integrate the security options I needed through serverless functions, so I decided to jump ship and use that instead. I think this illustrates how much of a learning process this was, and although it required some rework I did end up learning more about vanilla JavaScript and both React and Next than I would have otherwise! Moving to NextJS also turned out to give me a simpler way to handle deployment through Vercel.
Possible Enhancements
At this point other things in my life took me away from the project, but there were some planned improvements I had noted down as possible continuations of this project when I eventually get back to it.
- Access control on a user level: Allowing certain users to only create short links, while some would be able to utilize the protected shortlink API
- More control over the defaults in the form: an administrator account would be able to select which websites and platforms to include in the builder
- Integration with tracking: Have some basic integration with the Bit.ly visit tracker to display how many visits a particular shortlink has had