The role of the Event API in personalization
A recommender knows only what it was told. A lost event means the model does not know about a
product view, does not account for an abandoned cart, does not see a purchase. The Event API is the
channel that data arrives through.
Each event describes one fact: who did what, when, and in what context.
{
"event_type": "add_to_cart",
"user_id": "u_12345",
"anonymous_id": "sess_abc",
"timestamp": "2026-11-15T14:32:01Z",
"item_id": "sku_98765",
"item_category": "running-shoes",
"price": 89.90,
"quantity": 1
}
The platform processes that stream in real time: updating the affinity profile, recomputing
segments and preparing refreshed recommendations for the next page.
Event types in e-commerce
| Event | Signal to the system | Weight |
|---|---|---|
| view | Interest in an item | Weak |
| wishlist_add | Intent to buy | Medium |
| add_to_cart | Strong intent | Strong |
| purchase | Confirmed demand | Very strong |
| search | Active need | Medium |
| review | Post-purchase experience | Medium |
Integration patterns
Client-side. A snippet on the page intercepts interactions and sends events straight from the
browser. Simple to integrate, but vulnerable to blockers — 15–30% of users in some audiences — and
to losses on slow connections.
Server-side. The backend sends events after processing a transaction. Reliable for critical
events: a purchase cannot be lost to a UX problem. Harder to integrate, and it needs backend access.
Hybrid. Client-side for behavioural events, server-side for transactional ones. The usual
balance between reliability and integration effort.
Important: for conversion attribution in A/B tests to work, the purchase event must carry the
session or experiment identifier. Without it the purchase cannot be attributed to a variation.