Conversion tracking is a chain of checks. Your application completes an action, measurement code describes it, an endpoint receives it, and reporting may attribute it to an eligible ad interaction. A failure at one step cannot be diagnosed reliably by inspecting only the last step.
Build the chain around a business event. For a booking service, that event is a confirmed appointment. For a store, it is a confirmed order. Do not substitute an easier-to-trigger button click and then label the result a completed conversion.
Choose events from the customer journey
Map the journey before installing code. A store might use product view, cart addition, checkout start, and order completion. The primary conversion should represent the outcome the campaign is intended to produce. Supporting events explain where people stop.
Advarde includes lead generation, booking, ecommerce, and SaaS presets. A preset provides a starting set of events and suggested primary goal. Review those choices against your actual application before creating definitions.
Reuse the right tracking source
Choose the pixel already installed on the destination when appropriate. Creating a new pixel for every setup can leave the installed ID and reporting configuration pointing at different resources. Record which account owns the source and which website uses it.
Review the proposed definitions before applying the setup. The review identifies resources that will be reused or created. Creating those resources does not install code on the website and does not activate campaigns.
Install on successful actions
Install the base code once and connect the consent behavior to the site’s consent manager. Call the event code after the corresponding business operation succeeds. For a form, wait for the server to accept the submission. For a purchase, use the confirmed payment or order state.
Give each business action a stable event ID. A retry of the same action should not become a new purchase simply because the request is sent again. A different order needs a different ID. Where browser and server delivery describe the same action, follow the platform’s documented deduplication requirements.
Test the browser and server paths separately
Use the Pixel Helper to inspect the browser implementation. Then complete a permitted action and check the recent browser receipts in Advarde. The diagnostic screen uses a limited sample; it is not a complete event ledger and does not cover every server event.
For a server integration, validate the stored configuration and test the destination server separately. A validation-only request can check configuration without establishing that your production checkout sends the right event at the right time. Keep application logs for successful dispatches and failures without exposing credentials.
Reconcile measurement with business records
Compare completed orders or accepted leads with measurement activity over a defined period. Investigate mismatches by event name, source, event ID, timestamp, and environment. A test event sent to the wrong pixel can look healthy locally while leaving the campaign’s conversion definition empty.
Finally, inspect attributed results using a documented date range, timezone, and attribution definition. Some received events may have no eligible ad interaction. Reporting latency can also separate receipt from visible attribution. Never force the numbers to match by renaming metrics or counting every event as an ad-driven sale.
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.