Google Tag Manager server-side url customization for third-parties/google package

[thinkjrs]

Goals

1. Allow customizing the GTM url. Currently the GTM url is hardcoded.

This is necessary for a server side Google Tag Manager setup.

I have this implemented already Tincre#1.

Non-Goals

No response

Background

Currently we can improve the GTM experience w/Next.js via the third-parties/google lib.

A typical implementation is usually something like the following:

// app/layout.tsx
import { GoogleTagManager } from '@next/third-parties/google'

<GoogleTagManager gtmId="GTM-EXAMPLE" />

This serves the google tag manager from https://www.googletagmanager.com. However, for server-side setups this url should point elsewhere, typically a first party domain or subdomain. For example, https://metrics.tincre.com, rather than https://www.googletagmanager.com.

Here's Google's setup instructions within their tagmanager application:

Proposal

I've already got this ready to go and will/can submit a PR with the exact changes listed below. Here's the PR in my forked repository: Tincre#1

From my seat it looks like two very simple changes, entirely non-breaking:

1. Update GTMParams type:

In the /packages/third-parties/src/types/google.ts file add an optional url parameter to GTMParams.

export type GTMParams = {
  gtmId: string
  dataLayer?: string[]
  dataLayerName?: string
  auth?: string
  preview?: string
  url?: string // new
}

2. Update the /packages/third-parties/src/google/gtm.tsx file add the url parameter only if it is included:

  const { gtmId, dataLayerName = 'dataLayer', auth, preview, dataLayer, url } = props
  const gtmLayer = dataLayerName !== 'dataLayer' ? `&l=${dataLayerName}` : ''
  const gtmAuth = auth ? `&gtm_auth=${auth}` : ''
  const gtmPreview = preview ? `&gtm_preview=${preview}&gtm_cookies_win=x` : ''
  const gtmUrl = url ? url : 'https://www.googletagmanager.com' // new

// second script component returned now uses gtmUrl which defaults to exactly the same url as was hardcoded before
      <Script
        id="_next-gtm"
        data-ntpc="GTM"
        src={`${gtmUrl}/gtm.js?id=${gtmId}${gtmLayer}${gtmAuth}${gtmPreview}`}
      />

3. Update docs on the topic at docs/02-app/01-building-your-application/06-optimizing/12-third-party-libraries.mdx:

Using a custom server URL

If you have a server-side tag manager deployment, you can customize the URL by passing i
n a url parameter. The component uses https://www.googletagamanager.com by default.

import { GoogleTagManager } from '@next/third-parties/google'

  <GoogleTagManager gtmId="GTM-XYZ" url="https://tag-manager-server.xyz" />
}

[thinkjrs]

In the meantime users can get the GoogleTagManager export (exact code as above) from https://www.npmjs.com/package/@tincre/next-gtm-server.

Note that users will need to add this as a client component in their apps, as my current lib build system removes "use client" directives.

For example:

'use client'
import React from 'react'
import { GoogleTagManager as GTM } from '@tincre/next-gtm-server'

export function GoogleTagManager(props: { gtmId: string; url?: string /* add what you need here */}) {
  return <GTM {...props} />
}

[tecoad]

@thinkjrs
Thanks for sharing this.
However this quite doesnt fix the whole problem.
Since some adblockers pattern usually includes also /gtm.js?id=GTM-XXXX in the pattern.

One solution is to use the whole custom loader (including .js filename and id).
As you can see here: https://www.simoahava.com/analytics/custom-gtm-loader-server-side-tagging/

This has been widely adopted, however you solution does not allow that, since it drops the extension and use only the domain from the given url. (I tried for example to use track.mydomain.com/loader.js and you overwrite it with track.mydomain.com/gtm.js which is blocked anyways.

So my suggestion is to let user put through the js filename aswell.

[thinkjrs]

@tecoad I was certainly not trying to solve for this use case so thank you for sharing. What you've reported is expected (and should be happening in the current version of next-third-parties).

I'll try to dig into this soon and refactor to allow the entire path. My objective here was to change as little as possible to allow for a custom server-side path.

That said, server-side tagging bypasses most ad blockers because the cookie is first party, which was my objective for this PR (the current functionality simply doesn't allow for server-side, since you can't customize the URL). And in many (most?) jurisdictions, if we don't get consent for that cookie there could be problems for the business/app/etc, outside of the scope of the software.