Введение.
Как известно, объекты PPC-поисковых систем (как правило, это keywords и ads) имеют
такой параметр, как Destination URL (целевой URL), который содержит в себе ссылку
на страницу, рекламируемую посредством платной рекламы.
Было необходимо организовать ротацию Destination URL таким образом, чтобы они последовательно
менялись друг за другом для большого количества PPC-объектов (миллионы ключевых
слов) на различных поисковых системах (Google, Yahoo, MSN, Baidu, ASK и др.).
На первый взгляд эту задачу можно было решить посредством создания нескольких Ad'ов
с необходимыми целевыми ссылками, но на самом деле такой подход обладал следующими
проблемами:
- Невозможно было управлять временем работы URL'а – т.е. нельзя было сделать так,
чтобы какой-то URL работал только по выходным, или только два часа в день по утрам
и т.п. - Невозможно было управлять частотой отображения того или иного целевого URL'а.
- Было сложно собрать воедино статистику по использованию целевых URL'ов с нескольких
разнородных поисковых систем.
Можно было просто обновлять целевые URL'ы по определенному графику, использую API
поисковых систем, но это также не могло решить проблему по нескольким причинам:
- Многие поисковые системы (например Baidu или Yahoo) после изменения URL'ов ставят
изменения в состояние ожидания (Pending) и тратят значительное время (до нескольких
суток) на их проверку. - На Google это приводило бы к дополнительным расходам на Google Developer Token.
- Baidu не позволяет применять URL'ы, если их домены не находятся в списке заранее
разрешенных доменов. Поэтому смена урлов URL'ов затруднена. - Google обнуляет статистику по Ad’ам, если у них изменить URL, потому что внутренне
для Google это означает создание нового Ad’а. - Даже при отсутствии этих проблем все равно остается проблема быстрого обновления
большого количества объектов – т.е. если мы имеем миллионы ключевых слов, мы не
сможем мгновенно отправить изменения на любую поисковую систему. - Кроме того, связь через интернет не всегда является надежной – бывают обрывы связи
между провайдерами, сами API поисковым систем периодически глючат и т.п
Поэтому, для организации подобного взаимодействия было решено организовать собственный
сервер, через который будет происходить редирект посетителей на целевые URL'ы.
Решение.
Вот как выглядит путь посетителя от поисковой системы до целевой страницы:
Т.е. посетитель попадает на промежуточный сервер, а затем перенаправляется на целевой
URL. Для посетителя это происходит практически незаметно.
Целевые URL’ы были объединены в группы, в пределах которых осуществлялась ротация.
В свою очередь идентификатор группы был указан в целевом URL’е для PPC-объектов.
Т.е. URL’ы ключевых слов и Ad'ов на поисковой системе имели примерно следующий вид:
my_redirect_server.ru/?rotation_group_id=123456
При попадании посетителя на промежуточный сервер происходила ротация целевых URL’ов
и посетитель перенаправлялся на выбранный URL. Ротация происходила с учетом временных
настроек целевых URL’, а также других настроек (частота отображения и т.п.).
Благодаря такому решению задача была решена.
Подводные камни.
Очень важно было обеспечить бесперебойную работу промежуточного сервера, потому
что в случае его падения могла возникнуть такая ситуация, при которой посетители
приходили бы с поисковой системы (т.е. тратили бы деньги на оплату кликов), но не
попадали бы на целевой URL. Т.е. деньги тратились бы впустую.
Кроме того, необходимо было обеспечить балансировку нагрузки на случай резкого роста
трафика от крупного рекламодателя.
Поэтому, вместо одного промежуточного сервера было использовано несколько физических
серверов, которые балансировали нагрузку между собой.
Однако, кроме балансировки нагрузки эти сервера должны были бы еще обмениваться
информацией между собой, для того, чтобы обеспечить равномерность ротации. Кроме
того, при изменении настроек групп пришлось бы уведомлять каждый из серверов, что
было бы не удобно.
Поэтому для обеспечения механизма ротации был выделен отдельный сервис на отдельном
сервере.
Этот сервис был ответственен за принятие решения о том, какой целевой URL должен
быть отображен в каждом конкретном случае. В случае падения Rotation service сервера
редиректа продолжали работать на закешированных результатах до момента его поднятия.
В общем случае, вообще нельзя было допустить такой ситуации, когда система не сможет
отправить посетителя на какой-либо URL.
Поскольку ротацию требовалось выполнять максимально быстро, Rotation service работал
исключительно на закешированных данных групп и текущего состояния ротации. При изменении
настроек Rotation service уведомлялся о необходимости обновить кеш.
Благодаря такому подходу обеспечивалась высокая скорость выбора целевого URL’а.
Еще одна проблема при обеспечении высокой скорости работы – это сохранение отчетных
данных, которое нельзя было выполнять в синхронном режиме.
Поэтому был реализован механизм, при котором сервера накапливали отчетные данные
в памяти и с периодичностью в несколько минут сбрасывали их в фоновом режиме на
сервер сбора статистики.
Еще одной проблемой стало обеспечение высокой скорости работы при географической
удаленности посетителей и серверов редиректа.
При работе с Baidu основная часть посетителей находилась в Китае и они испытывали
трудности при редиректе через сервера, которые располагались в Европе. Эта проблема
была решена установкой дополнительного сервера в Китае.
Заключение.
Описанное выше решение было запущено в эксплуатацию несколько лет назад и с тех
пор обеспечивает обработку до 100 миллионов запросов ежемесячно, хотя потенциал
решения значительно выше.
Комментариев нет:
Отправить комментарий