Beyond the page view

Early web analytics counted one thing: page views. That answered "how many people saw this page" and nothing else - it was blind to everything that happened between loading a page and leaving it. An event is the fix: a record that a specific interaction occurred - a button click, a video play, a form submission, a scroll to the bottom.

The shift is now total. In GA4 and every modern tool, everything is an event - even a page view is just an event named page_view. Grasp the event and you have grasped the atom the rest of marketing analytics is built from, including the conversions that measure outcomes.

The shape of an event

An event is two things: a name and a set of parameters. The name says what happened; the parameters carry the detail:

gtag('event', 'add_to_cart', {
  currency: 'USD',
  value: 49.00,
  items: [{ item_id: 'SKU-42', item_name: 'Trail Shoe' }]
});

The name (add_to_cart) is the verb; the parameters (value, items) are the context that makes it analyzable - so you can later ask not just "how many add-to-cart events" but "what was the total value" or "which item most often." An event without good parameters is a tally; an event with them is data you can slice.

Automatic and custom events

Events come from two places:

  • Automatic events - things the analytics library collects out of the box once installed: page views, first visits, scrolls, outbound clicks, file downloads. Free, but generic.
  • Custom events - the ones you define and fire for actions specific to your product: sign_up, start_trial, upgrade_plan. These are where the real insight lives, because only you know what matters in your funnel.

The practical work of instrumenting a site is deciding which custom events to fire and placing the calls at the right moments. Too few and you are blind to your own funnel; too many and the data becomes noise no one reads.

The data layer

Firing gtag() calls scattered through your code gets unmaintainable fast, so most teams use a data layer - a single structured object the page pushes events onto, which a tag manager reads and forwards:

// the app pushes a plain object; the tag manager decides where it goes
window.dataLayer.push({
  event: 'sign_up',
  method: 'google',
  plan: 'pro'
});

This decouples the app from the analytics tools. Your code announces "a sign-up happened" once, to the data layer; whether that goes to GA4, an ad platform, or three tools at once is configured in the tag manager, not re-coded in the app. It is the same separation-of-concerns instinct that makes good software - the page reports facts, the plumbing decides where they land.

From events to conversions

Events are the raw material; a conversion is an event you have marked as a goal. In GA4 you flag an event like sign_up or purchase as a key event, and it graduates from "something we track" to "something we measure success by" - the number tied back through UTM to the campaign that drove it.

So the chain of the whole measuring story is: instrument events → mark the important ones as conversions → attribute them to a source. Analytics events are step one, the foundation the other two stand on. Get the events right and the rest of the funnel becomes measurable; get them wrong and no attribution model can save data that was never captured.

The discipline of naming

The failure mode is the same as it was for UTM values: inconsistency. If one page fires sign_up, another signup, and a third SignUp, your reports fracture into three half-truths. A shared, written tracking plan - the list of event names, their parameters, and when each fires - is what keeps analytics trustworthy across a team.

Prefer the platform's recommended event names where they exist (GA4 has a standard set like purchase and login), reserve custom names for genuinely custom actions, and lowercase-with-underscores everything. It is unglamorous governance, and it is the difference between analytics you act on and analytics you argue about.

References