Installing Google Analytics 4 via Google Tag Manager

Google Analytics 4 is conveniently connected via Google Tag Manager when you need to manage analytics without constantly editing your website's code. The GTM container is installed on your website once, after which you can add Google tags, GA4 events, ad pixels, and other tags through its interface. This approach simplifies checking changes and reduces the risk of accidentally leaving multiple identical counters on your pages.

The Google Analytics and GTM integration is useful for both simple statistics and comprehensive user analytics. After a basic setup, you can track form submissions, phone clicks, file downloads, scroll depth, checkout initiation, and purchases. Before publishing, it's recommended to test each setting using Preview Mode, Google Tag Assistant, Realtime, and DebugView.

What is Google Analytics 4 and Google Tag Manager?

Google Analytics 4 collects data on visits, events, and user actions, then displays it in reports. In GA4, you can analyze traffic sources, landing pages, key events, action sequences, purchases, and other metrics. A separate Web Data Stream is created for each website, which receives its own measurement ID.

Google Tag Manager operates on a different level. GTM stores tags, triggers, and variables, determines when they should be fired, and transmits data to connected systems. The tag manager itself doesn't replace Google Analytics reports and isn't used as a standalone web analytics system. Therefore, queries like “google analytics tag manager” or “tag manager analytics” typically refer to the combined use of these two services.

How is Google Analytics different from Google Tag Manager?

The main difference lies in the purpose of the services. Google Analytics receives events, processes them, and generates reports, while Google Tag Manager is responsible for the technical execution of tags on the website. When a user clicks a button or submits a form, GTM can record the action based on a specified trigger and send the event to GA4.

When setting up Google Tag Manager with Google Analytics, both interfaces are used sequentially. First, a specialist creates a property and data stream in GA4, then installs or opens GTM, adds a Google tag, and, after testing, publishes the container. The final test is performed again in Google Analytics, where actual test events should appear.

Why use Google Tag Manager with Google Analytics?

GTM is especially convenient for projects where analytics evolves alongside the website. A new tag or event can be created in the workspace, tested separately from users, and published after verification. If an error occurs, the container version history is available, so the team can see what changes were made and when they appeared on the website.

A single GTM container lets you manage GA4, Google Ads, and other approved marketing tags. Setting up Google Analytics through GTM also simplifies working with data layers, custom events, and parameters. For developers, this means fewer separate template inserts, and for analysts, a clear tracking structure and a single place to test triggers.

Google Tag, gtag.js, and Google Tag Manager – What's the Difference?

Google Tag is used to transmit data to Google services, including Google Analytics 4. If the tag is installed directly through the website code, the gtag.js library is typically used. This option is suitable for basic integration when the project has few events and the developer can quickly make changes to the code.

Google Tag Manager adds a management layer between your website and analytics systems. It lets you install Google tags, configure GA4 Events, use variables, create triggers, and test changes before publishing. Queries like “google tag script”, “google tag html”, and “google tag install” often refer to direct installation, while “google tag manager for google analytics” implies managing analytics from within the GTM container.

What do you need before installing GA4 via GTM?

Before installing GA4 with Google Tag Manager, you need to check the initial project configuration. The user must have access to the Google Analytics 4 property and the Google Tag Manager container, and the GTM code must load correctly on the site pages. If the container hasn't yet been created, first register it and install it in the site template.

You'll also need a Web Data Stream for the domain you plan to track. From its settings, take the ID associated with the desired GA4 property. If your account has multiple sites or streams, it's especially helpful to check the domain and destination in advance to avoid sending real data to someone else's or a test property.

Before you begin setup, it is recommended that you check four things:

• The Google Analytics 4 property is created specifically for the required project and is available to a specialist with the necessary rights;
• The Web Data Stream is associated with the correct domain and contains a valid Measurement ID;
• Google Tag Manager container is installed on all templates that should participate in analytics;
• Old counters and test tags are found in advance to prevent double sending of events after launch.

After such verification, Google Analytics installation via Google Tag Manager goes more smoothly. Errors related to access rights, a wrong identifier, or multiple copies of analytics code are best detected before creating new tags.

How to create a GA4 property and data stream?

If a GA4 property doesn't already exist, create one in the Google Analytics admin section. After that, add a Web stream for the site, specify the domain, and configure data collection settings. A single property can contain multiple streams, so when working with multiple domains, don't just copy the ID from the first Web Data Stream you encounter.

For basic setup, simply ensure the stream is created for the desired website and its Measurement ID is available. Additional Enhanced Measurement parameters can be checked in the same section. These affect the automatic collection of certain actions, so before manually configuring scroll, outbound click, or file download events, it's worth checking which ones are already enabled.

Where can I find Measurement ID and Tag ID?

The Measurement ID is located in the website's data stream settings and typically appears as G-XXXXXXXXXX. This identifier associates events with a specific Web Data Stream. It is often searched for using queries like “Google Analytics account tracking ID”, although in GA4 it is more accurate to refer to the measurement ID of a specific stream.

The Tag ID is part of the Google Tag settings and is used in the current interface when creating a basic tag. If multiple destinations are connected to an account, different IDs may appear side by side. Before saving the setting, verify that the selected Google Tag is linked to the GA4 property that should actually receive the site's data.

How is Tag ID different from Measurement ID?

Confusion between Tag ID and Measurement ID often arises when reading old and new instructions simultaneously. In the current configuration, a basic Google tag is created with a tag ID, and a separate Google Analytics: GA4 Event sends the event to the appropriate GA4 destination. Specific fields in the interface may depend on the type of tag being created and the current GTM version.

If, after GA4 setup, GTM shows a tag firing, but there's no data in Analytics, the first step is to check the selected ID and destination. Multiple similar Tag IDs in one account don't necessarily mean any of them will lead to the desired property. A reliable check involves Preview, Tag Assistant, and viewing the event in DebugView.

What is Tracking ID and why are the old instructions different?

Older materials often contain Tracking IDs in the format UA-XXXXXXXX-X. This identifier was used in Universal Analytics, so instructions with UA Tracking IDs cannot be transferred to the new GA4 project without verification. Queries such as “universal analytics tag manager” and “google tag manager universal analytics” still appear, although they describe the previous version of Analytics.

For the new installation, Google Analytics 4 is used. If the site still has the old UA code, it should be taken into account during the audit, but there is no need to transfer this scheme to the new setup. Pay particular attention to instructions that list the old GA4 Configuration tag as the primary tag without mentioning the current Google tag.

How to install Google Analytics 4 via Google Tag Manager?

The installation begins with checking the GTM container, then creating a basic Google tag and setting the launch condition. After saving the changes, you need to open Preview Mode, verify that the tag is working correctly, and only then publish the new version of the container. Simply clicking “Save” isn't enough, because the saved workspace isn't yet available to regular site visitors.

The data transfer logic looks like this:

Website → GTM container → Google tag → Google Analytics 4

For individual actions, another level is added:

User Action → GTM Trigger → GA4 Event → Google Analytics 4

This diagram is convenient as a basis for setting up Google Analytics and GTM. It shows where to look for errors: in the user's actions, the triggering conditions, the tag itself, or the event received in GA4.

Step 1: Verify the Google Tag Manager container installation on your website

First, you need to ensure that the container code is loading on the intended pages. The container is typically installed in the site's master template so that new tags don't have to be added individually to each page. If the site uses multiple templates, subdomains, or a separate checkout, the test should cover every area where data collection is planned.

The easiest way is to open the site in Preview Mode or check the container using Tag Assistant. If GTM isn't detected, there's no point in configuring Google Analytics. First, you need to fix the container installation itself, clear the cache if necessary, and ensure that production pages are receiving the latest template version.

Step 2: Create a Google tag in GTM

In the GTM workspace, open the Tags section, create a new tag, and select Google Tag. It's best to use a name that's clear to the entire team, for example, GA4 – Google Tag – All Pages. It's helpful to include the system, purpose, and scope in the name, as over time, a container can contain dozens of tags with similar functionality.

After selecting the tag type, you need to specify the ID associated with the desired Google Analytics 4. Older instructions may suggest a GA4 Configuration tag, but in the current structure, the Google tag performs the basic configuration function. This approach better aligns with the current logic of Google Tag Manager and GA4.

Step 3: Add your Google Analytics ID

Copy the Tag ID or other identifier provided by the current Google Tag setting for the selected property. Don't enter a random code from another stream, a test property, or an old Universal Analytics property. An error at this stage is often undetectable in GTM because the tag itself can technically fire without explicitly reporting an incorrect destination.

After inserting the ID, compare the domain and GA4 property again. If the team manages multiple projects from a single account, it's helpful to include the site name in the tag name. This small step reduces the likelihood of a situation where Google Analytics settings via GTM send real client events to a different property.

Step 4: Set up the trigger

For a basic Google tag, an early launch is typically used on all relevant pages to ensure the configuration is available before subsequent events are sent. Current recommendations use Initialization – All Initialization Events. This trigger helps load the basic tag before event tags that use its settings.

If analytics is required only for a specific section of the site, the condition can be limited, but this decision must be made consciously. For a typical site, basic analytics is usually needed on all indexed and user-facing pages. Exceptions such as service sections, private accounts, or specific domains are best explicitly defined and then verified using Preview.

Step 5: Save and test the tag

After saving, open Preview, enter the website address, and enable Tag Assistant. Browse several pages to see if the Google tag fires on each one and if there are any unexpected re-triggers. This is also a good time to check the variables you'll need for events later.

The successful “Fired” status indicates that GTM has met the launch conditions, but it's too early to end the final check. The data must reach Google Analytics. Therefore, after the Preview, open Realtime or DebugView to ensure that the test user and events are actually displayed in the intended property.

Step 6: Publish the container

After successful testing, click Submit and create a new version of the container. It's best to name the version briefly to describe the change, such as “GA4 base tag” or “GA4 events for forms”. This history helps quickly understand what exactly was pushed into production, especially if multiple people are working with GTM.

After publishing, repeat the test without Preview Mode. Open a regular website page, perform the test action, and check Realtime. Saved settings and published settings are different GTM states, so a forgotten Publish remains one of the simplest reasons why Google Analytics GTM code doesn't produce the expected data.

How to check if Google Analytics is working through GTM?

The check should cover both GTM and Google Analytics 4 itself. In the container, you need to ensure that the tag fires when the desired event occurs, and in GA4, you need to ensure that the event is received with the correct parameters. A single tool doesn't show the entire chain, so diagnostics based solely on the Fired status often misses errors.

For a basic setup, it's convenient to go through three levels: Tag Assistant shows how tags work, Realtime confirms live data, and DebugView helps you thoroughly check events and their parameters. If you're using forms, e-commerce, or dataLayer, testing should be done on a real user scenario, from the start of the action to receiving the event in GA4.

Checking via Preview Mode and Google Tag Assistant

Preview Mode connects the browser to the selected GTM workspace and displays the sequence of events on the page. In Tag Assistant, you can see which tags fired, which remained in the Not Fired state, and which conditions prevented them from firing. This is especially useful for clicks, forms, and dataLayer custom events.

During testing, follow a typical visitor's path: open a page, click a button, submit a test form, or add a product to a cart. Then compare the expected and actual triggers. If the tag fires multiple times for the same action, the issue must be corrected before publishing, otherwise duplicates will appear in GA4.

Checking data in Realtime

The Realtime report shows recent activity and is suitable for quickly checking a basic installation. After opening the site, active users, page views, and other events sent by the current configuration should appear. When testing multiple properties, ensure that the property opened is the one targeted by the Google tag.

Realtime is useful for general information about whether GA4 is currently receiving data. However, its capabilities may be insufficient for complex debugging, as it doesn't replace technical review of the event sequence. If you need to check parameters, event names, or the sending order, it's better to use DebugView in conjunction with Tag Assistant.

Checking events via DebugView

DebugView displays a stream of debug events for the selected device in near real time. Here you can see page_view, custom events, and parameters sent from GTM. This is especially useful for form or e-commerce events, as the Fired status alone doesn't confirm the correctness of each value.

Check the event name, sending time, and available parameters. If an event arrives without a value, currency, form_name, or other required parameter, the problem lies in the GTM configuration or data source. It's best to fix it before your reports start filling up with incomplete information.

Lead SEO specialist — Gennady

I consider GA4 setup complete after verifying the entire chain, not after the Fired status appears in Google Tag Manager. I also monitor the event in Tag Assistant, Realtime, and DebugView. This order helps me spot an incorrect Measurement ID, a duplicate page_view submission, or a saved but unpublished version of the container.

Why isn't Google Analytics receiving data from Google Tag Manager?

If Google Analytics isn't showing data, it's best to troubleshoot sequentially. First, check the container loading, then the Google tag launch, the selected identifier, the version publication, and the event receipt in GA4. This sequence is faster than randomly changing settings, because at each step, you can confirm a specific section of the chain.

It's also worth checking your site's old scripts, CMS plugins, and other GTM containers. After migrating analytics, there are often leftover Google tags or old tags that continue to send parallel data. As a result, some events are duplicated, while others are sent to another property.

Incorrect Tag ID or Measurement ID used

If the tag fires but the data doesn't appear in the expected property, compare the ID in GTM with the settings of the desired Web Data Stream. Be especially careful in projects where multiple sites, test properties, or destinations are created in a single account. Seemingly similar IDs may refer to different data streams.

After fixing this, run Preview again and perform a test action. It's best to test a new event, which can be easily identified by its time. If it appears in the correct DebugView, the connection is restored. If there's still no data, proceed to verifying the container's publication and consent.

GTM container not published

In GTM, you can create a tag, save it, and successfully test it in Preview, but users of the production site will still receive the previously published version. This often happens after setup at the end of the workday or when handing off a task between specialists. Everything looks correct in Workspace, but the regular visitor sees no changes.

Check the current published version and container history. If the desired setting remains only in the workspace, publish it after retesting. Then open the site in normal mode and verify that the new event appears without Preview Mode enabled.

Google tag doesn't fire on all pages

The cause is often a limited trigger or different site template structure. For example, the main site might load GTM correctly, while the checkout, subdomain, or separate landing page might use a different template. As a result, part of the user journey is missed by analytics, and the funnel appears incomplete.

Test multiple page types, not just the homepage. In Tag Assistant, compare Google tag execution on category, product, form, and confirmation pages. If you're using Page URL or hostname exclusions, ensure they actually match your current project structure.

There are multiple identical tags installed on the site

Duplicates appear when Google Analytics is installed simultaneously through the website code, CMS plugin, and GTM. In this case, the same page_view may be sent twice, and key events may receive inflated values. The problem is especially noticeable after a redesign or migration, when people forget to remove the old integration.

Check the source code, plugins, CMS settings, and all containers loaded on the page. After choosing a single working setup, remove any unnecessary inserts. For GA4 via GTM, a correctly installed container and tags managed within it are usually sufficient.

Events are blocked by Consent Mode or cookie settings

If a website uses CMP and Consent Mode, the tag's behavior depends on the user's choice and the current consent mode. Therefore, testing in a browser with cookies already saved may yield different results than testing in a clean profile. Consent conditions should be taken into account when analyzing tags that don't fire.

When debugging, check the consent status before and after interacting with the banner. Don't disable consent mechanisms just to collect more data. Proper analytics should take into account the chosen website operating model and user data processing requirements.

A browser or extension is blocking analytics

Some ad-blocking and tracker-blocking extensions interfere with the loading of analytics requests. Similar behavior occurs with strict browser settings, corporate filters, and certain network restrictions. Therefore, a single failed test in a personal browser does not necessarily prove a GTM error.

To diagnose this, repeat the test in a clean browser profile without any additional extensions. Then compare the results with the standard mode. If GTM and GA4 are running in a clean environment, consider the limitations of the specific browser rather than blindly changing the working tag configuration.

How to set up Google Analytics 4 events via Google Tag Manager?

After the basic GA4 connection is established, you can move on to actions that are valuable for website analysis. GA4 uses an event-based model, so page views, form submissions, purchases, and other actions are passed as events. For each event, you can add parameters that clarify the context of the action.

Before creating a new GA4 Event, check whether the desired action is already collected automatically. Excessive duplication complicates reports and increases the risk of discrepancies. Setting up Google Tag Manager events should begin with a user journey map and an understanding of what data will actually be needed for analysis or advertising.

What events does GA4 collect automatically?

GA4 receives some events without manual configuration. These include basic technical events related to session start, first visit, and page view. The set depends on the stream type and current configuration, so before creating your own event, check the official documentation and actual DebugView data.

Automatic events don't require a separate tag for each action. Creating a second tag with the same purpose could result in duplicates in reports. Therefore, a specialist first reviews the events already incoming and then adds only those analytical elements that the project truly needs.

What is Enhanced Measurement?

Enhanced Measurement expands the automatic collection of web stream actions. Settings include page scrolling, external clicks, internal searches, file downloads, and interactions with embedded videos. The specific set should be verified in the current Web Data Stream interface.

If Enhanced Measurement already sends a scroll or outbound click, a second similar tag via GTM is created only for a separate analytics task. For example, a standard scroll may not be sufficient if a project requires levels of 25%, 50%, 75%, and 90%. In this case, the custom event should have a different, clear purpose.

How to create a custom event via GTM?

First, define an action that can be reliably recorded. Then, create a trigger, add the Google Analytics: GA4 Event tag, set the Event Name and the desired event parameters. Once configured, execute the action in Preview Mode and verify that the event reaches DebugView with the expected values.

The workflow looks like this:

1. Determine the user action and its analytical value.
2. Select a reliable trigger signal in Google Tag Manager.
3. Create a GA4 Event with a clear and stable Event Name.
4. Add parameters via GTM variables or dataLayer.
5. Check the event using Preview Mode and Google Tag Assistant.
6. Make sure that the data appears in the DebugView of the desired property.
7. Publish the container and repeat the test in production.

After publishing, it's useful to test the event again using a regular user scenario. This test ensures that the setting works outside of debug mode and isn't affected by the Preview timing conditions.

Example: click on a button

Built-in click variables can be used to trigger a button click if the element is consistently identified by ID, class, text, or URL. The trigger should distinguish the desired button from other page elements. If the same text is used in multiple places, it's best for the developer to add a separate technical attribute for analytics.

The Event Name is chosen based on the meaning of the action. For a lead, the recommended event “generate_lead” may be appropriate if the click truly signifies confirmed lead generation. It's best not to call a simple transition to a form a “completed lead”. Additional parameters may include button_text, link_url, or the form type, without passing personal data.

Example: Submitting a form

It's best to record form submission after a confirmed successful result. Simply clicking the Submit button doesn't guarantee that the form has been validated and accepted by the server. If the site displays a success message or sends an event to the dataLayer after the server's response, this signal is usually more reliable.

You can pass the form_name parameter or another technical identifier for different forms. Then, a single event is used for multiple forms, and differences are analyzed by parameters. This approach simplifies reports and reduces the number of nearly identical events within GA4.

Example: Scroll depth

Standard Enhanced Measurement records scrolling using its own logic, but content projects sometimes require additional levels. In GTM, you can configure the Scroll Depth Trigger and pass values of 25%, 50%, 75%, and 90%. This data helps you understand how deeply users scroll on a long page.

Creating multiple levels without a goal isn't a good idea, as each event increases the volume of data and complicates analysis. For short commercial pages, it's more useful to track transitions to the form, CTA clicks, or lead submissions. The metric should help inform decision-making, not simply increase the number of events.

How to pass event parameters

Parameters add context to an event. For a click, this could be link_url, for a form, form_name, and for a purchase, transaction_id, value, and currency. Values can be retrieved from built-in GTM, DOM, URL, or dataLayer variables, depending on the website's technical implementation.

Users' personal data should not be passed to GA4 via event parameters. Email, phone number, name, and other identifying information should be excluded from the analytics model. If the dataLayer contains such data for internal website purposes, GA4 variables should select only safe parameters.

Custom Definitions in GA4

A custom parameter can arrive with an event, but for convenient use in standard reports, it's sometimes necessary to register it as a custom dimension or custom metric. Therefore, after successfully sending the parameter, it's important to check how the team plans to analyze this data within GA4.

Not every technical parameter needs to be converted into a Custom Definition. If a value is only used for one-time diagnostics, separate registration may be unnecessary. For regular segmentation, form comparisons, content types, or other business-related analysis, a custom dimension is usually more useful.

What is dataLayer and why is it needed for GA4?

The dataLayer is a structured data layer through which a website can pass events and values to GTM. Instead of trying to read the price, product ID, or order status from visual markup, the developer sends ready-made data in a clearly structured format. GTM receives it via the Data Layer Variable and passes it on to GA4.

A dataLayer may not be necessary for a basic click. For e-commerce, authorization, complex forms, and internal application states, this method is much more reliable than working with the DOM. The query “gtm ga4 datalayer” usually refers to exactly this setup: the site generates the data, GTM processes the event, and GA4 receives ready-made parameters.

How does GTM get data from dataLayer?

The developer sends an object with the event and the required values via dataLayer.push. GTM sees the event name, launches a Custom Event Trigger, and reads the parameters via variables. GA4 Event then receives the ready values and sends them to Google Analytics 4.

A simplified structure might look like this:

event: purchase
transaction_id: 12345
value: 2500
currency: UAH

The main requirement is a stable data schema. If the parameter name constantly changes or some values appear only in specific scenarios, the analytics will begin to diverge from actual user actions.

When can you do without dataLayer?

Simple clicks on stable links, visits to an external domain, and individual interface elements can be tracked using GTM's built-in tools. Click variables, URLs, or standard triggers are sufficient for such tasks. Additional development for each simple event will increase the cost of implementation without providing any noticeable benefit.

The decision depends on the reliability of the signal. If the desired action is clearly defined by the existing markup, a dataLayer is not necessary. If the interface changes frequently or the value cannot be reliably retrieved from the page, it is better to pass it from the application logic.

When is dataLayer needed?

E-commerce requires an accurate set of product, order, and price data. This occurs during successful payment, authorization, plan selection, and other actions where the visual interface doesn't always reflect the actual system state. Here, the dataLayer provides GTM with data directly from the website's logic.

This approach is especially useful for SPAs and complex forms. The user can remain on the same URL even though a significant event has already occurred within the application. A custom event in the dataLayer notifies GTM of this change, regardless of page reloads or element appearance.

GA4 e-commerce via GTM and dataLayer

For e-commerce, GA4 uses a set of recommended events. These include view_item, add_to_cart, view_cart, begin_checkout, add_payment_info, purchase, and refund. Order parameters and an array of products are passed along with these events, if required for a specific event.

Special attention should be paid to the purchase event. The event should be sent after a confirmed purchase and contain a stable transaction_id to reduce the risk of counting the same transaction twice. The value is transmitted as a number, and the currency is a separate currency code.

Consent Mode and privacy when installing GA4

If a website uses a cookie consent mechanism, GA4 and ad tags should be tested alongside it. CMP stores the user's choice, while Consent Mode communicates the consent status to Google tags. Analytics behavior may differ between consent and rejection, so testing should be performed in both scenarios.

During the verification process, it's helpful to use a clean browser profile and consistently check the state before and after making a choice in the banner. Consent settings must comply with the website's actual policy and the cookie categories used. Legal requirements vary by project and region, so technical configuration does not replace legal verification.

If some data has decreased after implementing consent, this doesn't necessarily indicate a GTM error. First, you need to review the actual consent status, CMP operation, and tag firing conditions. Then, check event transmission to GA4.

Server-side Google Tag Manager and GA4

Server-side GTM adds a server container between the user's browser and the systems receiving events. The browser sends a request to the server container, which then processes the data and transmits it further. This architecture requires a separate infrastructure, domain or subdomain, client configuration, tags, and request control.

For a typical small website, starting analytics with server-side GTM isn't necessary. It's more useful to first get the web container, events, dataLayer, consent, and data validation in order. If the project has grown, handles large volumes of e-commerce data, or requires a more manageable server-side approach, then server-side should be considered as a separate step.

How is server-side GTM different from regular GTM?

A standard web container runs in the user's browser. It responds to page events, reads variables, and sends requests to GA4 or other services. A server container runs on the server side and receives requests, which are then processed according to its own configuration.

The diagram looks like this:

Browser → Web GTM → Server GTM → GA4

This option requires more technical support than standard Google Tag Manager Analytics. Therefore, the decision to implement it is made after assessing the tasks, infrastructure, and the data that needs to be transmitted through the server.

When does server-side GTM make sense?

Server-side tagging is more often considered for e-commerce, SaaS, and large websites with sophisticated analytics. Reasons for this include data route control, working with first-party infrastructure, the need for centralized request processing, and a large number of marketing integrations.

Before implementation, it's important to assess the cost of support and technical complexity. Server-side processing won't fix a poorly designed event model. If a purchase is duplicated or the dataLayer passes an incorrect amount, moving processing to the server will preserve the same logical error.

The server_container_url parameter

When linking web GTM and a server-side container, the server endpoint address is used. The server_container_url parameter can be used for this in Google Tag settings. It specifies where the browser should forward the corresponding requests before further processing.

Before changing the route, first check the server container itself, DNS, SSL, and request acceptance. After the switch, retest events in Preview and GA4. For a production project, it's best to perform this migration in stages so you can compare results before and after the route change.

Google Tag Manager and Universal Analytics

Universal Analytics is often found in older instructions for installing Google Analytics via GTM. These materials use the UA Tracking ID, Universal Analytics tags, and the old goal model. This model is not suitable for a new project, as GA4 is the primary, current Google Analytics platform.

The old queries “Google Tag Manager and Universal Analytics”, “GTM Universal Analytics”, or “Tag Manager Universal Analytics” are only useful for understanding the previous implementation and auditing legacy code. If such a tag is found on a live site, it should be taken into account when cleaning the container and checking for duplicates.

Is it possible to install Universal Analytics via GTM now?

Universal Analytics should not be used for the new analytics system. Standard Universal Analytics stopped processing new data on July 1, 2023, and the main project migration has long been completed. The new setup should be built around Google Analytics 4 and the latest tag types.

If old UA tags remain on the site, they can be found during a GTM or source code audit. These elements are checked for unnecessary requests, outdated triggers, and duplicate logic. The relevant events are then migrated to GA4, taking into account the new event model.

Google Tag Manager vs. Universal Analytics – What's Being Compared Wrong?

Google Tag Manager and Universal Analytics belong to different product categories. GTM manages codes and launch conditions, while Universal Analytics was a web analytics system. Therefore, the query “Google Tag Manager vs. Universal Analytics” compares services with different purposes.

A proper modern setup looks like Google Tag Manager + Google Analytics 4. GTM is responsible for the technical implementation of tags and events, while GA4 receives the data and is used for analysis. The same principle helps explain the queries “google tag manager in google analytics” or “analytics tag manager”.

Google Analytics 4 Setup Checklist via GTM

Before completing a task, it's helpful to run through a short checklist. This helps spot errors that might be difficult to spot when checking just one page. This check is especially useful after a website migration, redesign, or changes to form logic.

Please check the following points:

• GA4 property and the required Web Data Stream are created for the correct domain;
• Google Tag Manager container is installed on all required site templates;
• Google tag uses the ID of the desired property and destination;
• The basic trigger fires the tag in the specified scenarios;
• Preview Mode and Tag Assistant do not show unexpected duplicates;
• test events appear in Realtime and DebugView;
• Custom events transmit the required parameters without personal data;
• Enhanced Measurement is not duplicated by custom tags without reason;
• e-commerce events receive the correct value, currency and transaction_id;
• consent is checked before and after user selection;
• old analytics and unnecessary plugins do not send the second set of events;
• The workspace has been saved, tested, and published as a new version.

After publishing, run another full user scenario. For an online store, this could be viewing a product, adding it to a cart, and making a test purchase, while for a service, it could be navigating to a form and submitting a confirmed request. The final test should be performed on the production version of the website.

Google Analytics 4 is more conveniently configured via Google Tag Manager as a sequential system: first, the correct container, then the Google tag, followed by events and parameters. Each new element should be verified before publishing and retested on the production site. This approach reduces the risk of duplicates, incorrect identifiers, and the loss of important user actions.

If your site already has multiple counters installed, legacy UA tags, ad pixels, and a custom dataLayer, it's best to start with an audit of the current configuration. After this, you can create a clean GTM structure, configure GA4, events, e-commerce, and check the data using Tag Assistant, Realtime, and DebugView.

If you need to properly configure Google Analytics 4 via Google Tag Manager, give a specialist access to GA4, GTM, and your test site. After the audit, you can determine which tags to keep, which events to add, and where the dataLayer needs to be improved.