Your website consent banner covers the browser journey. It does not automatically fix what happens later when a lead becomes qualified in a CRM, a salesperson closes a deal, or an in-store transaction is uploaded to Google Ads.
That is a separate implementation job: preserve the user’s approved consent state with the customer record, apply it to the correct downstream use, and send it with the offline event where the destination supports it.
This guide is intentionally separate from the website Consent Mode v2 setup guide. Use that guide for the banner, defaults, Google tag behavior, and Tag Assistant. Use this guide for CRM and offline conversion pipelines.
Technical details were checked against Google’s current Data Manager API field mapping, Google Ads API Consent object, and EU user consent policy guidance on August 23, 2026.
First, separate three jobs that teams often mix together
| Job | Example | Consent question |
|---|---|---|
| Website measurement | A visitor loads a landing page and submits a form | May Google tags use advertising or analytics storage and send advertising user data? |
| Offline conversion measurement | The CRM changes a lead from MQL to SQL or Closed Won | May this user’s data be sent to Google for advertising measurement? |
| Audience personalization | A customer record is added to a Customer Match audience | May this user’s data be used for personalized advertising? |
The fields are related, but the uses are not interchangeable. ad_user_data represents consent to send user data to Google for advertising. ad_personalization represents consent for personalized advertising.
Google’s Data Manager field mapping documents a consent object with both fields. Google’s API reference also notes that ad_personalization applies to audience-oriented services. In practical terms, conversion measurement and Customer Match must be treated as separate destinations with separate rules. Do not mark both fields granted simply because a record exists in the CRM.
ad_storage and analytics_storage control storage behavior for tags and SDKs. They belong in the website Consent Mode implementation. Do not invent those fields in an offline API payload unless the destination’s current schema explicitly supports them.
The offline consent data flow
Ad click → landing page stores permitted click and form identifiers → CMP records the user's choice → website sends the choice to Google tags and CustomerLabs → lead and consent history are connected to one profile → CRM reports Qualified Lead, Opportunity, or Closed Won → destination rule checks the current applicable consent state → CustomerLabs sends the permitted event to Google Data Manager → Google Ads diagnostics confirms acceptance or reports a field errorThe important word is history. A single consent=true field is weak evidence. Marketing operations needs to know what the user chose, when they chose it, which notice or purpose they saw, and whether they later withdrew it.
Build the source-of-truth record before the upload
For each person, retain the fields your approved policy requires. A useful operational record looks like this:
| Field | Example | Why it matters |
|---|---|---|
| Internal person ID | person_8472 | Joins web, form, and CRM records without relying on email alone |
| Consent type | ad_user_data | Identifies the specific permission |
| Consent state | granted or denied | Drives the destination rule |
| Recorded at | 2026-08-23T10:14:07Z | Resolves which state applied when the event occurred |
| Source | cookiebot_marketing_choice | Shows which banner or process supplied the state |
| Policy or notice version | privacy_notice_2026_07 | Supports audit and change control |
| Region | DE | Supports the approved regional rule |
| Revoked at | Timestamp or empty | Prevents an old grant from becoming permanent |
Do not use an inferred choice as a granted choice. Do not convert a missing value to granted. Decide with your privacy team whether missing data must be denied, suppressed, or handled by a separate lawful workflow.
Map the conversion fields separately from consent
An offline conversion still needs a valid measurement payload. For enhanced conversions for leads, Google recommends uploading available GCLIDs and user-provided data rather than treating them as substitutes.
| Business field | Google destination field or role | Validation rule |
|---|---|---|
| CRM stage | Conversion action | Use separate actions for meaningful stages such as Qualified Lead and Converted Lead |
| Stage-change time | Event timestamp | Send the actual outcome time in the required timezone or RFC 3339 format |
| GCLID, GBRAID, or WBRAID | Click identifier | Preserve the original value without trimming or reformatting |
| User identifier | Normalize, then hash with SHA-256 when your upload method requires client-side hashing | |
| Phone | User identifier | Normalize to E.164, then hash when required |
| Deal value | Conversion value | Send a numeric value with the correct currency |
| Deal or event ID | Order or transaction ID | Use a stable value for deduplication |
| Consent state | Consent object | Apply the state approved for this use and event time |
Hashing reduces exposure of direct identifiers during matching, but it is not consent. Google’s enhanced-conversion data policy makes the advertiser responsible for preparing and uploading customer data under the applicable terms.
Choose the current upload path
For a new implementation in 2026, use Google Ads Data Manager or the Data Manager API. Google announced that starting June 15, 2026, offline conversion and enhanced-conversion uploads from non-allowlisted developer tokens are blocked in the Google Ads API. Some existing integrations may retain limited legacy access, so audit the actual developer token before changing a live pipeline.
Do not assume a successful HTTP request means a valid conversion. Keep the request ID and read the diagnostics.
Google’s current Data Manager migration mapping shows:
conversion_actionmaps to a Data Manager destination reference.conversion_date_timemaps to an event timestamp.conversion_valueandcurrency_codemap to value and currency.user_identifiersmap into Data Manager user data.- the consent object maps to consent and can be set per event or at request level.
Use request-level consent only if every event in that request has the same valid state. Per-event consent is safer when batches contain people with different choices.
Configure the CustomerLabs path
CustomerLabs can connect the consent state collected on the website with later CRM stages. The product setup is:
- Connect the website and CRM sources to the same CustomerLabs account.
- Confirm the same test person resolves into one profile.
- Send the CMP choice to CustomerLabs with
_cl.trackConsent()whenever the choice changes. - In Destinations, configure the Google Data Manager or Google Ads connection.
- Create the Google Ads offline conversion actions first.
- Fetch those actions and map each one to the matching CustomerLabs event.
- Turn on enhanced conversion tracking when the Google Ads account and destination are configured for it.
- Configure destination consent rules so a denied or missing state follows the approved behavior.
- Enable the event workflow only after the test matrix passes.
Use the CustomerLabs Google Data Manager destination guide for the current screens. The offline conversion operations page is the commercial parent for teams that need CRM stages, identity, click IDs, and Google activation in one workflow.
Run these four test people before launch
Create test records, not real customers. Give each test a stable internal ID.
| Test person | Website choice | CRM action | Expected result |
|---|---|---|---|
| A | Grants the approved advertising measurement purpose | Becomes Qualified Lead | Event is sent with the allowed identifiers and applicable consent state |
| B | Denies advertising user data | Becomes Qualified Lead | Event is suppressed or sent without disallowed data according to the approved rule |
| C | Grants, then withdraws before the deal closes | Becomes Closed Won | Latest state wins; the old grant is not reused |
| D | Has no recorded choice | Becomes Opportunity | Missing state follows the documented fallback; it is never silently changed to granted |
For each record, verify all five seams:
- The banner created the expected state.
- The state and timestamp appear on the correct CustomerLabs profile.
- The CRM stage is attached to that same profile.
- The outbound event contains the right conversion fields and no prohibited identifiers.
- Data Manager or Google Ads diagnostics accepts the event.
Then repeat one test with a duplicate event ID. The platform should not count a second conversion. Repeat another with a deliberately malformed phone number so your monitoring proves it can surface a field-quality error.
Common failures and fixes
The CRM has consent, but it cannot be joined to the web visitor
Use a stable internal person or lead ID across the form and CRM. Email alone can change, arrive in multiple formats, or belong to multiple records.
Every imported record is marked granted
Stop the workflow. Trace the source of the value, add state timestamps, and test withdrawal. A default value is not evidence that the person made a choice.
The conversion uploads, but Google Ads does not attribute it
Check the conversion action, timestamp, account, click-ID capture, user-data normalization, and upload delay. Keep sending available GCLIDs; Google explicitly recommends them even when enhanced matching is enabled.
Customer Match works, so the team assumes conversions are correct
These are different jobs. An audience list tests personalization eligibility. An offline conversion tests measurement and attribution. Validate each destination independently.
The API returns partial or batch failures with no owner
Create an alert with the request ID, destination, conversion action, error class, and first-seen time. Assign an operations owner. A dashboard with no response process is not monitoring.
Production acceptance checklist
Do not launch because the connector says “Active.” Launch when the team can answer yes to each question:
- Are website and CRM records joined for a real test journey?
- Is consent stored by type, state, source, and timestamp?
- Does withdrawal stop later disallowed sends?
- Are conversion actions separated by meaningful lifecycle stage?
- Are GCLID and user-provided identifiers sent when available and permitted?
- Are timestamps, values, currencies, and deduplication IDs correct?
- Are Data Manager diagnostics reviewed by a named owner?
- Does a weekly reconciliation compare CRM events, sent events, accepted events, and Google Ads conversions?
If your team cannot prove that full path today, book a CustomerLabs demo. Bring one test lead, the CMP field map, the CRM stage list, and the Google Ads conversion action IDs. The goal should be one validated journey, not another consent toggle.
