- Status changed to Needs work
over 1 year ago 5:30pm 22 May 2023 - 🇺🇸United States japerry KVUO
Thanks for the insight! As part of combining Google Tag Manager and Google Analytics into Google Tag, your issue was brought up as a potential use case. However, since the existing 1.x version the migration would move separate GTM Drupal containers into new separate Drupal containers and we assumed that GTM IDs were a 1:1 pairing with Drupal containers. (There actually was some debate about this, but baring actual use cases, this is the route we decided)
That being said, your questions and confusion are well founded-- we should be allowing multiple GTM ids per Drupal 'container'. In 2.x a container is actually a set of conditions and events that execute for a particular Google Tag / GTM ID, and have little if nothing to do with the concept of containers in GTM. If a user feels more comfortable about putting 1 GTM ID per Drupal container and copying the settings (what the migration does), cool. But if you have the same settings for multiple IDs, you should be able to do that as well.
There are two parts to this issue: Technical and documentation. We will fix the issue technically so you can get multiple GTM IDs working within a single container. Then follow up and fix drupal.org documentation to more clearly define what a drupal 'Google Tag' container is.
Thanks, @japerry -- I really appreciate your reply and the additional information. And I look forward to seeing the revised documentation and code, as well as trying out the ability to have multiple GTM IDs in a single Drupal container.
I wonder, though, if our local installation might have glitched when I updated from google_tag v1.6 to v2.0.1? The update/migration seemed to do exactly what you described: it converted our two GTM container IDs into two separate Drupal containers with the two different GTM IDs associated with the respective Drupal containers.
However, when I looked at the public-facing pages of the site, only one of the two GTM IDs was showing up in the <head> section as a GTM <script> entry. I could only get both GTM ID <script> entries to appear in the public-facing pages by downgrading back to v1.6.
Based on my reading of your reply, though, it sounds as if we should have seen both GTM ID <script> entries in public-facing pages in our two-Drupal-containers-with-one-GTM-ID-in-each-container scenario? In v2.0.1 I couldn't seem to get two GTM <script> entries on our public-facing pages no matter what combination of things I tried -- using the default migration setup (two Drupal containers with separate GTM IDs), starting fresh with two separate Drupal containers with two different GTM IDs, putting both GTM IDs in one Drupal container, etc. It sounds like that latter scenario (two GTM IDs in one Drupal container) isn't ready yet in 2.x, but it sounds like the first two approaches _should_ have worked, yet didn't, at least in our installation.
I'm not sure if the missing GTM <script> entry on our site is due to a coding issue, or a user-comprehension issue? Either way, though, I look forward to testing out the enhancements when they get rolled out.
Thanks again,
Ken- 🇺🇸United States japerry KVUO
Sorry I was mistaken, after consulting with Google I was reminded that past practices around multiple GTM containers is frowned upon, and unsupported in general. But if you need multiple GTM containers, there is a path (last paragraph below). I'll attempt to draft how the module works now:
Only one 'container' (or Measurement/Drupal container') will ever get loaded per request. Multiple container support does exist, but this for different conditions only. (IE: turn on some events for the 'admin' user and send it to a different gtag ID, then add another container as a catch-all for all other users) The first container to match the conditions gets loaded. (see TagContainerResolver->resolve())
Unfortunately, this means that migrations of multiple containers from 8.x-1.x aren't going to work out of the box if the only change is the GTM id. In this case, you simply need to move the GTM id to the main container, now that we support multiple IDs per drupal container.
The reason behind all this is that gtag and gtm all share the datalayer, which must be the same name for all IDs. (this is opposite from earlier documentation from Google). Loading multiple containers that meet the same conditions means multiple GTM snippets, with conflicting names could be loaded. The new gtag.js implementation for GTM and Google Tag emphasizes one snippet with multiple tags.
However, multiple GTM IDs should be able to fire from the same 'Drupal container', allowing them to be added to the same snippet. You'll see only one script tag, but it should contain all the GTM IDs. This issue will address this, because currently only the first GTM ID is loaded in. (The error caused by the getGtmId() method which returns a string of the first GTM id is fetches, line 163 TagContainer.php)
So, in short: Consolidating your GTM IDs to one container was correct, and its a bug that the second one is not showing.
Thanks again @japerry -- this is really helpful! And I appreciate the extensive explanation of the mechanics in the new gtag.js implementation. That makes perfect sense now why v2.x was only using one of our Drupal containers, since they had identical conditions. And it will be great to be able to have multiple GTM IDs cited in the <script> tag once that portion of the code is enhanced. Thank you!
Thanks too for dealing with what is likely an outlier for most sites. The main reason we have (and need) multiple GTM container IDs on each page in our site is because of a legacy arrangement with our site where an outside contractor is using their own GTM container to inject some marketing-related tags on select pages on our site, and we ended up wanting our own GTM container to not only fold in our Google Analytics tracking codes but also to add our own GTM tags to other pages on our site. It would probably have been best if we had worked with the contractor to share access to a single GTM container/account, but there seemed to be some contractual barriers to this, so we're stuck with needing to inject two different GTM container IDs on every page in our site. I'm just glad to know that we now have a path forward for this in the 2.x branch--thank you!
- last update
over 1 year ago 50 pass, 1 fail - @japerry opened merge request.
- Status changed to Needs review
over 1 year ago 7:56pm 23 May 2023 - 🇺🇸United States japerry KVUO
The above Merge Request supports two GTM containers within the same Drupal container. I tested with the HTML output on each GTM tag and they both appear on the site. we'll see if this passes tests, and if so get it committed for release later today.
- last update
over 1 year ago 50 pass, 1 fail - last update
over 1 year ago 54 pass - last update
over 1 year ago 54 pass - Status changed to Fixed
over 1 year ago 10:01pm 23 May 2023 Fantastic! Thanks for all your help and quick work on this @japerry -- I really appreciate it!
- 🇺🇸United States mario.elias
I'm encountering the same issue with utilizing multiple tags. In version 1.6, we employed tags for all pages and a secondary tag for a select few. This is necessary as we are using two distinct analytics accounts.. Please advise what should do.
Automatically closed - issue fixed for 2 weeks with no activity.
- Status changed to Fixed
about 1 year ago 5:34pm 29 August 2023 - 🇺🇸United States trackleft2 Tucson, AZ 🇺🇸
One use case for multiple containers, We have a distribution that manages configuration for 1000's of sites, and do want not to override our core distro config just to add an additional container for our clients that have them, because that adds significant overhead.