Identify Visitor's Traffic Source In the Data Layer, In Real Time

Enable the User Source Listener and then turn on “Capture User Source” under features. Once published, this will automatically begin to identify how users reach your website and push it into the data layer.

The Listener contains 2 default User Source rule sets. Each rule set contains a number of individual rules. Rule sets, and rules, are read from top to bottom and stop when a match is founds. This allows you to “waterfall” your rules and control the output (i.e. more detailed rules can be placed above more generic rules to ensure matches are found properly).

Review the default rules and consider how you might customize them now or in the future.

After publishing your changes, visit your website with a URL that will trigger a User Source. Any time you want to see User Source activity, use a new URL to trigger a source different from your latest source. You can also clear your browser storage.

User Source will be pushed into the data layer and written to the console.

Turn on Browser Storage inside the User Source Listener. This allows you to write rules that will store values from your data layer into the browser when specific conditions are met. We must use browser storage to persist the user source data!

Under global settings, create new browser storage keys. These can be local, session, or cookie storage. They will become available for ListenLayer to write values to based on rules you create across all of your Listeners.

In this example, we create 3 Local Storage Keys: userSourcePath, userSourceFirst, userSourceLast.

We’ll write a simple rule to act as a condition. When this condition is met, we’ll store the user source into the browser (next step). In this case our rule is simple: any time we have a user source event in the data layer, the condition will be met.

After writing our condition (previous step) we’ll configure how to store our data in the browser. We are going to store data into all 3 Local Storage Keys that we created above at a single point in time.

Inside each key, we will save the user source; however, we will change how the data persists in each key so that one key will always hold the first value, one will always hold the latest, and another will chain the values together (separated by commas). In this way, we will alway know the first traffic source, last traffic source, and entire path that a user has taken at any point in time!

After publishing your changes, visit your website using a number of URLs that trigger different User Sources (refer back to step 3). You should see your User Source values saving in the data layer.

In the video, we’ve added additional details to enrich our User Source information (such as Keyword, Ad Groups, Referring URLs, etc.).

After storing User Source details in the browser, we need to find ways to use them! The easiest thing to do is to push the values from our Local Storage Keys back into the data layer when critical actions occur on our website. For example, we might want to have the data available when forms are submitted. If we track form submissions using the data layer (as we should!), we can capture the user source information with the form submission data directly out of the data layer (using GTM).

To begin we will simply create custom data layer variables where we can push the data from our Local Storage Keys. Do this under global settings.

Create a custom data layer value rule inside of your form Listener. Write a simple condition that matches form loads and form submissions. When this condition is met, we’ll push our Local Storage Keys back into the data layer!

For each custom data layer value we crated in step 9, we’ll push a Local Storage Key value into the data layer.

We can also capture our User Source details from Local Storage into hidden fields on our forms. This makes it easy to collect the data into your CRM (although you can also use the solution above and merge the data using Zapier).

Create hidden fields on your forms – one for each Local Storage Key.

Pro Tip: You can write a monitoring rule inside ListenLayer to identify any forms on your website that are missing the hidden fields!

Create a unique CSS class for each of your hidden fields. You don’t need to have actual styles for this class, the class is used to identify the field across forms, which is not always required. Some forms systems generate unique fields for each form, making it hard to globally identify a single hidden field unless we unify the with a common identifier (the CSS Class).

Here we are putting the string “userSource_first” into the class of one field. In the next step we will write a rule to always push a specific Local Storage Key into any field with this class.

Now you can write rules inside of you forms listener to populate the hidden fields. The condition for this rule should simply match “when a form loads.” You can see here that each rule uses a CSS Selector to target the fields we created and configured in the previous 2 steps.

Publish your changes and test – you’re done!