We are seeing a very strange behavior with v201109 Java API. We are testing with an MCC that has no budget but other than that, this is against the production v201109 API. In other words, not the sandbox.
We are porting our system from v200909 and for the most part things are working OK (with a few small issues that we can fix on our end, mostly). However we are seeing one really strange behavior that genuinely seems like it might be a bug on the Google side of things. The problem is with setting geographic locations using CampaignCriterionService, and only when updating an existing Campaign (things always work perfectly when adding the campaign for the first time). Background - In the old days with v200909, this was a lot simpler because we could just provide a list of all the desired targets and the API would replace the old data with the new data in one nice operation. Today with v201109, it is more complex because we can't use the SET operator anymore, we can only use ADD and REMOVE. In the new code, we first query the existing locations, create REMOVE operations for them, and then queue up the ADD operations for the new geo targets. The bug is that on every other call (updates 2, 4, 6, etc) our geo targets are not added to the Campaign, even though we are adding them in the list of operations. Just to get this out of the way - we know that the ideal approach would be to perform a diff so we only have to add/remove what is needed. However in the interests of time we are using a dumber approach in the short term, where we front-load the operation array with the REMOVE operations for the existing data, followed by the ADD operations for the data as we want it to exist. We were told by our adWords API contact at Google that this would be acceptable: "Operations in a single call act like they are transactional/atomic. So it is safe to remove and then add in the same call. ... The recommended best practice is what you suggested - perform the diff, and apply the ADD only if needed." This doesn't really seem to work, in practice. Here is the detailed workflow: A. CREATE THE CAMPAIGN - Push these operations: [0] ADD Language = US [1] ADD Proximity = x, y After this, the Campaign looks perfect when we view it in the adWords UI. B. UPDATE THE CAMPAIGN, FIRST TIME - Query the existing operations, getting back this: [0] Language = US [1] Platform 30000 [2] Platform 30001 [3] Platform 30002 [4] Proximity = x, y - We ignore the Platform items since we don't manage them ourselves. Instead we turn around and push this: [0] REMOVE Language = US [1] REMOVE Proximity = x, y [2] ADD Language = US [3] ADD Proximity = x, y BUG: After this, in the adWords UI, the Campaign shows its Locations as "All countries and territories". The adWords API seems to have ignored our ADD Proximity operation. C. UPDATE CAMPAIGN, SECOND TIME Basically identical to the above, except when we query adWords we don't get the Proximity in the list. Therefore we don't create a REMOVE operation for it, and adWords seems happy to accept it back again. - Query the existing operations, getting back this (NOTE: no Proximity this time, consistent with the UI): [0] Language = US [1] Platform 30000 [2] Platform 30001 [3] Platform 30002 - Ignoring Platform items like above, and not issuing a REMOVE for the Proximity since none was returned in the get(), we push these operations to mutate(): [0] REMOVE Language = US [1] ADD Language = US [2] ADD Proximity = x, y After this the campaign looks great again in the adWords UI, and correctly shows our geo targeting. Summing up... So at first this looks like a problem with using REMOVE + ADD equivalent objects in the same mutate() call, but strangely this doesn't seem to behave this same way for Language. Just geo targets (proximity, state, etc). Originally we were sending all the REMOVE operations in one mutate() call, followed afterwards with another mutate() call to ADD the stuff back, but that showed the same problem. We consolidated them into one mutate call in the hopes that it would behave like a database transaction, and maybe be a little more reliable, but it still happens. Today this is completely repeatable with every other call - in other words it always cycles between accepting and ignoring the Proximity. I'm going to proceed on towards implementing the diff operation, since hopefully that will avoid this, but in the meantime I wanted to get this report out there in case the behavior still lingers on even after we implement the diff. Thanks for any clues or advice - - Jim -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
