Privacy Policy
Last updated 4 October 2026.
Rubric is operated by Things Reklam ve Bilişim Hizmetleri Tic Ltd Şti, a limited liability company incorporated in the Republic of Türkiye, which is the controller of the personal data described here. Write to help@rubric.design about anything on this page.
The short version
We collect what running a metered API requires and nothing else. Our public pages use our own cookieless analytics (described below); there is no advertising, no third-party trackers and no tracking cookies — which is why you have never seen a cookie banner here. We do not sell or share personal data, and we do not use your audits to train anything.
Through MCP, your own agent does the looking. When you start a managed run instead, our worker opens the site you named in its own browser, shows what it sees to an AI model, and keeps the screenshots and report the run produces.
What we collect
| What | Where it comes from | Why |
|---|---|---|
| Email address, name and avatar URL | Google or GitHub, when you sign in | To identify your account and contact you about it |
| API keys, stored only as a hash | Created by you in the panel | To recognise a key on a call. The key itself is shown once and never stored, so we cannot recover it for you or for anyone else |
| Usage events — which tool or run, when, and what it used of your plan | Your calls | Metering, billing, the free-tier limit, and abuse detection |
| Audits — the URL, vertical and label you give | You, via create_audit |
To store the audit and produce its report |
| Observations you submit against an audit | You, via submit_findings |
To resolve them into findings and keep the report readable later |
| Annotated screenshots your agent captures and uploads against a finding | You, via create_annotations |
To show the evidence for a finding in your panel and in the report you download |
| Managed runs — the URL, the pages you pick, whether the site needs a login, and for user simulation the persona and goals you describe | You, when you start an audit, heatmap, user simulation or site analysis in the panel | To run the job you asked for and keep its result |
| What a managed run sees — the text and structure of the pages it opens, full-page screenshots at desktop and mobile width for a heatmap, a screenshot per simulation task, and small step images of what the agent is looking at | Our worker’s browser, opening the site you named | To produce the report and to show the run live while it works |
| Run results — findings and annotated screenshots for an audit, the attention overlay for a heatmap, the persona’s tasks, answers and think-aloud notes for user simulation, and the list of pages a site analysis found | Our agent, from what the run saw | To show you the report and let you download it |
| Plan and payment records — your plan, term, amount, currency, provider identifiers. No stored balance is kept | The payment provider, after a payment | To run your plan and to keep the accounts |
| Connected applications, if you sign in an agent with OAuth | The authorisation you gave | So you can see and revoke them |
A screenshot is a copy of whatever was on the screen. If your agent captures a page while signed in to an account, or a page showing someone’s name, address or order, that appears in the image and is then stored with your audit. Your agent decides what to capture; we store what it sends. Capture the evidence for the finding and not the surrounding data, and never let an agent enter a password — sign in yourself, in your own browser, and let it look at the result.
The same is true of a managed run. Its screenshots and step images show whatever the page showed. After you sign in through a login handoff, that includes the signed-in pages of your account on that site, and they are stored with the run.
What we do not collect
- Card details. The payment provider holds those. They never touch our servers.
- The sites you audit, unless you start a run. Through MCP we never crawl, fetch or open them: your agent does the looking, and only what it chooses to send reaches us. A managed run is the one exception, and only for the site you named, when you start it.
- Passwords for the sites you sign in to. In a login handoff you sign in yourself, inside the run’s browser. What you type goes to that site and is not logged or stored, no screenshot or step image is taken while the handoff is open, and the AI model never sees it. The view of the browser is encrypted between the run’s browser and your browser, with a key used for that handoff only, so the relay in between cannot read it, and only members of your account can open it. When the run ends, its browser — cookies, storage and the signed-in session — is destroyed.
- Your password. There isn’t one; sign-in is delegated to Google or GitHub.
-
Test runs. A synthetic URL — localhost, a private IP, a
.test/.local/.examplehost — is never written to the database at all. Not the audit, not the findings, not even the usage event.
Rubric Analytics: your site’s visitors
When you add the Rubric Analytics snippet to your site, we process data about your visitors on your behalf. You are the controller of that data; we are your processor.
- Events, without cookies. Page views, where on the page a visitor clicked and how far they scrolled, time on page, JavaScript errors and Core Web Vitals. No cookies or browser storage are used, no IP address is stored, and a visit is grouped only by a hash that changes every day. E-mail addresses and long numbers are masked in everything the snippet sends.
- Where a visit came from and what it did. The site that linked to the page and any campaign tags in its address, the browser and operating system family (worked out from the browser’s identifier, which itself is not stored), the text of a button or link that was clicked, the website a visitor left to, the name of a file they downloaded, and the kind of contact link they used (phone, e-mail, SMS or WhatsApp, never the number or address).
-
Forms, never what is typed. When a visitor starts, submits or leaves a
form, the snippet sends the form’s name and the names of the fields they touched,
and which field the browser flagged as invalid. It never sends a value. Password, card,
one-time-code, hidden and file fields, and anything inside
data-rubric-mask, are not tracked at all. -
A masked copy of each page, for heatmaps. So clicks can be drawn on the
real page, the snippet occasionally sends a copy of a page’s structure from a
visitor’s browser: a page is copied once, then again only when it changes or the
copy is a week old. Before the copy leaves the browser, and again on our servers, every
form field is emptied, e-mail addresses, long numbers and long codes are masked, scripts
and embedded frames are removed, and link and image addresses lose their query strings.
Other text on the page is kept, so a page that shows a visitor’s own name or
details while they are signed in can carry that text into the copy. Add
data-rubric-maskto any area to blank it completely, ordata-snapshot="off"to the snippet to turn copies off. - Retention. Raw events 30 days, daily summaries 13 months, page copies until they are 90 days old. Deleting a site deletes its events, summaries and copies within 30 days.
rubric.design itself uses Rubric Analytics: cookieless, no IP or user agent stored. It runs on our public pages (the home page, the demo form, release notes and these legal pages), never inside the panel.
Demo requests
When you ask for a demo at rubric.design/demo, we store what you enter in the form: your name, work e-mail, company or agency, role, how many client sites you manage, the services you offer, and — if you give them — your website, what the demo should cover and how you heard about us. We also keep a one-way hash of your IP address (not the address itself) and your browser’s user-agent string, to stop the form being flooded.
- Why: to arrange and prepare your demo, and nothing else. We send you occasional product updates only if you ticked that box; it is not needed for the demo.
- How long: 90 days from your request, then deleted.
- Who processes it: Supabase stores the request; Microsoft 365 delivers the notice to us and the confirmation to you.
- Deleting it sooner: write to help@rubric.design and we will delete it.
Why we are allowed to hold it
Where Türkiye's Personal Data Protection Law (KVKK, Law 6698) applies, we process personal data because performing the contract makes it necessary, because a legal obligation requires it, and on our legitimate interests where they do not override your rights and freedoms. Where the UK GDPR or EU GDPR applies to you, our lawful bases are performance of a contract (running the service you asked for, and billing it), legal obligation (keeping financial records) and legitimate interests (keeping the service secure and working out what to fix).
Who else processes it
We use a small number of providers, each for one job. They act on our instructions and may not use your data for their own purposes.
| Provider | What it does | Where |
|---|---|---|
| Supabase | Database, authentication, file storage for screenshots, and the relay that carries the encrypted login-handoff view | EU (Frankfurt) |
| Google Cloud (Cloud Run) | The worker that runs managed runs in its own browser, the attention model behind heatmaps, and the Analytics collector | EU (Frankfurt) |
| OpenRouter | Passes what a managed run reads — page text and structure, screenshots, and the persona and goals you gave — to the AI model that does the work, currently Anthropic’s Claude. Also used for the weekly Analytics insights | USA |
| Netlify | Hosting, CDN and the serverless functions | USA, served from edge locations worldwide |
| Cloudflare (Turnstile) | Bot check on the demo request form. Cloudflare receives the signals your browser sends to run the check, such as its type and settings and your IP address, and tells us only whether the check passed. We set no cookies for it | USA, served from edge locations worldwide |
| Google / GitHub | Sign-in, if you choose that provider | USA |
We are a Turkish company and our database is in the EU, so your data is processed in Türkiye, the EU and the United States. Where transfers out of the UK or EEA need a safeguard, we rely on the standard contractual clauses our providers offer; transfers out of Türkiye rest on the grounds Article 9 of the KVKK allows.
How long we keep it
- Account, audits, findings and screenshots: until you delete the account. Deleting it removes the uploaded image files as well as the rows that point at them.
- Managed runs — the job, its screenshots and step images, heatmaps, simulation reports and site analyses: until you delete the account. Deleting it removes the stored image files as well as the rows. An account cannot be deleted while one of its runs is still in progress.
- Analytics sites: deleting the account deletes its sites, and with them their events and summaries, within 30 days.
- A login handoff: only for the run. The browser session is destroyed when the run ends and the handoff key is cleared when the handoff closes. A handoff left idle for 10 minutes ends the run, and its runs are given back.
- Usage events: up to 24 months, because they are what a billing dispute is settled from.
- Payment records: as long as Turkish tax and commercial law requires, which can run to ten years. These survive account deletion because they must.
How it is protected
- Every customer table is closed by default at the database level. The browser never queries the database directly — every read goes through our own server, which applies the account boundary in one place.
- API keys are stored as hashes. A stolen database yields no usable key.
- Two-factor authentication is available on your account and required for administrative access.
- Everything is served over TLS.
No system is perfectly secure. If a breach affects you we will tell you, and any regulator we must, without undue delay.
Your rights
You can ask for a copy of your data, correction of anything wrong, deletion, restriction of processing, or portability, and you may object to processing based on legitimate interests. Deleting your account from the panel does most of this immediately: it revokes your keys and connected applications and removes your audits, findings and managed runs.
For anything else, write to help@rubric.design and we will answer within 30 days. If you are in Türkiye, you may apply to us first under Article 13 of the KVKK and then complain to the Personal Data Protection Authority (KVKK). If you are in the UK or EEA and think we have got it wrong, you may complain to your data protection authority. If you are in California, we do not sell or share personal information as those terms are defined by the CCPA, and we will not discriminate against you for exercising a right.
Cookies and storage
The landing page sets nothing, and neither does our analytics. On the demo request form, Cloudflare Turnstile runs a bot check and may keep its own data in your browser for that check only; we set nothing for it. The panel keeps your sign-in session in your browser’s local storage so you are not asked to sign in on every visit, and stores the short-lived verifier that makes the sign-in round trip safe. That is all of it — strictly necessary, no analytics cookies, no advertising identifiers.
Children
Rubric is a developer tool and is not directed at anyone under 18. We do not knowingly collect data from children; if you believe we have, tell us and we will delete it.
Changes
We will update this page when what we do changes, and change the date at the top. If a change is material we will tell you at the email on your account before it takes effect.