What the server adds to a beacon
The body that leaves the browser is not the record that gets stored. Receipt time, a parsed user agent, and edge headers are added on the way in.
A beacon is a small JSON body. On this site it is a page view, a click, a scroll milestone, or a web vital, plus the personalization profile the browser had at that moment. The browser builds it. POST /api/collect receives it.
What the route stores is not a copy of that body. It is the body plus a server-enriched profile.
Added on arrival
The route records:
- the time the server received the request, which is not the timestamp the browser put on the event
- the clock skew between those two timestamps
- a parse of the User-Agent header: browser, OS, device type
- the forwarding and edge headers that happen to be present: IP, country, region, city
On a local machine most of those headers are empty. The enriched record says so instead of inventing a location. Empty is a result.
Where the two profiles disagree
The page decides mobile versus desktop from the viewport, because that is what the layout actually used. The User-Agent parser on the server may disagree, especially on a desktop browser with a narrow window, or on a phone whose UA does not advertise a device type. The stored record keeps both and writes a reconciliation line. The page does not silently replace the viewport class with the server’s guess.
The client profile is echoed inside the enriched record so you can see the join: what the browser claimed, what the server could see, and which one personalization trusted.
Nothing in that store is durable. It lives in the memory of the Node process and disappears when the process does. That is enough to show the shape of the record. It is not a warehouse.