Web tracking records what visitors do on your site and sends those signals to analytics, advertising, and activation tools. It's one of the main ways to build audiences, measure campaign performance, and trigger personalized experiences based on real visitor behavior.
This article covers how to add the base script to your site, classify pages, pass context to tags, and confirm that events arrive correctly. For technical details about the base script and its full command reference, see Base script configuration reference.
What web tracking enables
Web events capture intent in real time, which backend data alone can't always provide. Web tracking supports these specific needs:
Measuring what drives demand: Understand which channels, campaigns, and messages lead to site engagement and conversions.
Building retargeting and suppression audiences: Advertising platforms need event signals — such as "viewed product page" or "started checkout" — to build accurate audiences. Without these signals, targeting different audiences with different creatives is much harder.
Triggering experiences based on intent: Many personalization and lifecycle use cases start from website behavior, because it reflects intent before a visitor is identified.
Web events are tied to an anonymous visitor until an identifier becomes available. If a visitor later logs in or submits a form, your setup can connect their earlier activity to a known profile.
How web tracking works
The web tracking pattern is consistent across implementations:
A small snippet runs in the browser.
The snippet records key interactions as events.
The snippet forwards those events to analytics, advertising, and activation tools.
Web events are tied to an anonymous visitor until an identifier becomes available. If the visitor later logs in or submits an identifier, your setup can connect the activity to a known profile.
Most web events include:
Event name and timestamp
Page or screen context
Browser or device identifier
Product or content identifiers, when relevant
Acquisition context, such as referrer or UTM parameters
Customer identifier when available after login or form submission
Common concepts:
Pixels are tracking tags that send events to a specific vendor (for example, Meta Pixel). They measure conversions, build retargeting pools, and train ad delivery algorithms.
Tag managers are tools used for deploying and managing website tags without changing code. Google Tag Manager is the most common example. They help marketing teams move faster, but can lead to uncontrolled tag growth if governance is weak.
Recommended starter events
At a minimum, track these events to support common activation use cases:
Event | When to fire | Key properties |
|---|---|---|
| Every page load | Page structure, URL |
| Product detail page | Product ID, category |
| Item added to cart | Product ID, quantity, value |
| Checkout initiated | Cart value |
| Order confirmed | Order ID, order value |
| User authenticates | Customer ID (hashed if needed) |
Example: anonymous visitor retargeting
A retailer wants to retarget visitors who viewed a product but did not buy:
The site tracks product-view events with a product ID and timestamp.
The visitor remains anonymous, but the site still records their behavior.
You have defined an audience as "viewed product in the last 3 days and no purchase".
The platform pushes that audience to an ad platform for retargeting.
If the visitor later becomes known, the same behavior can support personalized journeys.
Effectiveness depends on what identifiers are available and how well the destination can match them.
How the base script loads
The base script loads asynchronously. This means it doesn't block your page from rendering while it downloads. The browser continues building the page, and the basescript runs as soon as it's ready.
This approach keeps your site fast. The snippet creates a small queue in the browser's memory. Any commands you add before the basescript finishes loading are stored in this queue. Once the basescript is ready, it processes the queued commands in order. Commands you add after loading run immediately.
All interaction with the basescript goes through the global command-function _st. You call it by passing a command name and its arguments:
_st('setEnvironment', 'test');The _st function uses a queue mechanism:
Before the basescript loads: Commands are stored in an internal queue. The function returns immediately without waiting for execution.
After the basescript loads: Commands run synchronously as soon as you add them.
This means you can safely place _st calls anywhere on your page. They'll always execute, whether the basescript has loaded or not.
Word of caution about browser scripts
Browser tracking has real limitations that should be planned for. Too many tags can slow page load times and increase bounce rates. Ad blockers, tracking prevention, and script failures all reduce data completeness. And scripts that run without consistent consent handling can create compliance risks.
This doesn't mean browser tracking is obsolete. Many teams pair it with server-side collection for critical signals and apply governance to keep the tag footprint small.
Before you begin
Make sure that you have the following details needed to set up web tracking:
Access to edit your website's HTML or tag manager configuration
The base script snippet is provided during platform onboarding.
You and your team have agreed on a page structure naming convention.
You know which environments you need (test and production).
Instructions
Step 1: Add the base script to your site
Add the base script snippet to every page where you want to collect data. Place it in the <head> element, above any other external resources, including stylesheets.
(function(a, d, e, b, f, c, s) {
a[b] = a[b] || function() { a[b].q.push(arguments); };
a[b].q = [];
c = d.createElement(e);
c.async = 1;
c.src = "//tdn.r42tag.com/lib/" + f + ".js";
s = d.getElementsByTagName(e)[0];
s.parentNode.insertBefore(c, s);
})(window, document, "script", "_st", "1661-v1");
// Add additional settings here (optional)
_st("loadTags");
Replace 1661-v1 with your site's base script version. Contact your support representative to find the correct version.
Follow these implementation guidelines:
Embed the base script through a single shared include file or component to prevent it from loading twice on the same page.
Add a server-side switch to disable the script quickly if needed, for example, during a security incident, to remove all tags and stop unexpected costs.
Store the script version in a server-side variable to simplify future upgrades.
Step 2: Set the environment (optional)
Set the environment to control whether you're in test or production mode. If not set, the system defaults to the production environment.
Use test during initial setup and QA. Switch to production when going live.
_st('setEnvironment', 'test');Step 3: Set the page structure
Page structure classifies the current page using a predictable hierarchy. This controls which tags load and makes rules easier to maintain.
_st('setPageStructure', 'product|details');Follow these patterns:
Keep the first level broad:
homepage,category,product,checkout,account.Add detail only when it changes what should load (for example,
checkout|paymentvs.checkout|confirmation).Use the same names across markets and brands.
You can set a default fallback for pages that are hard to classify:
_st('setDefaultPageStructure', 'generic|content');Step 4: Add tag properties
Tag properties contain additional context for the current pageview. Use them for locale, site section, or other non-sensitive page context.
_st('addTagProperties', { country: 'fi', language: 'en' });Don't pass any personally identifiable information to the service, such as:
Email addresses, phone numbers, or direct identifiers
Sensitive customer attributes
Anything not needed to run tagging rules
For single-page applications, reset the context before setting new properties:
_st('resetTags');Step 5: Trigger tag loading
After setting the environment, page structure, and properties, trigger tag loading:
_st('loadTags');Complete example for a product details page:
_st('setEnvironment', 'test');
_st('setPageStructure', 'product|details');
_st('addTagProperties', { country: 'fi', language: 'sv' });
_st('loadTags');Verify the setup works
After the setup is complete, confirm that events are arriving:
Open your browser's developer tools and check the Network tab for requests to the platform endpoint.
Verify that page structure and properties appear correctly in the request payload.
If not, you may have inconsistent page naming. To fix this, compare the values across pages and teams.
In the Data activation platform, check that events appear for test profiles.
If the events aren't appearing, it's likely the script isn't loading. Check for script errors in the browser's developer tools console.
If the properties are missing, check the call order in your setup and verify that the properties are set before loadTags.
If you see duplicate events, the script may have loaded twice. Check that the script loads just once.
If the events are in the wrong environment, check that you have set the correct environment and that setEnvironment is called before loadTags.
Confirm that audiences based on these events start populating as expected.
See How to test and roll out web tracking.
Common pitfalls
Your data activation is only as reliable as your data is. The following issues are common in web tracking, so be on the lookout for these:
Key events are missing (for example, purchase confirmation), leading to stale retargeting.
IDs are inconsistent between web events and backend systems.
Your team adds too many tags without governance, hurting performance.
Your setup expects cross-device continuity without deterministic identifiers. Without merged profiles, you won’t be able to identify users across sessions or across devices, which hampers your ability to target and personalize