gtm-support / core Goto Github PK

Request / Idea

The Google Tag Manager (GTM) allows for the customization of the dataLayer variable name through its configuration. This feature is particularly useful for websites that need to run multiple instances of GTM or wish to avoid naming conflicts with existing JavaScript variables. Currently, the gtm-support module assumes the use of the default dataLayer variable name, which limits its flexibility and applicability in environments where custom dataLayer names are used or multiple GTM containers are deployed.

Proposed Solution

I propose enhancing the gtm-support module to support dynamic naming of the dataLayer variable. This could be achieved by allowing users to specify the name of the dataLayer variable when initializing the module. The module would then use this custom name in all operations related to the data layer, including pushing events and variables.

API Changes

The change could involve updating the module's initialization function to accept an additional configuration option, such as dataLayerName. For example:

interface GtmSupportOptions {
  ...
  /**
   * The name of the dataLayer variable to push events.
   *
   * @example dataLayerName: 'dataLayerDemo'
   *
   * @default dataLayer
   */
  dataLayerName?: string;
}

class GtmSupport {
  constructor(options: GtmSupportOptions) {
    ...
    this.options = {
      ...
      dataLayerName: 'dataLayer',
      ...options,
    };
  }
  // Further implementation...
}

Benefits

• Flexibility: Users can integrate gtm-support more seamlessly into projects with existing naming conventions or multiple GTM instances.
• Compatibility: Increases the module's compatibility with complex web applications and marketing strategies that require the use of multiple data layers.
• Customization: Provides users with greater control over their GTM implementation, aligning with the customizable nature of GTM itself.

Use Cases

• Websites that utilize multiple GTM containers and need to differentiate between different dataLayer variables.
• Projects that already have a global dataLayer variable used for purposes other than GTM and need to integrate GTM without naming conflicts.
• Users seeking to adopt naming conventions that align more closely with their project's terminology or organizational practices.

Implementation Considerations

• The module should ensure backward compatibility, defaulting to the standard dataLayer name when the custom name is not provided.
• Care should be taken to validate the custom dataLayer name to ensure it adheres to JavaScript variable naming conventions and does not conflict with existing global variables.

Pull request

#401

Sometimes there is a need to perform an action after we know exactly when the script is loaded.

@Shinigami92

Request / Idea

The proposal is to add an option or something similar to the trackEvent function so that we can have raw/pure custom data sent to the data layer.

Something like:

gtm.trackEvent({ custom: 'test' }, { raw: true })
// object in data layer will be: { custom: 'test' }

This can be achieved if we use dataLayer directly, but I think it would be nice to have the option already here since we also have logging here if debug is enabled.

Also, one more question, what's the reasoning behind in the first place why the defaults are set?

Additional Context

Currently trackEvent has some prefined values (event, value etc) already set (prefined values are set within here).

Example:

gtm.trackEvent({ custom: 'test' })
// object in data layer will be: { custom: 'test', event: null, value: null …. }

...

Futhermore, first thread started within the nuxt-gtm module

Request / Idea

At the moment in https://github.com/gtm-support/core/blob/main/src/assert-is-gtm-id.ts only gtag's for analyticts are accepted.
In order to use this project Google Ads as well, id's with AW-XXXX need also be accepted.

Regarding method trackView:

Summary: When the plugin is initialized as disabled but with debugging enabled, trackView() logs an event to console even though it shouldn’t.

Steps to reproduce:

1. Set this.options.debug to true
2. Set this.options.enabled to false
3. Call trackView

Expected:
Log message [GTM-Support]: Dispatching TrackView … is not present in the console

Actual:
Log message [GTM-Support]: Dispatching TrackView … is present in the console

The reason why I think this is a bug: The log message made me believe our setup is incorrect because the plugin (even though configured as disabled) claimed it tracked views but nothing turned up in the dataLayer array. Took some time to figure out what actually was happening. The plugin should only log when it actually pushes something to the dataLayer array.

Info

Info

Description

Options "enabled" and "loadScript" are always set to true independently of the passed configuration.

See:

Was this done on purpose maybe? Or what's the point?

Info

When running a production (Vue) build which uses https://www.npmjs.com/package/@gtm-support/vue2-gtm, the bundle fails to load in IE11 (screenshot below) due to a problem in utils.js from gtm-support/core.

Request / Idea

I have a very stubborn 3rd Party Cookie Consent banner which relies of certain data-attributes being present on the script tags in order to allow / block them based on user responses to the consent banner.

Is there a way to add some custom HTML data-attributes & classes to the script tag that initialises the GTM script? In a nice way using the configuration object?

If I were to create an PR for this, is it likely to be accepted?

Additional Context

They want me to inject tags like this if I were using a conventional GTM initialisation snippet

j.setAttributeNode(d.createAttribute('data-ot-ignore'));
j.setAttribute('class','optanon-category-C0001');

To produce something like this

<script src="https://www.googletagmanager.com/gtm.js" data-ot-ignore class="optanon-category-C0001"></script>

Request / Idea

Could we provide a config support to load the script in head tag instead of body tag
...

Additional Context

...