Google Ads offline conversions: importing CRM outcomes and lead quality

Offline conversion tracking connects an ad touchpoint with a later business outcome: a qualified lead, a sales opportunity, a new customer or a closed-won deal. The import is only useful when identity, funnel definition, time, value and consent are valid and duplicates are controlled. Do not start with the API. Start with an authoritative CRM event and a clear decision about which stage may become visible in Google Ads or relevant to bidding.

What problem does offline conversion tracking solve?

Google Ads sees a click, a form or a call. In complex sales, the value emerges later: a team reviews the enquiry, accepts it, opens an opportunity and perhaps closes a contract. Without feedback, the platform optimises towards early actions even though their quality varies widely.

An offline import closes this information gap in part. It shows the platform which early contacts reached a later stage. It replaces neither CRM quality nor causal measurement. An attributed deal may also have come about without an ad.

Which conversion stage should be imported?

Define every stage in writing:

• “Valid enquiry”: technically and substantively valid enquiry;
• “Qualified lead”: agreed marketing criteria met;
• “Lead accepted by sales”: accepted by sales according to a rule;
• “Sales opportunity”: sales opportunity with a defined stage;
• “New customer or closed-won deal”: a new customer or an agreed closed status.

Choose a point that is frequent enough, reliable and timely. A very late conversion sits closer to revenue but may be too rare for operational bidding. Carry further stages as secondary actions until a documented change is justified. Secondary actions are normally observational; however, an action in a custom goal that a campaign uses can be used for bidding regardless of whether it is primary or secondary (manage conversion goals from the conversions summary, about primary and secondary conversion actions).

Which identifiers connect the click and the CRM?

One possible link is the Google Click ID (GCLID). It is stored on arrival and transmitted later with the CRM event. Enhanced conversions for leads can use hashed first-party identifiers. Which identifier is required or permitted depends on the chosen import method and tag: a GCLID or the hashed identifiers that method supports. A single hashed identifier is not automatically enough for every route, and only the identifiers that the method requires are hashed – not every field or the complete event payload.

Store identifiers on the authoritative lead before redirects or CRM synchronisations lose them. Document the source, capture time, consent status and retention. Hashing applies only to the identifiers the chosen method provides for; it is a transmission requirement, not universal anonymisation. Review the purpose and permitted use independently of it.

Which data belongs in an import event?

The business event needs at least a stable internal ID, the conversion action, the actual event time of the business transaction rather than the later send or storage time, the time zone and a permitted match key. Value and currency are optional but must comply with the chosen import route together and come from a defined source; a value alone is not automatically valid. An opportunity amount is not automatically realised revenue.

Add an idempotent event key. The same CRM status must not be counted twice on a retry. A local key alone does not guarantee idempotency at the provider: align local duplicate control with the deduplication identity actually supported by the chosen route, and keep unknown remote outcomes as a state of their own. Distinguish whether a record is merely received, accepted as valid, matched to a contact or visible in reporting; accepted quantities need not equal attributed conversions. Store the payload version, source system, export time and outcome. Raw personal data does not belong in logs or error messages.

How are duplicates prevented?

There are several types of duplicate:

• the same export is sent again;
• the CRM and direct tag measurement report the same business action;
• GA4 and the direct import are both primary;
• several CRM status changes create the same conversion action;
• a merged lead keeps two active identities.

Define exactly one primary source per business outcome; that prevents duplicates. It is not a universal rule, however, that a campaign may optimise towards only one outcome: a campaign can include several conversion actions. Use stable transaction or event IDs. Test retries, late data, correction and merging. A platform message of “success” does not prove that the business outcome was counted exactly once.

What changes on the technical path in 2026?

Google’s current help documentation describes a transition that starts on 15 June 2026: offline conversion imports and enhanced conversions for leads uploads are moved to the Data Manager API and blocked in the Google Ads API. Whether an existing access still runs through the legacy route depends on the eligibility conditions; developer tokens that sent no request between January 2026 and June 2026 are not added to the allowlist for legacy access. For new projects the Data Manager API is therefore the target route. Existing guides may be out of date. Verify the target route, the eligibility conditions, data fields and policies immediately before implementation, and distinguish general event ingestion from features that require their own approval.

Which tests are needed before go-live?

Create a synthetic test matrix:

1. a valid lead with a click ID;
2. a valid lead with only permitted hashed data;
3. a missing match key;
4. a duplicate export;
5. a late conversion;
6. an incorrect time zone;
7. a missing or contradictory currency;
8. a corrected status;
9. consent that does not permit the planned processing;
10. the provider accepts technically, but the event appears under the wrong action.

For each case, record the expected outcome, the actual response and the later UI or reporting check. Test data must not imitate a real person unless a controlled process exists for that. Synthetic lead data does not create real attributed conversions in a live advertising account: test invented cases locally or with mock data; an end-to-end measurement needs separately authorised valid events and data rules.

How does acceptance work?

Compare the CRM source, export log, provider response and Google Ads report over a defined period. Do not reconcile counts as totals alone; check unique event IDs. Explain permissible delays and differences. Stop the change of the bid signal if coverage, duplicates or time attribution are not robust.

Google’s upgrade guidance distinguishes two cases: upgrading an existing conversion action and migrating to a new action. An upgrade keeps the same action. The parallel replacement of a primary and a secondary action belongs to a migration to a new action. For a new action, Google recommends waiting for the longer of one to two conversion cycles or four weeks before switching; that recommendation applies to the scope described and does not replace an account-specific check, which may require a longer observation period. Do not adopt a fixed duration blindly; document the current recommendation and your own conversion cycles.

How are import errors handled in operation?

An import needs a log: event, attempt, provider status, cost where relevant, error class, retry decision and final state. A timeout with an unknown outcome must not automatically resend. Quarantine faulty rows without silently discarding the whole cohort.

Reliable operation needs dashboards for freshness, expected and accepted events, duplicates, rejections and unlinked leads. An alert leads to a runbook – the action guide for the incident. It does not automatically trigger a change in Google Ads.

Which data protection and governance questions apply?

Clarify the purpose, transparency, legal basis, data minimisation, recipients, retention, access roles and deletion. Review the current Google Customer Data Terms. Record hashing before transmission and secret handling technically. A person responsible on the business side approves the conversion definition; data protection and security review the data processing.

Do not use additional personal fields “for better matches” without necessity and approval. A rise in match rate is not a sufficient business or legal ground.

AI support for qualification and handover

A second step is AI-supported assistance with qualification and handover. It is a project of its own that has to be agreed explicitly and it presupposes a valid CRM outcome and feedback process – not necessarily a completed Google Ads upload. In lead management, AI can flag patterns, summarise information or suggest a priority. It should not, however, become the hidden decision maker that determines which contact is “good”. A score is an estimate for a predefined event in a defined period. It is neither customer intent nor revenue nor a verified sales outcome. A robust use therefore begins with clear stages, observable target events, permitted actions, human handover and a feedback path.

Describe the process without AI first

Before a model scores anything, the team must be able to explain how a lead moves from one state to the next today. Which stages are there? Which observable criteria apply? Who takes over when? Which cases are deferred or excluded? If marketing and sales already mean different things by “qualified”, a model merely learns that ambiguity in numbers.

A workable process separates facts, rules, forecasts and decisions. “Form submitted in full” is an observable fact. “Region is served by this team” is a rule. “Probability of an agreed conversation within 30 days” is a forecast. “A person calls today” is an operational decision. These four levels belong in separate fields. Only then can it be seen later what the AI actually contributed.

Define the target event narrowly and with a time frame

“Purchase readiness” sounds intuitive but is not a training target. A clear outcome is better, for example a documented first conversation that took place within a defined window. Even that is not perfect business impact; it is merely observable. The time frame prevents very old outcomes from distorting current prioritisation.

At the same time, define what is not a positive label. A case that is still open must not automatically count as negative. It may simply be too young. An interrupted data transmission is not a lack of interest. And a lead that sales did not work says more about capacity than about suitability. Such delayed or missing outcomes must be preserved as states of their own.

A score needs a readable meaning

Every score must answer four questions: which event is being estimated? Over which period? For which population? Data as of when? Without that information, a number such as 82 cannot be interpreted. A ranking can also appear stable even though the underlying population has changed. Model version, calculation time and data window therefore belong with the output.

Avoid labels such as “hot lead” when they disguise a forecast as a fact. A comprehensible display could read: “Model suggestion: review before contact for the defined 30-day event; three permitted input signals were decisive; the person responsible decides.” It names neither a guarantee of closing nor a character trait of the person. A ranking or group assignment is not a calibrated probability; it places cases in relation to one another. If the model cannot make a reliable statement, “not assessable” is a fully valid outcome.

Check permitted data and proxies

A CRM often contains more fields than a specific prioritisation requires. Do not start with the full export. For each attribute, record the source, purpose, recency, quality status and responsible role. Free text can unintentionally contain sensitive or irrelevant information and deserves particular care. Even seemingly neutral fields can act as proxies for protected or unwanted categories.

If an input signal comes from cookies or similar web technologies, its origin is not hidden under the CRM label. The current FDPIC guidance requires a specific review of purpose, transparency and proportionality for such technologies. This does not yield a universal consent rule for every CRM field. It does mean that a derived browsing signal keeps its own data-flow and legal review, even when it later appears in the CRM as a compact score.

Swiss data protection law applies directly to AI-supported processing of personal data. The FDPIC emphasises transparency about the purpose, how the system works and the data sources. As a precautionary design rule, this guide therefore relies on a small, purpose-related field selection. Whether a scoring process constitutes profiling or an automated individual decision with special duties must be examined on the concrete workflow. Where the risk is expected to be high, a data protection impact assessment has to be clarified.

Decouple score and action

A model must not silently determine who is contacted, excluded or treated differently. Define a permitted next action for each score group. A low-impact action is, for example, an internal sorting aid. A higher-impact action would be automatically triggered outreach or the permanent discarding of a case. For a pilot, the score should initially only produce a proposal that a named role reviews together with its justification.

The action needs a fallback. With missing fields, outdated data, an unknown model version or contradictory rules, the case goes into a neutral queue. It is not automatically downgraded. An override function is just as important: sales or marketing may change the proposal but must choose a structured reason. That enables learning without reinterpreting every deviation as a human or model error.

Design handover as a contract between roles

A good handover is not a field change from MQL (marketing qualified lead) to SQL (sales qualified lead) but a verifiable agreement. It contains the observed facts, the suitability rules applied, the model proposal, open questions, permitted contact channels, a deadline and the new responsible role. The receiving person can accept, return or escalate for clarification. Every outcome gets a reason code.

This creates a feedback path. “Not accepted”, however, is not yet a negative business outcome. Perhaps capacity or a mandatory field was missing. Feedback must therefore separate the process reason from the later customer outcome. Only robust, mature outcomes may enter a model evaluation or later training. Otherwise the system reinforces its own prioritisation: what stood at the top was worked more often and afterwards appears more successful.

Permission to contact remains a separate check

A high score does not create permission to contact. Whether a person may be approached through a particular channel and for a particular purpose is a separate business and legal review. This guide does not prescribe a universal consent rule for that. It requires the team to have the relevant current Swiss basis and, where applicable, additional platform rules reviewed by a competent specialist before the action.

Do not simply store “contactable = true”. Keep purpose, channel, source, time, scope and withdrawal status separate. The contact status is checked immediately before an action, not only when the lead arrives. A model must never override a block. Legal and business review remain separate from the technical score calculation.

Measure quality before productivity

For the pilot, process metrics are enough at first: share of assessable cases, missing data, review rate, reasons for acceptance and return, time to handover and overrides. These figures show whether the workflow is comprehensible. They prove no additional demand or revenue impact. Even a shorter processing time can be worthless if unsuitable cases are passed on faster.

Model quality is checked in time-based cohorts. Do the predicted groups match the later observed, narrowly defined event? Is the distribution changing? Are there groups with conspicuous errors or missing values? A single accuracy figure is not enough. Thresholds should respond to the cost of different errors: a missed relevant case and an unnecessary review are not the same thing.

A controlled comparison can examine whether the support actually produces a better process or outcome measure. This guide promises no improvement. It ensures that a later statement can rest on traceable data at all.

Plan for drift and feedback loops

Lead processes change: campaigns address different groups, offers change, teams re-prioritise and fields are maintained differently. A model can lose explanatory power as a result, even though its technology runs unchanged. Monitor input distributions, the share of non-assessable cases, the distribution across groups and later outcomes over time. A threshold that was plausible in an old cohort is not automatically reused.

The feedback loop between score and observation is particularly critical. If only highly prioritised cases are worked, reliable outcomes are missing for the remaining cases. The model then sees mainly the results of its own selection. Document which cases actually had a chance of being worked, and preserve “unknown” as a state of its own. Every change to stages, labels, input fields or thresholds gets a new version. A named role decides on the basis of predefined criteria whether to pause, return to the old version or validate anew.

Build a pilot in safe stages

Stage one uses synthetic data sets with missing, contradictory and impermissible fields. Stage two calculates proposals in shadow mode; nobody sees a changed priority. Stage three shows the proposal to a small, trained group that reviews every case. Only afterwards can a limited process action be considered. Such a process action concerns the lead workflow and is not the same as the maitiq proposal and approval lifecycle for changes in the Google Ads account. Automatic external outreach or permanent exclusion are not a suitable starting point.

Before every stage there are stop criteria: unexplained data shift, missing logs, a breach of a block, sharply rising overrides or complaints that cannot be resolved. A named person responsible may stop the pilot. Model, rule or data changes create a new version and require renewed review. A score approved once is not a permanent approval.

The limits of this guide

AI-supported lead management is ready for a pilot when stages, target event, population, data fields, score meaning, permitted actions, contact status, handover rules, feedback, metrics and stop signals are documented. If the process definition is missing, a CRM tool will not solve the problem.

How does maitiq fit into the workflow?

maitiq helps define and assess the data and measurement plan: which CRM stage, which identifiers, which time attribution and which acceptance criteria are viable in business terms. Its live Data Manager upload is not implemented or available; real imports, monitoring dashboards and automated CRM scoring are not current maitiq product features. Your team provides the relevant business events and data paths. A CRM or AI pilot is scoped separately; agreeing a project scope does not create an existing integration.

From shadow mode to bid signal

Start the new import as a diagnostic. Compare CRM events, accepted uploads and reported conversions over at least one representative conversion cycle. Check duplicates, match coverage, event time versus click time in reporting, and error classes. Run the diagnostic outside the custom goals that a campaign uses for bidding: an action in such a goal can take part in bidding regardless of whether it is primary or secondary (manage conversion goals from the conversions summary, about primary and secondary conversion actions). A high match rate alone is not enough; the business events must be right.

Changing an action from secondary to primary is a decision of its own. It names the old and new source, the observation period, acceptance criteria, the person responsible and the rollback path. During the transition, the same business conversion must not count as primary twice. After the changeover, monitoring for freshness, rejections and unexpected volumes stays active.

How maitiq prepares the pilot: clarify the data and measurement plan for lead quality

A meaningful pilot result is a structured handover note: the enquiry, product interest, missing details and a suggested responsibility. Use only approved data. The model should leave unknown details open and must not invent company size, budget or purchase readiness. Sales confirms later whether a qualified conversation took place.

Check assignment quality, time to first contact and the share of qualified conversations. maitiq helps align marketing and sales on a shared definition and plan the workflow with the systems you already have. A CRM integration and the return of outcomes are not part of the product today; they can only be considered as a separately scoped project, and agreeing such a scope does not replace an existing integration.

How a first pilot with maitiq begins

An initial assessment shows which CRM data is viable, which wrong decision would be expensive and how a limited lead pilot could be set up. You receive a clearly scoped use case, the open data and control questions, a pilot plan and the criteria for later operation.

Frequently asked questions

Sources and how to read them

Platform documentation explains features and limits; authority sources the legal context. Publications by providers and associations must be read accordingly, not as a general market price or proof of success. Information about how maitiq works is available at maitiq.com.

Access to Google Ads alone does not evidence the entire measurement chain. For website tracking, CRM quality or revenue attribution, the relevant systems and evidence are included as well.

Have maitiq review your specific case.