Data Manager API adds call conversions and row-level diagnostics

What changed

Google's 4 November Data Manager API announcement adds Google Ads call-conversion ingestion and a more precise way to investigate processing failures. For a call event, call_info.start_timestamp records when the phone call began, while user_data identifies the caller using a hashed phone number. The announcement links to implementation and migration instructions for existing Google Ads API users.

The diagnostics change addresses a common distinction in data pipelines: accepting an ingestion request does not establish that every record was successfully processed. ErrorCount and WarningCount now expose record_indices, identifying affected entries by their zero-based positions in the original request. This allows the implementer to connect a processing reason to particular submitted events.

For example, positions 0 and 3 refer to the first and fourth records. If those records failed, the team can investigate their identifiers and other inputs, correct them and resend the affected records. A warning has a different meaning: the record was not rejected, but some data was ignored. Google advises fixing the warning's cause in future requests rather than treating warnings as identical to failed events.

A practical implementation should preserve a reliable link between submitted rows and the request's diagnostics. If a team rearranges or filters its local file after upload without retaining that mapping, an index can point the reviewer at the wrong row. Keep an appropriate request manifest within the organisation's existing data-handling controls and review failures separately from warnings. This is an operational implication of positional diagnostics, not a claim that Google stores an advertiser's internal row identifiers.

The same release accepts lead_id, the Google-generated identifier associated with lead-form submission, alongside the existing match_id for offline and multi-source events sent to supported destinations. However, attribution using lead_id or match_id is not yet available. Other supported identifiers remain necessary for attribution; accepting a field must not be reported as completed attribution support.

Lindsey Volta signed the announcement on behalf of the Data Manager API team. The change is distinct from the earlier Data Manager encryption notice and other ingestion announcements. Review the linked release notes and destination-specific requirements before changing a production upload, and verify actual processing results after a test submission.