A Google Ads lead may turn into a qualified sales call or a valuable opportunity days after the initial click. If that offline outcome never reaches Google Ads, campaign reports and bidding signals can miss the result the business actually cares about. Released on November 4, 2026, Google Data Manager API v1.9 adds a way to upload eligible Google Ads call conversions and identify individual records affected by processing problems. It also introduces support for Google-generated lead-form IDs.
The important distinction for B2B SaaS marketers is that an accepted API upload is not necessarily a processed or attributed conversion. Teams still need to trace the path from CRM-qualified outcome to uploaded event, processing result and Google Ads reporting. The new diagnostics make failures easier to investigate, but they cannot fix inaccurate source data or attribution on their own.
Three updates that address different parts of the measurement problem
Google’s November 4 developer announcement confirms three changes in the generally available API. These are not all new ways to attribute a sale.
| Update | What’s new | What it does not solve |
|---|---|---|
| Google Ads call conversions | Send phone-call conversion events through the Data Manager API | Identifying which calls were qualified or revenue-generating |
| Row-level diagnostics | Find records affected by processing errors or warnings | Fixing poor data at its source without follow-up |
| Lead-form IDs | Include Google’s lead_id and existing match_id with supported event uploads | Attribution based on those two identifiers, which is not available yet |
This is separate from the Google Analytics Data Manager beta introduced on November 6. That beta brings connection management into the Analytics interface. The November 4 API update changes what developers can upload and diagnose. Confusing the two could lead teams to assume a new interface automatically repairs conversion tracking.
Google Ads call conversions can now enter the Data Manager API
For businesses that close valuable leads over the phone, a call is rarely the whole conversion story. The useful outcome might be a booked consultation, an accepted sales meeting, or a qualified opportunity recorded after someone hangs up.
Google Ads call conversions can now be sent using the API’s event model. Each event needs the call’s start time in call_info.start_timestamp and the conversion time in event_timestamp. The conversion cannot precede the call. The destination must point to a Google Ads conversion action of type UPLOAD_CALLS, and caller phone numbers must be formatted in E.164 format, hashed with SHA-256, and encoded correctly.
This adds an option for teams already connecting CRM and event data to Google. It does not automatically identify phone callers, grade conversations, or create CRM records. Your call-tracking and sales systems still need to establish what happened and whether the event is eligible to be sent.
There is also a technical migration detail. The older Google Ads API accepts an unhashed caller_id for this use case, while the Data Manager API requires the hashed phone number. Developers need to update their field mapping rather than simply switch the endpoint. For a wider view of the data behind these imports, see our guide to first-party data marketing.
Row-level diagnostics show which conversion uploads failed
The less flashy feature may save more debugging time than the new call upload support.
Imagine an ingestion request containing several conversion events. Google accepts the request, but some records later fail processing. Previously, an error count could be available without identifying the events behind it. Row-level diagnostics now include record_indices in ErrorCount and WarningCount entries returned by request-status diagnostics, making the affected records easier to locate.
Google’s example is specific: record_indices: [0, 3] with PROCESSING_ERROR_REASON_CLICK_NOT_FOUND points to the first and fourth records, because the positions are zero-based. The indices refer to record positions in the relevant uploaded destination data, not the business’s CRM IDs. A record may appear in more than one diagnostic category. Engineers should retain the submitted payload or a source-row mapping so they can inspect, correct and safely retry affected events.
Three stages need separate checks: request acceptance, asynchronous event processing and final Google Ads attribution. Structural or required-field problems can cause the entire request to fail immediately. Other errors and warnings can surface later, after the API has accepted the upload. Warnings may mean the event is processed with some fields ignored. validateOnly catches basic errors before a live upload, but it cannot guarantee that the eventual events will be processed or attributed.
That matters for campaign analysis. If some qualified events never enter Google Ads correctly, reported conversion totals may understate the outcomes that the CRM already knows about. Conversely, a larger conversion count after repairing imports should not be mistaken for newly generated revenue. We explored that distinction in our breakdown of Google Ads Data Strength Uplift.
Lead IDs are now accepted, but attribution still needs more
The third change is easy to overread. Google added lead_id to ad_identifiers so developers can include the Google-generated identifier associated with a lead-form submission. It can be sent alongside match_id for supported offline and multi-source events routed to Google Ads, Floodlight, or Google Analytics destinations.
The limitation is explicit: Google has not yet enabled attribution using lead_id and match_id. Teams must continue sending other supported identifiers if they expect eligible events to be attributed.
For a SaaS company capturing inquiries through Google lead forms, storing the form’s identifier alongside CRM status can improve record continuity. But sending that identifier does not automatically prove which campaign created an opportunity. That still requires careful event definitions, matchable data, and reconciliation. Our guide to B2B marketing attribution explains why a form submission and a sales-qualified opportunity must remain distinct outcomes.
Where Google Data Manager API v1.9 helps paid media and RevOps
The Google Data Manager API v1.9 update matters most when conversion measurement crosses systems. Consider a company running search ads for enterprise software. A prospect calls through an eligible Google ad, speaks to sales, and becomes a qualified opportunity days later. Marketing sees the original interaction. Sales sees the eventual result. The engineering team has to connect the records without duplicating or misclassifying the outcome.
The new release can make two parts of that process easier: moving eligible call outcomes into Google Ads, and finding event-level failures that would otherwise demand manual investigation. It does not replace the CRM, call tracking software, consent checks, or the rules that decide which business outcomes are worth reporting.
For teams using offline conversion tracking, a useful test is to reconcile a small, fixed cohort across four stages: events recorded in the CRM, events sent to the API, events processed without errors, and conversions finally attributed in Google Ads. Those figures measure different steps; treating them as interchangeable is how misleading dashboards are built. Our framework for connecting ad spend to pipeline and revenue explains the reporting handoff, while the B2B Google Ads offline conversion tracking checklist provides a practical setup and QA guide.
Four QA checks before changing production uploads
- Check the conversion action. Confirm the Google Ads destination owns a correctly configured
UPLOAD_CALLSaction, and define what qualifies as a meaningful call outcome. - Validate the identifiers and timestamps. Normalize and hash caller numbers as specified, check time order, and use only data collected and shared under applicable permissions and consent.
- Track the request through processing. Run
validateOnlyto catch basic issues, then submit a small live batch and retain its request ID and source-record mapping. Check processing status after approximately 30 minutes and inspect errors, warnings andrecord_indices. Investigate and correct affected records before any retry. - Reconcile before resending. Compare source CRM records, accepted uploads, processed records and conversions finally attributed in Google Ads. Retry only the corrected records that need it; do not automatically resend the entire batch. When migrating from the Google Ads API, remember that duplicate call uploads can be accepted initially and deduplicated later by Google Ads.
One more constraint belongs on the developer checklist: Google’s call-conversion guidance says request-level encryption is not supported for this use case. Required phone-number hashing is a different operation. That difference should be reviewed before reusing an existing ingestion configuration.
What to watch after the November release
The Google Data Manager API v1.9 release is available as part of the existing generally available Data Manager API, not a newly announced beta. Google did not report a performance benchmark in its announcement showing that these features increase conversions or reduce acquisition costs. Those outcomes depend on whether the records were missing, whether their identifiers are valid, and what the business chooses to count.
Two developments are worth monitoring: when Google enables attribution from lead_id and match_id, and how reliably CRM or call-tracking integrations surface record-level diagnostics in their own interfaces. API support is only useful to nontechnical marketers when the tools they work in expose the errors clearly.
OneMetrik Takeaway
An accepted upload is not a measured conversion. That is the most useful lesson in this release. The call-conversion endpoint is valuable for advertisers with meaningful phone-led sales, but row-level diagnostics may be the broader improvement because they help teams identify data that did not make it through processing.
At OneMetrik, we would audit conversion actions and event quality before changing what campaigns optimize for. Start with a representative batch, retain its request ID, check processing diagnostics and reconcile results against the CRM. If the counts do not match, fix the measurement pipeline before treating a bidding adjustment as the answer. A smarter bidding strategy cannot compensate for a conversion signal that never arrived.