Discrepancy Between API Response and UI for Device Models in Google Ads

[Amit Tomar]

Dear Team,

I am currently working on the Device Settings (Sales - Display) section, specifically selecting Device Models. While retrieving device data via the Google Ads API and comparing it with the UI, I noticed a discrepancy in both the number of devices and device names. Below are the details of my concern:

1. Device List Discrepancy:  
   - I executed an API query to retrieve mobile devices where the `manufacturer_name` is "Alcatel". The API response returned 86 mobile devices with `operating_system_name` as "Android" and `type` as "MOBILE".  
   - However, in the UI, I can only see 2 devices under the same manufacturer (screenshots attached).

2. Device Name Mismatch:  
   - In the Google Ads UI, the device names appear as "PIXI 4 (4034E)" and "Pixi 4 5.0 (5010G)".  
   - In the API response, the corresponding names are shown as "4034e" and "5010G", which do not match exactly with the UI naming format. 

To assist with a detailed understanding of the issue, I have attached the following screenshots:  
- API Response
- Google Ads UI for Device Models

Could you please confirm if this behavior is expected? If not, kindly advise on how to resolve this discrepancy or align the API response with the UI.

Looking forward to your assistance.

[Google Ads API Forum Advisor]

Hi,

Thank you for reaching out to the Google Ads API support team.

We would like to first specify the following when comparing the value of the Google Ads UI and Google Ads API:

• The segments and fields of the API and UI should be the same
• Comparing the API and UI at the same level as much as possible

To investigate the discrepancy, please provide us with the 'complete API logs' (request and response logs with request-id and request header) generated at your end while executing the query. Copy and paste these logs in a '.txt' file and attach it to this email thread.

If you are using a client library and haven't enabled the logging yet, I would request you to enable logging for the specific client library that you are using. You can refer to the guides Java, .Net, PHP, Python, Ruby or Perl to enable logging at your end. For REST interface requests, you can enable logging via the curl command by using the -i flag.

You can send the details via Reply privately to the author option, or direct private reply to this email.

 

This message is in relation to case "ref:!00D1U01174p.!5004Q02vGp5n:ref" (ADR-00278830)

Thanks,
 

Google Ads API Team

Feedback
How was our support today?

               

[Amit Tomar]

Dear Team,

I shared the requested logs yesterday via the "Reply privately to the author" option. Could you please provide an update on the status of the investigation?

Thank you for your support.

[Google Ads API Forum Advisor]

Hi Amit - 

I'm a developer relations engineer jumping in to help out here. Just letting you know that I'm going over these details and will send along my thoughts later today.
 

This message is in relation to case "ref:!00D1U01174p.!5004Q02vGp5n:ref" (ADR-00278830)

Thanks,
 

Ben Karl Google Ads API Team

Feedback
How was our support today?
               
 

 

[Google Ads API Forum Advisor]

Amit:

Understanding the Discrepancy

1. Device Count:

   • API shows 86 Alcatel devices with Android OS.

   • UI shows only 2 Alcatel devices.

2. Device Names:

   • API shows names like "4034e" and "5010G".

   • UI shows names like "PIXI 4 (4034E)" and "Pixi 4 5.0 (5010G)".

The Core Issue:

The fundamental issue is that the mobile_device_constant resource in the API provides a comprehensive list of all known mobile devices that Google Ads could potentially target. The Google Ads UI, on the other hand, likely filters this list down to devices that are currently relevant and actively receiving traffic for ad targeting in the specific account or campaign context the user is viewing.

Why the Discrepancy Exists:

• API is a Master List: The mobile_device_constant resource is essentially a database of all device models. It doesn't reflect live campaign performance or current targeting trends.

• UI is Contextual: The UI likely uses dynamic filtering based on factors like:

  • Recent Traffic: Only showing devices that have generated impressions or clicks recently.

  • Market Relevance: Some devices might be outdated or not commonly used in the target location.

  • Campaign Settings: Specific campaign settings (e.g., geographic targeting) could further filter the list.

• UI is Simplified: Google ads UI presents a simplified version of the master list to not overwhelm the user with irrelevant devices.

Device Name Differences:

The name differences are also likely due to the UI adding marketing/user-friendly names ("PIXI 4") for better readability, while the API might use the device's model identifiers ("4034e").

mobile_device_constant resource is a catalog of all possible mobile devices, not a list of devices currently being targeted or receiving traffic in their account.

The Google Ads UI dynamically filters the master device list based on several factors to show only the most relevant devices for a particular account/campaign.

The API uses technical model identifiers, while the UI may use more user-friendly names for clarity. The name retrieved from the API should be treated as an identifier for targeting purposes.

This message is in relation to case "ref:!00D1U01174p.!5004Q02vGp5n:ref" (ADR-00278830)

Thanks,
 

Bob Hancock Google Ads API Team

Feedback
How was our support today?
               
 

 

[Amit Tomar]

Hello Team,

Thank you for your detailed explanation regarding the discrepancy between the API response and the UI for device models in Google Ads.

I appreciate this clarification, as it helps me to better understand the behavior of the API and UI.

To ensure we align our implementation with best practices and user expectations, I would like to confirm/ask the following:

1. Relevance of Device Lists: Can you confirm if there is a reliable way to filter or query the mobile_device_constant resource to obtain only the currently relevant devices (e.g., those with recent traffic or actively targeted in campaigns)?

2. Mapping User-Friendly Names: Is there a programmatic method or resource available to map the API's technical identifiers to the user-friendly names displayed in the UI? This would help improve the usability of our reporting and targeting features.

3. Campaign Context: If the filtering in the UI is influenced by specific campaign settings (e.g., geographic or demographic targeting), is there a way to replicate similar filtering logic via the API to retrieve a contextually relevant subset of devices?

We appreciate your continued support in addressing this query and look forward to your guidance on the points above.

[Google Ads API Forum Advisor]

Hi Amit,

I'm checking with my team for the answer to your questions. Please note there may be a delay in response time due to the holiday season. I'll write back to you as soon as I hear back from them.
 

This message is in relation to case "ref:!00D1U01174p.!5004Q02vGp5n:ref" (ADR-00278830)

Thanks,
 

Benji Rothman Google Ads API Team

Feedback
How was our support today?
               
 

 

[Amit Tomar]

Hello Team,

Could you please let me know if there are any updates or additional information available?
Looking forward to your response.

[Google Ads API Forum Advisor]

Dear Amit,

No update yet. I followed up with the team again today. I'll update you as soon as I hear back from them.