The GA4 data model: events, parameters, and why everything is an event

Part 1 flagged the core shift from Universal Analytics: GA4 has no separate, special category for a pageview versus any other interaction. This part covers what that actually means structurally — every single thing GA4 records, from a page loading to a purchase completing, is the exact same kind of object: an event, with parameters attached describing its specific details.

An event, structurally

Event name: purchase
Parameters:
  currency: "USD"
  value: 45.00
  transaction_id: "BLC-10293"
  items: [{ item_id: "BLC-002", item_name: "Gift Subscription", price: 45.00 }]

The event name (purchase) identifies what kind of thing happened; the parameters attached to it carry every specific detail about that particular occurrence. A page_view event is structurally identical in shape — just a different event name with different parameters (page_location, page_title) attached to it.

The four real event categories

Automatically collected: triggered by GA4's base tracking itself
  (first_visit, session_start)
Enhanced measurement: the part 2 defaults (scroll, click, page_view,
  video_start) — on automatically, no custom code required
Recommended events: GA4's own predefined names for common actions
  (purchase, sign_up, generate_lead) — Google recommends using these
  exact names for consistent reporting across GA4's built-in reports
Custom events: anything specific to a particular business that doesn't
  fit a recommended event, defined and named entirely by the implementer

Using a recommended event name where one exists — purchase instead of a custom bought_something — matters directly: GA4's own built-in e-commerce reports (part 9) are built to recognize these specific standard names automatically, and a custom name for something that already has a recommended equivalent means losing that automatic reporting entirely.

A real, complete purchase event for Bright Leaf Coffee

Event: purchase
Parameters:
  transaction_id: "BLC-10293"
  value: 45.00
  currency: "USD"
  items: [
    { item_id: "BLC-002", item_name: "Gift Subscription", item_category: "Subscriptions", price: 45.00, quantity: 1 }
  ]

This exact structure — a recommended event name, standard parameters, and an items array with real product-level detail — is what powers every e-commerce report covered in part 9. Missing transaction_id specifically risks duplicate-counting the same purchase if the event accidentally fires more than once; missing items entirely means no product-level breakdown is possible at all, even though the total revenue would still be recorded correctly.

User properties: attached to a person, not one event

User property: customer_type = "subscriber"

Distinct from event parameters, a user property persists across every event a specific person triggers, not just one — useful for segmenting reports by something durable about the visitor themselves ("subscriber" vs. "one-time purchaser"), rather than something specific to a single interaction.

Why this model matters for real analysis

Question: "How many people scrolled past 75% of our storage/freshness
blog post, but never clicked through to the shop?"

Because scroll depth and outbound clicks are both just events with parameters, in the exact same underlying structure as a purchase, GA4's exploration reports (part 12) can genuinely cross-reference them together — this kind of specific, cross-event question would require substantially more custom setup under Universal Analytics' older, session-and-pageview-centric model.

Next: actually installing the tracking that generates these events — gtag.js and Google Tag Manager, and how the two relate to each other.