The banner is not there because “analytics is illegal”. It is there because browsers store identifiers, ePrivacy-style rules care about storing information on a device, and GA4’s default web stream stores a first-party cookie. Teams then wire Consent Mode so Google still receives some signals when the user clicks reject, and the dashboard fills gaps with models. That stack is coherent. It is also why the weekly session count is a political number.
SiteLine’s tracker is built so this collect path does not set an analytics cookie. That is a narrower claim than “GDPR solved”. This page draws the line. It is not legal advice; if a regulator reads the facts differently, that reading wins. Product facts: /docs/privacy and /privacy.
Why GA4 shows up in the CMP
A GA4 tag on a marketing site typically:
- Writes
_ga/_ga_*in the first-party context. - Sends hits to Google, who is at least a processor and, in Ads-linked setups, entangled with a much larger identity graph.
- Invites Google signals, advertising features, and audience export — each of which makes counsel more nervous.
Consent Mode v2 is Google’s answer for EEA ads and measurement. It is not a substitute for a lawful basis, and it does not make rejected traffic appear as a full event stream. If your CMP reports 40% accept on analytics storage, GA4 is describing 40% of eligible browsers plus whatever you are willing to treat as modelled.
A cookieless competitor that still drops a first-party id cookie is not a banner strategy. Read the network tab. If Set-Cookie appears on the analytics response or document, you still have a storage conversation.
What SiteLine does not store in the browser
No first-party analytics cookie. Collect is fetch with keepalive and credentials: 'omit'. Unique visitors are computed on the server: SHA-256 of truncated IP (/24 IPv4, /48 IPv6), user agent, and a daily rotating salt. Hash resets UTC midnight. Raw IP is not stored on the event. Hostname allowlist. Bots filtered.
That design is why SiteLine says a consent banner is not required for analytics cookies, because there are none for this tracker. You remain responsible for:
- Your own privacy notice and lawful basis for whatever you collect, including hashed identifiers.
- Every other script on the page (ads, replay, live chat, A/B tools).
- Whether your jurisdiction treats IP-derived identifiers as needing consent rather than legitimate interest. SiteLine does not decide that for you.
Australian Privacy Act, UK GDPR, EU GDPR, and US state laws do not collapse into one “cookieless = skip the notice” rule. Publish a notice. Link /privacy if you use SiteLine. Do not copy a competitor’s “no cookie banner needed!” hero and call it a DPIA.
Banner, proxy, and ad blockers are three different problems
| Problem | What people try | What actually happens |
|---|---|---|
| Cookie consent for GA4 | CMP + Consent Mode | Rejected users vanish or become models |
Ad blockers dropping google-analytics.com / GTM |
Server-side GTM, first-party domains | Some recovery; you still have Google cookies if you set them |
| Ad blockers dropping third-party analytics hosts | First-party proxy | More events survive; identity model unchanged |
| Counsel wants fewer processors | Switch vendor | New DPA; the banner only shrinks if storage actually stops |
SiteLine’s first-party proxy is the third row: you reverse-proxy /js/script.js and POST /api/analytics/event to your SiteLine origin. SiteLine does not manage CNAMEs in v1. Proxying does not create a cookie, and it does not anonymise other tools you have not removed.
If the remaining pixels still need consent, keep the banner for those and stop gating the cookieless pageview on the same “Accept analytics” toggle. Mixing them is how you recreate the hole you just left GA4 to escape. The operational version of that story is why teams leave GA4.
Search Console never lived in the banner
Search Console data is collected by Google from search, not from a script you add. SiteLine’s import is read-only (webmasters.readonly), 16-month backfill, kept while you subscribe, 25k rows per day per report, reimport every 4 hours of the last 7 days, including fresh data before Google finalizes it. Connecting it does not set a cookie on your marketing site. It does mean Google user data sits in SiteLine under the Limited Use rules described in the privacy policy. Agents you authorise (Claude, ChatGPT, Cursor via MCP) can query it; that is a sharing choice you make.
What to tell counsel in one paragraph
We propose replacing the GA4 browser tag on the public site with SiteLine’s cookieless tracker: no analytics cookie, credentials omitted on collect, daily hash of truncated IP and user agent, no cross-day identity, no Ads, no replay. Search Console remains Google’s; SiteLine imports a copy read-only. Other tags stay behind the CMP until we remove them. This is a reduction in browser storage for analytics, not a claim that personal data is absent.
If they want the identity mechanics, send cookieless analytics vs GA4. If they want the vendor grid, privacy-first comparison. Install: /docs/script. Trial (card required, ~50k event visibility, 7 days): /register. Starter is $4.99 / 1M events.
FAQ
If we keep GTM for ads, do we still need a banner?
Almost certainly, for those tags. Removing GA4 does not clean a container full of marketing pixels. SiteLine only speaks for its own script and collect endpoint.
Does the daily hash require consent as a cookie equivalent?
Some regulators treat non-cookie identifiers under the same ePrivacy storage rules; others focus on cookies specifically. SiteLine does not write storage in the browser for analytics. Whether the server-side hash needs consent or legitimate interest is a question for your counsel, not a feature flag.
Can we load the script only after Accept?
You can, and you will recreate consent-gated measurement. If the point of leaving GA4 is a complete pageview series, load the cookieless script like any other first-party asset you have a basis for, and keep the banner for tools that actually store or advertise.