AI transparency

coExploro provides automated product analysis of publicly accessible SaaS products for research and competitive benchmarking. A user pastes a URL; we produce a product teardown — a structured, scored summary drawn from AI vision extraction, evaluation from analyst perspectives, and a synthesis step.

This page documents which providers process your analyses, where your data lives, how human oversight works, and which sub-processors touch your analyses. It is a research-classification disclosure under EU AI Act Article 4. We do not make automated decisions about identified individuals, and we do not profile people.

Each analysis runs through a multi-stage pipeline. The table below lists the provider in each role as of the last-updated date above. Provider-side routing may relocate requests to a region selected by the provider — we do not claim single-region routing for third-party model providers.

We change models as better ones ship; providers above are updated on this page when they change.

We analyse only the URLs you submit. For each URL, we visit the page(s) with a headless browser, capture screenshots, and extract observable facts with vision models. We do not crawl pages you did not request.

Submitted URLs must resolve to public HTTP/HTTPS hosts. We reject loopback, private network ranges, link-local addresses, credentialed URLs, and non-standard ports before any browser runs; the same check re-runs immediately before navigation to prevent DNS rebinding.

coExploro is a research-classification tool — it exists to help people compare and understand product surfaces, not to target or profile individuals. We do not extract personal information by design; where a screenshot incidentally captures a visible name or email on a public page, it persists as an image artefact, not as a structured person record.

We do not train AI models on your submissions, on the outputs we produce, or on any data captured during an analysis. We do not sell your analyses. Analyses are transmitted only to the active sub-processors disclosed below (infrastructure vendors and the AI model providers that run the pipeline); they are not shared with any other third parties for advertising, resale, or training.

The third-party model providers we use (Google, Anthropic, OpenAI) receive prompts and, at the extraction and grounding stages, screenshots. Each provider is bound by its own published terms of service, which we treat as the ceiling for provider-side behaviour, not as a substitute for our own commitment. We do not opt into provider-side programmes that would allow customer prompts or outputs to be used for improving shared models. Provider-side request retention is governed by provider terms; we do not control it directly.

A teardown is produced in stages. We first record what is observably present on the captured pages, then generate analysis from that record rather than from the images directly. Findings are traceable to the part of the page that produced them, so any judgement can be checked against the source.

Exported artifacts are marked as AI-generated in a machine-readable format (EU AI Act Article 50(2)): PDF downloads carry the marking in both the document properties and embedded XMP metadata, and PNG downloads carry it in embedded text metadata, each using the regulation's "artificially generated" wording.

You retain full control of each output. A teardown is a draft for you to read, edit, share, or discard at your discretion; nothing is actioned on your behalf beyond producing the teardown itself.

coExploro makes no automated decisions about identified individuals within the meaning of GDPR Article 22. The pipeline does not profile, score, rank, or select people — it describes publicly visible product surfaces.

• The UX score is heuristic. It is calibrated against the pattern of observable product surfaces; it is not an audited, certified, or industry-benchmarked metric.
• Analyst coverage is limited to a fixed set of roles. Real-world stakeholder diversity exceeds this; treat the outputs as starting points for team discussion, not as a replacement for it.
• English is the only supported interface language at launch. Non-English pages are still analysed, but the narrative outputs are English-only.
• We monitor upstream model drift via observability tooling, but drift detection is not automated. Outputs for the same URL may differ from run to run because the underlying models are stochastic.

We process the URLs you submit and the analyses derived from them. We are the data controller for user-submitted analyses under the GDPR. Every vendor listed below is an active sub-processor; where a data flow depends on environment configuration or only occurs on a specific event — such as starting a paid checkout — the entry says so explicitly.

Active AI model providers

Each pipeline stage has a primary provider and a fallback chain. If the primary call fails, the same stage is retried on the next provider in the chain, which receives the same payload the primary would have received (including screenshots on image-bearing stages).

• Anthropic — model provider. Receives screenshots and prompts on image-bearing steps, and text-only prompts on the rest. Region: global (per provider).
• Google — model provider. Receives screenshots and prompts when it serves an image-bearing step, and text-only prompts otherwise. Region: global (per provider).
• OpenAI — model provider. Receives screenshots and prompts when it serves an image-bearing step, and text-only prompts otherwise. Region: global (per provider).

Active infrastructure sub-processors

• Railway Pro — application hosting, PostgreSQL, Redis. Region: US Virginia (us-east4-eqdc4a).
• Cloudflare R2 — screenshot and document storage. Bucket location: ENAM (Eastern North America). No EU jurisdictional restriction is configured for the active bucket.
• Browserbase — headless Chromium sessions for URL capture. Region: multi-region (cloud Chromium).
• Langfuse Cloud — LLM observability: receives per-AI-call trace metadata (model name, stage identifier, prompt / completion token counts including Anthropic cache tokens, latency, fallback status). Input fields are limited to analysis ID and URL origin + pathname (query and hash stripped); raw prompts, model outputs, and user content are not sent. Region: US. Active when LANGFUSE_PUBLIC_KEY and LANGFUSE_SECRET_KEY are configured; tracing is gracefully disabled otherwise.
• Resend — transactional email delivery for account password reset and email verification, and for run emails. Receives recipient email, the password-reset link or verification link (each containing a short-lived single-use token, including the email verification token), and standard SMTP envelope metadata. Run emails also send the recipient address and the teardown link. The visitor's email contains fixed text and the teardown link only: never the analysed site's name or any text from the teardown, because anyone can type any address into the field. The owner's email also names the analysed site's host. No screenshots, no marketing content, no persistent profile data. Delivery region is provider-configurable; account data, email metadata, logs, and API records are stored in the US per Resend's published data-residency documentation. Active when RESEND_API_KEY and RESEND_FROM_EMAIL are configured; when keys are absent, email-dependent auth flows return an explicit 503 and no email is delivered, while local dev and CI can run the rest of the API without sending email.

  On the wait screen of a teardown run without an account, a visitor may give an email address. It is used once, to send one email with the link to that teardown when the run finishes or stops. The address is deleted once that email is sent or can no longer be sent, and at the latest 7 days after it was given.

  A verified account owner who starts a teardown from the form or by upload gets one email with the link when it finishes or stops while they are away and not watching it, sent to the account address. The owner's email contains the analysed site's host and the link. Both run emails are sent through Resend.

• PostHog — product analytics: receives client-side web usage events (such as page views and feature interactions) from the browser when NEXT_PUBLIC_POSTHOG_KEY is configured. The browser sends them, and any session recording, to a route on coExploro's own web domain, and our web server forwards them to PostHog without storing them. That forwarding passes on your IP address, which PostHog uses for coarse geolocation, and your browser's user agent, but not your cookies; URLs attached to events are reduced to origin and pathname, with query strings and hashes stripped before send, while the standard UTM fields (utm_source, utm_medium, utm_campaign, utm_content, utm_term) are kept as their own fields. The address your visit started on is also sent with feature-flag requests; in it, sensitive parameters such as tokens and email addresses and recognised advertising click identifiers such as gclid and fbclid are masked, while other query parameters and any fragment are sent as they are. When session replay is enabled for your visit, the recording is masked at the point of capture: text entered into standard text inputs and text areas is replaced with masking characters as it is captured (checkboxes, radio buttons and file pickers are not masked), so what you type into those fields is not readable in the recording; the page and navigation URLs the recorder attaches are reduced to origin and pathname; and very short visits are discarded rather than stored. A recording is a stream of the page's structure and your interactions with it, not only what was visible: it includes unblocked page text and element attributes as rendered — which can include what the page shows back to you, saved or not, such as your account email in the navigation, the names and links of competitors you have saved, and image addresses — together with clicks, cursor movement, scrolling, and the state of checkboxes and menus. Masking replaces typed text with a string of similar length, so roughly how much you typed remains visible. We do not use PostHog's automatic event-capture; the events we collect are the ones we instrument by name, plus a page-leave event the PostHog library sends when a page is unloaded: when you close the tab, reload the page, or leave it by a full page load. Each page-view event records how long the previous page was open and how far down it was scrolled, and the page-leave event records the same for the page being left. A person profile is created only for signed-in users and is keyed by account id (your email is not sent as a profile property). Persistence is cookieless (in-memory). When a visitor answers the optional question on the wait screen about how they found coExploro, the browser sends one event with a fixed label for the answer chosen, where on the site it was asked, and whether the visitor has an account. Separately, when POSTHOG_API_KEY is configured, the coExploro API relays five Chrome-extension events covering popup open, check completion, library hit or miss, and teardown click. Each relayed extension event carries an event name and a timestamp only — no site hostname, no page content, no URL, and no finding text. The extension posts these events to the coExploro API rather than to PostHog, so PostHog does not receive the device IP address for them. The relay uses a fixed extension identifier and does not create a person profile. When POSTHOG_API_KEY is configured and ANALYSIS_LIFECYCLE_TELEMETRY_ENABLED is true, the coExploro API and its background workers send three teardown lifecycle events — a teardown run started (including a retry of a failed teardown), completed, and failed. Each event carries the teardown's identifier, an ISO timestamp, and a fixed sender label. The start event also carries a fixed label for where the run was started from; a failure event also carries a fixed label for where it failed — a processing stage, a queueing failure, or a Compare run stopped before a refund for the comparison was attempted, regardless of the refund's outcome. They carry no URL, page content, or finding text. When the run was started from a browser our team has marked as its own, or from the Claude desktop app's built-in browser, which the API recognises from the user agent its request carries, all three events also carry a fixed label saying so, and the teardown's record keeps that label. These events are sent from coExploro's servers rather than the browser, so PostHog does not receive the visitor's IP address for them. PostHog identifies these events with a value derived from the teardown's identifier, not a user or device identity, and creates no person profile for them. They can be joined to browser events that carry the same teardown identifier. When POSTHOG_API_KEY is configured and MCP_CALL_TELEMETRY_ENABLED is true, the coExploro API also sends one event for each MCP request that starts a connection, lists the tools, or calls a tool, once the API has sent its answer, up to a fixed daily limit per server process. A request is counted even when its answer reports an error. A request refused before processing, or one whose client hangs up before the answer is sent, is not counted. Each event carries the request type, the tool name for a tool call (or a fixed "unknown" label), a fixed label for the client application family, read from the name the client gives when it connects (such as Claude, ChatGPT, or Cursor, or "other"), an ISO timestamp, and a fixed sender label. For a tool call, the client family is read the same way from the user agent the request carries, and a fixed label says whether the call succeeded, returned an error from the tool, or was refused as an invalid request. When a corpus lookup finds no teardown, the event also carries a fixed "not found" label. It carries no tool arguments — no product host, sample name, or share token — and no other tool output. These events are sent from coExploro's servers, so PostHog does not receive the caller's IP address for them; PostHog identifies them with one fixed identifier and creates no person profile for them. Region: US. The browser flow requires NEXT_PUBLIC_POSTHOG_KEY; the extension relay, server lifecycle events, and MCP request events share POSTHOG_API_KEY, but lifecycle events and MCP request events are each enabled separately from the Chrome-extension relay, by ANALYSIS_LIFECYCLE_TELEMETRY_ENABLED and MCP_CALL_TELEMETRY_ENABLED. The browser key and server key can be configured independently. When both keys are unset, no PostHog events are sent.
• Brandfetch — company-name to website and logo resolution for URL autocomplete. Active when BRANDFETCH_API_KEY is configured and external suggestions are enabled. When you type a competitor name and your saved history has fewer than three close matches for it, our backend (never your browser) sends a sanitized search term to Brandfetch to resolve a matching website and logo — for a pasted URL or domain, the path, query, and fragment are stripped and only the hostname may be sent; no account, history, or analysis data is sent. Region: global (per provider).

Active payment processor

• Paddle — Merchant of Record/payment provider and active sub-processor of payment data for paid checkout. When you start or complete Paddle-managed checkout, Paddle processes the details you enter at checkout — email address, country and, where required, postal code or region, optional business/VAT information, and payment method details — together with checkout, transaction, subscription, tax/VAT, refund, and customer-support records. Payment card details are entered directly into Paddle's checkout and are never stored on coExploro infrastructure. Region: global (per provider).

Chrome extension. The extension reads the page you are on only when you ask it to, and never uploads what it reads. When the popup opens it sends the current tab's hostname to coExploro's own library endpoint, to ask whether a published teardown already exists for that site; that request carries no account credentials, and the hostname is not passed on to PostHog or to any other sub-processor. The analytics events described above are a separate flow and carry no hostname at all. The full page URL leaves the browser only when you click through to run a teardown, and then it goes to coExploro as the address you asked us to analyse. Sites you choose to track, and the comparison between one check and the next, are held on your own device under a hashed site name and are never uploaded.

Retention (active stack). Application and infrastructure logs are retained for 30 days by default. Session replay recordings are retained for 30 days and are then deleted by our analytics provider. Stored screenshots and analysis records are retained indefinitely at present — automated account-triggered deletion is not yet available. Answers to the optional question on how a visitor found coExploro, and the campaign tags of the first link a new account came from, are kept with those analysis and account records. You may request deletion of your analyses, screenshots, or other data held about you at any time via the feedback channel below; fulfilment today is handled manually by the coExploro team. Your right to erasure under GDPR Article 17 applies regardless of whether automated deletion is available. Provider-side request retention is governed by each provider's terms. Retention terms for Paddle-managed checkout records are governed by Paddle's published buyer and privacy terms, alongside any mandatory rights that apply.

Session continuity. Where repeat captures of the same domain require authentication or cookie-wall dismissal, we may retain browser cookies observed during capture. Cookies are scoped to your account and the target domain; they are never reused across accounts.

Questions about this document, the providers we use, or the data we hold should reach us at admin@coexploro.com.

• 2026-10-18 — Model providers. Anthropic now also receives screenshots with prompts on image-bearing steps, not only as a fallback. The provider entries now describe Google and OpenAI by the payload they receive when they serve a step, and the provider table names Anthropic for vision and language analysis.
• 2026-10-17 — How visitors found coExploro. The PostHog entry now describes the event sent when a visitor answers the optional wait-screen question on how they found coExploro (the answer chosen). The MCP request event for a tool call now carries a client family read from the user agent and a fixed label for whether the call succeeded, returned an error from the tool, or was refused. The retention note now names the stored answers and the campaign tags of the first link a new account came from.
• 2026-10-17 — Run emails. The Resend entry now describes the visitor address collected on the wait screen, its one-email use and deletion rule, and the email sent to a verified account owner who is away when a run finishes or stops. It also lists what a run email carries.
• 2026-10-15 — MCP corpus misses labelled. The MCP request event for a corpus lookup that finds no teardown now carries a fixed "not found" label. It still carries no tool arguments, so never the host that was asked about.
• 2026-10-09 — Team-run label on teardown lifecycle events. The teardown run start, completion and failure events now carry a fixed label when the run came from a browser our team marked as its own or from the Claude desktop app's built-in browser, and the teardown's record keeps that label, so our own test runs can be left out of the counts.
• 2026-10-09 — Time on page and scroll depth disclosed. The PostHog entry now names the two measurements page-view events record for the previous page, how long it was open and how far down it was scrolled, and adds the page-leave event the PostHog library sends when a page is unloaded (closing the tab, reloading, or leaving by a full page load), which records the same for that page.
• 2026-10-08 — Analytics sent through our own domain. Browser analytics events and session recordings now reach PostHog through a route on coExploro's own web domain instead of directly from the browser. Our web server forwards them without storing them and passes on the visitor's IP address, so PostHog's coarse geolocation still reflects the visitor; it does not pass on cookies.
• 2026-10-06 — MCP request counts disclosed. Added the separately enabled server-side event the coExploro API sends for each answered MCP request that starts a connection, lists the tools, or calls a tool, up to a fixed daily limit. The PostHog entry now describes its request type, tool name, client family, time, and sender label, and states that it carries no tool arguments or output.
• 2026-09-28 — Teardown lifecycle analytics disclosed. Added the separately enabled server-side teardown run start (including retries), completion, and failure events. The PostHog entry now describes their identifier, origin, failure stage, time, and sender label alongside browser events and the Chrome-extension relay.
• 2026-09-01 — Session replay wording narrowed. The analytics entry above previously said that text you type into form fields never leaves your browser in readable form. That is true of standard text inputs and text areas, whose typed text is replaced with masking characters as it is captured — but not of checkboxes, radio buttons or file pickers, and not of the same value where unblocked page text or an element attribute shows it back to you, saved or not, which a recording carries as rendered. The entry above now says exactly that, describes what a recording contains beyond the visible page, distinguishes the URLs attached to events from the starting address sent with feature-flag requests, and notes that the standard UTM fields are kept while recognised advertising click identifiers are masked. Nothing about what is collected changed; the description did.
• 2026-09-01 — Session replay, and a narrower technical disclosure. Product analytics may now record a masked session replay: form input is masked at the point of capture, URLs in the recording are reduced to origin and pathname, and very short visits are discarded. Automatic event capture stays off and persistence stays cookieless. Separately, this page no longer publishes model version identifiers or an internal breakdown of pipeline stages — neither is required for the disclosures this page makes, and both went stale between edits. That narrowing removed no disclosure: providers, the data each receives, and your rights are unchanged and stay listed above. Retention is unchanged for everything except the new replay recordings, whose retention period is stated in the retention section above.
• 2026-08-20 — Extension data flows corrected. An earlier draft of this page said extension analytics events could include the site hostname on a library hit or miss. They cannot: the extension records an event name and a timestamp and has no way to attach a property to either. The hostname reaches coExploro only through our own library lookup, which is now described as its own flow, alongside the full page URL handed over when you click through to run a teardown.
• 2026-08-19 — Extension analytics relay. Added the independently configured API-side PostHog relay for five Chrome extension events.
• 2026-08-15 — UX score narrowed to six dimensions. Mobile responsiveness was retired as a scored dimension because a desktop capture never measured it, and a dimension the model cannot judge is now excluded from the score rather than averaged in at a neutral value. Extraction output changed shape; no change to sub-processors or to what data leaves your account. The dated record of score-formula changes lives on the methodology page.
• 2026-08-06 — Machine-readable AI marking. Every PDF and PNG export now embeds machine-readable metadata identifying the content as artificially generated (EU AI Act Article 50(2)); this page remains the human-readable half of that disclosure.
• 2026-06-15 — Brandfetch brand search. Added Brandfetch as an active infrastructure sub-processor for company-name to website and logo resolution in URL autocomplete. A sanitized search term (a company name, or only the hostname of a pasted URL) is sent server-side only when your saved history has fewer than three close matches; gated behind a default-off flag.
• 2026-06-14 — PostHog analytics. Added PostHog as an active infrastructure sub-processor for product analytics (cookieless, no autocapture, no session replay; identified-only person profiles; URLs reduced to origin and pathname).
• 2026-06-10 — Paddle activation. Moved Paddle from feature-gated wording to an active payment processor disclosure and enumerated the checkout data Paddle processes as Merchant of Record.
• 2026-05-22 — Paddle billing readiness. Updated Paddle from planned-only wording to feature-gated payment processor wording for paid checkout readiness.
• 2026-05-20 — Email verification. Updated Resend disclosure to include account email verification in addition to password reset.