How Google Analytics and Google Tag Manager Actually Work

A Measurement ID looks like G-4XKQ2P8LM3 and identifies one Google Analytics 4 data stream. It is the address every event is stamped with so the data lands in your property rather than someone else's. A GTM container ID looks like GTM-K9QW4ZT and identifies the Tag Manager container installed on your site, which is the box holding your tags, triggers and variables. They are separate identifiers issued by separate products. The container ID never replaces the Measurement ID: when you set GA4 up through Tag Manager, the Measurement ID is still required, entered as the Tag ID on the Google tag inside the container.

The browser reads the page from the first line to the last. When it reaches the script tag in the head, it treats that line as an instruction: it downloads gtag.js from Google and runs it. The running script then uses a mechanism called events. Noticing that a page has been viewed, it creates an event named page_view in the browser, attaches parameters such as page_location, page_title, client_id and session_id, and dispatches it as an ordinary web request to Google's collection endpoint with the Measurement ID in the query string. Google answers 204 No Content, the property recognises the event name, and the page_view counter increases by one. Every number in a Google Analytics report is the sum of events that completed that journey.

Because the script only runs on pages that contain it. There is no crawling, no site-wide registration, and no way for Google Analytics to observe a page it was never told about. A page missing the snippet produces no page_view, no session data and no events, and it will also break attribution for the journeys that pass through it. This is why the first question in any analytics audit is whether the tag is present on every template, including checkout steps, thank-you pages, error pages and anything rendered by a different system.

A WordPress site uses a plugin to do the copying. A header-and-footer injector, Site Kit, or a similar plugin takes your Measurement ID and writes the snippet into the theme head on every render, so you do not edit template files by hand. That is a convenience for the person managing the site, not a different mechanism for the browser: the browser still reads a line, still fetches the script, still builds a page_view, and still posts it. The same is true of a large AI-generated site or any framework-rendered site.

Because nothing in that setup decides when to fire or what to send. The gtag snippet reports the things it was built to notice, principally page views and the enhanced measurement events. When a visitor clicks a button and lands on the next page, Google Analytics records a second page_view, but nothing records that a button was clicked, which button it was, or what it said. You can infer it from the destination page's view count, but that inference breaks the moment anyone reaches that page another way. Measuring your own interactions requires either custom JavaScript written for each one, or a tool sitting in that position, which is what Google Tag Manager is.

Yes. If the gtag snippet stays in the page head while Tag Manager also loads Google Analytics, both will report, and every page view arrives twice. That inflates views, distorts sessions and engagement, and quietly corrupts every downstream report and audience. Delete the snippet from every page, upload the files again, and accept that the site measures nothing for the few minutes between removing the direct install and publishing the GTM version.

Any action breaks into three questions: when does it happen, what should happen, and what extra detail is needed. A person needs to reach the office at 9 AM to start a board meeting: when is 9 AM, what is reach the office, and the extra detail is that the meeting is called Board Meeting. In Google Tag Manager those three questions are three menu items. Triggers configure the when. Tags configure the what. Variables supply the extra information, whether that is a value to send or a condition to check. A tag with no trigger never fires and a trigger with no tag does nothing, so the two are built separately and then attached.

Run the framework on it. What: load the GA4 tag on all pages. When: whenever a page loads in the browser. Build the trigger first, because a tag cannot be saved usefully without one: trigger type Page View, firing on All Page Views. Note that the trigger says nothing about Google Analytics, because a trigger only ever answers when. Then build the tag: type Google Tag, with the Tag ID set to your GA4 Measurement ID, and attach the All Pages trigger under Triggering. Save, test it in Preview mode, and submit.

Preview opens Tag Assistant and loads your site in a debugging window connected to your workspace. A Connected status proves the container is present on the page and receiving events, which is the site-to-GTM half of the wiring. It does not prove anything reaches Google Analytics: a freshly installed, empty container shows events arriving and zero tags fired, and that is correct rather than broken. Once tags exist, the summary shows which fired on each event and what the variables resolved to, and GA4 DebugView confirms the event arrived at the property.

Because Preview runs your unpublished workspace, and real visitors run the last published version of the container. Everything you build exists only for you until you click Submit, name the version and publish it. Forgetting that step is the most common cause of a setup that tests perfectly and collects nothing in production. It is worth confirming the version number and publish time in the container's Versions screen after any change you expect to see in reports.

Use the Click - Just Links trigger type if the button is an anchor, or Click - All Elements if it is a button element. Left on All Link Clicks it fires for every link on the site, so choose Some Link Clicks and add a condition that identifies your button, such as Click ID equals cta-button. That condition depends on the button carrying a stable id or class in the HTML, which is why those attributes matter long before anyone opens Tag Manager. Keep Wait for Tags enabled so the navigation is held briefly and the event has time to leave the browser before the page changes.

Set the tag type to Google Analytics: GA4 Event, point it at the same Measurement ID, and give it the event name you want to see in reports, such as button_clicked. Event names should be lowercase with underscores and consistent across the site. The event parameters are the extra information from the framework and are filled by variables that GTM resolves at the moment of the click: button_id from {{Click ID}}, button_text from {{Click Text}}, link_url from {{Click URL}}. Attach the click trigger you built, save, preview, click the button on the live site, confirm the tag fired with the expected values, then submit and publish.

Yes. If page views are genuinely all you need, a direct gtag install is simpler, has one less moving part, and is perfectly legitimate. The reason to move to Tag Manager is the second requirement: the moment you want to measure a button, a form, a scroll, a video or a purchase, or to add a second marketing tool, you need something that can decide when to fire and what to send without a developer editing files each time. Adopt GTM when that need arrives, not because it is the expected answer.

Everywhere, using the same four screens. Form submissions, scroll depth, video engagement, file downloads, ecommerce steps, consent handling and server-side tagging are all the same procedure asking the same three questions about a different action: when does it happen, what should be sent, and what extra detail belongs on it. The interface does not change and the mechanism does not change. What grows is the discipline around it: consistent event names, a documented tracking plan, and testing each addition in Preview before publishing.