The browser as an execution environment — what it observes, what it can send, and why it stays relevant in modern architectures.
Browser-side tracking occurs when measurement code runs inside the visitor's web browser. It is also called client-side tracking. The browser is an execution environment: when someone loads a webpage, the browser downloads the resources needed to render it — HTML, CSS, JavaScript, images, fonts, analytics libraries, marketing pixels, and tag management containers. JavaScript then responds to activity on the page.
It can detect actions such as page loads and virtual page views, button and link clicks, form submissions, video interactions, product views and add-to-cart actions, and checkout and purchase confirmations displayed in the browser.
Imagine a visitor clicks Add to Cart. The website updates the cart, changes the user interface, and may generate a browser event. A pixel, JavaScript SDK, analytics library, or web GTM container can then send information about that event to one or more destinations. The deciding factor is not which tool manages the tag. The deciding factor is where the code executes. If the visitor's browser detects and transmits the event, it is browser-side tracking.
What the browser may send depends on the implementation, destination, and consent state: event name and timestamp, current URL, page title, and referring URL, campaign and click parameters, product, cart, value, and currency data, browser or platform identifiers, user-provided identifiers when appropriate and permitted, and consent signals.
Calling browser-side tracking "legacy" is misleading. The browser is often the most direct place to observe immediate on-page interactions and capture context at the moment it appears. Modern architecture is not about abandoning the browser. It is about deciding which responsibilities belong there and which belong elsewhere.