Google Tag Manager for Franchises and Multi-Location Microsites

In the multilocation SEO world, I encounter many hybrid marketing scenarios where a corporate, central entity runs some brand marketing and the local entity runs other campaigns, usually lead generation, all on consistently designed sites at the subdomain, folder or page level.   The funding, planning, execution, and measurement of these programs vary, but what I frequently see on the back end is a large amount of effort to manage the various tags to satisfy everyone’s analytics needs, and a lot of overhead when there are needed changes.

I’d like to propose a Google Tag Manager tip that can significantly help with this using the Regex Lookup Table.  Let’s dive in.

What Website Scenarios Does This Work?

Most multi-location micro-site scenarios can be simplified using Google Tag Manager’s more advanced variable types.

For this mechanism to work, it is required you’ve embraced consistency in your network, and that you’ve fully embraced Google Tag Manager as your tag management solution.  This means that all of your marketing pixels, analytics snippets, and other installed scripts are encapsulated within GTM containers or that you plan for them to be.

For example, a WordPress multi-site installation or a location-page or location-microsite setup is an ideal platform for this kind of approach.

What Website Scenarios Does This Not Work?

In some cases, the Content Management System might throw a wrench into this, but so far I’ve been able to work around all of them.  One example are those CMSs which give CSS elements different names across sites when you’re trying to trigger on click events (grrr.)  I’ve run into some complex GDPR setups and strange event listener code that added a lot of complexity.

Tag Sprawl

Container and Tag sprawl happens fast in multi-location businesses.  Before you know it, adding a new type of tag to your system takes all day, and you end up with bugs that affect some locations and not others.

 

Let’s consider a pretty basic, but typical scenario for a franchisee or local office location:

• Corporate hosted sub-sites (top level domains, sub-domains, sub-folders or pages)
• One Google Analytics (GA) dashboard per location (local owners want their own property)
• Local marketing pixels/tags such as those used in Call Tracking, conversion tracking or social media ad networks.
• Cookie management tags

Preparation and Organization

The internal process you use to gather together the needed IDs (e.g. GA-IDs for the local GA accounts) really is up to you.  We managed all of the needed IDs in a shared Google Spreadsheet.  As with any franchise or multi-location business, how you set up the sharing architecture is a critical decision that has implications down the road.  It pays dividends to discuss your growth plans with someone who has planned a scalable sub-site network before starting – most web developers have never done this in my experience.

Google Tag Manager (GTM) Components:

Within the GTM Container for this case, there are two ways to set up the tags, based on whether it’s a built-in tag or custom HTML.

• For built-in Tags, such as Google Analytics, we will replace their variable fields with a reference to a lookup table (the one on the left in the illustration.)
• For custom HTML tags, we will add the lookup table reference directly into the script itself within the Master tags, using the curly braces syntax, like {{this}}

Here’s a sketch of the setup for a single built-in tag and two custom HTML tags:

Our example has these variable tags:

• Google Analytics Built-in Tag
• CallTrackingMeasurement Custom HTML Tag
• Facebook Pixel Custom HTML Tag

In addition, we set up a corresponding lookup table for each one, like this.

The “Google Analytics” setup referring to a {{GA Settings}} variable is super common to anyone who has used GTM before, with a twist!

Here’s the GA Settings variable – where you’ll notice something a bit different than usual in the Tracking ID field.  Rather than refer to a UA number constant, it refers to the lookup table to get its value:

Similarly, the Facebook Pixel Tag example here (Custom HTML) has {{lookup table variables}} inserted into the code wherever those IDs are referred to.

The Regex Lookup Tables

Ok, so let’s look at the way the lookup tables are set up to serve the tags and {{variables}} above.

For all three of the Regex Tables, you’ll set up an input variable that will identify the subsite. It could be site’s unique hostname, domain name or subfolder.  In our example here, we are using separate domain names for each location’s sub-site, so we use {{Page hostname}} as the input variable.  Each Google Analytics account will only track data on the sub-site,so there are no cross-domain setups to worry about.  However, if you want to track all domains in one parent-GA account at the HQ “roll-up” level, you will need to set up cross-domain tracking on a second GA ID, trigger, and tag which fires everywhere separate from these tables.

Back to our example:  Here’s how the Google Analytics lookup variable is configured for a simple, 4-site scenario:

As you can see there is a row for each site.  In this table, the current site’s hostname is passed in as the input, where it looks it up the matching row and serves the output back to the tag.  Here this means the Google Analytics GA Property ID, in the right column, will be injected into the {{GA Settings}} variable for each page view.  The use of regex lookup instead of plain lookup variables is to give us more powerful matching options if needed.  For this simple example, our regex was as simple as they get.  Note that you can only pass one input into the regex lookup tables and only one value comes back as output.

IMPORTANT:  Under Advanced settings, notice also the full matches only and Enable Capture Groups options are unchecked – this is very important – the tables will not work properly for this if they are checked.

The Facebook Pixel Lookup table is similar to our GA lookup, but instead of GA Ids, it uses Facebook Pixel IDs:

As you can see, the advanced settings here are the same as were used in the GA setup.  The lookup tables can be used to gather IDs of any complexity.  Callrail, for example, has a three part ID that looks like this “part1/part2/part3” and it works fine in the lookup variables.

Put it in preview mode and test it.

I admit, it feels a bit like magic to watch these tags swap out on the fly as you move from location to location and to see the data distributed to the different systems.

The key is to think scale in everything you do.

What if we don’t use the same tags in all locations?

I don’t recommend this from both a business and measurement perspective.  But if this is your situation, things get a bit more complicated.  In my clients’ cases, they enforce the same marketing structure on each location, which I think is quite wise.

For multi-location environments without consistent deployments, you’ll usually have a subset of the tags which are valid across the system.  When you’ve sacrificed individual GTM containers, as is suggested in this post, you will be faced with how to selectively fire triggers due to the inconsistency.

There are two ways to deal with this.  One is the lazy way and the other the cleaner way

1. The lazy way:  Create a bogus fallback default value in the lookups that is used when the lookup tables fail.  This means the script would simply fail and life goes on. I don’t like this method but it does work, perhaps temporarily.
2. The better way here is to bake in a method for determining which sites had which tags.  One idea to explore is the creation of a tag inventory lookup table, perhaps using a GTM Lookup Table Builder that keep track of which sites had which tags.  You could use CSS element tags, cookies, and other data-layer variable tricks to make this work.  The thing is that once baked in, you’re very scalable.

Now The Win.

As your franchise or business grows to new locations, all you need to do is to add entries into each table or, using the GTM table builder, upload a new table over the old one.  You don’t need to add more GTM containers or other time-suck overhead.  And as you add new tracking systems, such as call tracking, system-wide, you only need to add a new set of lookup tables to handle ID-creation in a scalable fashion, whether you have four locations or 500.   If you migrate to a new CMS or new architecture, you only have a small task to reconfigure these tables.

Run with this idea!   I welcome feedback!  What scenarios did I not consider?  How did you put it to work or make it better?

H/T to Eoghan Henn and Simoa Hava for their dialogue in mastering this system.

 

Murmuration Image by Ian Cook – Used under Attribution 2.0 Generic (CC BY 2.0) License

Murmuration Video/Animation by Karen Roe used under Attribution 2.0 Generic (CC By 2.0) License