To connect Google Ads to what happens in your CRM, define a measurable business outcome, preserve the identifiers and evidence attached to that outcome, and transfer it through a currently supported path. Then reconcile the source records, transfer results and Google Ads reporting separately. A successful upload alone does not prove that Google attributed a conversion or counted it in the report you are viewing.
This guide explains how to map qualified leads and completed sales, including enhanced conversions for leads, into a controlled offline conversion process. It includes an original field-mapping worksheet and a deliberately non-uploadable fictional fixture. The examples are design exercises; no advertising account, CRM connection or live conversion transfer was tested.
- Map a precise CRM milestone to each conversion action, with an explicit rule for repeat visits to that stage.
- Keep event identity, advertising identifiers, consent evidence and outcome timestamps distinct.
- For a new custom integration, start with Data Manager API and check the June 2026 access restriction before considering older Google Ads API examples.
- Make retries repeat the same event identity; handle corrections through the selected route’s documented adjustment behaviour.
- Reconcile counts at every boundary, then investigate attribution and reporting differences using a comparable cohort.
Download the offline-conversion planning kit (ZIP; design-only worksheets and fictional examples).
What changed for Google Ads API offline uploads in June 2026?
As checked on , Google’s developer deprecation page states that, effective 15 June 2026, developer tokens with no offline conversion upload requests between 17 December 2025 and 15 June 2026 are restricted from using the Google Ads API for offline conversions. Their UploadClickConversions requests return CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE. Google directs these workflows to Data Manager API. See the dated feature-deprecation entry.
The offline conversion implementation guide also warns about this restriction. Both developer pages now note that developer tokens have been deprecated in favour of Google Cloud projects, while the historical access restriction remains. Treat this as a restriction on the named upload method and historical access, rather than evidence that every existing offline integration stopped working.
Some Google help pages summarise the historical period more broadly as January through June 2026. For the exact eligibility interval above, this guide follows the developer deprecation entry. The practical decision is straightforward: a new custom build should follow Google’s Data Manager API offline conversion documentation. An existing connector needs its own compatibility review. Its vendor’s authorised transfer path may differ from a custom application’s.
Do not copy a legacy upload script, change its credentials and assume it is suitable. Record which interface the implementation uses, which Google account owns the conversion action, which documentation version informed the mapping, and who maintains the connection. These four facts should be visible in the handover before anyone schedules a transfer.
Define the CRM outcome before mapping fields
An offline conversion is a recorded milestone after an advertising interaction: for example, a sales representative confirms that an enquiry meets your qualification criteria, or an opportunity becomes a completed sale. The CRM is the source of evidence for that milestone. It should not infer success merely because someone opened a record or assigned a sales task.
Start with an outcome contract. Write the event’s definition, its source object, the person responsible for the definition, its timestamp and its repeat rule. Ask two colleagues to classify the same fictional cases. If one calls a booked consultation qualified and the other requires attendance, resolve that disagreement before connecting any software.
| CRM milestone | Evidence required | Proposed action | Repeat rule |
|---|---|---|---|
| Enquiry received | A submitted request exists. | Keep the online form measurement separate. | Do not relabel every enquiry as qualified. |
| Qualified opportunity | A representative confirms service fit and an active purchasing requirement. | CRM qualified opportunity | Once per opportunity’s first qualifying milestone. |
| Assessment booked | A confirmed appointment has a booking reference. | CRM assessment booked, if needed | A reschedule retains the original booking identity. |
| Contract accepted | An accepted contract is linked to the opportunity. | CRM contract accepted | Once per distinct contract. |
| Opportunity reopened | A previous record becomes active again. | No automatic new conversion | Review whether a new commercial opportunity actually exists. |
We build and run Google Ads campaigns measured on calls, forms and booked jobs, not clicks.
This is an example taxonomy, not a recommended set of bidding goals for every account. Decide separately which actions should influence bidding and which should be observed. Multiple legitimate milestones can describe one sale; adding their counts together does not produce a count of unique customers.
Use the right CRM object and historical transition
A contact, an opportunity and a contract represent different things. One contact can have several opportunities. One opportunity can involve several contacts. Choose the object that matches the outcome, then document which associated person supplied the advertising identifiers and eligible first-party data. Do not duplicate the sale once for every associated contact.
Capture the stage transition when it occurs, or reconstruct it from a trustworthy history. A current-stage export cannot necessarily tell you when the record first qualified. HubSpot’s contacts documentation, for example, distinguishes current properties from propertiesWithHistory and notes that enumeration internal names can remain stable when labels change. Use actual property definitions from the chosen CRM when implementing this design.
Store a mapping version alongside each event. If the sales team tightens the qualification rule next month, historical events should retain the definition used when they were created. A visible version boundary makes later comparisons explainable without rewriting the past.
Online GA4 event collection, phone-source measurement, broad investigations into poor lead quality and financial cost-per-qualified-lead modelling are separate subjects. This guide owns the handoff from a defined CRM outcome to validated advertising measurement. For the surrounding implementation context, see Canada Create’s CRM setup and implementation services.
Complete the field-mapping worksheet
Copy this worksheet into your project notes and add the exact source property, transformation, owner and evidence location for every row. The suggested internal names are original examples. They are not Google upload headers or a ready-made CRM schema.
| Internal field | Meaning and source to record | Validation or transfer decision |
|---|---|---|
| outcome_key | Stable identity of one business milestone. | Unique within the chosen action; preserve it across retries and migrations. |
| source_record_key | CRM object type and record identifier. | Keep internally for audit; avoid using email as the event identity. |
| outcome_code | Approved milestone from the outcome contract. | Map only recognised codes; quarantine unexpected stage values. |
| mapping_version | Version of the outcome definition and transformation rules. | Retain with the event ledger; exclude from transfer unless specifically supported and needed. |
| destination_owner | Google account that owns the conversion action. | Verify ownership and access independently of the campaign account. |
| destination_action | Approved conversion action identifier or route-specific name. | Use an allowlist; reject a blank or unknown destination. |
| occurred_at | Actual milestone time from stage history or transaction evidence. | Require an unambiguous timestamp and timezone. |
| observed_at | Time the integration learned about the milestone. | Use for lag monitoring, never as a replacement for occurrence time. |
| event_origin | Where the outcome occurred, recorded separately from its advertising source. | Map to a valid eventSource for the offline API use case; do not infer it from the fact that the data came from a CRM. |
| ad_identifiers | Captured GCLID and any supported braid identifiers, with provenance. | Preserve identifier type and exact value; never invent a missing identifier. |
| eligible_user_data | Permitted first-party matching fields, such as email or phone. | Document which component normalises and hashes each field. |
| consent_evidence_ref | Reference to disclosure, choice, time and collection source. | Keep the evidence internally; translate approved states for the selected route. |
| measurement_eligibility | Decision from privacy, consent and policy checks. | Block denied or unresolved records under the documented operating policy. |
| value_and_currency | Approved value basis and currency, if used. | Validate numeric type and currency together; distinguish missing from zero. |
| revision_and_delivery | Payload revision, batch reference and processing state. | Separate unchanged retry, authorised adjustment and new event. |
For Data Manager API, map outcome identity to transactionId, occurrence time to eventTimestamp, event origin to eventSource, and approved value and currency to conversionValue and currency. This design requires a stable transaction ID even though Google makes it optional for an initial offline event. Read the events.ingest reference together with the offline-specific requirements: the generic multi-product schema labels eventSource optional, but the offline guide requires a valid value. Each event also needs a supported identifier combination, and a request containing user data must declare its encoding. The worksheet is not a complete API schema. Retain the additional internal evidence that explains why each event exists.
Add a signed-off example beside every business rule. “Qualified” is too vague; “first transition to the approved stage after service fit is confirmed” can be tested. “Use the contact email” is incomplete; identify the property, its collection source and the component responsible for preparing it. Review these details with the people who maintain both the CRM and advertising measurement.
Preserve identifiers and add enhanced conversions for leads
Keep advertising identifiers and customer identifiers in separate fields. A GCLID describes an advertising click. An email address identifies a contact channel. Your CRM record ID identifies a record in your own system. Your outcome key identifies a particular business event. None is a safe universal substitute for the others.
For GCLID-based measurement, Google documents auto-tagging and capture of the identifier into the lead-management system, and specifies that GCLIDs are case sensitive. Preserve the value through redirects, forms and CRM transfers. The GCLID setup guide is the reference for that collection requirement. A lowercasing transformation that is appropriate for an email address must never be applied indiscriminately to every field.
Store GBRAID and WBRAID under their own names when they are genuinely captured and supported by the chosen route. Data Manager API exposes separate fields for them in its advertising identifier structure. Their presence in an API schema does not prove that a particular CRM connector transfers them. Record the connector’s supported fields before relying on it.
Where enhanced conversions fit into the same workflow
Enhanced conversions for leads supplements offline measurement with first-party customer data. Google describes matching imported hashed data with information collected on the website and with signed-in customers who engaged with advertising. This belongs in the same outcome pipeline: qualification and sale definitions remain the same, while the eligible matching information improves. See Google’s explanation of enhanced conversions for leads.
Document both ends of the connection: what the website collects and what the CRM retains for the eventual outcome. Use the same relevant customer data consistently. Google recommends retaining GCLIDs where available; its current help page says GCLIDs are required if a tag is not collecting user-provided data. A missing click identifier therefore needs a route-specific eligibility decision, not an automatic assumption that email alone is sufficient.
Google also documents a unified enhanced-conversions setting beginning in April 2026. Avoid handover instructions that depend on an older choice between separate implementation methods. Confirm the current settings when an authorised implementation takes place; this draft does not verify any account’s configuration.
Assign one owner for normalisation and hashing
For a direct Data Manager API implementation, follow its current formatting specification: prepare email and phone data before SHA-256 hashing, then use the declared hex or Base64 encoding. Phone numbers use E.164. Email normalisation includes lowercase and removal of leading, trailing and intermediate whitespace; Gmail and Googlemail addresses additionally lose local-part dots and the plus suffix. Other domains retain their dots and plus suffixes.
Write unit cases for those domain differences. A general business address such as the fictional planner.team+west@example.invalid must not receive Gmail-specific transformations. Use deliberately fictional inputs for these checks and keep the tests disconnected from any uploader.
Choose exactly one hashing boundary. A CRM connector may prepare customer data itself; a direct API implementation may require your transformation component to do so. If a hashed field is hashed again, its shape can still look valid while matching fails. Record whether each input is raw, normalised or hashed, and reject mixed states.
A string with 64 hexadecimal characters proves neither that it came from the correct person nor that it was normalised correctly. Keep a restricted, auditable path back to the source record. Routine operational logs should use internal references and error categories rather than exposing matching data.
Keep consent evidence with the outcome
A consent field is a representation of a decision; it is not the evidence behind that decision. Keep an internal evidence record that identifies the disclosure shown, its version, the purpose, the collection channel, the person’s recorded choice and the time. Include a way to trace later withdrawals or corrections.
Google’s customer data policies require appropriate disclosure of sharing for advertising measurement and consent where legally required. They also restrict sensitive-category measurement and the customer information that may be uploaded. Hashing does not remove those requirements. Avoid sending free-text sales notes, descriptions of sensitive circumstances or other unnecessary CRM content.
For a Canadian business, the operating policy should be reviewed against the jurisdictions and activities involved. Do not treat a Canadian postal address, a newsletter subscription or agreement to be contacted about a quote as automatic evidence of every advertising-data permission. This worksheet records the organisation’s approved decision; it does not determine the legal basis for each business.
| Evidence component | Question the record should answer |
|---|---|
| Collection source | Which form, booking flow or other direct interaction collected the data? |
| Disclosure version | Which wording and purposes were presented at that time? |
| Recorded choice and time | What did the person choose, and when was that choice recorded? |
| Applicable decision | Which approved policy permits or blocks this measurement use? |
| Withdrawal history | Was a later choice recorded before the transfer decision? |
| Reviewer and evidence reference | Who can resolve uncertainty without placing personal data in ordinary logs? |
Data Manager API’s Consent reference distinguishes adUserData from adPersonalization, with granted, denied and unspecified states. These signals do not constitute a complete consent-management system. Keep their mapping explicit; never turn an empty CRM field into granted consent to improve coverage.
The API permits request-level consent, with event-level consent overriding it. A mixed batch therefore needs careful handling. Prefer explicit per-event decisions in the internal ledger, even when the transfer component later groups identical states. Under the conservative example policy used here, denied and unresolved cases are held out of transfer. That is a chosen operating control, not a claim that one rule resolves every jurisdiction’s requirements.
Use the outcome time and check every relevant window
Keep four times distinct: advertising interaction, outcome occurrence, CRM observation and transfer. If a contract was accepted on Monday and entered into the CRM on Wednesday, Wednesday is the observation time. Replacing Monday with Wednesday changes the event you are measuring.
Data Manager API event timestamps use RFC 3339 as specified for eventTimestamp, such as 2026-09-14T13:20:00-04:00 or the equivalent 2026-09-14T17:20:00Z. Older Google Ads API examples use a different textual convention. Build a serializer for the selected interface rather than reusing a date string because it looks readable.
Preserve the source timezone and resolved instant. Canadian businesses can operate across several timezones, and daylight-saving changes make some local times ambiguous. A value such as “November 1, 1:30 a.m.” is insufficient where that local hour occurs twice. Resolve it using source evidence; do not guess from the CRM user’s current location.
Separate three constraints: the conversion action’s attribution window, the age limits for the selected identifier and event type, and the connector’s extraction lookback. A connector might never fetch a record that would otherwise be eligible. Conversely, fetching a record does not make it eligible for attribution.
Google’s Data Manager source guidance describes different retrieval patterns: certain file sources read a 90-day range, while database sources described there read 14 days. Its Salesforce and HubSpot connections have an initial 14-day retrieval followed by changes since the previous successful run. These are connector behaviours, not a universal permission to backfill any conversion for 90 days.
Create an ageing report before launch. Show how long records wait for sales approval, how long extraction takes, and how much time remains under the applicable route rules. Flag a backlog before it expires. If a legitimate sale occurs too late for the available measurement path, preserve it in the CRM and reporting warehouse; never move its date backwards to make it fit.
Choose one supported transfer path for each outcome
Choose the path from the source system, support requirements and available engineering capacity. The objective is a maintainable transfer with traceable results. A familiar interface is useful only if it supports the data and recovery behaviour your outcome contract requires.
| Path | Suitable use | What to verify |
|---|---|---|
| Google Ads Data Manager connection | A supported CRM, warehouse or file source maintained by an operations team. | Source availability, extraction range, refresh timing, field mapping, consent handling and diagnostics. |
| Data Manager API | A new custom integration that needs explicit transformation and delivery control. | Current access setup, destination ownership, event schema, warnings, diagnostics and adjustment behaviour. |
| CRM’s own advertising integration | A documented lifecycle-stage connector meets the outcome definition. | Subscription availability, trigger eligibility, supported identifiers and whether historical changes are included. |
| Documented third-party connector | A supported automation bridges a source unavailable through the preferred direct connection. | Its current Google transfer method, mapping controls, recovery process and data responsibilities. |
| Existing Google Ads API uploader | Maintenance of a workflow with established historical access. | The June 2026 restriction, current access model, migration plan and method-specific errors. |
Google’s legacy file-import help page now says enhanced conversions for leads supports Data Manager files and directs legacy file setups to upgrade. Use the current Data Manager template and mapping for the chosen source. This guide’s worksheet and fixture are intentionally unsuitable for upload.
Design a new custom API workflow
Follow the current Data Manager API access guide for the application’s authorised access. Then bind each outcome to a destination. The offline event guide requires the operating account to own the conversion action; its product destination identifies an UPLOAD_CLICKS action. A manager used for access and an account that owns a conversion action are not automatically interchangeable.
Before building network delivery, create a local transformation that accepts approved internal events and produces a proposed route-specific mapping. Keep the transport disabled. Review the event key, time, destination and eligibility decision together. This makes a wrong-account mapping visible before it can affect reporting.
Use a dedicated source view containing only the necessary approved events. Google’s data preparation guidance recommends a dedicated table or filtered subset per use case and refreshing data before the connection runs. Specify which team owns that refresh, and alert when the source is stale even if the connection itself reports success.
Check CRM connector behaviour independently
HubSpot’s Google Ads conversion-events documentation, updated 9 September 2026, describes lifecycle-stage changes using enhanced conversions for leads. It says only changes occurring after event creation are counted, and describes GCLID or shared contact data as matching inputs. A business moving a contact through several configured stages can send several corresponding events.
That is why “the CRM is connected” is an incomplete acceptance criterion. Verify the specific event trigger and destination. Record whether the connector exports the milestone on a contact or an opportunity, whether it supports the required consent mapping, and what happens after a record merge. Do not assume a direct Data Manager CRM connection and the CRM vendor’s own Ads integration have identical backfill rules.
Keep one active producer for each outcome during normal operation. If a migration temporarily needs two producers, define non-overlapping records or another reviewed transition mechanism before enabling the second. A second connection should not quietly replay every historical milestone.
Make deduplication and corrections explicit
Create an outcome key when the business event is recognised. For example, the fictional key DEMO-OPP-A|QUALIFIED|1 identifies one first qualification. Re-reading that event tomorrow should produce the same key. A completed contract has its own identity and destination action. Never use the upload time, spreadsheet row number or a newly generated random value as the retry identity.
Maintain a ledger keyed by destination and outcome. Store the source record, payload revision, latest known processing state and any authorised change. Before sending, compare the proposed record with this ledger. An unchanged event is a replay; a changed value requires adjustment review; a genuinely different milestone requires a new event identity.
Data Manager API now treats a matching transaction ID within the same conversion action as an adjustment. Its adjustment documentation says value and currency can be replaced; user data can supplement an event that lacked it, while other fields such as the original GCLID are not updated. An unmatched transaction ID can create a new conversion. Retain the same destination and identity when correcting a supported field. An adjustment must still include the required event fields and a supported identifier: Google validates the event before looking for a matching transaction ID. Keep the original occurrence time and identifiers in the proposed adjustment; a value-only record is insufficient.
The API migration guide also states that Data Manager API does not support retractions that remove both value and count. Restating value to zero leaves the count. Therefore a cancelled contract needs an agreed measurement treatment before launch; “we will delete it later” is not an adequate recovery plan.
Handle CRM merges through an internal alias map. If two contact records are merged, the original opportunity event should retain its key. If a stage is toggled accidentally and restored, apply the repeat rule instead of generating another qualification. When an identifier was attached to the wrong person, quarantine the incident and review the route’s actual correction capabilities. Do not manufacture a new event to conceal an unresolved error.
Use a deliberately non-uploadable synthetic fixture
The following cases describe imaginary records. They contain no actual customers, valid advertising identifiers, account IDs or conversion action IDs. The marker NOT_A_CLICK_ID is deliberately invalid. These are local design cases, not API examples, upload templates or evidence of integration success.
| Case | Fictional input condition | Expected local result |
|---|---|---|
| F01 | First qualification; explicit offset; approved fictional evidence; marker identifier. | Pass business-rule checks, retain synthetic transfer block. |
| F02 | An exact replay of F01, including outcome key. | Suppress as an unchanged local duplicate. |
| F03 | Qualified record with no recorded consent evidence. | Hold for evidence under the example policy. |
| F04 | Outcome time precedes its fictional click time. | Quarantine timestamp conflict. |
| F05 | Valid-looking local time with no offset or source timezone. | Quarantine unresolved time. |
| F06 | Contract value supplied without a currency. | Hold incomplete value mapping. |
| F07 | Reopened opportunity returns to the same qualifying stage. | No new qualification under the example repeat rule. |
| F08 | Previously represented contract receives a revised fictional value. | Route to adjustment review; never silently create a fresh sale. |
| F09 | Advertising-data permission is recorded as denied. | Exclude under the example policy. |
| F10 | Destination action is absent from the approved local mapping. | Quarantine destination mismatch. |
The accompanying teaching classifier illustrates these ten outcomes only. Its results do not validate a Google schema, actual hashing, daylight-saving resolution, route-specific age limits or a real consent system. Run the fixture only inside a local test harness with a mandatory synthetic-data guard. A business-rule pass must never disable that guard. Keep the fixture in a separate file family from production exports, omit usable destinations, and require the transfer component to reject every fixture record. Passing F01 means only that the proposed business logic is internally consistent.
Validate locally before any authorised live implementation
Use a staged validation plan. Each stage should produce an artefact another person can inspect: the mapping contract, the classified fixture, the proposed serialisation and the reconciliation specification. Keep business validation separate from delivery so you can establish whether the right event is being prepared before investigating the network.
- Validate structure. Require the internal event key, recognised outcome, source reference, occurrence time, mapping version and eligibility decision. Reject unknown destinations and unexpected fields.
- Validate chronology. Parse timestamps strictly, compare resolved instants and check the outcome against the available interaction evidence. Add explicit daylight-saving and missing-timezone cases.
- Validate identifier preparation. Confirm field types, case preservation for click identifiers, email domain rules and phone formatting. Test raw-to-hash ownership without sending data anywhere.
- Validate consent decisions. Test granted, denied, missing, withdrawn and conflicting evidence. Confirm a batch default cannot replace a restrictive event decision.
- Validate repetition and revisions. Replay identical events, merge source records and alter a value. Confirm that each result follows the documented deduplication or correction rule.
- Validate the proposed transfer representation. Compare field names, required identifiers, encoding and destination structure against the current route specification. Keep fictional markers blocked.
- Validate reconciliation arithmetic. Every source row must end in one explicit local state. Batch membership and later delivery states must be traceable without counting retries as new outcomes.
Data Manager API documents validateOnly for checking requests without executing ingestion. That still involves an external API request and does not prove identity matching or reporting. Its send-events guide distinguishes these checks from processed-event diagnostics. No such request was made for this guide; the fixture must not be submitted even as a validation request.
A future authorised implementation should use a separate, reviewed validation procedure for its actual environment. Define the operator, permitted account, eligible real data, acceptance criteria and recovery process first. Local success is a prerequisite for that work, not a substitute for it.
Diagnose the failing boundary
Give each failure a home. A missing stage timestamp belongs to CRM extraction. A malformed hash belongs to preparation. An inaccessible action belongs to destination or access configuration. A processed event absent from a chosen report may require an attribution or reporting investigation. Mixing these categories creates repeated uploads without a clear hypothesis.
Data Manager API uses fast-fail validation: a structural error or failed required-field check rejects the entire request before processing. Optional-field problems can instead produce fieldWarnings. More complex checks happen asynchronously, so initial acceptance still requires inspection. Google’s diagnostics guide recommends retaining the request ID, beginning status checks after 30 minutes, and checking each destination until it reaches success, partial success or failure. Processing can take up to 24 hours. These are documented expectations, not timings measured here.
| Symptom | First evidence to examine | Controlled next step |
|---|---|---|
| No source events | Stage history, extraction watermark and source refresh time. | Confirm whether the milestone occurred and was eligible for retrieval. |
| Request rejected | Exact error category, affected field and destination mapping. | Correct the identified fault; preserve event identities. |
| Request accepted with warnings | Field warnings and the prepared payload revision. | Determine which optional data was ignored before declaring success. |
| Destination processing incomplete | Request status and elapsed time. | Follow documented status-check timing; avoid blind resubmission. |
| Processed count differs from report | Action, date basis, timezone, count settings and attribution scope. | Rebuild a comparable cohort before investigating individual exceptions. |
| Sudden duplicate or value changes | Producer inventory, outcome keys and revision history. | Pause the faulty producer and classify replays versus intended adjustments. |
Google Ads also provides offline data diagnostics with data-quality alerts and upload history. These help explain whether imported events were well formed and valid. Keep your own ledger as well: a dashboard status cannot reconstruct a deleted extraction file or explain a changed sales definition.
“Unknown click” can occur when eligible enhanced-conversion outcomes include other marketing channels. It becomes more concerning when expected Google-attributed records consistently fail. Google’s discrepancy guidance covers this distinction. Investigate evidence and capture quality; never replace identifiers or alter dates simply to make an error disappear.
Reconcile source, delivery and reporting separately
Create three views. The source view explains every selected CRM event. The delivery view explains every attempted transfer and subsequent result. The reporting view explains the advertising metrics available for the comparable action and time period. Retain the date and time each view was extracted because processing and corrections can change later totals.
Use mutually exclusive source states so the arithmetic closes. In a purely fictional example, 120 candidate rows become 12 duplicate rows, 8 consent holds, 5 mapping holds and 95 eligible unique events. The equality is 120 = 12 + 8 + 5 + 95. This illustrates a reconciliation method; it is not a client result or a benchmark.
Now track those 95 eligible events by identity. If an event is attempted twice, it is still one eligible event. Keep attempt counts in a separate column. When a timeout leaves delivery uncertain, record “outcome unknown” until the available status evidence or documented replay behaviour resolves it. Do not automatically mark the record failed or create a new transaction ID.
For reporting comparison, align the conversion action, timezone, date range and metric. Google explains that ordinary conversion reporting is organised by interaction time, while “by conv. time” columns support conversion-date analysis. Upload date is a different basis. Google also notes that the “One” counting setting can reduce reported counts when several conversions follow the same interaction. See its reporting discrepancy guidance.
Destination-processing completion and appearance in an Ads report are separate clocks. Google’s discrepancy guide describes reporting delays of up to 72 hours for GBRAID- or WBRAID-keyed conversions. Do not treat the API diagnostics’ 24-hour processing expectation as a universal reporting deadline.
Choose a mature cohort and preserve that choice. For example, compare outcomes from an agreed completed week after allowing for the selected route’s documented processing lag, then refresh the same cohort later. Keep late arrivals and value adjustments visible. A total that changes after refresh is explainable when the event ledger identifies what changed.
Do not force the CRM’s total qualified opportunities to equal Google-attributed conversions. The populations can differ. Reconciliation should account for known differences, quantify unresolved ones and assign each exception an owner. It should not manufacture a one-to-one attribution claim that the available reports cannot support.
Reconciliation checklist
- Freeze the CRM cohort definition, extraction time and mapping version.
- Balance candidate rows against exclusions, duplicates, holds and eligible unique events.
- Match batch membership to the ledger and separate event counts from delivery attempts.
- Retain rejected-request details, warnings and final destination statuses where available.
- Record pending, failed and uncertain outcomes separately from completed processing.
- Align reporting action, metric, timezone, date basis and processing allowance.
- Explain adjustments and late arrivals; assign unresolved differences an owner and review date.
Final implementation checklist
- Each milestone has a documented definition, evidence source, owner and repeat rule.
- Source identifiers, outcome identity and conversion destination remain distinct.
- Consent evidence and the approved measurement decision travel with the internal event.
- Occurrence timestamps are genuine, unambiguous and eligible for the chosen route.
- Normalisation, hashing and encoding have one documented owner.
- The selected connection is currently supported, including its historical-access and correction limits.
- Synthetic fixtures are blocked from transfer, and local validation results are retained.
- Retries, adjustments, monitoring and reconciliation have named operational owners.
Use the completed mapping as the handover between CRM operations and the team responsible for Google Ads management. Approval should cover the meaning of each event as well as its technical representation. Campaign performance remains dependent on many factors; a validated data pipeline does not guarantee improved results.
If the source system is still undecided, the small-business CRM comparison covers vendor-selection questions. If the outcome data instead points to unsuitable search demand, the high-intent Google Ads guide covers search-query decisions.
Sources, method and testing limits
This original guide was researched and technically reviewed on using official Google and HubSpot documentation. The worksheet, fictional cases and reconciliation method are original design aids. Documentation findings describe platform behaviour; operating controls are recommendations to evaluate for the specific business.
The key time-sensitive sources are Google’s deprecation register (updated 30 September 2026), offline API guide (updated 6 October 2026), Data Manager migration guide (updated 7 October 2026), and HubSpot conversion-events guide (updated 9 September 2026). Other linked references were checked on the research date; a displayed publication date is not assumed when absent.
A local replay checked all ten fictional classifications and their synthetic-data flags. These checks establish only the teaching example’s behaviour. No live advertising-account reads, CRM integration tests, conversion submissions, API validation requests or campaign changes were performed. Actual permissions, connector availability, tag operation, match rates, processing times and account reporting remain untested. Recheck the cited technical documentation before implementation, particularly access restrictions, identifier requirements and adjustment support.
