The Word Everyone Defines Differently

Links on a page used to be simple - a plain HREF, maybe a title or a class, and that was the whole job. Now every interaction on a page, across pages, and across domains gets asked to tie back to a campaign, a project, or a sprint. With that much capability available, it would be reasonable to assume answering "how many times was that clicked" is simple. It isn't.

"Link" used to mean underlined text or an image that took you somewhere else. Browsers and devices now support real-time, interactive functionality that goes far beyond that original definition. The word has become an umbrella term for far more than an anchor tag, and the gap between the old definition and the current reality is where the actual work happens.

Why the Same Page Gets Described Three Ways

Getting a large group of people, spread across different teams, aligned before a release is difficult on its own. Today's web treats every "touch" or "click" on a page, in an application, or on a kiosk as fair game for the word "link" - and that word now covers all of it.

Defining a measurement request that actually answers a business question means first understanding how the people asking it think. Ask a developer, an analyst, and a stakeholder what a "link" is, and each will answer differently, even looking at the exact same page. What each person believes a link is says a lot about how well they understand the thing they're asking to have measured.

Links, Broadly Defined

To the business, everything is a link. True HREFs, of course, but also anything that acts like one - buttons, divs, spans, and other elements a developer would never personally call a link.

The HTML attribute is a strong tool for untangling this, and so is a data layer - but neither is a complete answer on its own. Used together, with the ability to update metadata in real time within the application, they answer the original question and the ones nobody thought to ask yet.

A single-page application makes this especially visible: there are many different ways to capture the same interaction, and no universal answer that fits every environment. The pieces are dynamic, and they don't hold still.

Two Halves of the Same Approach

The HTML attribute and the data layer aren't competing solutions - they're two halves of the same approach. Used separately, each one breaks the moment the page changes. Used together, with the ability to update metadata in real time, tracking stops depending on the DOM and starts depending on intent.

That's the actual definition of analytics architecture: a layer built to survive the site around it, not one rebuilt every time the site changes. The solution still has to be worked out per feature, per request, per business definition of "link." What doesn't have to be reinvented every time is the architecture underneath it - and that consistency, not a universal template, is what makes the answer repeatable.

Common Questions

Isn't a data layer just another name for tracking code?

Not quite. Tracking code reads from the data layer - it doesn't replace it. The data layer is the structured, consistent source of truth; the tracking code is what consumes it and sends it somewhere useful.

Does every project need a full architecture like this?

A small, static site can often get by on HTML attributes alone. The case for a real data layer grows with the number of dynamic elements, teams, and one-off tracking requests a site has to support over time.

What happens when the page itself changes?

That's the exact failure this architecture is built to avoid. Tracking tied only to the DOM breaks the moment a selector or layout changes; tracking tied to intent through a maintained data layer keeps working through most redesigns.

Who should own the definition of a "link" on a project?

No single role should own it alone. The definition needs input from whoever builds the page, whoever analyzes the data, and whoever's asking the business question - otherwise it ends up reflecting only one of those three perspectives.

An Architecture That Survives the Next Redesign

If "how many times was that clicked" keeps getting a different answer depending on who's asked, that's usually a sign the architecture underneath hasn't been defined yet.