How to use the Product Partition Report vs. Shopping Performance Report

1,386 views
Skip to first unread message

Stephen Yeargin

unread,
Feb 5, 2015, 1:33:06 PM2/5/15
to adwor...@googlegroups.com
Hi there!

We are in the process of implementing R.120 as part of the RMF audit to include the PRODUCT_PARTITION_REPORT. We had previously implemented the SHOPPING_PERFORMANCE_REPORT without too much trouble. In looking at these two report definitions, I cannot help but be confused as to what data I'm trying to show to our clients. Most of our agency clients are not using Google Shopping, and this isn't something they are really clamoring for.

In SHOPPING_PERFORMANCE_REPORT:
  • OfferId -- appears to be a UPC
  • ProductCategory[X] - These make sense
  • ProductType[X] - These make sense
In PRODUCT_PARTION_REPORT:
  • Id -- Appears to be a standard keyword ID
  • ParentCriterionId -- Can't actually include this column (see below)
  • ProductGroup -- Can't actually include this column (see below)
  • PartitionType (segment) -- Can't actually include this column (see below)

For the two above columns, I get an XML error indicating it's an invalid column. The report runs fine if I remove them.


<?xml version="1.0" encoding="UTF-8" standalone="yes"?><reportDownloadError><ApiError><type>ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT</type><trigger></trigger><fieldPath>PartitionType</fieldPath></ApiError></reportDownloadError>


So the PRODUCT_PARTITION_REPORT isn't terribly useful right now. It just shows an ID and the relevant metrics.

My root question is what am I trying to communicate with these two reports? The SHOPPING_PERFORMANCE_REPORT makes sense, but the PRODUCT_PARTITION_REPORT less so. And what should I call these in our UI? They are both "Shopping" related, so I'm guessing "Offers" for SHOPPING_PERFORMANCE_REPORT and "Products" for PRODUCT_PARTITION_REPORT

Josh Radcliff (AdWords API Team)

unread,
Feb 5, 2015, 3:00:46 PM2/5/15
to adwor...@googlegroups.com
Hi,

Regarding the errors you mentioned, please note that the report documentation shows the fields that are available in the latest version of the API, which is currently v201409. If you are using an earlier version (v201406), you can use ReportDefinitionService.getReportFields for v201406 to get the list of available fields.

Regarding the difference between the two reports, the SHOPPING_PERFORMANCE_REPORT provides statistics at the product level, while the PRODUCT_PARTITION_REPORT provides statistics at the criterion level (specifically, one row per AdGroupCriterion where the criterion is of type ProductPartition). The former is useful for giving advertisers a view of which products are being advertised in their impressions and which of those impressions are generating clicks. The latter is useful for evaluating their bidding configuration, since all bidding in shopping campaigns is configured at the AdGroupCriterion level as described in our Shopping campaigns guide. See the detailed descriptions for the reports here and here as well.

Best regards,
Josh, AdWords API Team

Stephen Yeargin

unread,
Feb 5, 2015, 3:21:31 PM2/5/15
to adwor...@googlegroups.com

I really appreciate your response, that is very helpful. I am a version behind on the API and was hoping not to go through an SDK update (it is a painful process with the PHP library right now). That allowed me to get more data in place. Here is a draft example of the report I was able to generate using a customer's data that happens to have a Shopping account attached to it.



Those column labels are likely wrong, but I don't have anything else to explain them. I'd rather show a more descriptive name than IDs, as those are meaningless to the end user. Is there any guidance on what we can show here to make this actionable?

- Stephen

Stephen Yeargin

unread,
Feb 5, 2015, 3:24:11 PM2/5/15
to adwor...@googlegroups.com

Josh Radcliff (AdWords API Team)

unread,
Feb 6, 2015, 9:55:10 AM2/6/15
to adwor...@googlegroups.com
Hi Stephen,

The fields you labeled as Product ID and Parent ID correspond to the id and parentCriterionId attributes of AdGroupCriterionService.ProductPartition, respectively.

The ProductPartitions in your example are a bit of a special case, because they all have as their caseValue instances of the ProductDimension subclass of ProductOfferId. The only meaningful attribute of that dimension type is its value, which is simply the Offer ID of the corresponding product in Merchant Center. The AdWords API does not have any additional information beyond that, such as the product description, etc.

For other types of ProductDimensions, such as ProductBrand, the value attribute is far more meaningful, e.g., with a value of "Nike" for products where brand = Nike, and those values will appear in the ProductGroup field in reports.

As far as how you can best show this information to your users and meet RMF requirements, you can contact our API Compliance Team using this form, and they may have some suggestions. They can also clear up any other RMF questions you may have.

Hope that helps!

Cheers,
Josh, AdWords API Team

Stephen Yeargin

unread,
Feb 6, 2015, 10:24:15 AM2/6/15
to adwor...@googlegroups.com

Ok, so it seems the real issue I'm running into into is that I do not have a quick way to cross reference the Criterion IDs through the Reporting API to its human-readable value. It isn't provided into the CSV file, so I would have to look the list and then map them into the user's report. That seems like a missed detail, as the other reports I'm using are a bit more user-friendly (meaning, I could generate a CSV file and it potentially be ready to hand off to the end advertiser).

I'll chase down that road.

- Stephen

Josh Radcliff (AdWords API Team)

unread,
Feb 6, 2015, 5:15:55 PM2/6/15
to adwor...@googlegroups.com
Hi Stephen,

This is exactly why we added the ProductGroup field in v201409, since it will provide the complete product partition path that users see in the UI. For example, if I have a shopping ad group with a product partition (Product Group) of:
  • All products
    • Product Brand = mybrand
      • Product Condition = new
        • Product offer ID = 123 (some product identifier defined in my Merchant Center account, e.g., a UPC)
        • Product offer ID = 456
      • Product Condition = used
        • Product offer ID = 789
then the ProductGroup field will return something like:

* / brand value = "mybrand" / condition = "new" / item id = "123"
* / brand value = "mybrand" / condition = "new" / item id = "456"
* / brand value = "mybrand" / condition = "used" / item id = "789"

In your example, the it looks like the product partition tree is only one level deep and defined solely by Product offer ID, e.g.,:
  • All products
    • Product offer ID = 123
    • Product offer ID = 456
    • ...
As a result, the ProductGroup field is less useful, because it just gives back:

* / item id = "123"
* / item id = "456"

This is similar to what you'd see in the AdWords UI on the Product Groups tab for this particular setup.

Cheers,
Josh, AdWords API Team

Stephen Yeargin

unread,
Feb 6, 2015, 5:27:56 PM2/6/15
to adwor...@googlegroups.com

Ok, now I understand a bit better. The third column ProductGroup in my example is really the vital bit. The IDs aren't as vital to understanding the report (when combined with the AdGroupName). This particular campaign is just not set up where this report is as clear. We actually don't have access to the UI for these campaigns -- the user OAuth2's their account and that's our only way of viewing the data.

- Stephen
Reply all
Reply to author
Forward
0 new messages