How do I replicate AdWords' CONTAINS operator in Google Ads?

569 views
Skip to first unread message

stefano...@webrepublic.ch

unread,
Jan 10, 2022, 9:21:24 AM1/10/22
to AdWords API and Google Ads API Forum
Hi,

I've read the documentation about the GAQL grammar, however I cannot find an easy way to replicate AdWords' CONTAINS behavior in some cases.
I'm mostly interested in returning a list of campaigns that contain a specific substring. This substring should never be interpreted, even it has special characters.


For instance, let's assume we have an account with these two campaigns:
- TestCampaignProduct1Search
- [test][campaign][product2][search]

In Google AdWords I could write:
- CampaignName CONTAINS "CampaignProduct1" --> returns TestCampaignProduct1Search (ok)
- CampaignName CONTAINS "[campaign][product2]" --> returns [test][campaign][product2][search] (ok)

that worked because the squared brackets weren't interpreted as special characters.

In Google Ads:
- campaign.name LIKE "%CampaignProduct1%"  -->  returns TestCampaignProduct1Search (ok)
- campaign.name LIKE "%[campaign][product2]%" -->   [test][campaign][product2][search] is not matched (not ok but expected)

as pointed out in the documentation, if I want to match a square bracket character it needs to be surrounded by square brackets:
- campaign.name LIKE "%[[]campaign[]][[]product2[]]%" -->  returns  [test][campaign][product2][search]  (ok but "complex", especially if the Filter is exposed to the users of my application)

using square brackets works but it adds a complexity that I would rather not have.
Isn't there an easier way to execute a search without having special characters interpreted?

I read that REGEXP_MATCH uses re2 and in the re2 documentation I found the  "\Q...\E" escape sequence that matches  "literal text ... even if ... has punctuation" but that doesn't seem to be supported by the API as I get an error.
Example:
campaign.name REGEXP_MATCH ".*\Q[campaign][product2]\E.*" --> returns "Request with ID "0dW9nXNyL8980lNmJJYHVQ" failed with status "INVALID_ARGUMENT" and includes the following errors: Error with message "Error in WHERE clause: invalid value ".*\.""

How come this is invalid even though \Q...\E is listed as a valid escape operator?

Is there a better solution to emulate the old "CONTAINS" behavior?

Cheers


Google Ads API Forum Advisor

unread,
Jan 10, 2022, 5:48:49 PM1/10/22
to stefano...@webrepublic.ch, adwor...@googlegroups.com
Hi Stefano,

This works:
curl -v   "https://googleads.googleapis.com/v9/customers/<CID>/googleAds:search" \
--header "Content-Type: application/json" \
--header "login-customer-id: <LGINID>" \
--header "developer-token: <DT>" \
--header "Authorization: Bearer <AT>" \
--data "{
'query': '
SELECT campaign.name FROM campaign WHERE campaign.name = \"[campaign][product2]\" ' , 'returnTotalResultsCount': true
  }"

​​​​​​​Feel free to get back to us.

Regards,

Google Logo
Aryeh Baker
Google Ads API Team
 


ref:_00D1U1174p._5004Q2UiO2O:ref

stefano...@webrepublic.ch

unread,
Jan 11, 2022, 3:09:28 AM1/11/22
to Google Ads API and AdWords API Forum
Hi Aryeh,

Thanks for the answer.

Unfortunately that doesn't work because the "=" looks for an exact match and "[campaign][product2]" is just a substring of the name "[test][campaign][product2][search]".

What I would like to have is an easy way to filter campaign names by a substring without having special characters interpreted.
By easy I mean using any substring and not having to escape the characters.
Is there one?

Cheers

Google Ads API Forum Advisor

unread,
Jan 11, 2022, 10:32:33 AM1/11/22
to stefano...@webrepublic.ch, adwor...@googlegroups.com
Hi Stefano,

In zshell this didn't create errors, but it didn't return the campaigns requested:
--data '{
"query": "
SELECT campaign.name FROM campaign WHERE campaign.name REGEXP_MATCH '\''.*\Q[campaign][product2]\E.*'\'' " , "returnTotalResultsCount": true
  }'

When echoing in my shell (zshell) the correct regex showed. Let me bring this up with my team. We will get back to you as soon as possible.

Regards,
 

stefano...@webrepublic.ch

unread,
Jan 11, 2022, 10:44:48 AM1/11/22
to Google Ads API and AdWords API Forum
Thank you Aryeh!

Looking forward to knowing the answer.

> \Q, \L, \l, \U, \u and \E are actually part of double-quotish syntax, and not part of regexp syntax proper. They will work if they appear in a regular expression embedded directly in a program, but not when contained in a string that is interpolated in a pattern.

I'm not sure how to interpret this but maybe it will point your team in the right direction.

Cheers

Google Ads API Forum Advisor

unread,
Jan 12, 2022, 1:10:03 AM1/12/22
to stefano...@webrepublic.ch, adwor...@googlegroups.com
Hi Stefano,

We've raised this concern to the rest of our team and this is currently being investigated. In the meantime, one suggestion we received is that you may also try not using .* at the beginning and end, as that may also work as well.

Best regards,

Google Logo
Peter Laurence Napa Oliquino
Google Ads API Team
 


ref:_00D1U1174p._5004Q2UiO2O:ref

stefano...@webrepublic.ch

unread,
Jan 25, 2022, 10:09:48 AM1/25/22
to Google Ads API and AdWords API Forum
Hello,

Just wanted to check if there's any news about this issue.

Currently, I'm still unable to reproduce the old "CONTAINS" behaviour.
I also tried omitting the `.*` at the beginning but it didn't work.
It would be great to find a solution because at the moment I need to escape the characters which is not ideal.

Best,
Stefano

Google Ads API Forum Advisor

unread,
Jan 26, 2022, 11:37:47 AM1/26/22
to stefano...@webrepublic.ch, adwor...@googlegroups.com
Hello Stefano,

Thanks for getting back to us. I've been chatting with a lot of people over here to see if there's an alternate solution. As you've noticed, the current workaround is to escape the characters. I'm checking if it's possible to introduce the \Q and \E into the Regex since that's pretty common and would give you the desired behavior; I'm still waiting to hear back on that. 

Best,
Google Logo
Nadine Wang
Google Ads API Team
 


ref:_00D1U1174p._5004Q2UiO2O:ref
Reply all
Reply to author
Forward
0 new messages