The page loads, the headline looks right, and the test conversion appears. Then the tracker reports a conversion that belongs to an unknown click. A landing page release can look healthy in a browser while one step in its redirect chain drops the identifier that connects the visit to the result. A short trace captured before release gives the next person enough detail to find that step.
Start with a click you can recognise
Use the documented test route in an account you control. Give that visit a fictitious value such as release-check-ember in the field your tracker expects, or record the synthetic identifier the tracker actually assigns. Keep that value and the release name together. Record the starting host and path from the same journey. If you paste the final destination directly into the browser, you skip the tracker and any intermediate redirects. That can prove the landing page works in isolation, which is a different check.
Record which browser and device you used. A desktop test is a good first pass, but it does not tell you whether an in-app browser makes the same requests or handles consent in the same way. If most visits come from an in-app browser, make one additional test there through the supported preview or test route and save its result separately.
Follow the document requests in order
Open the Network panel before navigating. Turn on Preserve log so the request list survives each navigation. The Chrome DevTools Network reference shows where to find that control. Start at the test URL and look first at document requests. An image or analytics request may help later, but it is rarely the easiest place to reconstruct the path of the page itself.
For each step, write down the requested host and path, the response status, and the destination stated in any Location header. A relative Location value is resolved against the current request URL. MDN's guide to HTTP redirections explains which responses perform this handoff and how they differ from a navigation started by a page. If the list shows a successful HTML response followed by another document request, inspect the initiator before attributing the second request to the server. The HTML page may have started it.
Find the first request where the value changes
Suppose a fictitious click goes to a tracking path with ref=release-check-ember. The tracking response points to /offer?ref=release-check-ember on the landing site. A second redirect points to /en/offer with an empty query string. The final page reports a successful response. Those observations locate the loss between the request for /offer and the redirect to /en/offer. You can take that pair to the team responsible for locale routing and show exactly what a visitor received.
Some trackers intentionally put an identifier in first-party storage at a documented step. In that case, an empty final query can be normal. Confirm that the approved tracker stored the expected test value and that the allowed conversion receives it. When the application changes the parameter name along the chain, record both names next to the same test value. The FroggyAds conversion tracking guide includes redirect and cross-domain handling as a separate part of validating a conversion. Check the mapping you actually use before calling a missing query parameter a failure.
Save enough evidence for someone else to reproduce it
Keep the release identifier, the test device, and the ordered document requests together. For each hop, include the outgoing destination and whether the synthetic value survived. A short text record is usually enough. If you capture browser diagnostics, remove cookies, authorization headers, customer identifiers, and unrelated requests before sharing. Use a synthetic value in a saved example so the person reading it can follow the trace without seeing a real visitor's data.
Repeat the same test after a repair. Keep the outcome with the release whether the chain now works or the problem moved. A useful handoff shows where the browser arrived, where the tracker got its test identifier, and where the test event ended up. If the tracker and the page disagree, the first changed request gives you a single place to start the next check.