The experience of organizing the rotation of Destination URLs for PPC-objects

Introduction

As you know, PPC search engine objects (as a rule, these are keywords and ads) have
parameter such as Destination URL (target URL), which contains a link
on the page advertised through paid advertising.
It was necessary to organize the rotation of the Destination URL so that they are consistently
varied one after another for a large number of PPC objects (millions of key
words) on various search engines (Google, Yahoo, MSN, Baidu, ASK, etc.).

At first glance, this task could be solved by creating several Ad'ov
with the necessary target links, but in fact this approach had the following
problems:

• It was impossible to control the time of the URL - that is, it was impossible to do so
  for a URL to work only on weekends, or only two hours a day in the morning
  etc.
• It was impossible to control the frequency of displaying one or another target URL.
• It was difficult to put together statistics on the use of target URLs from several
  heterogeneous search engines.

You could just update the target URLs for a specific schedule, using the API
search engines, but it also could not solve the problem for several reasons:

• Many search engines (for example, Baidu or Yahoo) after changing URLs put
  changes in the pending state and spend considerable time (up to several
  days) to check them.
• On Google, this would result in additional costs for the Google Developer Token.
• Baidu does not allow URLs to be used if their domains are not listed in advance
  allowed domains Therefore, changing URL URLs is difficult.
• Google will reset Ad'am statistics if they change the URL, because internally
  for Google, this means creating a new Ad'a.
• Even in the absence of these problems, the problem of quick update still remains.
  a large number of objects - i.e. if we have millions of keywords, we don't
  we can instantly send changes to any search engine.
• In addition, communication via the Internet is not always reliable - there are communication breaks.
  between providers, the search engines API themselves are periodically buggy, etc.

Therefore, for the organization of such interaction, it was decided to organize its own
server through which visitors will be redirected to target URLs.
')

Decision.

Here’s what a visitor’s path from a search engine to a landing page looks like:

Those. the visitor gets to the intermediate server and then is redirected to the target
URL. For the visitor, this happens almost unnoticed.
The target URLs were combined into groups within which the rotation took place.
In turn, the group identifier was specified in the target URL for PPC objects.
Those. URLs of keywords and Ads on the search engine looked like the following:
my_redirect_server.ru/?rotation_group_id=123456
When a visitor hit an intermediate server, target URLs rotated
and the visitor is redirected to the selected URL. The rotation took into account the temporary
target URL settings, as well as other settings (display frequency, etc.).
Thanks to this solution, the problem was solved.

Underwater rocks.

It was very important to ensure the smooth operation of the intermediate server, because
that in the event of his fall there could be a situation in which visitors
would come from a search engine (i.e., spend money to pay for clicks), but not
would hit the target URL. Those. money would be wasted.

In addition, it was necessary to provide load balancing in the event of a sharp increase in
traffic from a large advertiser.

Therefore, instead of a single intermediate server, several physical
servers that balanced the load among themselves.

However, in addition to load balancing, these servers would have to share
information among themselves, in order to ensure uniform rotation. Besides
Moreover, if the group settings were changed, each of the servers would have to be notified that
it would not be convenient.
Therefore, to ensure the rotation mechanism, a separate service was allocated on a separate
server.

This service was responsible for deciding which destination URL should
be displayed case by case. In case of the Rotation service of the server
The redirect continued to work on the cached results until it was raised.

In general, it was generally impossible to prevent such a situation when the system could not
send a visitor to any URL.

Since the rotation was required to be performed as quickly as possible, the Rotation service worked
exclusively on cached data groups and the current state of rotation. When it changes
Rotation service settings were notified of the need to update the cache.
Thanks to this approach, a high speed selection of the target URL was provided.
Another problem in ensuring high speed of work is the preservation of reported
data that could not be performed in synchronous mode.
Therefore, a mechanism was implemented in which servers accumulated reporting data
in memory and at intervals of several minutes dumped them in the background on
server statistics collection.

Another problem was to ensure high speed work with geographic
remoteness of visitors and servers redirect.
When working with Baidu, most of the visitors were in China and they experienced
Difficulties in redirecting through servers located in Europe. This problem
was solved by installing an additional server in China.

Conclusion

The solution described above was commissioned several years ago and since
pore provides processing up to 100 million requests monthly, although the potential
solutions are much higher.