Analytics That Survive a Website Rebuild
Most rebuilds quietly break Google Analytics, Meta Pixel, GTM, Hotjar, and LinkedIn Insight — and the owner notices six weeks later when the numbers look wrong. How SOSEI preserves every tracker, gates them behind consent, and avoids the silent-zero data outage.
The most expensive bug in a typical website rebuild isn’t a broken layout or a missing page. It’s the moment, several weeks after launch, when the marketing team realises that conversions are no longer firing into Google Ads, that Meta Pixel hasn’t recorded a single event, and that the historical analytics view in GA4 has a hard gap on launch day.
Tracking debt compounds: every week of broken pixels means a week of mis-attributed ad spend, retargeting audiences that can’t be rebuilt, and conversion data that’s lost forever. SOSEI treats analytics preservation as a first-class pipeline step, not an afterthought.
Stage 1: detection during scrape
Before any AI runs, SOSEI’s scraper sweeps the source site for every known tracking pattern. The list above isn’t exhaustive — the scraper also catches Pardot, HubSpot tracking, Mixpanel, Segment, and a long tail of less common tools — but those nine cover ~95% of real-world small-business sites.
Detection is signal-based, not pattern-matching on partial code. For Google Analytics 4 the scraper extracts the actual measurement ID (G-XXXXXXXXXX); for GTM the container ID (GTM-XXXXXXX); for Meta Pixel the pixel ID argument to fbq('init', …); for LinkedIn the _linkedin_partner_idvalue. Without these IDs the rebuild can’t reinstall the right account’s tracking.
Stage 2: re-installation in the generated site
Every detected tracker is re-installed in the rebuild at the same logical injection point: GTM in <head>(with the noscript iframe near body open), GA4 in head if not already inside GTM, pixels at the right body position. The same IDs the original site used — so historical data continuity is preserved.
This is the difference between “reinstalling Google Analytics” and “preserving Google Analytics.” Many agency rebuilds create a fresh GA4 property, which means a clean reporting break on launch day and orphaned historical data. SOSEI keeps the same property.
Stage 3: consent gating
This is the GDPR-mandatory part most rebuilds skip. Every non-essential tracker is wired behind the cookie consent banner (see the GDPR cookie banner explainer): nothing fires before the user opts in, and previously-fired trackers are dynamically stopped if the user opts out later.
Concretely, the generated site implements the IAB TCF v2.2-style category model:
- Strictly necessary— cookie consent state, language preference, security tokens. Always on.
- Analytics— GA4, Plausible, Umami, Clarity. Off until consented.
- Marketing— Meta Pixel, LinkedIn Insight, TikTok Pixel, GTM (if it loads marketing tags). Off until consented.
- Preferences— Hotjar session replay, customer-engagement tools. Off until consented.
Stage 4: server-side validation
After publish, the generated site self-checks: does the GA4 property receive a page-view from the new domain? Does the Pixel return a 200 for an init event? The validation runs in the dashboard’s post-publish step so the owner sees a green checkmark per tracker or a flag for any that need attention.
What this means for your numbers
Two practical outcomes worth flagging in advance:
- Total page-view volume may drop 10–25% in week one— not because the site is broken, but because the new consent banner gives visitors a real choice and a meaningful fraction will decline. This is the GDPR- compliant baseline you actually have; the previous number was a fiction.
- Conversion rate often goes up— modern layout, faster load times, and better mobile UX more than compensate for the consent dropoff. Net revenue usually rises even when raw traffic appears to fall.
Edge cases the scraper can’t catch
The scraper sees what’s in the HTML. It can’t see trackers that load dynamically from a tag-manager container it doesn’t have access to, server-side CAPI integrations (Meta Conversions API server-side, Google’s Measurement Protocol) implemented in PHP or Node, or trackers loaded only in checkout flows the scraper doesn’t walk through.
These need to be re-added manually after launch. The dashboard has a free-text “additional tracking” field on every project for exactly this purpose, and any custom scripts you paste in are re-injected into every regenerated version.
Want to see which trackers are on your current site — and which ones might be silently broken already? The free analyzer flags every detected tracker as part of the 40-point audit.