“Conversions are not showing” can describe several different problems. The customer action may not have completed, the event may not have fired, the request may have used the wrong source, or reporting may not yet attribute the event. Start by identifying which observation is missing.
Write down the missing evidence
Record one reproducible example: the page, the successful action, approximate time, event name, expected pixel or source, and the report being checked. Include the account and timezone. Avoid a vague ticket such as “tracking broken” because it hides the distinction between a website failure and a reporting question.
Use a test order or booking that your team is allowed to create. Keep personal details out of screenshots and support messages. An event ID and timestamp are usually more useful for tracing than a customer’s full record.
Check the website action first
Confirm that the booking or purchase exists in the system of record. If the application rejected the action, a completed-action event should not have fired. Inspect the success callback, payment state, or form response that triggers measurement.
For single-page applications, check both a direct visit and an in-app navigation. Code attached only to the initial page load may miss a later route transition. Code attached to both route changes and confirmation rendering may produce duplicate events.
Check code, consent, and the destination source
Inspect whether the measurement script loads and whether the event call occurs after consent is granted where required by the implementation. Advarde’s generated helper starts with measurement consent denied and does not replay blocked events automatically.
Confirm that the installed pixel ID matches the setup you are inspecting. Check the event name and payload for spelling or unit errors. A working request sent to a test source will not establish that the production source is correctly installed.
| Observation | Next check |
|---|---|
| No event call | Success trigger and consent behavior |
| Event call but failed request | Browser network error and payload |
| Successful request, wrong report | Account, source, definition, and date range |
| Received event, no attribution | Eligible ad interaction and reporting rules |
Interpret the receipt sample correctly
In Advarde, open the conversion setup, choose Test events, and use Check for events after a permitted action. “Not in sample” means the expected event was absent from the limited recent browser sample. It does not prove that no event was ever sent.
The sample is limited to recent browser SDK receipts, with a window and count cap. Use the server’s own logs for server-delivered events and repeat the test at a known time. Keep evidence from each layer instead of repeatedly reinstalling the pixel.
Escalate with a bounded reproduction
If the event reached the expected source but reporting still disagrees, capture the report range, timezone, event definition, and time since receipt. Include a redacted request result and the stable event ID when appropriate. Do not include secret keys.
Make one correction at a time and repeat the same action. Changing the pixel, event name, destination, and report settings together can make the symptom disappear without revealing which change fixed it.
Sources and verification
Platform details checked on September 11, 2026. Your account may expose a different set of features. Examples are illustrative unless a dataset is explicitly supplied.