A tiny client component mounted once in the app shell. It sends a path and a title on every route change and nothing else. The endpoint ignores anyone who is not platform staff, so it is inert for customers.
Also called: page view audit · what did support look at · read trail · snooping detection
- 1On mount and on every hash or history change it sends the current path.
- 2Repeated identical paths are skipped, so it writes one row per screen rather than per re-render.
- 3The request uses keepalive, so a click that navigates away still delivers the row it was about to write.
- 4Rows join the audit log as 'Viewed a screen' events and feed the session grouping.
The component says why it is deliberately dumb: 'the audit question is "did they open this customer's contacts", which a route answers, and anything richer would mean copying customer data into a second store to answer a question nobody asked.' API traffic says what staff touched; this says what they READ, 'which is the half an audit of snooping depends on' (mig 216).
- Hash routing meant screen navigation never reached the server, so reads were invisible.
- A write-only audit cannot detect someone browsing data they had no reason to see.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →