Security and data handling

Last updated: 13 August 2026

This page describes what we actually do, taken from the running code rather than from an aspirational policy. Where we do not have something, it says so plainly. If a control you need is missing here, assume we do not have it and ask.

What we can read, and how you grant it

Two optional connections let us read data you already own. Both are read-only, both are granted by you inside Google, and both are revoked by you inside Google without involving us.

We use service-account delegation, not OAuth. That means we store no access token and no refresh token for your Google account, and there is no long-lived credential of yours in our database to leak. You add one named service-account address as a viewer on the specific property you choose. Access is limited to that property, and removing the address ends it immediately.

Neither connection can write anything. We never post, never modify a property, and never read a property you have not named.

What we store, and for how long

The measurement data is the questions you track, the answers the engines gave, and the figures derived from them.

Credentials we issue

Outbound connections

If you configure a webhook, we send events to it. Those requests are HTTPS only, signed with a shared secret so you can verify they came from us, and refused if the destination resolves to a private or internal address. Repeated failures disable the endpoint rather than retrying forever.

Event payloads carry no credential. A webhook destination is often a shared channel, so anything we send should be assumed to sit in that channel's history. Where an event points at your data, it carries the address and not the key.

Publication is off by default

Nothing about your measurement is public unless you switch it on. The embeddable score card and the emailed export are both opt-in and both start off. Signing up is not consent to publish anything, and a shared client report shows only what that switch allows.

What we do not have

Stated because a security page that lists only strengths is not useful to somebody doing diligence.

If any of these is a blocker for your organisation, say so before you buy rather than after. We would rather lose the deal than describe a control we do not operate.

Reporting a problem

Email [email protected] with anything that looks like a security issue. We would rather hear about it early and awkwardly than late and politely. If you are unsure whether something counts, send it anyway.