Items from getUserInterestCriterion for NEW_SMART_PHONE_USER return non-existent parent

82 views
Skip to first unread message

HK

unread,
Mar 15, 2016, 9:22:29 PM3/15/16
to AdWords API Forum
Hi,

I'm using v201601 and calling getUserInterestCriterion passing NEW_SMART_PHONE_USER as the ConstantDataServiceUserInterestTaxonomyType. I get back 5 items, all with a parent ID of 85001. However, I'm not getting back an item with the ID of 85001. Should 85001 be included in the returned values? For the other types the parents are returned as well.

Thanks,
Hans

Anthony Madrigal

unread,
Mar 16, 2016, 11:37:32 AM3/16/16
to AdWords API Forum
Hi Hans,

I haven't found any criteria codes with 85001 in the documentation. Do you have the SOAP request and response where you saw this behavior? If you do, please send it to me via Reply privately to author.

Thanks,
Anthony
AdWords API Team

HK

unread,
Mar 16, 2016, 4:00:57 PM3/16/16
to AdWords API Forum


Hi, Anthony

Don't have the SOAP right here right now, but here's the data I got back (ignore the FeedTrackingID). Your comment is the exact problem, there is no 85001. So maybe a better question then is, to which parent does for example 85002 belong to? See attachment.

Hans

Josh Radcliff (AdWords API Team)

unread,
Mar 17, 2016, 8:04:29 AM3/17/16
to AdWords API Forum
Hi Hans,

From what I've gathered, 85001 is not returned because although it is the parent of those criteria, it is not itself targetable.

Since this particular criteria type is essentially flat, is the parent ID important for your use case?

Thanks,
Josh, AdWords API Team

HK

unread,
Mar 17, 2016, 12:52:47 PM3/17/16
to AdWords API Forum
Hi, Josh

My main concern with this is that it breaks the pattern of all the other types, such as MOBILE_APP_INSTALL_USER. The other types point to a parent with ID 0 and that item again has a parent ID of -1 flagging that there is none. To my knowledge, the top level items with ID 0 are not targetable either. We use the IDs and parent IDs to build a user friendly name that represents all the levels in the hierarchy and without the top level item, we have to special case it. Example of name we build based on IDs and parent IDs:

Arts & Entertainment > Music & Audio > Jazz & Blues > Jazz


No, it's not that important, but I'm not seeing why it should be different for NEW_SMART_PHONE_USER versus the other ones. See attachment for an example of what is returned for the other types. Using 85001 is confusing to me, as there is nothing telling me what that represents and whether it's the top level or not.



Thanks,
Hans

Josh Radcliff (AdWords API Team)

unread,
Mar 18, 2016, 8:45:59 AM3/18/16
to AdWords API Forum
Hi Hans,

I see what you're saying. We're not being terribly consistent here, are we? ;)

I'll pass this along to the targeting team and see what they have to say. I'll update this thread when I hear back from them.

Cheers,
Josh, AdWords API Team

HK

unread,
Mar 18, 2016, 7:16:28 PM3/18/16
to AdWords API Forum
Thanks, Josh :-)

Josh Radcliff (AdWords API Team)

unread,
Apr 11, 2016, 5:15:59 PM4/11/16
to AdWords API Forum
Hi Hans,

The response for NEW_SMART_PHONE_USER now follows the same pattern as other user interest criteria (see below). Thanks for pointing out this inconsistency.

Cheers,
Josh, AdWords API Team

      <rval>
        <Criterion.Type>CriterionUserInterest</Criterion.Type>
        <userInterestId>0</userInterestId>
        <userInterestParentId>-1</userInterestParentId>
        <userInterestName>/</userInterestName>
      </rval>
      <rval>
        <Criterion.Type>CriterionUserInterest</Criterion.Type>
        <userInterestId>85003</userInterestId>
        <userInterestParentId>0</userInterestParentId>
        <userInterestName>Recent 14 Days</userInterestName>
      </rval>
      <rval>
        <Criterion.Type>CriterionUserInterest</Criterion.Type>
        <userInterestId>85002</userInterestId>
        <userInterestParentId>0</userInterestParentId>
        <userInterestName>Recent 7 Days</userInterestName>
      </rval>
      ...


On Friday, March 18, 2016 at 7:16:28 PM UTC-4, HK wrote:
Thanks, Josh :-)
Reply all
Reply to author
Forward
0 new messages