Введение.
Как вы знаете, объекты поисковой системы PPC (обычно ключевые слова и объявления) имеют параметр, такой как URL-адрес назначения, который содержит ссылку на страницу, рекламируемую через платную рекламу.
Необходимо было организовать ротацию URL-адресов назначения таким образом, чтобы они менялись один за другим для большого количества PPC-объектов (миллионы ключевых слов) в различных поисковых системах (Google, Yahoo, MSN, Baidu, ASK и др.
).
На первый взгляд, эту проблему можно решить, создав несколько объявлений.
с необходимыми целевыми ссылками, но по факту этот подход имел следующее проблемы:
- Контролировать время работы URL было невозможно - т.е.
сделать это было невозможно чтобы какой-то URL работал только по выходным или только два часа в день утром и так далее.
- Невозможно было контролировать частоту показа конкретного целевого URL.
- Было сложно собрать статистику использования целевых URL-адресов из нескольких
гетерогенные поисковые системы.
- Многие поисковые системы (например, Baidu или Yahoo) после смены URL-адресов ставят
переходит в состояние «Ожидание» и тратит значительное время (до нескольких
дней), чтобы проверить их.
- В Google это приведет к дополнительным расходам на Google Developer Token.
- Baidu не разрешает URL-адреса, если их домены не указаны заранее.
разрешенные домены.
Поэтому изменить URL-адреса сложно.
- Google сбрасывает статистику по рекламе, если они меняют URL, потому что внутренне
для Google это означает создание нового объявления.
- Даже без этих проблем проблема быстрого обновления все равно остается.
большое количество объектов – т. е.
если у нас есть миллионы ключевых слов, мы не Мы можем мгновенно отправить изменения в любую поисковую систему.
- Кроме того, связь через Интернет не всегда надежна – бывают обрывы соединения.
между провайдерами, сами API поисковых систем периодически глючат и т.д.
Решение.
Вот как выглядит путь посетителя от поисковой системы до целевой страницы: 
Те.
посетитель попадает на промежуточный сервер, а затем перенаправляется на целевой сервер URL-адрес.
Для посетителя это происходит практически незаметно.
Целевые URL были объединены в группы, внутри которых осуществлялась ротация.
В свою очередь, идентификатор группы был указан в целевом URL для объектов PPC. Те.
URL-адреса ключевых слов и объявлений в поисковой системе выглядели примерно так: my_redirect_server.ru/Эrotation_group_id=123456 Когда посетитель попадал на промежуточный сервер, целевые URL-адреса менялись.
и посетитель был перенаправлен на выбранный URL. Ротация прошла с учетом временных настройки целевого URL», а также другие настройки (частота отображения и т. д.).
Благодаря этому решению проблема была решена.
Подводные скалы.
Очень важно было обеспечить бесперебойную работу промежуточного сервера, т.к.
что если он упадет, может возникнуть ситуация, при которой посетители придут из поисковой системы (т.е.
потратят деньги на оплату кликов), а не достигнет целевого URL. Те.
деньги будут потрачены зря.
Кроме того, необходимо было обеспечить балансировку нагрузки на случай резкого роста трафик от крупного рекламодателя.
Поэтому вместо одного промежуточного сервера использовалось несколько физических.
серверы, которые балансировали нагрузку между собой.
Однако помимо балансировки нагрузки этим серверам придется еще и обмениваться
информацию между собой с целью обеспечения равномерного вращения.
Кроме Кроме того, при изменении настроек группы каждый из серверов должен был бы быть уведомлен о том, что это было бы не удобно.
Поэтому для обеспечения механизма ротации на отдельном участке была выделена отдельная служба.
сервер.
Эта служба отвечала за принятие решения о том, какой целевой URL-адрес следует
отображаться в каждом конкретном случае.
В случае выхода из строя сервера службы ротации Перенаправление продолжало работать с кэшированными результатами, пока оно не было вызвано.
В общем, вообще нельзя было допустить ситуации, когда система не сможет отправить посетителя на какой-то URL. Так как ротацию нужно было сделать как можно быстрее, сработала услуга Ротация.
исключительно на кешированных данных групп и текущем состоянии ротации.
Когда это изменится Настройки службы ротации уведомили о необходимости обновления кэша.
Благодаря такому подходу была обеспечена высокая скорость выбора целевого URL. Еще одной проблемой при обеспечении высокой скорости работы является сохранение отчетности.
данные, которые не могли быть выполнены в синхронном режиме.
Поэтому был реализован механизм, при котором на серверах накапливались отчетные данные.
в памяти и с интервалом в несколько минут в фоновом режиме сбрасывались на сервер сбора статистики.
Еще одной проблемой было обеспечение высокой скорости работы с географическими
удаленность посетителей и серверы перенаправления.
При работе с Baidu большинство посетителей находились в Китае и испытали трудности при перенаправлении через серверы, расположенные в Европе.
Это проблема решилось установкой дополнительного сервера в Китае.
Заключение.
Описанное выше решение было введено в эксплуатацию несколько лет назад и с тех пор в настоящее время обеспечивает обработку до 100 миллионов запросов ежемесячно, хотя потенциал решения гораздо выше.
Теги: #ppc #плата за клик #Чулан
-
Фламанский
19 Oct, 24 -
Основы Управления Памятью Vsphere 4.1
19 Oct, 24 -
Как Оценить Преимущества Перехода В Облако
19 Oct, 24
