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.