How to properly count symbols with different bytes weight for chars limitations in ads

[Nadezhda Yakuba]

So, we have such a situation, when symbols like this one ✅ are counted as 2 symbols in Google Ads (on screenshot you can see the symbol in the first headline)

If we count bytes for this symbol, it will be 3 bytes.

Then we also have cyrillic chars, which count as 2 bytes, but are considered as 1-symbol chars in google ads len for ad elements.

Is it right to consider that symbols, which weight 1-2 bytes, are counted as 1 char, and symbols that are >= 3 bytes count as "bytes-1" char?

Like cyrillic: 2 bytes and 1 char, 

and ✅: 3 bytes and 2 chars?

Thanks in advance

[Nadezhda Yakuba]

Here is the mentioned screenshot

[Google Ads API Forum Advisor Prod]

Hi Nadezhda,

Based on your screenshot, it looks like you are using the UI. Since this team specializes in the Google Ads/AdWords API inquiries, I recommend reaching out to product support team via the help center

Thanks,
Matthew
Google Ads API Team

Matthew Google Ads API Team

ref:_00D1U1174p._5004Q26990N:ref

[Nadezhda Yakuba]

Hi Matthew,
I just illustrated it with UI, we are creating ads via mix of adwords and google ads APIs actually, and we have the same problem - how to properly count chars, so we won't get the api error "TOO_LONG"?

Cause it is a bit confusing.

[Nadezhda Yakuba]

I just posted a question as you suggested at help center here https://support.google.com/google-ads/thread/77068643, but the answer that I got there does not help me at all cause I work with API

So, can you please help me and give a more definitive answer?

[Google Ads API Forum Advisor Prod]

Hi Nadezhda,

The help center thread is pretty much to the point, except that it doesn't give you something to work on. https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms has the background on double byte system (i.e. it takes twice the width to render on a monospace console -- so you can render only 40 of these chars on a 80 column console. Historically, these characters were represented in the display buffer using two bytes, hence the name "double byte character system -- (DBCS)", not to be confused with unicode, which is also a double-byte character system, but has an entirely different meaning.)

I don't know all the specific char code ranges, but I think that they are referring to the unicode pages. E.g. Indic block would be from \u0900 to \u0d7f. Thai would be from \u0e00 to \u0e7f and so on. You could ask the thread to share the exact unicode pages if you want to get more details.

My suggestion would be not to focus on the exact char set, because that would mean that you have to stay in sync with whatever rules might change in the future, and the exact charsets aren't widely documented as far as I know. Instead, you could specify validateOnly=true when creating a MutateAdGroupAdsRequest and let the API do the length validation for you.

Hope this helps? Let me know if you have more questions.

Cheers
Anash
 

ref:_00D1U1174p._5004Q26990N:ref

[Nadezhda Yakuba]

Thank you, Anash!
You see, we are building a system that helps people to work with google ads, and we have a site, where we ask users to provide settings they want to see in their ads. So, before even creating an ad, we need to validate descriptions, titles and other stuff to warn users beforehand, as soon as possible, if they are invalid in any way for Google Ads.

And yeah, we are using validateOnly=true before we try to create campaigns with ads, but it can be a little bit too late, and if we could warn our users a step earlier, when we ask them to provide settings for ads, it would be really awesome and that's is the problem I am trying to find solution for - to get as much detailed validation rules as possible.

[Google Ads API Forum Advisor Prod]

Hi Nadezhda,

Understood, I think the easiest way would be to look up the character blocks that Igor mentioned, and map their unicode ranges from Wikipedia: https://en.wikipedia.org/wiki/Unicode_block

Cheers