Google on November 4, 2026 released version 1.9 of its Data Manager API, adding support for Google Ads call conversions, a list of the exact records that failed or drew warnings during processing, and a new lead ID field that Google says cannot yet be used for attribution. The changes were set out in a Google Ads Developer Blog post signed by Lindsey Volta on behalf of the Data Manager API team.

In Short

When someone sees an ad, phones a business and later becomes a customer, the business can now tell Google about that call through the same data pipe it uses for other offline sales, as long as it scrambles the caller's phone number first. Google will also now say exactly which rows in an upload went wrong, instead of only how many did. That matters to anyone sending phone leads or offline sales back to Google Ads, because those records feed how automated bidding values each call, and one more piece of the old Google Ads API work can now run through Data Manager.

What Google released on November 4

The post, titled "Data Manager API now supports Google Ads call conversions and row-level diagnostics," is dated Wednesday, November 4, 2026. It describes three changes to the API, the developer route into Data Manager, Google's hub for sending first-party data to its advertising products. The matching entry in the API's release notes is dated 2026-11-04 and labelled v1.9.

The first change is call conversions. "Call conversions track when your ads lead to phone calls and when those calls lead to valuable customer actions," according to the post. To send one, a developer sets a new call_info field on the event, whose start_timestamp holds the time the call began, and identifies the caller with a hashed phone number in user_data.

The second is row-level detail in diagnostics. Each ErrorCount and WarningCount returned when a developer checks the status of a request now includes a record_indices field listing the positions of the affected records in the original request.

The third is a lead_id field in ad_identifiers, which, according to the post, carries "the Google-generated ID that's issued when a user submits a lead form."

The release notes add a longer list of new enum values than the post mentions: eight new ErrorReason values, four new ProcessingErrorReason values, two new ProcessingWarningReason values and one new WarningReason. That makes 15 new codes by PPC Land's count, several of them tied specifically to phone calls.

The post contains no performance claims, no adoption figures and no deadline for anything.

How a call conversion is sent

The mechanics are spelled out in a pair of developer guides linked from the post, both marked as last updated on November 3, 2026. A call conversion goes to a Google Ads conversion action whose type is set to UPLOAD_CALLS. The request names the Google Ads account as the operating account, using its 10-digit customer ID without hyphens; data partners sending on behalf of advertisers identify themselves with a DATA_PARTNER login account.

Three fields are required on each event, according to the send-events guide. call_info.start_timestamp records when the call started. event_timestamp records the conversion itself and must not be earlier than the start of the call. And user_data must carry the caller's phone number. A new error, CONVERSION_PRECEDES_CALL, is returned when a conversion is timestamped before the call that supposedly produced it.

Everything else is optional: an event source (Google's sample uses PHONE), a conversion value, a three-letter ISO 4217 currency code, custom variables, and consent settings for ad user data and ad personalization, which can be set for the whole request and overridden per event. A validate_only flag lets a request be tested for errors without any data being ingested.

The Data Manager API already handled offline conversions and enhanced conversions for leads, and its event model has carried a PHONE event source since version 1.2 in August 2025, according to the release notes. None of the earlier entries in those notes mentions call conversions as such. Version 1.9 is the first in which a Google Ads call conversion action can be the destination.

Formatted, hashed and encoded

The phone number cannot be sent as typed. According to the guide, it must first be put into E.164 format, the international standard that strips spaces, brackets and dashes and adds the country code: Google's example turns +1 (800) 555-0199 into +18005550199. The formatted number is then hashed with SHA-256 and encoded as hex or Base64, with an encoding field at request level declaring which.

That is a departure from the Google Ads API, which takes the caller's number unhashed in a caller_id field, according to Google's comparison of the two. A new warning, WARNING_REASON_INVALID_NUMBER_FORMAT, appears among the v1.9 additions.

Hashing is not the same as anonymity. The US Federal Trade Commission said as much in July 2024, when it warned that hashed data is not anonymous and that companies describing it that way risk deceptive practice claims. A hashed phone number can still be matched to a person, which is the point of sending it.

Encryption is another matter. According to the guide, encryption is not supported for this use case, and developers are told not to set the encryptionInfo field. A new ENCRYPTION_NOT_SUPPORTED error covers requests that try. The timing is awkward. On October 18, PPC Land reported a Google email telling advertisers that Google Ads Data Manager will stop requiring SHA-256 hashed customer data from November 16, 2026, accepting encrypted data by default and processing it in a trusted execution environment. That email listed the Data Manager API among the routes covered. Twelve days before that switch, the newest event type on the same API requires hashing and refuses encryption. Neither the post nor the guides say whether call conversions will follow the November 16 model later.

What changes for teams on the Google Ads API

Call conversions could already be uploaded through the Google Ads API. Google has published an upgrade guide for developers moving that work across, and its comparison table shows the two systems behave differently in ways that go beyond field names.

The first difference is the phone number, hashed in one and raw in the other. The second is error handling. The Google Ads API uses a partial failure model, in which valid rows go through while bad ones are rejected individually. The Data Manager API uses what Google calls a fast-fail model: according to the upgrade steps, all records in a request fail if any record has an error at the validation stage. The partial_failure setting has no equivalent, and the per-row results returned by the old method have none either, because processing is asynchronous and outcomes surface later in diagnostics.

The third difference concerns duplicates. The Google Ads API rejects a repeated call conversion with a CALL_CONVERSION_ALREADY_EXISTS error. The Data Manager API accepts it without an error, and, according to the comparison, Google Ads performs deduplication on call conversions after they have been processed. A pipeline that used the old error as a signal that a call had already been recorded loses that signal.

The field mappings are mostly direct. call_start_date_time becomes call_info.start_timestamp; conversion_date_time becomes event_timestamp; conversion_value and currency_code become conversion_value and currency. The conversion action moves to product_destination_id and must be given as a numeric ID rather than a resource name, and custom variables are referenced by name. New credentials are needed, because, according to the upgrade steps, the Data Manager API requires a different OAuth scope from the Google Ads API.

What the upgrade guide does not contain is a deadline. It sets no date after which the Google Ads API stops accepting call conversions and makes no statement about deprecation. That stands apart from the other conversion routes Google has moved this year. In May, Google said developer tokens without recent use would be blocked from importing offline conversions through the Google Ads API from June 15, with the Data Manager API as the replacement. That restriction covered UploadClickConversions, standard offline imports and enhanced conversions for leads. Call conversions were not named in PPC Land's coverage of it.

Diagnostics that name the failed rows

The second change addresses a problem the post states plainly. "A successful ingestion request doesn't guarantee that every record was processed," it says.

Data Manager has offered status checks since version 1.3, in October 2025, through a method called RetrieveRequestStatus. A request that passes validation returns a request ID; the developer then asks for the status of that ID once processing has run. Until now, the answer gave counts: how many records failed for each reason, and how many drew warnings. It did not say which ones.

Version 1.9 fills that gap. Each ErrorCount and WarningCount now carries record_indices, which, according to the post, "lists the 0-based positions of the affected records in your original request." The post gives an example. A record_indices value of [0, 3] on an ErrorCount with reason PROCESSING_ERROR_REASON_CLICK_NOT_FOUND "means the first and fourth events in your request failed for that reason."

Google's instruction follows: "Use these indexes with the error reason to correct the failed records and resend them." Warnings are treated differently. "Records with warnings weren't rejected, but some of their data was ignored, so fix the cause of the warning in future requests," the post says.

Timing and limits

The diagnostics guide sets out how the check works in practice. Google says to wait 30 minutes after ingestion before the first status request, then back off exponentially, multiplying the wait by 1.3 each time up to a maximum of 60 minutes between attempts. Processing may take up to 24 hours, although, according to the guide, some requests finish in as little as 30 minutes. Each destination in a request reports one of four states: PROCESSING, SUCCESS, FAILED or PARTIAL_SUCCESS.

Indexes are reported per destination, so a request sent to two destinations can produce two separate lists. A record can appear under more than one reason. The status check must use exactly the same access path as the original upload, and read-only access returns a permission error. The guide also tells developers not to resend records that succeeded, which matters now that duplicate call conversions are accepted silently rather than rejected.

There is a window. The new REQUEST_TOO_OLD error, according to the API reference, signals that request status is only available for approximately 50 days after the API receives a request. The guide does not state a maximum number of indexes per error count or describe any truncation of long lists.

For developers, this changes the shape of the work. Under the fast-fail model, a malformed record sinks the whole request at once, which makes it visible immediately. The harder cases are records that pass validation and then fail during matching, such as a click that cannot be found. Google's developer podcast drew that distinction in May, when its fourth episode explained that synchronous errors reject a whole batch while asynchronous errors come back through the status endpoint. Until version 1.9, the second category came back as a number with no address attached.

The new codes

Several of the 15 new codes concern calls directly. Alongside CONVERSION_PRECEDES_CALL, the processing errors now include PROCESSING_ERROR_REASON_TOO_RECENT_CALL, PROCESSING_ERROR_REASON_EXPIRED_CALL and PROCESSING_ERROR_REASON_INVALID_CALL. The names suggest timing windows on both sides of a call: too soon to import, or too old to count. Neither the post nor the release notes say what those windows are.

Two codes deal with newly created setups: CONVERSION_ACTION_TOO_RECENTLY_CREATED at validation and PROCESSING_ERROR_REASON_DESTINATION_TOO_RECENTLY_CREATED during processing. Two warnings concern custom variables that are not enabled or not predefined. The remaining additions are DUPLICATE_ELEMENTS, INVALID_AD_IDENTIFIER_FOR_ACCOUNT, INVALID_DATE and UNSUPPORTED_BASELINE_LOCATION, the last relating to the insights feature rather than conversions.

Lead IDs, with a caveat

The third change is smaller in code and larger in its implications. The new lead_id field sits in ad_identifiers and carries the identifier Google generates when someone submits a lead form. Google-hosted forms are the mechanism behind lead ads on Google's inventory, where a user's details are captured without a visit to the advertiser's site.

According to the post, lead_id and the existing match_id field can be included "as event identifiers for offline and multi-source events sent to Google Ads, Floodlight, and Google Analytics destinations." The API reference describes match_id as the field used to join an event with a previous event. It was added in version 1.7, on May 28, 2026, when Data Manager API v1.7 extended offline conversions to Campaign Manager 360, Search Ads 360 and Display and Video 360.

Then comes the caveat. "Attribution using lead_id and match_id isn't available yet. Until it is, include other identifiers to ensure events are attributed," the post says. No date is given. By PPC Land's count, match_id has been in the API for 160 days without attribution support. Developers can now populate two identifier fields that Google's own systems will not yet use to credit a conversion to an ad.

The lead field arrives as Google builds out its lead tools inside Google Ads. On June 1, PPC Land reported that Google Ads had gained a native Leads screen showing 60 days of raw, qualified, converted and lost leads from Google-hosted forms. Ginny Marvin, Ads Product Liaison, had earlier summarised 42 lead generation launches from Google Marketing Live 2026. And in June, Google merged enhanced conversions for web and for leads into a single setting, a change that coincided with the June 15 restriction on lead uploads through the Google Ads API.

A Google-issued lead ID would give advertisers a way to tie a form submission to a later sale without relying on hashed email addresses or a click identifier captured in a CRM. That is the promise. The release ships the field, but not the matching.

How the API reached version 1.9

The release notes trace a steady build-out. Version 1.0 appeared on April 2, 2025. An IngestEvents method followed in version 1.1 that June, offline conversions and enhanced conversions for leads in version 1.2 that August, and general availability, along with status checks, in version 1.3 on October 6, 2025. Google then promoted the Data Manager API publicly on December 9, 2025, with eleven partners and limits of 100,000 requests per day and 300 per minute per project.

The Google Ads API began losing functions to it soon after. In January, Google said new implementations of session attributes and IP addresses in conversion imports would stop being accepted from February 2, 2026. In March, developers were told that Customer Match uploads through the Google Ads API would fail from April 1. In an April episode of Google's developer podcast, Melissa Ng described a roadmap aimed at full use-case parity by the end of 2026, with Customer Match closed to new developers and a March 2027 deadline for data partners.

Releases came faster through the spring. Version 1.6, on May 7, added store sales and broadened Google Analytics events. Version 1.7, three weeks later, brought Google Marketing Platform destinations, match_id and, as PPC Land reported, IP addresses as a Customer Match signal. Version 1.8, on July 30, added a method to remove all members of an audience at once, field-level warnings and address fields for Google Analytics, according to the release notes.

Version 1.9 arrives 97 days after version 1.8, by PPC Land's count. In the weeks before it, Google's DV360 API v5 beta removed Customer Match audience management, sending that work to the Data Manager API as well. Two days after the call conversion release, on November 6, Google put Data Manager inside Google Analytics in beta.

Agent skills

The post closes with a pointer to what Google calls Data Manager API agent skills, aimed at developers "building with AI coding tools." According to the linked guide, these are three packaged sets of instructions, covering setup, event ingestion and audience ingestion, published in a Google repository on GitHub. They follow the open Agent Skills format, and the guide gives install commands for Google Antigravity, Claude Code, Codex and Cursor. No release date is stated.

Calls in Google Ads this year

Phone calls have been a busy area for Google Ads in 2026, mostly on the measurement side. In January, PPC Land reported that Google, which first announced the change in October 2025, was phasing out call-only ads, with creation removed in February 2026 and existing ads losing impressions in February 2027, pushing calls towards responsive search ads with call assets.

In April, Google Ads began using AI to qualify phone call leads, analysing call recordings where available and falling back on call duration where not. In August, a View call report link appeared inside phone conversion actions.

Imported calls also figure in attribution. Later in August, PPC Land reported that Google Ads attribution modeling ignores offline conversions uploaded more than seven days after the event, and that the attribution reports' coverage includes call import. A call conversion pipeline that waits up to 24 hours for diagnostics, then corrects and resends failed rows, has that seven-day horizon to work within.

What the release leaves open

Several questions sit outside the post and the guides.

Will the Google Ads API route for call conversions be closed, as Customer Match and new click conversion imports were? The upgrade guide sets no deadline and makes no statement that one is coming. Given how those earlier moves were handled, the absence is notable, but it is an absence, not a commitment.

The relationship with the November 16 encryption change is not addressed. Offline data sent through Google Ads Data Manager, the API included, is due to be processed in encrypted form from that date, twelve days after this release, yet call conversions arrive hash-only, with a dedicated error for encrypted requests.

The timing thresholds behind the new too-recent and expired call errors are not given in the post or release notes. Nor is a date for attribution on lead_id and match_id.

And there are no numbers. How many advertisers import calls through the Google Ads API today, how much of their conversion data comes from calls, or what share of Data Manager records fail processing: the post offers none of it.

Why this matters for marketers

For businesses where the phone is the sales channel, such as home services, legal, healthcare, insurance and car dealers, the call that follows an ad is often where the money is decided. Uploading the outcome of those calls tells Google which ad clicks produced revenue, and that information feeds Smart Bidding. Until now, teams that had moved Customer Match, offline click conversions and enhanced conversions for leads onto the Data Manager API still had to keep a Google Ads API integration running for calls. Version 1.9 removes that split, at the cost of rewriting the pipeline to hash numbers, handle fast-fail requests and track outcomes asynchronously.

The diagnostics change is less visible but probably more widely felt. Any team uploading conversions through the Data Manager API can now trace a processing failure to a specific record, rather than knowing only that some records failed. For agencies and data partners sending large batches on behalf of many advertisers, that is the difference between resending a whole file and resending a handful of rows.

The lead ID points somewhere Google has not yet arrived. A Google-generated identifier for form submissions, usable across Google Ads, Floodlight and Google Analytics, would deepen the link between Google's own lead forms and the sales advertisers record later. For now, the field exists and attribution does not.

Taken together with the year's other moves, the release fits a clear direction. Each conversion type Google adds to the Data Manager API is one fewer reason to keep the Google Ads API conversion endpoints alive. Until November 4, call conversions had been a gap in that list.

Timeline

Summary

Who: Google, through the Data Manager API team, in a Google Ads Developer Blog post signed by Lindsey Volta. The release affects developers, data partners and advertisers that upload conversions to Google Ads, Floodlight and Google Analytics, and in particular those importing phone call conversions through the Google Ads API.

What: Version 1.9 of the Data Manager API adds Google Ads call conversions, sent with a call_info.start_timestamp and a caller phone number formatted to E.164 and SHA-256 hashed; record_indices on every error and warning count in diagnostics, listing the 0-based positions of affected records; a lead_id field for Google-generated lead form IDs, which, like match_id, cannot yet be used for attribution; and 15 new error and warning codes. Encryption is not supported for call conversions, duplicates are accepted and deduplicated after processing, and no deadline is set for the Google Ads API call conversion route.

When: The blog post and release notes are dated November 4, 2026. The linked guides were last updated November 3, 2026. The release comes 97 days after version 1.8 and twelve days before Google Ads Data Manager is due to accept encrypted customer data by default.

Where: In the Data Manager API, documented on Google's developer site, with call conversions going to Google Ads conversion actions of type UPLOAD_CALLS and lead and match identifiers usable on events sent to Google Ads, Floodlight and Google Analytics destinations.

Why: Google says call conversions track when ads lead to phone calls and when those calls lead to valuable customer actions, and that the diagnostics change lets developers find and fix the exact records that had problems. The release continues Google's 2026 move of conversion and audience uploads from the Google Ads API to the Data Manager API, following Customer Match, offline click conversions and enhanced conversions for leads.