Theme preference in your browser, product telemetry in ours.
This page explains what SHVL currently uses for browser storage, Google Analytics 4, Ahrefs Web Analytics, and technical cookie-like behaviour on the public site.
SHVL currently uses local browser storage for theme preference, a small SHVL analytics helper for selected funnel events, Google Analytics 4, and Ahrefs Web Analytics on public marketing pages for page-level measurement. That is a much narrower setup than an ad-pixel stack, but it is still worth describing clearly.
Browser storage on public pages
The public site stores a small amount of state in the browser so the interface behaves properly.
- Theme preference is stored locally as
shvl-theme. - Free tool pages use local sign-in markers after login so they can open without calling Supabase on every tool page:
shvl_signed_in,shvl_auth_seen_at,shvl_user_id, andshvl_email_domain. - This is browser storage rather than a marketing cookie.
- It is there to keep the interface consistent between visits.
Analytics in use
Public marketing pages load js/analytics.js for selected funnel events such as demo requests, checkout clicks, and install intent, plus Google Analytics 4 measurement ID G-KQ4M2NMLQD and a small Ahrefs Web Analytics tag for page-level measurement.
- The payload is meant to stay content-light and conversion-focused.
- The current goal is product telemetry, not ad retargeting.
- Signed-in free-tool events may include tool name, page path, Supabase account id, and email domain so usage can be tied back to an account.
- GA4 is loaded with anonymised IP settings, Google signals disabled, ad personalisation signals disabled, and Consent Mode defaults set to denied for analytics storage and advertising storage.
- Public-site analytics is no longer routed through the old shared CompeteDesk endpoint.
- Workflow and signed-in pages may also keep normal auth or operational state where required.
Where necessary provider behaviour may still apply.
Even without a broad marketing-cookie setup, hosting, auth, and security providers may still set strictly necessary cookies or challenge tokens in some flows.
- Signed-in routes can require normal auth or session behaviour.
- Anti-abuse and security tooling may use technical cookies or tokens if needed.
- Those controls are different from cross-site advertising profiles.
What the current public-site setup is not.
The current acquisition surface is not intended to behave like a heavy ad-tech property.
- No current claim that SHVL uses retargeting pixels across the public site.
- No current claim that public-site telemetry is being used to build ad audiences.
- No current claim that the site is cookie-free in an absolute legal sense if technical provider behaviour still exists.
If the tracking model changes, this page should change too.
If SHVL later adds materially broader analytics, testing tools, or marketing pixels, this page and the site behaviour should be updated so the public description stays exact.
Need the workflow to feel legible, not sneaky?
That applies to browser storage, telemetry, and the workflow boundary itself.
Related pages: Privacy, Data handling, Terms, and Accessibility.