Event tracking versus page view tracking
Traditional analytics counted page views, which said little about what a person actually did on the
page. Event tracking records specific actions inside the page — clicks, scrolls, form fills,
widget interactions.
In GA4 a page view is itself an event (page_view). The whole model is event-based, which unifies
the two approaches.
The structure of an event
An event has several components:
// An enhanced ecommerce event
gtag('event', 'add_to_cart', {
currency: 'USD',
value: 89.90,
items: [{
item_id: 'SKU-12345',
item_name: 'Nike Air Max sneakers',
item_category: 'running-shoes',
price: 89.90,
quantity: 1
}]
});
| Component | Description | Example |
|---|---|---|
| event_name | The action type | add_to_cart, purchase |
| parameters | Contextual data | item_id, price, category |
| user_id | The user identifier | Authenticated or anonymous |
| timestamp | The time of the event | Automatic |
What personalization needs in an event
Personalization platforms train on events. The richer the payload, the better the model:
- item_id — mandatory; without it a view cannot be tied to a product
- item_category — critical for affinity profiles; a shopper is interested in sport, not simply
in products - price and revenue — for RFM segmentation and monetary metrics
- session_id — to connect the events of one visit
Important: for a personalization platform, a purchase event without item attributes is
worthless. The system cannot update the profile or adjust recommendations if it does not know what
was bought.
Common mistakes
- Duplicated purchase events. The thank-you page reloads and the event fires twice. The fix is
deduplication by order ID. - Lost events in a single-page app. Navigation without a reload fires no automatic page view;
events have to be sent explicitly on a route change. - Tracking with no item_id. An add-to-cart event with no product identifier is noise rather than
data.