A conversion can look healthy in the browser and be dead everywhere that matters. The event fired. The tag turned green. The preview looked reassuring. Yet the request never reached the server, the server never recognized it, or the advertising platform never received the conversion.
That is not an edge case in the logic of server-side measurement. It is what happens when a chain is judged by its first link.
A conversion is a chain of receipts
Server-side measurement is not one event moving through one system. It is a sequence of handoffs, and each handoff needs its own proof.
The browser must create the intended event. A network request must leave for the intended endpoint. The server container must receive and claim that request. The expected server event must appear with the required name and parameters. The conversion trigger must match. Its tag must fire. Finally, the destination must record what was sent.
A green browser trigger proves only the first receipt. Even a visible GA4 event does not prove that the advertising conversion completed its separate path. Treating those signals as interchangeable is how a migration can appear finished while bidding loses the outcome it was meant to learn from.
Find the last boundary that worked
Good debugging moves forward until the evidence stops. If the browser event exists but no request reaches the endpoint, changing a server trigger is premature. If the server client claims the request but the conversion tag stays inactive, transport is no longer the leading question.
This is more useful than repeating a large setup checklist. Confirm the server-container URL, the receiving client, the exact event name, and the trigger conditions—but record what each check proves. Once a boundary passes, stop treating it as the default explanation and inspect the next one.
The result should be a short chain of receipts, not a screenshot collection: event created, request emitted, request claimed, server event formed, conversion matched, destination received.
Let the new path earn primary status
A migration changes measurement and optimization at the same time. Replacing the proven client-side goal before the server path is independently visible turns every missed conversion into both a technical problem and lost business feedback.
Run the paths in parallel during validation. Keep the established goal primary while the server-side goal remains secondary, then compare whether the new path receives plausible events across the journeys that matter. Distinct goals or labels can make that comparison easier, but the larger principle is the safeguard: the old signal stays available until the new one has produced its own receipts.
Parallel operation is a test period, not the final architecture. Promotion should be a decision made from observed delivery, not confidence in the implementation plan.
Root causes stay local until proven otherwise
Consent handling, checkout sandboxes, endpoint routing, and platform restrictions can all break a handoff, but none is a universal diagnosis. In one checkout case, a custom HTML canary and direct-send tags worked while the GA4 request did not leave the sandbox. That made consent-specific behavior and sandbox compatibility reasonable boundaries to isolate; it did not establish a general platform defect.
The same caution applies to endpoint advice. Moving traffic to a subdomain reportedly fixed one similar setup, while another failing setup already used a subdomain. A fix is useful only when it changes the boundary under test.
The precise failures in these cases remained unresolved. That uncertainty is not a reason to guess more aggressively. It is the reason to demand better receipts.
Promote proof, not intention
The migration is ready when the complete path works and the business can compare it with the signal it will replace. Until then, a fired browser event is merely evidence that the investigation has started.