Duga Does Server-Side Part 1

What does it do exactly?

This is a more detailed description of what happens in an automated server-side migration. A typical migration will handle GA4 tags, Google Ads, Conversion Linker setup, best practice housekeeping, cleaning up a container, Facebook CAPI, LinkedIn, TikTok tags, triggers, variables, user defined, and enabling/disabling built in variables - it does the lot.

First, we clean up

Before we migrate a container, we clean it. A clean, lean container is more efficient to migrate, and less prone to error.  So we automate the cleaning too!  Here’s an example output:

The goal is to end with a solid naming convention, no unused assets, everything nicely foldered, no legacy cruft to slow us down.

Before we migrate

As you noticed above, the automation is fed by a config json file. We don’t ask clients to write json files. We ask for the relevant information to be entered via a Google form.

We can take the answer filled spreadsheet to generate the json file to feed to the automation.

We can fire an individual automation, or, as we often do with the clean up script, use a shell script to run through a batch of config files in a folder.

Now it is time to migrate…

As the automation executes, we see the log output to screen.  This output is also recorded in the workspace description:

So what does it all mean?

First, we go through authorisation on GA and GTM.  We need to be account admins as we’re creating properties and containers in the automation.  

With authorisation sorted, now we check GA4. We might be deploying server-side in parallel with client side, so we create the server side property - a direct copy of the client side settings - key events, locale, currency, time zone.

We might not run in parallel depending on client requirements, or we might be running the automation repeatedly - it’ll update a container but is aware of what's done already and doesn’t screw up existing work. So this example, it’s checked GA4 is in the state we want and no further work to do:

Now we get cracking with setting up the server side container.  Notice that additive changes are prefixed with ++, and informational with ~~ where deletions get – and alerts !!

So, there’s a new container, and new workspace - we make sure the necessary variables are setup, and folders - (love folders), clients, and templates.

We’ve effectively done a little audit on the server-side container, so with the preliminaries done, we create the assets to deliver a minimum viable server-side container: 

A very similar process then runs through the client-side container. Notice where it finds the expected folders, variables, tags, and triggers and doesn’t need to recreate them:

With the client side container in good order, we can now copy the GA4 tags to be server-side versions. Here we’re not doing a parallel migration so the old client-side tags are deleted.

Having done the GA4 tags, that’s the easy part.  Now we’ll do the GMP tags and get on to the custom template tags. 

Here we assess what templates are present so we can map them to server-side equivalents:

Some server-side assets created, and some assets found:

Now we migrate tags. Notice that the first example needs the GA4 tag creating.  We try to find a matching tag first.  It needs to match trigger logic, and have all the correct parameter payload fields. Where we can use existing tags, we do. If not, we create a custom GA4 tag but make sure the GA4 event doesn’t pollute the GA4 data using a flag in the event parameters:

Where the client-side variables don’t exist on the server side, we have to create them:

And that’s a tag migrated. Now we’ll do a Meta tag. Each time we migrate an asset, we have to make sure our assets are up to date. Then we find we’ve got a GA4 equivalent ready to use client side.  Sweeeeet

And that’s a meta tag migrated.  Rinse and repeat.  It’s fast and resilient to quota restrictions - we play nicely with the Google APIs.

And without any fuss, all the tags are migrated:

That last point is crucial. We can, but chose not to automate the deployment in this case. That’s configurable.  If the container delta is minor and less likely to contain potentially breaking changes, automatic publication is supported.

That’s all well and good, but what value has been delivered to the business here?  We’ve made server-side migration quite boring - and that’s a good thing. That’s how it should be so we can get on with much more valuable and exciting activation projects that deliver value on the data rather than treating server-side as a badge of honour and data as a treasured ornament.