Google user data we access
If you use Sign in with Google, we receive your Google profile identifier, name and email address. We use these fields only to create or sign in to your Webshop Vitals account.
If you separately connect Google Merchant Center, we access the Merchant Center accounts available to you, the account you select, processed product data, product and account diagnostics, eligibility status, and product performance metrics. We use this data only to build your audit, compare it with your storefront, show your reports, and run monitoring you request.
If you separately connect Google Search Console, we access the properties available to you and, for the property associated with your store, read search analytics, sitemap status, and URL inspection results. We use this data only in your technical audit and monitoring.
Google Sign-In, Merchant Center, and Search Console permissions are requested in separate steps. Connecting one feature does not authorize the others.
Other data we collect
Store data: the URLs we crawl on stores you ask us to scan, the HTML those URLs return, and the product information we extract from it.
Usage data: counts of scans, pages crawled, products analysed, AI requests and exports, used to enforce plan limits.
What we do not collect
We never store raw IP addresses for anonymous scans. We store a salted hash so we can enforce a per day limit and nothing else.
We never store your Google access or refresh tokens in readable form, and we never display them in the interface.
We do not place orders, submit forms, enter payment details or create accounts on the stores we scan.
How we protect Google user data
Google OAuth refresh tokens are encrypted at rest with authenticated AES-256-GCM encryption using a dedicated application encryption key. Tokens and encryption keys are never rendered in the interface or written to application logs.
Google user data is encrypted in transit with HTTPS/TLS. Access to stored data is enforced on the server: authenticated users may access only organizations and stores of which they are members. Production systems and secrets are restricted to authorized personnel and service accounts that need them to operate the service.
OAuth requests use PKCE, a signed and time-limited state value, and secure, HTTP-only session cookies. We request the minimum Google scope available for each feature and keep Merchant Center and Search Console authorization separate.
We monitor application failures without logging OAuth tokens. If you disconnect Google, we delete the stored credential and attempt to revoke it with Google. You can also revoke access from your Google Account security settings.
Retention
Raw and rendered page HTML is deleted after 7 days. It exists only so a report can show you the exact markup we saw.
Google Merchant Center and Search Console data normalized into audit results, such as issues, scores, product snapshots and performance summaries, is retained for as long as your account exists so historical trends remain meaningful.
Google OAuth refresh tokens are retained only while the integration is connected. Disconnecting Google deletes the stored credential. Short-lived access tokens are held only in server memory while a Google API request is made and are not stored in the database.
Unclaimed anonymous scans and the throwaway workspaces holding them are deleted after 7 days.
Deletion
You can delete your account from Settings. Deleting an organization removes its sites, scan data, stored HTML, product snapshots, OAuth tokens, reports and every other row that belongs to it. This is enforced by database level cascades, not by a cleanup script that might not run.
Disconnecting Google deletes the stored refresh token and attempts to revoke it with Google. Historical scans are kept so your trend data survives.
Contact
Questions about any of the above: support@webshopvitals.com.
Core safeguards are implemented in the product: deletion runs on database cascades, Google refresh tokens use authenticated encryption with a key the interface never exposes, organization access is checked on the server, and anonymous scan limits use a salted hash instead of a stored address.
