Privacy

We store the business details you type in, the AI answers we collect on your behalf, and — if you give us one — an email address. Signing in is by emailed link, so there are no passwords; the only cookies this site sets are the first-party session cookies that keep you signed in and one that remembers which organization you are acting in; a one-hour cookie that remembers which page to return you to after the sign-in link; and ten-minute cookies that protect a Google, Slack or Meta connect flow or hold an assistant’s connection request, each set only if you start that flow. There are no tracking cookies, no analytics scripts, and no advertising pixels. We do not sell or share your data for anyone else's marketing.

What you type into the audit form: brand name and aliases, your domains, the competitors you track — their names, domains and any aliases you list — your category, who your buyers are, and any seed questions. A run measures at most four competitors; brands you add beyond that are stored as watch-only and scored against answers we already hold, so the number you can store is not capped at four. This is business information, not personal information, with one exception below.

An email address, if you give one. It is optional on the setup form. If you buy a plan, Stripe passes us the email you used at checkout so we can send you the report and reach you about billing. It is not the only personal data we hold. Lead capture in our WordPress plugin adds more if you switch it on, and the section on connecting a CRM says what. The reviews read is other people's: the text of the public reviews they wrote about your business and, on a paid report, its competitors, kept with each review's id and, where the vendor gives one, its link, and the text or the link can identify the person who wrote it. We keep no reviewer's name and no owner's reply text; the Reviews paragraph under who else sees your information says what it stores. Giving us an address also means a few follow-ups about your report: what to fix first, and after a month, whether a fresh run is worth it. Every one of those carries a one-click stop link; using it puts the address on a stop list (the address and the date, kept for as long as we send mail at all) and no more follow-ups go to it. Mail you asked for by running a report still arrives: the report itself, a month waiting for your approval, and a payment that did not go through. When you are signed in, we also note the day you open a report or your dashboard, so we do not mail you about a report you read this morning. That note is a row in our own database tied to your address, never a script or a cookie, it is never recorded for anyone signed out, and it is deleted after 90 days.

What the audit produces: the full text of every answer each AI engine returned, the whole response the engine sent with it — which on some engines includes the search queries it wrote for itself before answering, and a paid report shows those for the questions your brand lost — the URLs those answers cited, what our extraction step found in them, and the per-call API cost. These are what make the report auditable — every number on it traces back to a stored answer.

A Stripe subscription identifier, so we know whether your plan is active. We never see or store your card number, expiry, or CVC — those go straight to Stripe.

Tags and settings you put on your questions. On the Questions page you can tag a question or override its journey phase. Those tags are stored on the question itself — business configuration you wrote, shown back to you and included in your own CSV exports, never used for anything else.

A record of paid feature runs. Some paid features call an AI model when you click them (suggested questions, for example) and carry a daily allowance. Each click stores one ledger row — which account asked (your sign-in email), which property, and when — because that count is what enforces the allowance and what lets us show you “2 of 5 used today.” It records that the feature ran, never the content it produced for you beyond what the feature itself saves.

Health-check results for your own domain. The Sources page can probe your homepage, robots.txt, llms.txt and agents.md to check whether AI crawlers can reach and read your site. Each check you run stores one row — which property, which signed-in account ran it (your sign-in email), when it ran, whether it completed, and the pass/fail result per named check. The probes fetch only the domain already on your property; they store the verdicts, not copies of your pages.

Fix items and their history. The Fixes page turns findings your audit already stores — lost questions, diagnosed gaps, failed health checks, your action plan’s content briefs — into tracked work items. Each item stores its title, the evidence rows it came from, its priority and status; every status change stores one history row recording who changed it (your sign-in email, or our team) and when. When a fix ships, the item can carry the published page’s URL so we can measure whether AI engines start citing it. This is business configuration and work history on your own property, shown identically to you and to the team doing the work, never used for anything else.

A standing work authorization, if you grant one. On the Fixes page, the Command plan — the tier whose price includes us implementing fixes — lets you authorize us to take on every new fix automatically, or to let our agents apply changes you have approved. That consent is stored as one row per grant: which property, the level you chose, the signed-in email that granted it, and when. Withdrawing it keeps the row and stamps the withdrawal date — “you agreed on the 3rd and withdrew on the 9th” is a question this record exists to answer — so it is kept for as long as the property exists, and goes when the property’s audit is deleted.

Assistant chat transcripts. Messages you send to the in-product assistant, and its replies, are stored as a transcript on the property you asked about — that history is what lets you reopen a conversation. Each message is capped at 10,000 characters, and each conversation at 200 messages. Transcripts are stored exactly as written: we cannot detect a password or key you paste into chat, so treat the box like any other stored field. Our team can view a transcript for support. When the assistant proposes an action (like a re-run), the proposal stays stored with the transcript; it can no longer run 15 minutes after it was proposed. Each message you send — along with the conversation so far — goes to Anthropic (Claude) to generate the answer, the same processor listed under “Who else touches your data” below. Transcripts are kept while the property exists, deleted with it, and deletable earlier on request via the contact below. We do not use them to train any model, ours or anyone else’s.

API tokens you mint. Settings can mint a token so an AI assistant reads your reports directly, through our MCP endpoint. We store the first few characters of the token, a SHA-256 hash of the whole value, your sign-in email, when it was made, when it was last used, and, once you revoke it, when that happened. The token itself is never stored: it appears once, in the response to the click that made it, and if you lose it the only remedy is to revoke it and mint another. A token reads every property your email owns, revalidated on each call, and keeps working until you revoke it. Revoking keeps the row and ends the credential. Each call stores one ledger row — your sign-in email, which token asked, and when — because that count is what holds a token to 60 calls per clock hour. It names the token rather than a property, since one token reads them all.

Apps you connect by signing in. When an app registers with us, we store the name it gave itself and the addresses it asked us to send people back to, whether or not anyone connects it. If an assistant sends you to our sign-in page to connect, and you allow it, we store your sign-in email, when you connected it, when it last renewed its tokens and when it last called us, and SHA-256 hashes of the access and refresh tokens we issued it, never the tokens themselves. The one-time code that hands it those tokens is stored the same way, as a hash beside your email; it works once, within five minutes, and its record is kept. Starting the connection sets one cookie, aeo_oauth_req, before you sign in: for ten minutes it holds the app’s request (which app, where to send you back, and the values that let the app check our reply), and allowing or cancelling clears it. Disconnecting the app in Settings ends both tokens on its next call and keeps the row, marked revoked. Its calls are counted in the same ledger as a token’s, naming the connection instead. An app you connect can also start this account’s one free report: that creates a report under your sign-in email with the site, product and buyer the app gave us, exactly as the free report form does, and the completion email comes to you.

Your fact sheet, if you fill one in. The Answer check page stores the facts you enter about your business (names, phone numbers, addresses, hours, prices, the year you started, services, service area, and the people you list with their roles), the signed-in email that last saved it, and when. Running a check sends Anthropic (Claude) up to 240 stored answers that name you, one call each, and with each one your business names, services offered and not offered, people and roles, service area and locations (addresses included). Your hours, phone numbers, prices and founding year are not in that call: code compares them, and your addresses, with what the answer says. Where code finds a match or a mismatch in hours, phone, address, year or price, a second call for that answer sends your business names, the sentence, the value code read from it, and your value for that field, and asks whether the sentence states it of your business itself and whether the two values really differ. We store what came back: the quoted sentence, the model’s label for what it is about (a day, an item, a person), the value read from it, the verdict, the matching fact from your sheet, the second call’s answer and its one-line reason, and up to three pages the answer cited. A fact an answer contradicts is shown beside it in your report, so anyone you share the report link with sees that fact. All of it is kept while the property exists and deleted with it.

AI-crawler counts from your WordPress plugin, if you share them. The plugin counts, on your own server, how often crawlers like GPTBot, ClaudeBot and PerplexityBot fetch your site. Switch on sharing in its crawler observatory and it sends us those totals once a day: for each day, how many fetches each crawler made. Newer versions also send, per day, how many of those fetches came from an address the crawler’s operator publishes, how many didn’t, and how many weren’t checked because that operator publishes no address list, plus the date of the crawler list that did the counting. We store one row per site, day and crawler, and show it back to you as the crawler panel. No visitor’s IP address, page path or raw user agent is sent or stored: the plugin checks the address inside the request and drops it there. Switching sharing off stops the sends; the rows already stored stay with the site until you ask us, at the contact below, to delete them.

Which plugin sent you here, if one did. Start an audit from the link in our WordPress plugin or Shopify app and we store one row recording that this audit came from that plugin. It describes the audit, not the visitor: a first-party database row that sets no cookie, runs no script, and follows nobody between pages or sites. It stores no name, email address, IP address, or device identifier — only which plugin, and the id of the audit it belongs to.
Which ad sent you here, if one did. Arrive from a link we paid for and the campaign labels in that link (the utm_ values and the ad network's click id) are stored on the audit the same way. When that audit connects, and again if it is bought, we tell the network that sold the click that it converted: the click id, the campaign label, and for a purchase a one-way hash of the checkout email. Never the answers, never the brand, never a page you visited. Still no cookie and no script; the link carried it, the server kept it.

A scrambled stamp of your address, if you run the free readiness scan. The scan at /scan needs no account, so the only thing that holds it to five scans a day per visitor is the address the request came from. We never store that address. We combine it (the whole IPv4 address, or the first half of an IPv6 one) with a long secret value and keep only the one-way hash of the two, which can’t be turned back into the address. Each scan stores one row: that hash, the domain you asked about, and the date. The hash is only ever compared with other scans on the same day, and the address itself is never written to our database or our logs. The scan’s findings about the domain are stored too, and open to anyone holding the result link. Ask us at the contact below, naming the domain and the day, and we’ll delete both. A scan an assistant runs through our keyless MCP server stores no address: every scan through that door carries one shared marker in place of the hash, and the calling address is never written to our database or our logs.

If you reserve a seat on the agencies page, we store what that form asks for: your email address, your agency name if you give one, a client-count band, and which tier you said you were interested in. We use it for exactly two things: following up on the offer, and counting demand before we build more. It is never shared or sold. To be removed, email the contact address at the bottom of this page and we will delete the row.

You can sign in with the email you used at checkout to see your reports in one place. We email you a one-time link; there is no password to create or leak. Sign-in is provided by Supabase Auth, the same provider that hosts our database, so your address is stored there as an auth user record.

Requesting a sign-in link sets one cookie immediately: sb-*-auth-token-code-verifier, the random value that proves the link is being opened by the browser that asked for it. It is set when you submit the form and cleared when the link is used, or it expires unused. Completing sign-in sets the session cookies, sb-*-auth-token.

If your account belongs to more than one organization, choosing which one you are acting in sets one more cookie: aeo_org, the id of that organization, signed by us so an edited value is ignored. It lasts a year because it is a preference, not a credential — every request re-checks it against your actual memberships, and if it no longer matches one, your earliest membership wins.

All of them are first-party and are set HttpOnly, Secure, SameSite=Lax, path /. They exist for one purpose — keeping you signed in. No script on the page can read them; they are never sent to any other site; they carry no tracking identifier and are used for no analytics. Signing out clears them. When the sign-in form carries a page to return you to (an assistant’s connection request does), it also sets aeo_next, that page’s path, for up to an hour, on path /auth/callback only; the sign-in link reads and clears it. If you never use the sign-in form, connect an assistant, or open a Google or Meta connect link you were given, this site sets no cookie at all.

Attaching a report to your account (“Add a report you already have”) writes your email address and a timestamp onto that audit's record — the same field the setup form or Stripe checkout would have filled.

In the agency console, setting a checklist step aside stores that step's name on your organization's record, so everyone in it sees the same list, and putting it back removes it. The ticks themselves are never stored: each one is read from the reports and properties that already exist.

No passwords — sign-in is by emailed link. No tracking cookies: the only cookies are the session and org-choice cookies described above, set only once you sign in; the return-page cookie described above, set when you send the sign-in form; a short-lived Google or Slack connect cookie that holds an encrypted envelope — a random state value, the property being connected, your sign-in email and (for Google) the PKCE verifier — for ten minutes while you authorize; a ten-minute cookie that protects the Meta ad-account connect flow; and a ten-minute cookie that holds an assistant’s connection request while you sign in and approve it — which you can confirm in your browser's developer tools. No Google Analytics, no Plausible, no PostHog, no session recording, no advertising pixels, no cross-site tracking. We do not know how many pages you visited before this one. Two settings — your theme, and whether you have dismissed the dashboard tour — are remembered in your browser's own storage. Neither is a cookie, and neither is sent to us or to anyone else.

Running an audit means sending your brand name, competitor names and questions to other companies' AI systems. That is the product; it cannot be done privately. In full:

AI engines — OpenAI (ChatGPT), Anthropic (Claude), Perplexity, Google (Gemini) and xAI (Grok) receive your questions, which contain your brand and competitor names. Each engine runs a live web search to answer. We also send answers to Anthropic a second time to extract which brands were mentioned; to write your question set, gap diagnosis and action plan; to answer your assistant chat messages (which are sent with the conversation so far); to point at the claims in the answers that name you and read the ones about services, people and places against your fact sheet, and to confirm each match or mismatch code finds with your fact sheet, when you run an Answer check; and — on plans that include content drafting — to write the content drafts themselves from your audit's data, and once a week to rank the questions most worth drafting (the desk, stored with the ids of the stored answers it rests on). A refresh draft, written for one question you lost, is stored with the ids of the stored answers it rests on, the searches the engines ran and the cited pages that don't name you; your WordPress site receives it as an unpublished draft, with those answer ids in the post's details, and nothing is published until you publish it.

DataForSEO receives the questions a report's Google line captures, a Consumer View's prompts for ChatGPT, Gemini, Google AI Overviews and Google AI Mode, and on a monthly plan two Google searches a month for your brand name; Bright Data receives a Consumer View's prompts for Microsoft Copilot. When a one-time consumer snapshot is requested on a free report, DataForSEO also receives up to 15 of that report's approved questions for ChatGPT, Gemini and Google AI Overviews, once, and we store the answers it returns the same way. Both contain your brand and competitor names, both vendors return the answer text those surfaces served, and we store it. Neither receives your email address or card details.

Reviews. When a new report finishes, or when we run it by hand on an existing report, we may read the public reviews of your business, and on a paid report those of the competitors it tracks. DataForSEO receives each business's name and domain, with the city and country when the report names a market, and returns its Google listing (name, address, category, rating, review count and whether the business has claimed it; when no listing names the business's website, the names and websites of up to five it found instead), its Google and Trustpilot reviews, and search results for its name on review sites such as Clutch, of which we keep the profile that matches and up to five of the results. Bright Data receives the Facebook, Yelp or G2 page a business's homepage links to and returns that page's reviews. For each review we store its text, rating and date, the vendor's id for it and its link where the vendor gives one (a Facebook review gets an id we compute from the review itself, and no link), and on Google, Trustpilot and Yelp whether the owner replied and, except on Yelp, when. We store no reviewer's name and no reply's words, on your reviews or a competitor's, and no page we show names a reviewer. The review text goes to Anthropic, which names the themes and tags each review with the ones it carries, and to OpenAI, which checks each tag against its review, one tag at a time: a tag it rejects is not counted, a tag it could not check still counts, and the reviews page says how many it checked. We store each tag with the passage of the review it quotes and the check's verdict, and Anthropic's reading of who wrote the review: a client, unless a passage of the review says the writer is a peer, a vendor or an employee, and then that passage too. The visible text of your homepage, up to 40,000 characters, goes to Anthropic to find which of those themes it states, and we store the passage it quotes. None of these vendors receives your email address or card details.

Supabase hosts the database. Vercel hosts the site. Stripe processes payments and holds your card details. Resend delivers report-ready emails when email delivery is switched on. When the weekly client digest is switched on, Resend also delivers it to the owners of an organization on an agency plan: one email a week for each client property with two or more complete runs, saying what moved since the last audit and naming one action from its plan, with links back to this site. We record the week each digest went out on the property's own record, so it goes once; nothing else about it is stored. Nango brokers the sign-in for Salesforce and Zoho CRM connections and holds those connections' access tokens; it never receives your audit data. If you connect a CRM, that CRM (or the webhook endpoint you name) also receives data — see the section on connecting a CRM below.

Google (Search Console and Analytics) — only if you connect them from the Measured panel. Google then tells us the email of the Google account you signed in with, and once a day we pull your Search Console rows (date, page, query, clicks, impressions, click-through rate, position) and two GA4 reports (sessions, engaged sessions and conversions by landing page, source and medium; sessions by referring site) for the site and property you pick from the list Google returns. Those rows are stored in our database against your audit, each with the id of the pull that fetched it. The refresh token Google issues is stored encrypted with a key held only on the server; it is never written to logs. Nothing about your audit is sent to Google on this path — the connection reads, it does not write. Reconnecting replaces the stored token and asks Google to revoke the old one; to disconnect entirely, revoke AEOSearch from your Google account's third-party access page and email us to delete the rows. AEOSearch's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements: Google data is shown only to your account and the members you add to it, is never sold, is never used for advertising, and is never sent to an AI model or used to train one.

Slack — only if you connect a workspace from the brand profile page. Slack then tells us the workspace name and the app's own user id, and lists the channels the app can see; we store those names and the ones you choose, at most four. When a brand profile is built, the last 90 days of messages in the chosen channels are read once, handed to the model that writes the profile, and discarded — no message is stored, and people who wrote them are never looked up by name. What remains is the profile itself and the channel a claim came from. The bot token Slack issues is stored encrypted with a key held only on the server. The connection also posts, in one place and only when you ask: pressing Send to Slack on the desk puts that week's lines into the channel you pick — the question, whether it is drafted, and a link back to this site. A draft's text is never posted, and nothing is posted on a schedule. Disconnecting from the profile page asks Slack to revoke the token and the next build reads nothing from Slack.

These providers process data in facilities they operate, including in the United States. If you are outside the United States, running an audit means your information is transferred there.

Several steps on our side make outbound requests to websites, among them the Sources page's health checks and the readiness scan at /scan described above, and these. If you use pre-fill, we read your homepage and up to four pages its own navigation points at — about, services, pricing, contact — and ask a model to suggest your brand details. Each suggestion comes back with the page it came from and a sentence off that page behind it, and we look that sentence up in the page text ourselves rather than take the model's word for it: a suggestion whose sentence isn't there is dropped before you see it, and the field is shown as not found. Those quotes and page addresses are there for you to check. They reach your browser with the suggestions and stop there — what we store is what is left in the form when you start the audit, the same as if you had typed it. During gap diagnosis we fetch the competitor pages the assistants actually cited, so we can say why that page won. Once your report is complete we may also fetch a capped number of the other pages the assistants cited (your own and third parties', never a competitor's), only to see whether each page says your brand name; what we keep is that yes, no or “not read” beside the citation, and never the page. We read robots.txt before following a link off your homepage and before every diagnosis or cited-page fetch, skip whatever it asks us to leave alone, and record a page it keeps us out of as not read. We identify ourselves as a normal HTTP client and do not log in anywhere. A competitor report adds no request at all: it is built from answers we already stored, and the competitor is neither fetched nor contacted for it. When a new report finishes, or when we run it by hand on an existing report, the reviews read fetches your homepage, and on a paid report each tracked competitor's, to find the review pages it links to and to read what your own homepage says. It fetches nothing past the homepage. Before a competitor's homepage it reads robots.txt, and a homepage robots.txt keeps us out of is recorded as not read; your own homepage is the site your report is about, and we read it the way pre-fill does, without robots.txt.

One more request is your browser's, not ours. Your dashboard shows each tracked brand's favicon, loaded by your own browser straight from that brand's website — never through us, and never through a favicon service, which would hand one company your whole competitor list. That website's server sees the request the way it sees any visitor: your IP address and browser, and no referrer telling it where you were. We receive nothing back from it.

Connecting a CRM is off by default and does nothing until you turn it on from your report's integrations page. Once connected, we send data out to a third party you chose:

Where it goes. To your CRM — HubSpot, Pipedrive, Salesforce or Zoho CRM — or, if you pick the generic webhook, to whatever HTTPS endpoint you name. That endpoint is yours to vet; we check only that it is a public HTTPS address, never a private or internal one.

What we send. For a completed audit: your brand name, your domain, the email address on the audit if there is one, the audit's numbers, and a link to the report. For a lead captured by our WordPress plugin: that person's email address, their name if the form collected one, the page URL they submitted from, and the form's id. Alongside those we send the audit's internal id and completion timestamp, so a repeat delivery can be recognised rather than duplicated. Nothing else, and no other customer's data ever goes to your CRM.

Leads are personal data about someone else. If you use lead capture, the person filling in your form is your contact, not ours — you are responsible for telling them and for having a lawful basis to pass their details on. We store and relay; we do not market to them.

Your CRM credentials. Stored encrypted (AES-256-GCM) with a key held in our deployment environment, never in the database. A HubSpot or Pipedrive token you paste in is never returned by any API, never written to a log, and never shown back to you — only the last four characters, masked. The one exception is the signing secret we generate for you when you choose the generic webhook: that one is displayed once, at the moment it is created, because you need it to verify our signature. After that screen it is masked like the rest and we cannot show it to you again. If we have no encryption key configured, the whole feature is switched off rather than storing anything in the clear.

Salesforce and Zoho sign-in uses an OAuth broker. Those two connect by signing in rather than by pasting a token, and the sign-in runs through Nango (Nango Inc.), a third-party service we use for exactly that. Nango holds the access and refresh tokens for those connections; we store only a reference to the connection and the name of the CRM, never a token of yours. Nango sees your CRM authorisation; it does not receive your audit data, which goes from us straight to your CRM.

If your agency connected the CRM. Some brands are audited under an agency arrangement, where the agency has connected its own CRM and we have recorded, in a committed configuration file, which audits belong to it. When one of those audits completes, the same audit data described above — brand, domain, the audit's numbers, and a signed link to the white-label report, which opens that one report for that one agency and nothing else — is written to that agency's CRM as a deal with a note attached, or, if the agency connected a generic webhook rather than a CRM that has deals, posted to that endpoint instead. If the agency has turned on deal values for its connection, the deal also carries the published list price of your audit's plan, taken verbatim from our pricing page — never an estimate of what your business is worth. This happens only for audits explicitly listed on that agency's roster; membership is an exact id match, never inferred from your domain, plan or email address. An audit on no roster is sent to no agency.

Retention. Captured leads and CRM delivery records are deleted after 90 days. Disconnecting a CRM deletes the connection and its whole delivery history immediately. What already reached your CRM is in your CRM — deleting it there is up to you. An unfinished CRM sign-in stops working after thirty minutes and is deleted by our daily clean-up. It holds no personal data — only which CRM you picked, the id of the audit it belongs to, a random reference for the broker, and when it expires.

On plans that include content drafting, a draft can have images made for it. Nothing happens until you ask on the draft's page.

What we send out. To OpenAI's image model: the draft's title and its first few hundred characters, your approved brand profile's positioning, audience and tone, what you typed, and any reference images you picked or uploaded. Never your email address or card details.

What we store. Every image made, and every reference image you upload, in private storage that no page serves without a link we sign for you, and that link expires in an hour. Uploads join your brand kit so later drafts can use them; you can remove any of them from the draft's page. With each image we keep what you asked for, the options you chose, the model that drew it, what it cost us, and the address that asked.

On plans that include content drafting, you can connect a venue — your WordPress site, your Shopify store, or an HTTPS webhook endpoint you name — so that a draft you approve is published to it. Like the CRM connection, this is off by default and does nothing until you add a connection from your dashboard.

What we send out. The content of the draft being published, to the venue you connected, and to WordPress or Shopify its featured image too when you picked one (a webhook gets the text only). Drafts are written from your own audit's data; nothing about any other customer is in them. Publishing to WordPress or Shopify records an undo token with the delivery, so a published item can be removed again; a webhook has no undo and the page that offers it says so.

Your venue credentials. Stored encrypted the same way as CRM credentials — AES-256-GCM, key held in our deployment environment, never in the database, never returned by any API or page after you save them. If no encryption key is configured on the deployment, publishing is switched off entirely rather than storing anything in the clear.

Revoking. Revoking a connection stops all publishing through it, including any standing permission you had recorded. What was already published to your venue is on your venue — removing it there is yours to do, or use the per-item undo where one exists.

Your report is protected by having an unguessable address and nothing else — signing in adds a dashboard that lists your reports, it does not lock the report links themselves. Anyone holding that URL can read the report. We chose that on purpose — the link is the delivery mechanism of record — but it means you control who sees your audit by controlling who has the link. The terms say the same thing in the same words.

Each page under /category/ counts how often the assistants named each brand across the answers stored for every report in that category over the last 90 days. The names on it are the ones the assistants said, pooled. It never shows a report’s questions, the brand that bought it, the competitors it tracked, or any one report’s numbers, and a category with fewer than 3 reports or 60 answers shows no counts at all, so no single customer’s measurement can be read back from it. A report you ask us to delete (next section) takes its answers out of the count with it.

Indefinitely by default, because a report you paid for should still open in two years and a subscription's value is the comparison across months. Two things are the exception: captured leads and CRM delivery records are deleted automatically after ninety days. Ask us to delete an audit and we will delete the audit and everything attached to it — questions, answers, extractions, gaps and your email — within thirty days, and confirm when it is done. Deletion is permanent and the report link stops working. We keep the Stripe payment record, because tax law requires it.

Email us to get a copy of everything we hold about you, correct it, or have it deleted. We do not charge for this and we do not require you to prove a legal basis. If you are in the EU, UK or California you have these rights by statute; we extend them to everyone because running two standards would be more work than honouring one.

AEOSearch is a business tool and not intended for anyone under 18.

If we start collecting something new, or add an analytics tool or a cookie, this page changes in the same commit that adds it — and if it affects a paying subscriber we email the address on the audit first. The date below is when this page last changed.

support@aeosearch.io — for data access, deletion, or any question about this page. A person reads it.