Problem
A CloudFront access log records what arrived and what was answered. It has no way to record how long a page took to settle, which element was the largest one painted, or that a script threw. Those are the measurements the beacon exists to add, and AGENTS.md names them beside route changes as the point of layer 2.
Current behaviour
The envelope carries three parameters, v, e and p. An event name and the page it happened on fit inside it. A web vital carries a number as well, and #100 left what each event type puts beside the envelope to the beacon's own issue.
Nothing collects any of this yet. It goes in the browser module #111 builds, and this is blocked on that.
Desired behaviour
The beacon reports Core Web Vitals and uncaught JavaScript errors as events, each carrying whatever it needs beside the envelope. A later rollup can then read a percentile out of the vitals and count errors by message.
What to decide
What a value looks like in the query string. A vital is a number and an error is a message with a stack. beaconVersionColumn and its neighbours each read one named parameter, so a new field is a new parameter and a new SQL reader beside them.
When each is sent. LCP and CLS settle late and a page can be closed before they do. visibilitychange is the usual answer, and it is a second thing the module has to hold on to.
Whether an error message is personal data. A stack trace carries URLs and sometimes more. #98 exists because a deployment can choose to hold none, and a site that made that choice should not get it back through the beacon.
Acceptance criteria
Out of scope
A rollup over the vitals, which is worth its own question once the rows exist.
Problem
A CloudFront access log records what arrived and what was answered. It has no way to record how long a page took to settle, which element was the largest one painted, or that a script threw. Those are the measurements the beacon exists to add, and AGENTS.md names them beside route changes as the point of layer 2.
Current behaviour
The envelope carries three parameters,
v,eandp. An event name and the page it happened on fit inside it. A web vital carries a number as well, and #100 left what each event type puts beside the envelope to the beacon's own issue.Nothing collects any of this yet. It goes in the browser module #111 builds, and this is blocked on that.
Desired behaviour
The beacon reports Core Web Vitals and uncaught JavaScript errors as events, each carrying whatever it needs beside the envelope. A later rollup can then read a percentile out of the vitals and count errors by message.
What to decide
What a value looks like in the query string. A vital is a number and an error is a message with a stack.
beaconVersionColumnand its neighbours each read one named parameter, so a new field is a new parameter and a new SQL reader beside them.When each is sent. LCP and CLS settle late and a page can be closed before they do.
visibilitychangeis the usual answer, and it is a second thing the module has to hold on to.Whether an error message is personal data. A stack trace carries URLs and sometimes more. #98 exists because a deployment can choose to hold none, and a site that made that choice should not get it back through the beacon.
Acceptance criteria
beacon-events.test.tscovers the envelope.docs/says what is collected, and what a site holding no personal data gets.Out of scope
A rollup over the vitals, which is worth its own question once the rows exist.