Google Ads operations

QA offline lead conversions before using Smart Bidding

Validate an offline conversion feed end to end before using it as a bidding signal. Check stage meaning, identifiers, timestamps, values, repeat-upload behavior, and provider diagnostics. As of September 2026, new integrations must also account for Google's restrictions on previously unused Google Ads API upload tokens and the Data Manager API path.

A CRM export runs every night and returns a success message. That proves a job completed, but it does not establish that Google Ads received the right business outcomes or that the campaign is using them as intended.

Offline lead conversion QA follows a small set of known records from the sales workflow to the advertising platform. It should test normal cases, duplicates, corrections, delayed records, and failures. The purpose is to make the signal trustworthy before increasing the consequences of using it.

Check the current integration path

Google's offline conversion API guide includes a June 15, 2026 restriction: upload requests fail for developer tokens that had not previously sent the relevant offline-conversion requests. It directs new affected implementations to the Data Manager API offline conversion guide.

This is an implementation-path check, not a reason to replace every working integration. Identify the actual connector or API in use, its current eligibility, and its owner. A tutorial that worked for an established token may not be an appropriate starting point for a new integration.

Keep provider-specific field and diagnostic rules with the implementation. Do not mix request formats from different APIs because both ultimately feed Google Ads.

Agree on what each stage means

Before inspecting payloads, define the event. Does “qualified” mean a salesperson reviewed the lead, the lead met a service-area rule, or the customer booked a meeting? Those are different facts.

Use the lead-stage conversion map to assign an owner and transition rule. Include examples that sales and marketing classify together. If two reviewers disagree regularly, the import can be technically accurate while delivering an inconsistent training signal.

Decide how reopened opportunities, duplicate contacts, and disqualified leads should appear. Document the business policy before encoding it in an integration.

Select a traceable sample

Choose records with known outcomes and appropriate access. Include a normal qualified lead, a later sale, a delayed update, a repeated export, and a correction. Use synthetic records in a suitable test setup where supported, and avoid sending fabricated conversions into live bidding data.

For legitimate production records, minimize copied personal information. The QA worksheet can refer to internal record IDs and restricted evidence rather than exposing customer details in a shared report.

Record expected behavior before running the check. Otherwise, a surprising output can be rationalized as correct after the fact.

Follow identity and time through the pipeline

StageEvidence to inspect
AcquisitionAvailable attribution identifiers and collection conditions
CRM transitionStable record, qualifying event, event timestamp
TransformationConversion destination, value, currency, normalized fields
UploadRequest or job identifier and per-record result
Platform reviewDiagnostics and eventual reporting appearance
Campaign useSelected goal and intended bidding role

Distinguish event time from upload time. A sale that happened Tuesday but was uploaded Friday should not silently become a Friday business event. Check timezone conversion and daylight-saving handling where relevant.

Also verify account identity. A valid record sent to the wrong conversion customer is not a successful business integration.

Test repeat uploads and corrections

An integration should have a defined policy for reprocessing a previously handled record. Identify the fields used to recognize the event under the chosen provider API and conversion setup, then test the intended retry behavior.

Do not assume that every successful HTTP response means every record was accepted or that every duplicate will be handled the way your CRM expects. Preserve item-level results and investigate unknown outcomes before replaying an entire batch.

Corrections need a separate design. If a value changes or an opportunity is reversed, document whether the integration sends an adjustment, a new event, or no update. Check the current provider rules for that path instead of inventing a universal replacement behavior.

Inspect diagnostics beyond the job status

For integrations using the Google Ads API, Google's offline data diagnostics documentation explains the reporting surfaces used to investigate upload health. Use the corresponding diagnostics for whichever integration path you actually operate.

Track accepted, rejected, pending, and otherwise unresolved records separately. Compare the source count with the eligible count and the accepted count. Differences can be legitimate, but they need an explanation.

A useful reconciliation might state that some CRM rows lacked required eligible identifiers and were never submitted, while a separate subset failed validation. Combining both categories into “missing conversions” hides the fix.

Verify values and campaign goals

Check a sample of event values against the approved business definition. A predicted opportunity value, contracted revenue, and collected cash are not interchangeable. Confirm currency and whether a fixed proxy is intentionally used.

Then run the primary and secondary conversion audit. A healthy feed can still be unused by the campaign or included through an unexpected custom goal. The measurement pipeline and the bidding configuration must be verified separately.

Set an operating acceptance gate

Define acceptance using the actual risks: consistent stage classification, traceable identifiers, correct times and values, understood retries, resolved material errors, and a visible owner for ongoing monitoring. Set account-specific tolerances based on business needs rather than copying a generic success percentage.

Save a baseline before changing the campaign's optimization goal. Continue monitoring feed health afterward, including import delays and changes to the sales process. Use the outage recovery guide if the signal later breaks.

The handoff should leave the buyer able to answer two questions: “What does this conversion mean?” and “What evidence shows the feed is healthy today?” If either answer is missing, the integration needs more work before it can carry a larger decision.

Keep the imported stage tied to the business definition

Use the lead quality scorecard to define the milestone being imported, its maturity window and the owner of the review. The Google Ads audit checklist adds a separate check for the campaign goals using that signal.

Audit primary and secondary conversions in Google Ads

Trace Google Ads conversion actions through standard goals, custom goals, campaign settings, values, and business outcomes before changing bidding signals.

Map lead stages from first inquiry to advertising conversion

Define CRM stages, entry evidence, timestamps, ownership, values, and advertising event mappings so lead-generation reporting reflects the actual sales process.

Recover from a conversion-tracking outage

Diagnose and recover a conversion-tracking outage by tracing business events, containing unreliable automation, repairing the failing stage, and reconciling recovery.

Use conversion lag before cutting Google Ads budgets

Build a conversion-lag worksheet that separates immature Google Ads results from a real efficiency decline before changing campaign budgets.

Have a correction or a question about the workflow? Contact GaaS. Read our editorial standards for sourcing and example conventions.