2 posts tagged with "engineering"

Following up on yesterday's article, this article describes a technique for tracking social logins in a single session using Google Analytics (GA) and Google Tag Manager (GTM).

In crafting this technique I mainly referenced a since deleted post from "advertisercommunity.com". I also used some info from this arcticle on simoahava.com but not the exact technique described.

During a social login (that is, allowing a user to use their Facebook or Google login to log into your site) the user's browser is moved for a split second to Facebook or Google domains to verify the login before being redirected back. In the process of this redirection the user lands back on your site, and GA decides that a new "session" has started and that the referrer is Facebook or Google. This causes the user's activity from before to not be connected to what they do after they log in.

As my friend Nick, founder of Mad Leads pointed out during our joint strategy work on a customer project, you can't just exclude the facebook.com or m.facebook.com domains from within GA without wrecking other real referrer information from FB, so that's not an option for correcting the breakage.

Ideally we want to skip creating this new session all together and roll with the original utm source/medium data from the original session. It turns out that, on the page where the user lands back from Facebook or Google, if you manually set the "referrer" value on the GA Page View tag to your site's own domain, then GA doesn't consider any new referrer and continues on with the old session. A strange workaround, but one that consistently worked in my testing.

Step 1#

Create a new Custom Event trigger. The "Event Name" of this trigger will be used later.

Step 2#

Create a new Google Analytics Page View tag, setting the "referrer" value to the built-in variable {{Page Hostname}}. Configure the tag's Firing Trigger to be the custom event from Step 1. This will cause the referrer information to be wiped out when we fire our custom event.

Step 3#

We want to make sure that this new Page View tag is the only Page View tag that fires on the social login return pages. To do that, we create an exception so that, if the Custom Event fires on a particular page, we exclude our main GA Page View tag and only fire the new one. So, in our main GA Page View tag configuration, create an Exception for our custom event.

Step 4#

On ONLY the social login landing pages back from Google or Facebook, we need to add some additional javascript to trigger our custom event. So just below the GTM tag in the header of those landing pages, I added the following code snippet to fire the Custom Event—

Of course, in the code above, the Event name set up in Step 1 should be plugged into those single quotes accordingly.

Note that this code should only be added to the pages you want to blow up the referrer information for. Adding it site-wide would of course destroy all of the referrer information for the entire site, which is probably not desired.

This article describes a technique for capturing "page changes" in an SPA when trying to track user movement using Google Analytics (GA) and Google Tag Manager (GTM).

For background, an SPA, or single-page web application, uses a browser technology called the History API, or window.history. It allows the recording of the movement around a web application without actual page loads into a stack, allowing the back and forward buttons to do something meaningful even though real page loads are not occurring.

The History API exists consistently in all modern browsers, and it turns out that Google Tag Manager can actually observe changes to it and push tags around accordingly. This isn't default behavior, however; it has to be configured to do so.

Step 1#

The first thing that has to happen is deciding what parts of the URL to track as individual pages. By default GA doesn't track anything but the URL (leaving off the ?query=string and #hashtag information), however these components can be useful sometimes in an SPA in a way that they weren't previously in a traditional web application. For example, we could use #hashtags to show certain dialogs over the top of another page, in which case the /main/url part of the URL is the main page content we show, the #hashtag represents which dialog is currently displayed.

Then, within Tag Manager you can create a Custom Javascript user-defined variable that combines all of these things together in a single value. For one customer's implementation, here's the function I ended up using—

Step 2#

Add a History Change trigger that fires on all events. This is a built-in trigger that doesn't require configuration.

Step 3#

Keep your existing Google Analytics tag for regular page loads, but then create a new Google Analytics: Universal Analytics "tag" to for triggering Page Views when the History Change trigger fires. The configuration for this is:

• Track Type— Page View
• Google Analytics Settings— (not sure here, I just used the UDF that one of you had set up previously, which was present on the other tag that already existed
• "Enable overriding settings"
• Under "More Settings" / "Fields to Set", set the "page" Field Name to the {{user-defined variable}} set up in Step 1.

Finally, set up the tag to trigger off the History Change trigger set up in step 2. Put all together it looks like this—

This setup is pretty generic and should work for most SPA situations as long as they are firing the History Change event, which any modern webapp using this technique should do. I didn't have to mess with dataLayer or anything like that to get this to work, it just did as soon as I created this configuration within Tag Manager.