Google Analytics App+Web Property: setting up a Configuration tag

This is part of a series on Google Analytics App+Web Property.

1. A brief walkthrough of the setup
2. Setting up a Configuration tag (this post)
3. Setting up an Event tag

In my previous post, I had provided a walkthrough of setting up a Google Analytics App+Web Property. If you don't know what this App+Web Property is or you want to learn again how to setup that property, head over to that post to read my review.

But an analytics property is kinda useless if you don't track any data to it. So in this post, I'll share how to setup some tags with Google Tag Manager (GTM) for a website, and what results you can expect from those tags.

What you'll find in this post:

• My App+Web Configuration tag
• The resulting network hits to GA
• Three gotchas that you must watch out for!

Here's my App+Web Property's web data stream in Google Analytics (GA):

I've left it with its default "Enhanced Measurement" setup. That means besides tracking Page views "out of the box", it also tracks scrolls, outbound clicks, etc. "out of the box".

My tags are setup in Google Tag Manager (GTM). There's no difference between setting up a GTM container for an App+Web Property vs the regular Universal Analytics property. It just needs to be a "Web" type.

There are two App+Web-related tag types: one for Configuration, the other for Event.

App+Web Configuration tag

I setup a Configuration tag first, because I figured that it would contain all of the Event Parameters that should be fired with every hit. Besides, this tag will also be used by the Event tags later on.

My Configuration tag looks like this:

• Measurement ID: this is the ID of the App+Web Property. I've opted to use a Variable (Constant type) to store this ID. It's a "best practice" that I use, just in case I need to swap the ID one day.
• Send a page view event when this configuration loads: this replicates how tracking works with Universal Property, where the recommendation is to fire a Page View tag when a web page starts loading. The difference here is that this checkbox will track the page view event without my needing to setup a separate Page View tag.
• Fields to Set: there isn't any documentation around this, but based on the documentation for gtag.js, I assume that this is where I set my config variables, so that they get set with every subsequent Event. I've setup two fields: one to track my GTM container ID and version (value set through GTM's Built-in Variables), the other to track a fictitious User ID (value set through the Data Layer).
• Firing trigger All Pages: no surprises there, this Configuration tag needs to be fired with every page, otherwise you wouldn't be configuring any App+Web tag!

Incidentally, these are my Built-in Variables (I had to enable "Container ID" and "Container Version" manually):

And this is my Measurement ID variable:

Recap: I've setup the following in GTM:

• Constant variable to hold my Measurement ID
• Built-in variables for Container ID and Container Version
• App+Web Configuration tag to fire on all pages

Inspecting the hits

What does this App+Web Configuration tag give me?

There are no surprises in terms of what GTM Preview shows me. My web page loaded, and GTM fired its three standard events: Page View, DOM Ready and Window Loaded. And as expected, my Configuration tag was fired with the Page View event (the one that corresponds with GTM's "All Pages" trigger):

But there was one more event: Scroll Depth.

I had not setup any scroll-related tags, triggers or variables, yet GTM fired this event anyway. This came as a result of the auto-configured tracking that the App+Web Property's web data stream provides. When GTM loads my Configuration tag, it loads a corresponding script from Google Analytics, and that script contains the pre-configured tracking information from my web data stream.

Altogether, three hits were sent to www.google-analytics.com/collect, GA's data collection endpoint (the same one used with Universal Analytics tags).

… Wait a minute! Didn't I fire one tag only???

Gotcha #1: more than one hit

Here are the data points that I found when I inspected the hits:

1. en=page_view
   ep.container_id=GTM-xxx vQUICK_PREVIEW
   dl=http://...
   dt=...
2. en=scroll
   epn.percent_scrolled=90
   dl=http://...
   dt=...
3. en=user_engagement

So it turns out that there's something going on. The page_view one is easy to understand, because it's the event that's fired with the Configuration tag. The scroll one can also be understood now, because of the web data stream's setup. (The "90" value indicates that I had scrolled 90% of my web page, though that's debatable since my web page was so short that all 100% of it fit in my browser screen actually! By the way, the fact that it's tracked as an integer implies that you probably can't track something like 91.3% scroll depth.)

But the user_engagement one is unique to Firebase (upon which the App+Web Property is based). Firebase fires this hit automatically after a short delay, so as to measure the user's engagement. See GA's Help article for automatically collected events. If I had taken my screenshot before that delay, then I would not have seen this hit.

By the way, here's what those hit parameter names mean:

• en: Event Name, i.e. the App+Web Event.
• ep.xxx: Event Parameter, where xxx is the Parameter's name.
• epn.xxx: Event Parameter also, but where the values are numbers (integers or floats/decimals).
• dl: Document Location, i.e. the URL of the web page.
• dt: Document Title, i.e. what you see in your browser's title bar when the web page is shown.

dl and dt should be familiar to anyone who has inspected hits from Universal Analytics tags. en, ep.xxx and epn.xxx are new ones for App+Web Properties.

If you're wondering why my ep.container_id is reported with "GTM-xxx vQUICK_PREVIEW", recall that I had setup my Configuration tag's field with the value "{{Container ID}} v{{Container Version}}. So "QUICK_PREVIEW" is the version "number" when previewing GTM.

… Wait a minute! Shouldn't my Configuration tag's fields be set with every event???

Gotcha #2: Configuration tag's fields don't persist

Since there are no GA's Help articles that describe the Configuration tag's "Fields to set" section, I assumed that these fields are the same fields that you set with gtag.js' config. By doing so, the fields should then persist with (i.e. tracked with) every subsequent event, according to GA's developer documentation.

But that is clearly not the case! So either the "Fields to set" are for something else, or I've setup the fields wrongly. Incidentally, user properties need to be set with a specific user_properties field, where its value is a JSON key-value object containing the properties to set.

This is why the App+Web Property and its related tags are still in beta version: they're just not working well enough for everyday, production use.

I can live without the non-persistent Configuration fields for now. Moving on…

So how does Google Analytics report these three hits? Over in the App+Web Property's Real-Time report, I see this:

Wha...? Five events? Didn't I send three hits only????

Gotcha #3: automatically collected events

Again, due to Firebase's automatically collected events, two other events got "snuck in": first_visit and session_start. This was even though there were no explicit hits from my web page for these two events. That implies that GA "added" those events when it started receiving hits from me.

This implies:

• One Configuration tag does not equal to one hit to GA.
• The number of GA hits in your browser's Network console does not equal to the number of hits that GA reports.

If you're a GA360 customer, where you're being billed by the volume of hits that GA receives, then this "one hit is not one hit" predicament could cause your billed hit volume to swell unexpectedly. Keep a close eye on your billed hit volume! (But you already are, right??)

Inspecting the cookies

One more thing to check: cookies. When my Configuration tag fired, it created two cookies: _ga and _ga_xxx, where xxx is my Measurement ID without the "G-" prefix. The _ga one is probably there to maintain parity with Universal Analytics.

The _ga_xxx is specific to the App+Web Property, and contains two timestamps: one for when the cookie was created, and the other for when the last hit was sent. This cookie is probably what controls the user_engagement hit.

Summary:

• There's a lot less that you need to setup in an App+Web tag compared to a Universal Analytics tag.
• GTM Preview is insufficient to validate the hits going out from your browser.
• Rely on GA's Real-Time report to identify the hits that get reported ultimately.

App+Web Event tag

… You know what? Learning about the Configuration tag is probably a lot to take in already. So I'll leave the Event tag to another post.