Skip to main content

Google Tag Manager

Google Tag Manager (GTM) is commonly used by publishers to manage third-party snippets, pixels, trackers, etc. on their sites without (or with minimal) involvement from engineering teams. Engineering teams can also benefit from the use of GTM as tags, triggers, and variables can be tested and deployed without code changes to the site’s primary repository.

While it is possible to have multiple GTM containers on a single website, it’s less common. The most common configurations (in order) are:

  1. One Google Tag Manager container per site.
  2. One Google Tag Manager container per publisher.
  3. One Google Tag Manager container per organization.
  4. One Google Tag Manager container per site + additional publisher/org container(s) included via the use of Zones (GTM360 only).

Other less common configurations might include multiple containers per site based on business requirements (marketing, editorial, engineering) or complexity1.

Organic CMS will support any of these configurations, but engineers should have access to all relevant containers during discovery to confirm any features/functionality within them can be maintained.

Not sure how best to structure your Google Tag Manager account?

Migrating Google Tag Manager

During a migration, engineers should ensure that Google Tag Manager is set up by logging into WP Admin and navigating to Options/Analytics. Here, the Google Tag Manager slider should be enabled and Code should be populated with the Google Tag Manager Container ID.

Organic CMS - Options - Google Tag Manager

Optional

There is a field called AMP Code where a publisher’s Google AMP Container ID can be added (if one has been configured).

GTM Migration Checklist

  • Does engineering have access to the Google Tag Manager account?
  • Do they have Publish permissions on the container(s)?
  • Who can the team contact with questions about existing configuration?
  • Has the team reviewed the container(s) to determine migration requirements?
  • What active tags, triggers, and variables depend on CMS data?
  • What paused tags depend on CMS data?
  • What Zone(s) exist? Does engineering have access to all related containers? (GTM360 only)
  • Depending on the results of the initial investigation, additional discovery may be required.
  • Create migration tasks for all “must-have” items that cannot be accomplished with out-of-the-box solutions.

What to Look For

When it comes to GTM configuration, every publisher is likely to be a little different. Some make use of workspaces and folders for organization, while others may choose to use a rigid naming convention instead. Some publishers may not have any standards at all in GTM, especially if it’s just one person or small team working in that account.

Here are some things to look out for when working with a new publisher account:

  1. Are they using any user-defined variables?
    • Built-in variables are standard for all GTM accounts, but user-defined variables are publisher-specific.
    • These variables are often set by code that runs on the publisher’s site. They can also be set by tags in GTM based on certain parameters/attributes of a user, session, page, or event.
    • These will likely require the most clarification from publishers during discovery.
  2. Are they using any Page View triggers that fire on “Some Events”?
    • Page View triggers allow users to set filters on what types of events the trigger fires on, usually based on variables.
    • Event filters that should not require custom development:
      • Click Text
      • Click URL
      • Page Hostname
      • Page Path (unless changing as part of migration)
      • Page URL (unless changing as part of migration)
      • Referrer
    • Trigger filters that should always be checked during migration:
      • All Custom Variables
      • Click Class/Element/ID
      • Form Class/Element/ID
  3. Are they using any “Just Links” click triggers?
    • Just Links triggers allow users to set filters on what types of link clicks the trigger fires on, usually based on variables.
    • Trigger filters that should not require custom development:
      • Click Text
      • Click URL
      • Page Hostname
      • Page Path (unless changing as part of migration)
      • Page URL (unless changing as part of migration)
      • Referrer
    • Trigger filters that should always be checked during migration:
      • All Custom Variables
      • Click Class/Element/ID
      • Form Class/Element/ID
  4. Are they using any element visibility triggers?
    • Confirm that element ID/CSS selectors do not change.
    • If they do, update to reflect the new ID/selector.
  5. Are they using any form submission triggers?
    • Confirm that the related variables do not change.
    • If they do, update to reflect the new variables.
  6. Are they using any custom event triggers?
    • Confirm that the custom events are still pushing to the data layer.
    • If they’re not, recreate the custom events or find an alternative method for triggering.
  7. Are they using any trigger groups?
    • If so, ensure all child triggers function based on the list above.
    • Replace or re-create any child triggers that do not function.

Google Analytics

Google currently recommends that publishers implement Google Analytics 4 (GA4) on their sites using Google Tag Manager so that GA4 events can be set up alongside GTM tags. There is a guide for this here.

If a publisher sets up GA4 in this way, the Google Analytics slider should be left disabled in WP Admin and the GA ID can be left blank to prevent duplicate events from triggering.

For more information on setting up Google Analytics without GTM, contact Organic Support.

Footnotes

  1. Google Tag Manager containers have a size limit of 200kb. For complex sites that reach this limit and cannot be optimized further, Google recommends upgrading to a Google Tag Manager 360 plan so code can be split into multiple containers and be loaded conditionally using Zones.