GA4's default tracking gives you a starting point, but it can't show which links people use or whether they read a page to the end. This tracking foundation in Google Tag Manager (GTM) fills that gap: URL-based content groups, tracking for every link click with its page area and style, scroll depth with a footer event, clean URLs, and a separate property for test traffic. With it in place, many new questions can be answered in Data Studio (formerly Looker Studio) without adding new tracking.
A new GA4 property can start collecting page views, sessions, traffic sources and engagement data almost immediately.
That’s helpful, but it can't answer common questions we regularly investigate:
Which links are visitors using on a particular page?
Are they clicking sidebar CTA buttons or text links?
Do they reach the end of an article?
Which sections of a large website attract traffic?
The best approach is to create a dedicated measurement plan for your data collection. Gather goals and requirements from every team, turn them into events, and test each one. We always recommend this, but it takes weeks, and the site keeps collecting thin data in the meantime.
We also believe every website should have a strong tracking foundation, even before those requirements are fully defined.
After years of working with many websites, we’ve built a standard GTM setup that collects the information we always find useful. This gives us a flexible reporting starting point and helps us spot opportunities that may not have been in the original tracking plan.
Collect useful interaction data before you know every question you'll need to answer.
A well-designed tracking baseline gives you more flexibility when reporting requirements change.
Turn hundreds of URLs into sections
Analyzing a website with hundreds or thousands of pages using individual URLs alone can mask the patterns. Content groups organize pages into meaningful sections and let you compare performance at different levels of the website.
The most durable approach is to build them from the URL. Use GA4's built-in content_group for the first two URL sections joined together (section1_section2), then add a custom dimension for each level: content_group1, content_group2, and so on. Two or three levels are enough for most sites. A manually maintained regex list that maps pages to groups can also work, but only until someone adds a page or moves a section.
Give broken pages a group of their own. A 404 still has a URL, and without a rule that checks for the error page, it lands in a real section and quietly inflates it. With that rule, your sections stay clean, and the content team gets one list of broken links to fix.
For more advanced analysis, you can add page types such as landing pages, articles, events or program pages. Unlike URL-based content groups, page types generally require information from the CMS, such as a dataLayer value or an identifier in the page markup.
One tracking setup, many ways to analyze clicks
GA4's enhanced measurement tracks outbound clicks and file downloads but not clicks that show how people navigate your site. One GTM tag can capture every link click and label it as it happens:
Link text, URL and domain.
Link type: internal, outbound, subdomain, email, phone, contact, social, file, booking or Zoom.
Page area: top menu, body, sidebar or footer.
Link style: menu item, text link or button.
Every value comes from a GTM variable, even the ones that look simple. Most use the If Else If – Advanced Lookup Table, a community template that checks rules in order and returns the first match. Link type, for example, reads the click URL: a mailto: link becomes email, a tel: link becomes tel, a URL containing the page’s own hostname becomes internal, and a known social media domain becomes social. Anything a custom JavaScript variable flags as leaving the site becomes outbound. The order matters, because a link can match more than one rule.
Anything that matches no rule is labelled unknown. In practice, that’s usually broken links or links that run JavaScript instead of opening a page, so the unknown list doubles as a list of things to check.
Link style reads the clicked element’s CSS classes, so a button class becomes button and a navigation class becomes menu.
Link text is usually the visible text, unless the link carries a data-content attribute. We first needed that on a site with a large international audience. Many visitors read it through browser translation, which changes link text too, so one “Apply now” button showed up in GA4 under many different labels. Translation leaves data attributes alone, so adding one to key CTAs gives them a fixed label. Filters and key events, such as apply clicks, then work in every language.
Page area comes from a custom JavaScript variable. The rules themselves are written for each site, because class names, file paths, booking tools and subdomains are different everywhere.
This takes more work than enabling a standard GA4 event, but the extra context makes the data much more useful.
Build reports from the data you already have
Imagine you want to know how many visitors clicked the Donate button in the top menu compared to a banner on a specific page.
Or how clicks on a quick links section compare to those in the main navigation.
Or which calls to action get the most clicks on mobile.
With tracking already in place, you can often answer these questions in Data Studio using filters and calculated fields, without creating a separate GA4 event for each interaction and waiting months for data collection.
The same event data can also power individual scorecards. For example, you can count clicks on donation links, contact links or social sharing buttons, then compare those metrics across reporting periods.
With cross-filtering in Data Studio, selecting a page automatically updates the related click tables. This provides a quick overview of which links visitors clicked from that page, without having to build a separate GA4 path exploration.
The button nobody saw
Click data is also where layout surprises turn up. On one post-secondary site, everyone expected the prominent Book a Tour button in the sidebar to do most of the work. The data disagreed: a plain-text link in the middle of the page content got more clicks.
Mobile explained it. On phones, the sidebar drops to the very bottom of the page, further down than many visitors ever scroll. Microsoft Clarity session recordings confirmed the finding.
Changing the button's colour or wording wouldn't solve the problem, so we recommended moving the sidebar content higher on mobile. Both links lead to the same destination, but their performance tells a very different story.
See how far your audience really goes
GA4’s built-in scroll event fires only once, when a visitor reaches 90% of the page (Google’s documentation on enhanced measurement events). It tells you who nearly finished, but not where everyone else stopped. A GTM scroll trigger at 25%, 50%, 75% and 90% captures the points in between. Once it’s in place, turn off the built-in scroll event in your web stream’s enhanced measurement settings. It fires at the same moment as scroll_90, so it only adds an extra event without new information.
Then add one more event when the footer appears.
The footer marks where the content ends, and on many pages it appears before the 90% mark. Reaching it is the clearest sign that someone has reached the end.
The difference is bigger than it sounds. On one client article, 89 views reached the 90% mark and 202 reached the footer. Counting only 90% would have missed more than half of the full reads.
In Data Studio, put the scroll funnel next to page views and let both follow the selected page. Checking whether an article gets read becomes a one-click job.
The same funnel holds a puzzle: more views reached the footer (202) than the 75% mark (178). Explaining that gap belongs in the scroll deep dive, along with scrolling back up, mobile versus desktop, and how page length skews the numbers.
One page, one row in your reports
If your site already has perfect URL hygiene (redirects in place, lowercase URLs, consistent trailing slashes and no duplicates), skip this part, and maybe give your dev team a high five. Most sites aren't there yet. Trailing slashes are the most common problem we see, followed by capital letters that authors type into internal links.
GA4 treats /Programs and /programs as two pages. The server, on platforms such as Umbraco and Sitecore, serves them as one. The result is a single page split across two or three rows, each holding part of its traffic.
In GTM, normalize the page location before it’s sent to GA4: lowercase, one trailing-slash rule and, when a site tracks several domains or subdomains, one consistent www prefix. Apply exactly the same rules to the referrer, so the previous page in the referrer matches the page as it appears in your reports.
Lowercase the query string too. Campaign links are typed by many different people, and filters in Data Studio are case-sensitive, so ?Category=News and ?category=news would otherwise need two filters.
Merge only what the site itself treats as one page. In its default configuration, Sitecore serves a URL with spaces and the same URL with dashes as one page, so on Sitecore sites spaces become dashes. Umbraco treats them as different URLs, so they stay as they are.
Keep test traffic out of the main property
Real visitors share a GA4 property with everyone testing the site: GTM preview sessions, development and staging servers, localhost, and now and then a stranger's site that copied your GTM container code. Send all of it to a separate GA4 property. Any hit from a hostname that isn't the live site, and any hit in debug mode, goes there. The main property keeps real visits only.
Mark suspicious traffic and add report filters
GA4 filters some known bots automatically, but suspicious traffic can still appear in reports and distort engagement metrics.
One approach that works is a custom traffic type dimension. A GTM variable reads each visitor’s user agent, operating system, and screen resolution, then labels the visit: likely bot, automation tool, monitoring service, in-app browser, or AI browser agent such as Claude or ChatGPT.
The bot rules rely on a set of signals together, never one alone. When we last measured them on a client site, a group of unusual screen resolutions on Windows 10 flagged about 95% of the automated traffic from Singapore and almost all of the zero-engagement traffic from smaller countries. The rules have held up for four months, and the most recent month needed no changes. Once labelled, that traffic can be filtered out of reports in Data Studio. We’ll share more details in a separate post on bot filtering.
The challenge is that bot behaviour changes. Rules that identify suspicious traffic today may become less effective as new patterns appear, which is why we recommend ongoing monitoring and regular updates for clients who need more advanced traffic filtering.
Better reports depend on more than collecting more events.
Consistent page data, reliable interaction classifications, and appropriate traffic filtering are just as important. Without them, even a detailed dashboard can lead to the wrong conclusions.
A tracking foundation that grows with your reporting needs
A standard tracking foundation doesn’t replace a measurement plan. Organizations still need to define their goals, key events, and more specialized tracking requirements.
What it changes is the starting point: those conversations begin with useful data already available, rather than waiting until a question comes up to begin collecting it.