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

Most webmasters, programmers, and marketers utilize Google Analytics to understand Source/Medium information for their website traffic. However, this data isn't available until after a user's session and is generally isolated and anonymized in GA. What if you wanted to know where users come from immediately as they begin a session? What if you need this data in real time to power your data collection, personalization, or to override or enrich Google Analytics? All of this is now possible with ListenLayer's User Source Listener! Simply turn it on and all your visitor's source information is pushed into the data layer, where it's available for easy collection and use via Google Tag Manager. Once enabled, you can customize the source rules to match your needs, or use our out-of-the-box configuration! In this use case, we'll show how you can capture a user's traffic sources over time. Build a path of these touch points so you can understand what traffic sources influence conversions (you can use this to build a multi-touch attribution model!).

Build Your Own Attribution Model by Capturing User Source Over Time

Listeners allow you to automate data collection and enrichment on your website or application. With the User Source Listener, you can easily identify how user’s reach your website in real time. Use this data to further customize your data layer or enrich your data collection. The steps below walk through how to set this up and then how to use it to build a path of traffic sources that user follow before taking critical actions.

Steps & Code Examples

Step 1: Enable the User Source Listener & Features
Step 1: Enable the User Source Listener & Features

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.

Step 2: Review the User Source Rules
Step 2: Review the User Source Rules

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.

Step 3: Test Your Initial User Source Rules
Step 3: Test Your Initial User Source Rules

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.

Step 4: Turn on Browser Storage
Step 4: Turn on Browser Storage

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!

Step 5: Create Local Storage Keys of Cookies to Hold User Source Details
Step 5: Create Local Storage Keys of Cookies to Hold User Source Details

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.

Step 6: Write a Rule to Store Traffic Source to the Browser
Step 6: Write a Rule to Store Traffic Source to the Browser

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.

Step 7: Store User's Traffic Source Into the Browser
Step 7: Store User's Traffic Source Into the Browser

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!

Step 8: Publish and Test Your Configuration
Step 8: Publish and Test Your Configuration

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.).

Step 9: Create Custom Data Layer Values
Step 9: Create Custom Data Layer Values

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.

Step 10: Write Rules to Push User Source Back to the Data Layer
Step 10: Write Rules to Push User Source Back to the Data Layer

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!

Step 11: Push The User Source Values Into the Data Layer
Step 11: Push The User Source Values 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.

Step 12: Create Hidden Fields to Capture Traffic Source
Step 12: Create Hidden Fields to Capture Traffic Source

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!

Step 13: Add Unique CSS Classes to Each Hidden Field
Step 13: Add Unique CSS Classes to Each Hidden Field

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.

Step 14: Write Rules in ListenLayer to Populate Hidden Fields
Step 14: Write Rules in ListenLayer to Populate Hidden Fields

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!