Media Tag Management Automation


Julià Pujol

May 4, 2021
Media tracking is important, the budget spent in media campaigns of the vast majority of multinational companies is enormous, failing to measure it properly could lead to bad decisions affecting the overall performance of the business.

Last year one of our clients, a multinational company, asked us to help them manage their media tag deployment. The objectives were to standardize the media measurement, make it scalable and efficient.

Managing media tracking codes for one site isn’t the same as doing it for several. In this particular case, the client is doing business on nine different countries, each one with their own ecommerce website, their own local media agency teams and their own local client teams. 

Requests for amendments or new tracking are continuous and although the sites are similar, each country has their own specific needs. Curious how we handled that? Keep reading.


As any kind of tracking, media tracking needs data - being that data in a form of user’s behaviour particularities or site/page data information. Willing to track products added to the cart of an e-commerce website would be of no use without, for example, passing along the product’s name or its price. Each vendor requires data in a very specific way and unfortunately, none of them converge.

The client in this case got a pretty good idea of what needed to be tracked and a data layer was already in place but they were lacking of any type of standardization process - while platform A was receiving, for example, either or not a user was logged in, platform B didn’t; while platform A was receiving pageName from the data layer, platform B got it from the browser’s URL. Additionally, there was no common standard among countries. No standardization means no purely media cross platform reporting beyond the traditional metrics such as clicks, views and the number of conversions. 

While standarization could be achieved by properly handling variables inside a Tag Manager, we were facing nine websites with at least two Tag Manager properties per website (one for all the e-commerce pages and the other for all branding pages of the same site). On top of this, for multilingual countries, we got extra properties per language - in total, twenty five properties.

The Tag Manager property set up strategy was intended for implementations to be managed on a country basis but now, we had to manage all of them together. The property set up is something on what we had no say, nor the client was willing to change it.

It’s pretty clear that manually adding/changing variables property by property wasn't sustainable besides being very prompt to error. We had the need of centralizing the standardization to one central entity:

Centralizing has its benefits and its drawbacks. By centralizing you have the power to spread one change across entities in one shot, but you can also mess everything up if something goes wrong - how can we achieve an acceptable middle ground?

In software engineering, canary deployment is the practice of making staged releases by rolling out a software update to a small part of the users first. Once the change is proven to work well, the update is rolled out to the rest of the users. That seemed like a good fit for our scenario so we used it.

Won’t go into details about the whole setup, but just think of the Tag Manager properties sharing to the framework what tracking codes to trigger for then, the framework, standardize (meaning, add custom data to the tag) and later dispatch those tracking codes.

That change alone has significantly improved the data quality, ensuring that the same data with the same format is sent across media platforms for all client countries websites.


Twenty five properties with an average of twenty media tracking codes per property gives us about five hundred media tags to manage. With the standarization framework, we not only put a process in place to guarantee data quality but we also made an important step towards scalability. Nevertheless we wanted to go a step further.

For this project, being just a purely implementation partners, we had no idea of how long a tracking code should be implemented or if its id needs to be changed or if a new variable needs to be added - this is something that only folks running the campaigns, the media agencies, know. They hold the knowledge so they should be the ones in charge of making changes.

Handling all this changes/requests via email is quite tedious; giving access to each local agency to their local Tag Management properties is not an option, technical skills are required and we could put in jeopardy all the standardization work done so far.

After giving it some thoughts, we finally opted to build a tool where campaign managers can manage the tags, without actually managing them. The idea is to bring a middle technology (a platform) where media folks can place the tracking codes and choose the conditions under which those would be fired without any technical knowledge and still, be compliant with the standarization process put in place. This is how easy it is for a media campaign executive to place a tag through the new platform:

The platform is linked to the client's Tag Manger properties via its API (in this case Adobe Launch API) so after a short review, the inputed tag is published with just a click. The entire lifecycle of tag publishing looks like:

By removing all the overhead of back and forth emails about requesting, changing and/or removing tags and automating the process of publishing a tag, we have substantially reduced the time from when a tag change is requested and when it is actually applied.


Last but not least, efficiency was a very important and sensitive topic for the client. We were tasked to ensure a great and accurate tracking using the minimum amount of trackers. Trackers, based on some estimations, increase the average page load time by 6.77 seconds - that's pretty important statement as it's also estimated that in e-commerces, one-second delay in mobile load times can impact conversion rates by up to 20%.

Not all clients we work with are as aware as this one about the importance of the page speed, maybe because on most of them the "sell" doesn't happen online. The first thing we did is to avoid redundancy and just fire those tags that were strictly necessary to measure the different campaigns performance but this wasn't enough to make an impactful change to the website's load time speed. How could we diminish page speed tracking impact then?

Lazy loading is a design pattern commonly used in computer programming and mostly in web design and development to defer initialization of an object until the point at which it is needed. That sound about right - we took the principle and we applied it to tracking. After some testing, we proved that by delaying tags to fire after 3 seconds from when the DOM is loaded, we could gain in average a reduction of almost 2 seconds of load time per page.

In addition, we also look into the tracking-loss impact and we came to realize that most of the users we missed to track were those considered as bounce (users leaving the site almost immediately), therefore users unworthy of any retargeting. For some pages, very relevant within the entire funnel purchase, we got reductions of 2.6 seconds. Results were pretty impressive.

Bonus Track

For those willing to get a bit more details about the architecture of the platform built for the client media agencies to place their tags, here is a simplified overview:

The platform is built on top of GCP. Given its serverless nature and its free tier, Cloud run is used to manage all the computing processes triggered as a result of a user interacting with the UI, powered by the first Cloud Run service (1). For asynchronous tasks, such as publishing, updating or removing a tag from Adobe Launch, a second Cloud Run service (4) is used leveraging Cloud Tasks (3) to reduce request latency and make the platform more responsive.

All data is saved into a Cloud SQL instance (2), Cloud Spanner is best suited for this platform but its cost made impossible to use it. On an hourly basis, there are Cloud Functions (5) triggered by Cloud Scheduler (7) that syncs tag statuses and information between Adobe Launch and the platform. Additionally, every time a tag is accessed by a user, the sync is also made.

Finally, Cloud Logging (8) is used to log all activity for all the compute services.


Automation is key to succeed in digital, it reduces time and costs while avoiding human errors. Although the digital industry is among the ones with highest levels of automation, there is still a large amount of tasks that can be automated.

Tracking, specially media tracking is a tedious task, many times not well understood but playing a big role in your media efforts success. Automate media tracking, specially if your company manages several webs/apps is an important thing to bear in mind.

At Uptimal we are specialists in automating media and analytics process. Get in touch if you look for potential improvements in your digital media processes.

Posts that might be of your interest