Data Layer or Google Tag Manager UI?

What is the Data Layer?

To ensure maximum flexibility, portability, and ease of implementation, Google Tag Manager functions best when deployed alongside a data layer. A data layer is an object that contains any information you want to pass from your website to Google Tag Manager. You can pass information such as events or variables to Google Tag Manager via the data layer, and triggers can be set up in Google Tag Manager based on the values of those variables or specific events (for example, you can tell GTM to fire a remarketing tag when the purchase_total > $100). Variable values can also be passed through to other tags (e.g. pass purchase_total into the value field of a tag).

Rather than referencing variables, transaction information, page categories, and other important signals scattered throughout your page, Google Tag Manager is designed to easily reference information that you include in this data layer. Implementing the data layer with variables and associated values (as opposed to waiting for those variables to load throughout the page), ensures that they will be available as soon as you need them to fire tags.

You can find more detailed information on the Data Layer in the developer documentation.

When setting up Google Tag Manager, you'll need to decide which information you want to include in the data layer, and which to include in click/form triggers and user-defined variables from the Google Tag Manager UI. While there is no right or wrong solution here, we generally recommend the following breakdown for Data Layer vs UI implementation.

When to use the Data Layer

It’s best to use the Data Layer for code that is scalable. For example, if you need to hard-code a certain type of element on each page, and you’d like to add that element as a Custom Dimension to Google Analytics, it would be best to use the Data Layer to implement this. Good use cases of such elements include: eCommerce, experimentation, page attributes and visitor attributes.

For example, a book publisher website collecting page category, author name, and visitor type to the data layer might look like this (placed before your container snippet):

dataLayer = [{
  'visitorType': 'signed-in',
  'pageCategory': 'book-preview',
  'authorName': 'Smith, Jon'
It's important to note that if you choose to declare the Data Layer, you should always do so before your container snippet, otherwise you risk breaking Google Tag Manager on your site.

This means that all three of these elements are being collected on each page where this Data Layer is implemented. The data collected here is then passed into Google Tag Manager, and the triggers and variables set up in Google Tag Manager determine what then happens to this data. It may be used as a value input for other variables, as values for Custom Dimensions sent to Google Analytics, or many other potential use cases.

Using the Google Tag Manager UI

There are also many use cases where it may make more sense to set up tags, variables, and triggers via the Google Tag Manager UI in order to bypass hardcoding the needed changes or additions into the Data Layer.

The most common use case for these types of tags, variables, and triggers is for quick fixes. Many times, editing Data Layer elements requires developer or engineering support and it may take time to prioritize these updates against other business needs. However, when something breaks in your code and data collection is interrupted, implementing a quick fix can be very important.

For example, imagine we have a three-page signup flow for a product trial and each page is tagged with of one the following pageview URLs (in order of progression through the flow):


Let's imagine that an engineering push went live that changed the third pageview URL to “”. This breaks all of your funnel reporting in Google Analytics (since your funnels were set up via exact URLs) and everywhere else this URL is used for reporting.

The solution to this issue is to either change all of your reports to the new URL (which may be a large effort depending on how many reports rely on the pageview URL), or fix the URL. Since changing all of your reports can take time and may be confusing if you have many users of analytics, we recommend pushing a fix for the pageview URL being sent to Google Analytics via Google Tag Manager. In this case, it’s a very quick fix to say that when “” is collected, send “” to Google Analytics. This now serves as a good patch to change the pageview URL being reported back to the proper URL, while you simultaneously submit a bug fix to your engineering team to make the fix permanent in your code base.

Another significant use case of the UI for creating tags, triggers, and variables is to take advantage of Auto-Event Tracking with Google Tag Manager. Read more about event tagging in this guide.

Previous: Use constant string user-defined variables | Next: Cross-domain tracking for Universal Analytics

Was this article helpful?
How can we improve it?