Your catalogue, open to AI shoppers.

See how
Skip to content
Chrome extension

What the extension sends, and what it never touches

This policy covers the Cresva Chrome extension only. It supplements our general privacy policy, which governs cresva.ai and the signed-in product, and adds to it rather than replacing it. Where the two speak to the same thing, the stricter statement is the one we hold ourselves to.

Last updated September 25, 2026

What a scan sends

Nothing is sent until you click. There is no background collection, no scan on page load and no scan of tabs you are not looking at.

Always, when you scan:

  • The address of the tab you scanned, stripped. The query string is reduced to variant and sku, and the fragment is dropped, in your browser, before the request is assembled. Session tokens, affiliate ids, click ids and email-campaign parameters all live in query strings and none of them reaches us. variant and sku stay because they select which product the page is showing, so dropping them would point us at a different item than the one you are looking at.
  • A page kind, which the extension works out from the address alone: one of product, collection, home or other.
  • A random install identifier and a proof of work value, sent as request headers. Neither identifies you. See Anonymous by default.

Additionally, only when the browser view option is switched on:

An extract of the page, read from what your browser has already rendered. This is what lets the panel tell you that something a shopper can see is missing from what an agent is served. It contains:

  • the page title and its H1 headings
  • structured data: the bodies of the page's JSON-LD blocks, up to 32 blocks and 32KB in total, plus the @type and itemtype names found on the page
  • meta tag names and values, up to 40 of them
  • price shaped strings visible on the page, availability text, and whether an add to cart control is present
  • counts only: how many words are visible, how many script tags there are, how many JSON-LD blocks there are, and how many bytes the extract came to
  • up to 2,048 characters of visible text from the page's main content region
  • the page address a second time, this one reduced to a whitelist of variant and sku, with everything else in the query string and the fragment dropped

Before any of that leaves the page, three redaction passes run in your browser, not on our servers. Email addresses become [email removed]. Digit runs that are the length of a payment card and pass the Luhn check become [number removed]. Phone shaped strings become [phone removed]. These passes run on everything listed above: the title, the headings, the text sample, every value in the structured data and the meta tags. Two kinds of value are spared the passes that would break them: product identifiers such as barcodes, SKUs and part numbers are kept as published, and web addresses get the email pass only, because a long product id inside a link can look like a card number. In the free text sample only, any remaining run of four or more digits is also removed, with prices deliberately kept because prices are the thing the scan exists to measure.

The text is read from what your browser rendered. The only markup read is the structured data blocks and the named meta tags above: no other script bodies, no inline event handlers and no hidden attributes travel with it.

What is never read

  • Cookies. The extension does not request the cookies permission, so Chrome does not give it the ability to read them, on any site.
  • Local storage, session storage and IndexedDB. The extension reads none of them on any page you visit. The storage permission it does hold writes only to the extension's own storage, and only the entries listed in full under Anonymous by default below. Three of them are ever sent to us: the install identifier, and, once you sign in, your Cresva sign-in and the client identifier it was issued to.
  • Credentials. No passwords, no session tokens, no authorization headers and no API keys are read from the pages you visit. Signing in to Cresva is a separate, optional step for the ads panel and for analysing Ad Library ads, described under Signing in below. Nothing a page carries is ever read as a credential.
  • Form fields. Before any text is read, inputs, textareas, selects, options, buttons, forms and contenteditable regions are removed from a working copy of the page. Whatever you have typed lives in exactly those elements, and they are gone before the text extraction starts.
  • Other tabs. The extension does not hold the tabs permission. Access is granted one tab at a time by your click on the Cresva icon, and it does not carry over to the next tab or the next page.
  • Anything at all, until you click. The extension declares one host permission, https://cresva.ai/*, which is our own API. It holds no standing permission on any store you visit. Its one standing script runs only on the Meta Ad Library, where it places an Analyse with Cresva button on each ad and reads nothing until you press one; see Analysing an ad below.

Pages the extension refuses outright

On these pages no request leaves your browser at all. Not a redacted request, and not a scan with the browser view turned off. Nothing. The refusal happens before a request is even assembled, because the address by itself is a disclosure: a Shopify admin URL tells us which store somebody administers and which order they were reading.

Refused by host:

admin.shopify.com, partners.shopify.com, accounts.google.com, myaccount.google.com, admin.google.com, login.microsoftonline.com, adsmanager.facebook.com, business.facebook.com, ads.google.com, ads.tiktok.com, analytics.google.com, app.klaviyo.com, mail.google.com, and any subdomain of those.

Refused by path, anywhere in the address:

admin, wp-admin, wp-login, administrator, checkout, cart, account, orders, order-status, my-account, profile, addresses, payment and billing. File extensions are stripped before matching, so /wp-login.php and /admin.aspx are refused too.

Refused because of what is on the page:

Any page carrying a password field. This one cannot be decided from the address, so it is checked a second time after the page has been looked at. When it fires, the extract already held in the extension's memory is discarded unsent and unlogged, and the scan ends there.

Browser pages are also refused: chrome://, about:, devtools://, view-source:, extension pages, and anything that is not http or https.

Signed in, on your own ad accounts, this changes and it changes narrowly:

Everything above describes the extension as anyone can install it, with no account. Cresva reads storefronts, not the screens behind your login. The thirteen hosts listed above are refused outright in that mode and nothing you do makes a scan of them happen.

Once you have signed in and connected an ad account you own, the panel opens on that account's own dashboard and shows you what Cresva already knows about the campaign you are looking at. On your own ad accounts, once you've signed in and connected them, it reads only the page address to know which campaign you're looking at. It never reads the page.

It never reads the page, and that is structural rather than a promise. The extension holds no host permission for any ad account domain, so the script injection the store mode relies on cannot reach an ads page at all. There is no setting that turns it on, and no version of this extension in which it reads one. The refusal list above is unchanged: a scan of those hosts is still refused, and so is a try-to-buy.

Try to buy, and where it stops

One of the checks is a real attempt to buy something, made by us, from our servers, the way an outside shopping agent would. It is worth being exact about what that means, because it is the only check that does anything other than read.

Nothing comes from your browser.

Your browser does not take part in this at all. Cresva's own servers make the requests, from our address, with no cookie, no session and nothing carried over from your tab. The store sees us, not you, and the walk would run identically if you were not signed in to anything.

What we ask the store.

  • Whether the store publishes the machine-readable routes an agent would use, which is one request for a well-known address and, where it exists, one call asking that endpoint to list what it can do.
  • A product, read from the store's own product route, for its variants and prices.
  • A cart, created with one item in it, then read back to check the store agrees on what is in it and what it costs.
  • Shipping rates for that cart, where the store offers them.

It stops before payment, and nothing is ever paid.

The checkout is never completed. No card, no token and no wallet exists anywhere in this path, and the agent profile we publish declares an empty list of payment methods so a merchant can verify that rather than take our word for it. Where a store answers a cart with a redirect to its own checkout, that address carries a session token, which is a credential: it is not followed, not logged, not stored and not returned. Only the status code is read.

The heaviest thing this leaves behind on a store is one abandoned cart in a session nobody holds a cookie for.

Suggesting a store for the AI Shopper Index

The panel has a button that offers the store you are looking at to our public index. It does nothing unless you press it.

What the suggestion sends:

  • the host of the store, and nothing else about the page
  • the identifier of the scan you were looking at, which identifies a SCAN and never a person
  • whether you ticked the box agreeing the store may be listed publicly

No email address is asked for and none is sent. A suggestion carries no contact details at all, which is why we cannot write back to you about one.

What happens to it, and what gets published.

The store is checked: is it reachable, does it sell online, and can we read a product catalogue from it. If it passes, the store's name and address appear on the public index. If it does not pass, nothing about it is published.

Listing only ever happens with that box ticked. A suggestion that arrives without it is recorded and never rendered, and so is one that arrives with the question unanswered. We treat those two the same on purpose: not being asked is not the same as agreeing, and neither is permission.

The AI shelf on a product page

On a product page, the panel can show where that product ranks when shopping assistants are asked about its category.

With browser view off, nothing from the page is read or sent for it unless you click Track. The panel says to turn on browser view to see the shelf. With browser view on, the extension asks Cresva for the product's shelf when you open a product page.

What that request sends, and what Track and Untrack send:

  • the page address, with the query string removed apart from variant and sku, and the page's canonical link
  • the product's name, brand and category, exactly as the page's own structured data states them
  • the extension's random install identifier, which we store only hashed

It sends no page text, no prices and nothing about you. The answer comes from a reading we already hold. Opening the panel asks no AI model anything.

What is kept, and for how long.

Each time the shelf is shown, we record the product page and the hashed install identifier, so we can count how often people come back to it. If you press Track this product, the same fields are recorded as a request, and a person confirms the shopping question before the product is measured. Both records are deleted after 90 days by the same nightly job as scans.

Untrack removes your request. The product stops being measured once nobody else tracks it; if someone else still does, the card says so. A tracked product page is a public page, not anything about you.

Signing in, and what that sends

Store mode never signs you in. Signing in is optional and turns on two things: the ads panel, on your own Meta Ads Manager and Google Ads accounts, and analysing ads in the Meta Ad Library. You can use the store panel indefinitely without ever signing in.

Signing in registers a client, starts a pairing and opens a Cresva tab where you consent. Your browser keeps a one-time verifier and exchanges it for a token that is stored in the extension's local storage. Everything the panel does with that access is a lookup, with one exception you grant on the consent screen: saving an ad analysis you ask for, described under Analysing an ad below.

Once signed in, and only while the ads panel is open on one of your own ad accounts, the panel sends:

  • Which brands your grant covers. The list is scoped on our side, never filtered in the browser.
  • Campaign performance, pacing and anomalies for the brand you select, and a budget recommendation when you ask for one.
  • The question you type, as you typed it, when you ask about a campaign, together with the campaign ids if you chose any. This is the one place the panel sends something you wrote rather than something it measured, and the question is also sent to OpenAI to be read, as listed under Which features use an AI model.

Nothing is written to an ad account.

When the panel proposes a budget change it opens the approvals queue in your dashboard and stops there. The change is made in the dashboard, by you. The panel has no ability to enact one.

Nothing from your own ad account's pages is ever sent. On an ads page the extension reads the address of the tab and never the page itself. The one page content ever sent is a single public Ad Library ad you choose to analyse.

Analysing an ad in the Meta Ad Library

On Meta Ad Library pages only, the extension adds an Analyse with Cresva button to each ad. Nothing is read until you press it. When you do, the extension reads only that ad: its image or video, its text, the advertiser's name, its start date and its Ad Library ID. It sends them to Cresva under your account, and we analyse the ad and save the result to your Competitor Intel.

When needed, Cresva's server downloads that ad's image or video from Meta's image server to analyse it. It downloads only the ad you pressed the button on, and only from Meta's own image server.

The ad is read by an AI model. What is sent, and to whom, is listed under Which features use an AI model below.

We store the analysis, not the image. The extension never reads your Facebook account, feed, messages, cookies or anything else on the page.

How long an analysis is kept. A saved analysis has no automatic expiry: it stays in your Competitor Intel history until it is deleted. To delete yours, write to us at the address below and we delete them. An analysis made for a brand in your dashboard is also deleted when that brand is deleted.

Which features use an AI model

A store scan never calls an AI model. These features do, each only when you are signed in and only when you use it:

  • When you analyse an ad in the Meta Ad Library, the ad's image, or four frames taken from its video, and its text are sent to OpenAI to produce the analysis.
  • When you ask about a campaign in the signed-in ads panel, the question you type is sent to OpenAI to work out which figures to fetch. The answer itself is built from your data without a model.

Under OpenAI's data policy for its API, OpenAI does not use what we send to train its models, and it keeps it only for a limited period to check for abuse before deleting it.

Daily limits

Scans are capped per install per day and the panel shows what is left. The counter is keyed to the random install identifier described under Anonymous by default, not to you, and it exists to stop one install crawling other people's storefronts without limit.

What is stored

One row is written per scan. It holds:

  • the hashed install identifier, never the raw one
  • the host, and the page address in the stripped form above
  • the page kind
  • the verdict and the individual check results, including the short evidence strings the panel shows you
  • whether a browser view extract arrived and how many bytes it came to, which is a size and never any content
  • the engine version, how long the scan took, and the timestamp
  • where we could work them out from the store itself, a category and a shipping country, used only for the comparison line

A try to buy writes one row too: the hashed install identifier, the store's host and the product page address, which steps worked and where the walk stopped, the market it tested, and how long it took. Putting a competitor beside a store runs the same scan against the address you type, from our servers, and stores it the same way as any scan.

The page text extract is never stored and never logged.

The up to 2,048 character text sample is used inside one comparison on the server and then dropped. It is not written to the database, it does not appear in any log line, and it is not returned in the response. What is kept about it is a boolean and a byte count.

Be aware of the one thing that does cross over: the short evidence strings in the stored check results are quotations from your page, so a page title or a price the page displays can appear there. Those are the same strings the panel shows you on screen.

Caching.

A verdict computed from a page we fetched ourselves is cached for one hour, keyed by host, so a repeat scan of the same store costs nothing. A verdict computed with help from your browser extract is never cached, because it describes one person's browser session and must never be served to a second person.

Your IP address.

Used as a rate limiting key, held in a short lived counter that expires on its own. It is not written to the scan record.

Two numbers a day, about the service and not about you.

We count how many scans were answered from our cache and how many were freshly read, as two running totals per day. Those totals carry no host, no install identifier and no address: a date and a word. They tell us whether the cache is doing its job, and they expire after fourteen days.

Retention, and what we do with it

Two uses, and no third.

  • Producing the report you asked for, in the panel, at the moment you asked for it.
  • Aggregate readiness statistics. Stored verdicts are counted together so the panel can tell you where a store stands against others in the same category and country. That comparison is only shown once at least thirty comparable stores exist, and it is a count of bands and never a list of stores.

    The panel also compares a store against the Cresva AI Shopper Index, which is a named population of direct-to-consumer stores we crawl and publish, not the web at large. That line is withheld until the population reaches 100 stores, and it names the population and its size in the sentence, so a percentage is never shown without saying what it is a percentage of.

We do not sell this data, and we do not share it with advertisers, data brokers or any third party for their own purposes.

A store scan makes no calls to any AI model. The analysis is code reading your page, not a model reading it, and there is therefore no third party model provider in this path and nothing to train on. The features that do use a model are listed under Which features use an AI model above.

That includes the panel's AI shoppers section. What it shows is read from a weekly record of what each assistant answered for that category: the question was asked once, for the category, on a schedule of ours, and the panel reads the answer. Your scan does not ask an assistant anything, the store you are looking at is not sent to one, and opening the panel a hundred times asks nothing a hundred times. Where we have not asked for a category yet, the panel says it has not been asked rather than asking on your behalf.

How long we keep it.

90 days. A job runs every night and deletes every scan and try-to-buy record older than that. It is not a policy we apply by hand on request: it is a scheduled deletion, it records what it deleted each night, and the number above is read from the same constant the deletion uses, so this sentence cannot quietly drift away from what the code does.

You can also ask us to delete yours sooner. Write to us at the address below.

Anonymous by default

Store mode is anonymous. No account, no sign in, no email address and no connected store: the extension asks you for nothing and we do not know who you are. Signing in is a separate, optional step that turns on the ads panel and Ad Library analysis, and only then do we know who you are. Everything on this page describes store mode unless it says otherwise.

  • The install identifier is a random UUID your browser generates once, at install, from the platform's cryptographic random source. It contains nothing about you or your machine.
  • It is kept in the extension's local storage and deliberately not in Chrome's sync storage, so it does not replicate to your other machines.
  • It is sent as a request header and stored only as a SHA-256 hash. The raw identifier is never written to our database.
  • It is a rate limiting partition key and nothing else. Your browser mints it, so it proves nothing to us and cannot be used as a credential.
  • Uninstalling the extension removes it. A fresh install mints a new one, unlinked to the old.

Everything the extension keeps in your browser.

This is the whole list, and it is generated from the list the code itself is checked against rather than written out here by hand. None of it is in Chrome's sync storage, so none of it reaches your other machines.

Kept until you uninstall (local storage for this extension):

  • installId: a random identifier your browser generates once, at install, used to partition rate limits and nothing else.
  • includeRendered: whether you have turned the browser view on, which is the setting that decides if a page text sample is sent at all.
  • sectionState: which sections of the panel you have folded away, so the panel opens the way you left it.
  • hasScanned: whether a scan has ever completed on this install, which is what stops the panel showing a first-run walkthrough for ever.
  • owned:<host>: one entry per store you have told the panel is yours, so it stops asking. The host is the only thing stored and it never leaves your browser.
  • cresvaSession: your Cresva sign-in, as an opaque token and the moment it expires. It is written when you sign in, and read before the ads panel opens on one of your own ad dashboards and before an Ad Library ad is analysed. An expired one is treated as no session at all rather than as a valid one. It is absent until you sign in, and it is removed when you sign out or when Cresva no longer accepts it. It also holds a refresh token, so a sign-in is renewed in the background rather than asked for again every hour.
  • cresvaOauthClient: the identifier this browser's copy of the extension registered itself under, so signing in a second time does not create a second registration. It is an identifier and not a secret: the extension is a public OAuth client and holds no client secret at all. It is absent until the first sign-in.
  • adsHintDismissed: whether you have dismissed the one line at the bottom of the panel that mentions checking your ad numbers. It is a single true once you press dismiss, it is absent until then, and nothing about it leaves your browser.

Kept only until you close the browser (session storage, which is never written to disk):

  • grantContext: the tab you clicked the Cresva icon on, as a tab id and, when Chrome supplies it, that tab's address. It is what lets a scan act on the tab you actually clicked rather than whichever one you are looking at a minute later, it is kept in session storage so it is never written to disk, it is treated as expired after ten minutes, and it is gone when you close the browser.

Changes to this policy

If we change what a scan sends, what is stored, or how long we keep it, we will update this page and move the date at the top of it. Material changes will also be noted in the extension's Chrome Web Store listing, which is the surface that tells you an update has been installed.

Contact

Privacy questions, deletion requests and anything on this page you think is wrong: hello@cresva.ai.

Cresva, Inc., Delaware, United States. This policy supplements the general privacy policy at /privacy, which covers cresva.ai and the signed-in product. What the extension actually does is described at /extension.