Inconsistencies for metrics.conversion_last_received_request_date_time

[Robert Heise]

Dear Google Ads API team,

when fetching data from `conversion_action` source (Google Ads API v9, using ruby gem v15.0.0), we noticed, that the timestamp format for metrics.conversion_last_received_request_date_time is inconsistent. The timestamp pattern is mixing "yyyy-MM-dd HH:mm:ss.SSS" and "yyyy-MM-dd HH:mm:ss" formats. Note, that this happens within the same report for the same account. In the documentation https://developers.google.com/google-ads/api/reference/rpc/v9/Metrics#conversion_last_received_request_date_time I see for this specific column no timestamp pattern documented so far - however other (e.g. date) do have patterns documented. It would be great to document the timestamp pattern and also ensure that e.g. metrics.conversion_last_received_request_date_time returns consistently timestamps using a single pattern only.

Another inconsistency we noticed, is that for conversions where there is no metrics.conversion_last_received_request_date_time present, Google Ads API returns 1970-01-01 00:... timestamp. In Google Adwords API the Conversion service didn't return last_received_request_time if it had no value. I think it would make more sense if the Google Ads API would return `null` for metrics.conversion_last_received_request_date_time or do not return this column at all in the response if there is no metrics.conversion_last_received_request_date_time present . This column is an optional column according to https://github.com/googleapis/googleapis/blob/master/google/ads/googleads/v9/common/metrics.proto#L208 . The Google Ads API already behaves in a way, that it does not return optional columns in case the value is not present, see e.g. https://github.com/googleads/google-ads-ruby/issues/376 . I feel like there is an inconsistency for this case as well.

Best,

Robert

[Google Ads API Forum Advisor]

Hi Robert,

Thanks for reaching out. Can you please provide us with a sample request and response for the date-time formatting inconsistency and the UNIX epoch timestamp behavior?

Thanks,
Matt
Google Ads API Team

Matt Google Ads API Team

 

 

ref:_00D1U1174p._5004Q2WxrfJ:ref

[Robert Heise]

Hi Matt,

I've sent request and response examples in a private message.

However I wanted to add publicly:

If there is no conversion_last_received_request_date_time tracked, instead of NULL, Google Ads API returns the UNIX epoch timestamp in the account’s timezone! See https://developers.google.com/google-ads/api/reference/rpc/v9/Metrics#conversion_last_received_request_date_time the "The date/time is in the customer's time zone.".

So an account in timezone 'Europe/Amsterdam', turns the epoch timestamp already on Google side from 1970-01-01 00:00:00 UTC to 1970-01-01 01:00:00 CET. An account in America/New_York timezone gets 1969-12-31 19:00:00 ! This feels really weird and doesn't allow simply filtering a single timestamp value so we get it replaced by NULL to resemble the old (in my opinion more correct) behavior.

I think this is an even stronger argument to follow the approach already applied for other optional fields in the Google Ads API (not providing the field in the response if the value is not set like in the example https://github.com/googleads/google-ads-ruby/issues/376 - instead of a pseudo-NULL value like in case of this timestamp).

Thanks,

Robert

[Google Ads API Forum Advisor]

Hi Robert,

Thanks for providing the requested logs. I've filed these requests internally. Relevant changes in subsequent versions can be found in the release notes.

Regards,