Google Ads server-side tracking: setup and verification
Choose the right delivery path, connect the intended Google Ads account, and verify one conversion from its source event through reporting.
By Mika Garcia · Published
In this article
Choose the path before following a setup guide
Google Ads server-side tracking sends conversion information through server infrastructure rather than relying only on a browser tag. The setup depends on whether you are using server-side Google Tag Manager, a supported platform integration, or a direct conversion-import API.
These are related approaches, not interchangeable instructions. A server container’s tag configuration is not the same thing as configuring an integration to deliver a payment event. Start by naming the event, its source, and the destination conversion action.
This DATALYR guide focuses on configuring and checking the DATALYR connection. It is not a claim that a live Google Ads test has been performed for your account, and it does not replace Google’s current prerequisites.
Choose one setup path before configuring it
1. Server-side Tag Manager
Browser → server container → Google Ads
Configure the server container and supported tags.
2. DATALYR integration
Source event → conversion rule → Google Ads
Connect the final customer account and verify the matching rule.
3. Direct API integration
Your sender → supported Google API
Follow current authorization, consent and upload requirements.
Define a conversion you can verify
Write down what should count before enabling a destination. A paid purchase, a submitted lead, and a started trial are different outcomes. If your rule matches a purchase event, a signup is not an adequate test of that rule.
Choose a transaction or event you are authorized to inspect. Keep its original time, currency, amount, and identifier available for comparison. A screenshot of an aggregate revenue number is not enough to establish that this particular event traveled through the intended path.
Also inventory existing delivery paths. A browser tag, a commerce integration, and another server-side service may already send the same business event. Decide how one purchase should be represented before adding a second path; do not assume that sharing an order ID deduplicates every combination of conversion actions and upload methods.
Server-side delivery does not remove consent requirements. Use the consent and data-handling rules applicable to the chosen integration and Google destination. A missing identifier is a diagnostic finding, not permission to invent one or substitute unrelated customer data.
- Business event and the precise trigger condition.
- Source of the event and its transaction identifier.
- Google Ads customer account and intended conversion action.
- Value and currency definition.
- Existing browser and server senders for the same outcome.
- Consent and identifier requirements for the selected delivery method.
Connect the intended customer account in DATALYR
Open Sources, connect Google Ads, authorize an account with access, choose the final customer account, and set it as primary. A manager account and the customer account running the campaigns are not interchangeable; verify the selected customer ID.
In Conversions, create a rule for a real incoming event, choose Google Ads as the destination, and use the supported configuration shown by the editor. Confirm that the rule is enabled and the account selection is complete.
If DATALYR displays a Google Ads reconnect warning, resolve it before testing delivery. The current application includes a Data Manager authorization check; an older connection may need updated authorization. Do not repeatedly replay events to compensate for a missing permission.
Treat these as setup checkpoints. This guide does not verify your connected account, access rights, or current conversion configuration. Check them in your own workspace before sending an event.
Trace one event through four checkpoints
Use a controlled event in an appropriate test setup, or inspect a known legitimate transaction. Do not submit invented production conversions just to make a report look active. Record the identifier so the same transaction can be followed at every stage.
First, verify the source. Confirm the event actually occurred and that its amount, currency, and time match the business record. If the source is a payment provider, confirm that the event represents a successful payment rather than an intermediate lifecycle notification.
Second, verify receipt and eligibility in DATALYR. Find the event and check that it matches the intended rule. If it does not, investigate the trigger and available properties before changing the destination settings.
Third, inspect the delivery result. Read a reported failure rather than treating the existence of an event as proof of successful delivery. Preserve enough detail to distinguish an authorization issue from an identifier, value, or configuration problem.
Fourth, inspect the relevant Google diagnostics and reporting after the applicable processing period. Record whether the event was accepted and whether it was attributed. The latter depends on Google’s eligibility rules and available matching information; acceptance alone is not a campaign conversion.
Four checkpoints for one real event
1. Source
Did the transaction happen?
Check identifier, successful status, value, currency and time.
2. Receipt
Did DATALYR receive an eligible event?
Check event properties and the intended conversion rule.
3. Delivery
Was the event accepted?
Inspect the destination result and any diagnostic.
4. Attribution
Did Google credit the conversion?
Check eligibility, matching information and the relevant reporting period.
Keep a small verification record
For a hypothetical $49 purchase, your review note could contain the following fields. The values are illustrative and should never be submitted as a fabricated production purchase.
Keep identifiers and evidence in an access-controlled workspace. If you share a screenshot for support or an article, remove customer details and credentials. A public tutorial should show an authorized test example, not a private customer record.
- Source: successful payment, transaction demo-order-001, USD 49.
- Receipt: the corresponding event is visible with the expected time and value.
- Rule: the intended Google Ads destination matches that event.
- Delivery: observed status and the exact diagnostic, if any.
- Google: checked conversion action, diagnostic result, and reporting date basis.
- Conclusion: received, delivered, and attributed are recorded separately; unverified stages stay unverified.
Investigate the stage that failed
If the source record exists but no event appears, investigate collection or the source integration. If the event appears but no rule matches, investigate the rule’s event name and conditions. If delivery fails, use the actual destination error to decide the next step.
If delivery is accepted but reporting is empty, check the selected account and action, the original event time, available matching information, and reporting delay. Review the report’s date basis as well: a conversion import may be associated with an earlier ad interaction rather than the day you uploaded it.
If totals are unexpectedly high, review the list of senders and conversion actions. Distinguish multiple notifications about one transaction from multiple real transactions. Do not delete records or disable a working sender until you understand the duplication path.
Use one known event to narrow the investigation. Sending a large batch repeatedly introduces more uncertainty and can affect reporting if the batch is not handled as expected.
Check current API guidance before building your own sender
Google’s current offline-conversion documentation directs newly restricted upload integrations toward the Data Manager API and describes access limits affecting older upload instructions. A code sample from an earlier tutorial may therefore be unsuitable for a new integration.
If you are building a sender yourself, verify the current API, authorization, destination, consent, and diagnostic requirements in Google’s documentation. Do not copy the setup for a server-side Tag Manager tag into an API integration, or infer that an existing provider’s permissions apply to your own project.
For a DATALYR connection, begin with the supported setup and the connection’s actual warnings. Finish with a recorded trace of one event. That is more useful than declaring tracking fixed because the connection badge turned green.