Upgraded URL - URL_NOT_EQUIVALENT error although they should be

[Udo Gröbner]

Hi,

we're currently preparing for the "upgraded url" migration for search campaigns.

As far as I understand it, this is what you have to do:

Given

http://tracking.server.com/tracker?param1={creative}&param2={network}&redirecturl=http%3A%2F%2Fwww.buystuff.com%2Fcatalogsearch%2Fresult%2F%3Fq%3Dthings%2520SN2%26adword%3Dgoogle%252FkampX%252F%257Bkeyword%257D

as initial destination url of an ad, the corresponding tracking template should be

http://tracking.server.com/tracker?param1={creative}&param2={network}&redirecturl={lpurl}

and the final url for the ad would be

http://www.buystuff.com/catalogsearch/result/?q=things%20SN2&adword=google%2FkampX%2F%7Bkeyword%7D

The API upgrade process works for some ads, but doesn't for others.

What I've found out so far:

it works if i change the original destination url before the upgrading process to correspond to final url http://www.buystuff.com/catalogsearch/result/?q=things

but doesn't work for the original destination url http://www.buystuff.com/catalogsearch/result/?q=things%20SN2&adword=google%2FkampX%2F%7Bkeyword%7D

Is that correct and intended?

I don't understand though, why this would trigger a URL_NOT_EQUIVALENT error. There have been parameters before and the same parameters afterwards...

Do you have some more information on this subject?

Many thanks in advance!

[Udo Gröbner]

Seems there is some sort of auto-decoding encoded {} ... yes, it's most likely an error in the URL to have encoded value track parameters, but that happens ...

When I substitute %7B and %7D by { and }, there's no URL_NOT_EQUIVALENT error any longer.

[Michael Cloonan (AdWords API Team)]

Hello,

I'm glad you found the source of your issue. Another interesting thing I'm noting is the double-encoded symbols in your original URL. You have %257B, for example. If decoded, that becomes %7B, then decoded again becomes {. There should be no need to encode at all, but double-encoding is definitely going to cause issues.

Regards,

Mike, AdWords API Team

[Udo Gröbner]

Hi Mike,

thanks for your answer.

While that worked for some examples, it doesn't for others.

What I'm trying to do now:

- URL unescape the final url until there are no encoded symbols left

- URL escape only the query parameters (if they're not value track parameters)

But that's also not working consistently.

It would be nice to have some more information on how the adwords system combines final url and tracking template.
Do you think, there's a chance to get that?

The problem is: we have several millions of URLs and there are inevitably some "wrong" ones (double encodings, ...).

Thank you!

[Udo Gröbner]

Or to rephrase the problem:

For your check for AdError.URL_NOT_EQUIVALENT, you decode the final URL.

I couldn't reproduce the decoding step in a consistent way for special URL parameters (especially value track parameters, that were wrongly encoded in the initial destination url).

This results in URL_NOT_EQUIVALENT errors.

So some information on that part would be highly appreciated.

[Michael Cloonan (AdWords API Team)]

Hello,

If you haven't already, please take a look at our guide on how to upgrade ads to use tracking templates.

Specifically relevant is the table that shows what the URL looked like before, and what the URL looks like after. Note that the encoded redirect URL in the original is decoded (once) when used as a new final URL. If you have a wrongly-encoded before URL, in order to have equivalent URLs in the last step, it will still likely need to be wrongly encoded. Try only decoding a single time rather than decoding until there are no encoded symbols left.

Regards,

Mike, AdWords API Team

[Udo Gröbner]

Hi Mike,

thank you for your answer.

I already had a look at the guide and tried just decoding once (for a single redirect).

Unfortunately, the API still responds with an URL_NOT_EQUIVALENT error. (Just tried again)

I think, it happens most likely when there is a wrongly encoded value track parameter present

example:

once decoded final url (which is a valid url, but contains a wrongly encoded value track parameter):

http://www.buy-stuff.com/catalogsearch/result/?q=things&adword=google%2FkampX%2F%7Bkeyword%7D

It worked for cases, where the value track parameter was absent or correctly encoded in the originating destination url.

[Michael Cloonan (AdWords API Team)]

Hello,

I am reaching out to our engineering team to see if there's some valid format that will be acceptable here for the migration. I will let you know as soon as I hear back.

Regards,

Mike, AdWords API Team

[Udo Gröbner]

Awesome, thank you!

[Michael Cloonan (AdWords API Team)]

Hello,

I suggested privately to Udo to use {lpurl+2}, which unfortunately didn't solve his specific issue. However, it could be useful for others to note how this works.

{lpurl} inherently escapes certain characters one time. If you need to escape twice, you can use {lpurl+2}. The number after the + indicates how many times the system should escape.

I am still working with the engineering team to try to find a valid solution to Udo's case.

Regards,

Mike, AdWords API Team