How to Build a World-Class GA4 Setup, Part 2: Correct Collection — Audit, Server-Side & Conversions

The property presented well. Over the thirty days before the audit it recorded 2,328 events, 401 active users, and 527 sessions, with a daily event count moving between 24 and 113. Data flowed. Realtime showed users. Six events carried the key-event star and eight custom dimensions sat registered and populated. A stack engineer glancing at the admin screens would have found nothing to alarm them — and that impression is exactly the problem. This is Part 2 of a three-part series; Part 1 built the measurement plan, and this part is the dramatic core: finding and fixing the silent failures before touching architecture.

The case study behind this series is an anonymized Central-California pest-control operator — call it Cypress — running one GA4 property across four counties. Its revenue arrives entirely offline: a homeowner finds a wasp nest in April or a rat in a November crawlspace, calls the phone number or submits a form, and a technician books the job days later. No cart, no checkout, no online transaction. The property has exactly one job, to count the leads that become booked jobs, and it was failing at that job while passing every surface check GA4 offers.

The through-line across everything that follows is that GA4 gives an operator almost no negative feedback. A wrong host returns nothing the application logic reads. A malformed event returns the same acknowledgement as a valid one. An over-broad conversion looks identical to a well-chosen one until the bidding money follows it. A two-month retention cap surfaces only when someone tries to build the report it forbids. The property passed every check it could run on itself. The audit’s contribution was to run the checks it could not.

The default GA4 audit is a person clicking through admin screens and writing down impressions. That method samples rather than enumerates, records readings without evidence, and collapses factual errors and reasoning errors into one pile. A durable audit defeats all three with two layers, and it keeps them strictly separate.

Layer one: a deterministic, read-only inventory

The first layer establishes what is true. It reads a fixed, ordered list of endpoints through the GA4 Admin API and the Data API, under a named service-account identity, using short-lived impersonated tokens rather than a downloaded key — so a leaked credential is worth one hour of read access, not a permanent one. Scopes are least-privilege: analytics.readonly for reporting, analytics.edit for configuration reads, and a distinct analytics.manage.users.readonly for the access-bindings read (forget it and Google returns ACCESS_TOKEN_SCOPE_INSUFFICIENT — a scope error, not a permissions one). Every raw JSON response is persisted to a timestamped directory before anyone interprets a field. A finding without a response file on disk is not a finding; it is a memory, and memories do not survive review.

That inventory is what read the two-month retention value verbatim, enumerated all eight custom dimensions, named the six key events, and pulled the Data API traffic mix that exposed google/cpc at 46 sessions flowing into a property with no Google Ads link. Facts first, judgment second.

Layer two: an adversarial multi-agent pass

The inventory says what is configured. It cannot say what that configuration means, or whether the auditor’s interpretation is correct — and interpretation is where audits fail, because a plausible-sounding measurement claim can be confidently false. The second layer supplies an adversary: a workflow of eighteen agents organized as nine measurement pillars, each staffed by a researcher who investigates and a fact-checker whose only mandate is to break the researcher’s claims. Self-critique inherits its own blind spots; a fresh agent pointed at a claim with instructions to falsify it starts somewhere else.

The verify pass earned its cost by reversing four over-claims a competent single auditor would have shipped: that Consent Mode v2 was a legal mandate (it is a Google Ads requirement for serving ads into the EEA and UK, not a statute, and this is a US-only operator); that the server payload leaked PII (it carried none — client_id, currency, a value, and identifiers, no names or emails); that Google Signals would corrupt data (it was already off, and its real harm at low volume is threshold-suppressed report rows, not wrong numbers); and that the legacy Google Ads offline-conversion path was still buildable (it was blocked for new accounts on 2026-06-15). More valuable still, the cross-pillar read surfaced an omission every researcher had half-seen: Enhanced Measurement’s form-interactions setting auto-fires GA4’s own form_start/form_submit on top of the site’s hand-built form events, double-counting form activity nobody had reconciled.

The single most consequential defect sat in two server routes, both posting their server-side Measurement Protocol event to https://www.google.com/mp/collect. That host is wrong. The documented and only functional collection endpoint is https://www.google-analytics.com/mp/collect. The distinction looks cosmetic. It is total. The audit did not infer it from documentation — it reproduced the failure live, sending the identical payload to each host with curl:

• POST https://www.google.com/mp/collect → HTTP 404 — the path does not exist on that host; the request is rejected before any GA4 system sees a payload.
• POST https://www.google-analytics.com/mp/collect → HTTP 204 — the standard Measurement Protocol acknowledgement, a bare "accepted, no content."

The failure is a delivery problem outside GA4, not a data-quality problem inside it. The generate_lead event the contact API constructed on every form submission — client ID, currency USD, a value, lead metadata — was serialized, posted, and thrown away by a Google web server that has nothing to do with analytics ingestion. Because Cypress has no online transaction, this server event was the entire point: the ad-blocker-resistant record of a lead that would count even when a visitor’s browser blocked the client tag. It reached GA4 zero times across the property’s life, from creation on 2026-04-24 through the audit.

The failure was silent in a specific and damning way. Because no generate_lead ever arrived, no one in the property’s history ever had reason to mark it a key event. One defect (the wrong host) produced a second symptom (no key event) that looked independent and was not. The absence of the event masked the absence of the data.

Two secondary defects rode inside the same payload and would have degraded the event even after the host was corrected. The client_id fell back to a synthetic server.<timestamp> string whenever the _ga cookie was absent — a fresh phantom user per cookieless lead. And the payload omitted both session_id and engagement_time_msec, so a correctly hosted event would still have attributed to (direct)/(none) regardless of how the visitor arrived. The audit ranked every finding by the money and the decisions it touched:

The reconstruction rewrote the Measurement Protocol block field by field, and every change addresses a named failure. The endpoint contract is unforgiving by design: a syntactically acceptable request returns HTTP 204, which means "I received your bytes," not "I recorded your event." An implementer who never reads the response is flying blind — which is exactly how a 404 lived for months.

The session_id is not stored in the _ga cookie; it lives in a per-stream _ga_<container> cookie whose packed value encodes the session. Two formats exist in the wild — a legacy dot-delimited GS1 string and a newer dollar-delimited GS2 string — and a parser that assumes one silently returns null for the other, dropping the event back to unsessioned direct traffic. Handling the union is correctness, not over-engineering. (Google documents that the cookie exists but not its internal layout, so this one parse is grounded empirically against the live cookie, and flagged as dependent on an undocumented format.)

The reconstruction treated a change as unverified until three signals agreed. First, the payload validated clean against the debug endpoint, returning validationMessages: [] — the only place Google will tell you a payload is well-formed before it silently swallows a malformed one in production. Second, a live send returned HTTP 204, the acknowledgement the wrong host could never produce. Third, the event surfaced in GA4 Realtime within about twenty seconds, registered as the generate_lead key event. Debug-clean, a live 204, and a Realtime appearance close the loop the original 404 left permanently open — and only then was generate_lead promoted to a key event, because you do not mark a conversion for data you have never seen.

The hardest decision in the repair is not a parsing detail. It is what to do when the join key is missing. The client_id lives in the _ga cookie that gtag.js sets, and a visitor whose browser blocks or never loads that tag still submits the form — the form is server-validated and does not depend on Google’s tag — but arrives with no cookie and no client ID. The reconstruction measured the size of that gap directly from the database rather than estimating it.

Faced with that gap, the original code chose to fake it with server.<timestamp>. The reconstruction chose to skip it. The reasoning is that a synthetic identifier does not repair attribution — it fabricates a user. Each value is unique, so every untrackable lead becomes a distinct new user arriving from (direct)/(none), smearing the channel mix with ghosts that correspond to no real acquisition. A property that exists to answer "which service and which county produce leads" is actively degraded by injecting users whose source is a lie. Skipping the send costs one conversion in GA4. Faking it costs the integrity of every aggregate the phantom touches — and the lead itself still lives in PostgreSQL either way, so the business loses only the GA4 credit for a lead it cannot honestly attribute.

A live test proved the gate behaves as designed. A real submission through the header quote panel, made on a clean Chrome profile that had never visited the site, landed in the database with an empty client ID — and the code correctly skipped the Measurement Protocol send rather than minting a ghost. That single hand-made lead is the empirical proof that the skip logic works, and it is a specimen of the discipline the whole reconstruction runs on: an honest gap is cheaper than a dishonest fill.

A conversion is a claim about business value, encoded as a measurement event. That definition sounds pedantic until you watch what happens when it is ignored. The audit found six key events, and at least three made claims the business could not honor. The discipline of conversion architecture is a bright line between the macro tier — the event you would pay to cause, here a submitted lead — and the micro tier of leading indicators (form_start, cta_click, view_item) that are valuable for diagnosis and actively harmful as optimization targets. GA4 blurs that line by letting any event become a key event with one toggle. The blur is the trap.

cta_click as a key event is the most instructive anti-pattern in the property, because one wrong toggle scales into systemic corruption. Nearly every one of roughly 1,200 static pages carries call-to-action buttons, and each click fired cta_click. Marked a conversion, a curious visitor clicking three CTAs on three pages generates three "conversions" while buying nothing. Once a Google Ads link exists — and google/cpc was already spending 46 sessions a month against an unlinked property, so the link is coming — the bidder learns conversions are cheap and abundant, then chases high-volume, low-intent browsing instead of the narrow stream of visitors who actually submit a lead. Because click events vastly outnumber lead events, the noise becomes the dominant training signal. Phase 0 deleted the key-event flag as a zero-risk change; the event still collects for analysis, it simply no longer claims to be a conversion. The same logic keeps career_application_submit permanently out of the Ads-eligible set: a job seeker is a real action but never a booked pest-control job, and optimizing toward it would spend the marketing budget attracting applicants.

The canonical lead carries a differentiated per-service value, because a flat number tells a value-based bidder that a fumigation lead and a single-ant call are worth the same, which is false and suppresses the exact optimization value-based bidding exists to perform. The reconstruction replaced the flat 150 with a map, applied as an explicit value on every generate_lead:

• Fumigation $500, termite $400, commercial $400 — the high-ticket, seasonal revenue.
• Bed-bug $250, rodent $180 — the mid tier.
• General/pest $150, other $120, ant $100, wasp-bee $100 — the low-ticket calls.
• Every figure is labeled provisional and internal: a bidding and analysis signal that lives in versioned application code, never a customer-facing price, to be replaced by observed closed-job values as real data accrues.

One judgment here is a deliberate deferral, not an omission. Demoting the client contact_form_submit and quote_form_submit from key events is the obvious final step of canonicalization, and the reconstruction did not take it — on purpose. With no Ads link yet, the double-count lives entirely inside GA4 reporting, where an analyst can see both the client and server events side by side; there it is not merely harmless but useful, because the events blockers suppress and the server event they do not bracket the blocker-loss gap from both sides. GA4 deduplicates only purchase, keyed on transaction_id, and offers no equivalent for any other event, so the moment an Ads link exists the redundancy stops being diagnostic and becomes a bidding hazard. The plan therefore binds the demotion to the Ads-link event: do the harmless thing now, schedule the consequential thing to the moment it becomes consequential.

The sequence matters as much as the fixes. Correctness comes before architecture, and architecture comes before activation. The host fix made the canonical conversion real; only then did promoting it to a key event make sense. The conversion demarcation removed a false claim before it could poison a bidder that does not yet exist. And the cheapest, highest-leverage change of all was a single setting.

That setting is a lesson in scope. GA4’s standard aggregate reports retain effectively indefinitely, so top-line trends were never at risk; the two-month cap bites only Explorations and funnels that pivot on event- or user-scoped custom dimensions — which is precisely the by-service, by-county seasonal analysis this business lives on. Do it before you need the report, because you cannot recover the window you never kept.

Honest expectations close the picture. At roughly 46 paid clicks and 500 sessions a month, this property sits below the volumes where Google’s data-driven attribution (historically near 400 conversions per 28 days) and value-based Smart Bidding (roughly 15 to 30 conversions a month) stabilize. Building the differentiated value model now is still correct: it gives the office cost-per-booked-job visibility immediately and accumulates honest history for the day volume rises. The point of this part of the series is not a clever configuration — it is a correct one. A property that reports confidently on missing, misattributed, or misdirected data is worse than one that reports nothing, because someone will act on the confident number.

With collection correct and conversions honest, the remaining work is activation and governance: closing the offline-revenue loop back into Google Ads, consent by design, warehousing, and the controls that stop a clean property from drifting. That is Part 3. If you would rather have the audit run on your own property, that is the shape of our measurement and SEO work — the same programmatic read, ranked by the money each defect touches.