Monitoring

Roles and permissions

Read-only is a real role, and it is enforced once at the door rather than screen by screen.

Member is read-onlyEnforced centrallyOne exception

Members can see everything on the account and change nothing. Admins and owners can create, edit and delete. That is the whole model, and its simplicity is what makes it safe to give an account to everybody who wants to look at a result.

It is enforced in one place, at the point every authenticated request passes through, rather than route by route. An unknown role is denied rather than allowed. That matters more than it sounds: a permission model applied per screen is a model where the next screen somebody builds is quietly the exception, and nobody finds out until it matters.

There is exactly one carve-out, and it is deliberate: a read-only member may mark their own notifications seen or read. A notification badge somebody cannot clear is not a badge.

Authentication and authorisation are kept apart on purpose. Whether a role may write at all is one question, answered centrally. Whether a particular experiment or website belongs to you is a different one, checked per resource. Merging them is how a model becomes impossible to reason about.

Better experiments, better conversions

Test on all visitors with the world’s lightest script and make confident decisions powered by real-time reporting.