Google Ads gains call conversion imports through the Data Manager API

Google added call conversions to the Data Manager API on November 4. Version 1.9 lets integrations send Google Ads a business outcome associated with a phone call, such as a sale recorded later. The update also adds affected record positions to diagnostics, allowing an integration to identify the events that produced each error or warning after a batch was submitted.

How imports connect calls with conversions

The import uses the information a business records about a call and its outcome. Google describes a scenario in which a CRM system retains the caller's number, the call start time and the fact that the conversation led to a sale. The outcome can be recorded when it occurs. Campaign reporting can then track the business result that the company has defined as a conversion.

For this type of import, Google Ads uses its forwarding numbers. Romania is on the list of countries where they are available. The requirements depend on where the call originated. Calls directly from ads require a call asset or call ad using a Google forwarding number. For calls from a website, the documentation specifies a call asset applied to the campaign being measured.

Google assigns forwarding numbers for measurement and can reassign them. If a person saves the number after their first call, it continues forwarding to the business for 60 days. Calling again during that period restarts the 60-day window. When it expires, the saved number stops forwarding to the same business. This period concerns the connection made through the Google forwarding number.

The destination in the API request identifies the Google Ads account that owns the conversion action. The action must have the UPLOAD_CALLS type, shown in the interface as the Call from Ads conversion source. The event carries both the conversion time and the call start time in callInfo.startTimestamp. A conversion can occur at the start of the call or later. Conversion value and currency are optional fields.

The caller's phone number is sent in the event's user identification data. Google requires normalization to international E.164 format, including the plus sign, country code and number digits, followed by SHA-256 hashing. The resulting value is encoded in hexadecimal or Base64. The request's encoding field identifies the format so the service can interpret the submitted value correctly.

Moving from the Google Ads API also changes duplicate handling. The Google Ads API returns a duplicate error for a call that has already been imported. The Data Manager API accepts these events in the request, and Google Ads deduplicates them after processing. The migration guide also distinguishes the raw number in the old caller_id field from the normalized, hashed and encoded identifier in the new integration.

Batch acceptance and record processing

A request with structural errors or an invalid required field is rejected in full during initial validation. Issues with optional fields can appear as warnings. The validateOnly option performs this check without importing data. Checks that depend on later processing, such as matching an event with data available at the destination, are reported through diagnostics after the request has been accepted.

On acceptance, the events.ingest operation returns a request identifier. The integration uses it to check status later for each destination. Google separates the processing state from final results, which can indicate success, partial success or failure. For a batch with multiple destinations, each has its own result. In a reporting workflow, the initial response shows that the batch passed validation and entered processing.

The new record_indices field identifies positions in the submitted list, starting at zero. The same event can appear in diagnostics for several destinations or under multiple reasons for one destination. An error indicates that a record was rejected. A warning indicates that it could be processed with some of its data ignored. The positions refer to the original order, including when the batch contains records that processed successfully.

Version 1.9 also adds distinct reasons for issues involving time or call eligibility. They include a conversion recorded before the call, a call that is too recent, an expired call and an invalid call. There is also a reason for a destination that was created too recently. Together with the event's position in the batch, these categories identify the record that needs checking and the condition the service reported.

Submitted identifiers and conversion attribution

Google also introduced lead_id, a field for the identifier generated when someone submits a lead form. It and the existing match_id field can accompany offline or multi-source events sent to Google Ads, Floodlight and Google Analytics. At the time of the announcement, attribution based on these two identifiers was unavailable. Event matching continues to use identifiers supported for the destination and conversion type.

Google limits an ingestion request to 2,000 events and ten destinations. Quotas apply to the Google Cloud project, with separate read and write limits for the ingestion service. Each list of positions in diagnostics therefore belongs to a single request, and the request identifier links it to the originating batch. For companies submitting calls from several accounts, the same integration can distinguish the destination, record and reported reason for each issue.