Tracking lab
Server events
crm-events-node from a server action: publish, profile upsert, and what rejected and fallback look like.
Lane B · Server-side eventsTry it
Awaited, so the console gets the status and event ID.
Sets the custom property PocLabLastSeen to now. Needs crm-events-delivery 0.2.0 with profiles:write to reach Klaviyo.
An event with an empty name: rejected before anything is sent.
A one-off publisher with a 1 ms budget: the event goes to the fallback log instead of the bus.
How it works
Lane B: this site's server code calls crm-events-node, which publishes to the AWS backbone (crm-events-infra); crm-events-delivery takes it on to Klaviyo. The browser only presses the button: who the event is for comes from the shop's persona cookie, never from the page.
crm-events-node never throws: every call ends in a status. These buttons show four of them.
What to expect in the console
- published with an event ID: on the bus. The event ID is the one Klaviyo deduplicates on.
- rejected: invalid input; the reason names the field (here
name). Nothing sent, nothing in the fallback log. - fallback: couldn't send in time; the payload holds the fallback record a replay would use.
- dry-run or skipped: the shop is in dry run, or no event bus is configured here.
More lane B
The shop's checkout, backstage and account profile update all use this route. /crm-timing measures how long publishing takes.