What is Google Tag?

The Google tag is a single tag you add to your website to use multiple Google products and services (GA4, Google Ads, CM360) from one implementation, rather than managing separate tags for each product.

Terminology Note: "Google tag" is the current product name (formerly called "global site tag"). The underlying JavaScript library is gtag.js. You may see both terms used interchangeably, and they refer to the same technology.

The Google tag sends data from your website to Google product destinations for measuring website and ad effectiveness. A "Google tag" screen in Google Ads and Google Analytics lets you access measurement features without adding code after the initial setup. Settings changes in the Google tag apply to all associated destinations.

Important: As website technologies (e.g., cookies) continue to change due to privacy, browser, or regulation changes, having high-quality, site-wide tagging is critical for accurate measurement.

How Google Tag Works with MetaRouter

MetaRouter syncs certain IDs — Google Click IDs, first-party IDs, and Measurement ID — as minimally as possible to preserve the benefits of the GTag. MetaRouter stores Client IDs as first-party cookies. If MetaRouter does not find the cookie, it creates a Client ID that fires a GTag first-party library sync. MetaRouter then stores the created Client ID as a first-party cookie and sends it along with events.

Key Benefit: After IDs are synced and persisted client-side, MetaRouter eliminates redundant GTag library loads on subsequent page views. The library only reloads when IDs expire, cookies are cleared, or the Analytics.js configuration changes — reducing network overhead and improving page performance.

MetaRouter's sync supports the following Google identifiers: Client ID (client_id), User ID (user_id), Google Click ID (gclid), DoubleClick Click ID (dclid), and Match ID (match_id). To maintain full GTag functionality, all account IDs for Google Ads, Google Analytics (GA4), and CM360 must be added to the MetaRouter UI.

Note: Google recommends websites have only one Google tag. Multiple tags can cause performance issues and maintenance complexity.

When the Google Tag Library Loads

MetaRouter decides whether to load the gtag.js library at two points:

Fresh page load: a first visit, a page refresh, or a new tab.
Consent change: the visitor updates their choice, for example in a consent management platform (CMP) banner.

At each of these points, MetaRouter runs through the following checks in order. The first check that applies decides the outcome.

Is gtag turned off? If yes, the library never loads and no further checks run.
Is consent denied, and is the sync set to skip loading on denial? If yes, the library does not load until consent changes. If no consent settings are configured, MetaRouter skips this check.
Is this a new or unrecognized visitor? The library loads if either of the following is true:
- This is the visitor's first visit.
- MetaRouter has lost track of the visitor since their last visit. For example, more than 45 days have passed, browser storage was cleared, or the visitor is on a new device.
Is a click ID or UTM parameter in the current URL? If yes, the library loads.
Have the Google Tag settings changed since the last load? If yes, the library loads.
None of the above? The library does not load.

Note: Step 4 only checks whether a supported parameter is present in the URL and has a value. ?utm_source=summer qualifies, but a bare ?utm_source does not. A returning visitor arriving on the same link still qualifies. This check does not reset the 45-day window in step 3 or affect the settings comparison in step 5. The list of supported parameters is the same for every pipeline and cannot be changed.

Note: Every load follows the same sequence. The library downloads, the consent signal is sent, the configured accounts (Google Ads, CM360, GA4) are set up, IDs are read, and any configured pings fire.

Considerations

VTC/EVC support overrides steps 3 through 6. When VTC/EVC support is turned on, the library loads on every page load, as long as steps 1 and 2 allow it.
Full page reloads and single-page apps behave differently. If a site fully reloads the page on every click and the parameter stays in the URL, gtag reloads each time. In a single-page app, moving between pages does not trigger the checks again, so gtag loads once per tab.
Failed loads are retried. If a load fails because of a network error, a timeout, or a consent change that cancels the request, MetaRouter does not record it as loaded. It tries again at the next page load or consent change.

Important: GA4, Google Ads, and CM360 re-fire their pings every time gtag reloads, not once per visitor. Outside of VTC/EVC mode, nothing prevents this. For Google Ads and CM360, each ping counts as a real conversion in your account. If you use these pings only for identity matching, not to track an actual sale or signup, set them up as a throwaway activity and leave them out of reporting.

Configuration Options

Send MetaRouterSync to GA4

Default is set to ON and should remain that way for any client that is not fully aware of the selection. We are leaving the MetaRouterSync on by default as we send the User ID (user_id) when you add an AW ID in the UI to create a match table. The option to turn it off will load the gtag and its config on first page load but will not fire the MetaRouterSync event with the User ID and ajs id. We will send these IDs as events are passed but it will not be on first page load.

Enable Google Consent Mode

Google has set new requirements in the EU that require sending opt-out consent if a user opts out vs. not just firing the tag. EU users should enable the consent mode so that they do not lose access to Google's ad networks. With the Consent Mode turned on, we will load the tag on an opt-out consent signal from the consent module and send the opt-out signal to Google.

Sync Architecture: Decoupled vs Coupled

MetaRouter offers two architectures for configuring Google Tag syncs:

Aspect	Decoupled	Coupled
Structure	Parent Google Tag Settings with separate child syncs for each product	Single Google GTag sync bundling all products together
GTag Library	Managed by parent Google Tag Settings	Managed within the single sync
Product Configuration	Each product (GA4, Google Ads, CM360) configured independently	All products configured in one place
Flexibility	Add/remove individual products without affecting others	Changes affect all bundled products

Decoupled Architecture

In the decoupled architecture, Google Tag Settings serves as a parent that controls gtag.js library loading, with individual syncs for each Google product configured as children.

Google Tag Settings (Parent)
  |- GTAG.js Tag ID
  |- Load GTAG library
  |- Load GTAG when zero consent granted
  |- Refresh On Empty Hash
  |- VTC/EVC Support
  |- Google Tag Gateway Mode
  |- Enhanced Google Consent Signal Mapping
  |    |- ad_storage
  |    |- ad_user_data
  |    |- ad_personalization
  |    \- analytics_storage
  |
  \- Syncs (Children)
       |- Google Analytics 4            -> destinations[]
       |- Google Ads                    -> conversions[]
       \- Google Campaign Manager 360   -> advertisers[]

Product-Specific Documentation:

Coupled Architecture

In the coupled architecture, a single Google GTag sync bundles GA4, Google Ads, and CM360 Floodlight together, managing the gtag.js library lifecycle internally.

Google GTag (Single Sync)
├── GTAG.js Tag ID (GA4/Google Ads)
├── Destination IDs
├── Floodlight Advertiser ID Object (CM360)
├── Consent Mode Settings
├── Cookie Lifetime Settings
└── Session Settings

Product-Specific Documentation:

Google Tag (Coupled)