Система управления раздачей куков

Управление пикселями

Назначение:

Помечание серферов куками различных сайтов за один визит для удобства дальнейшего тракинга их поведения. На пальцах: у нас имеется группа однотипных сайтов. Серфер посетил один из них. Покинул сайт и посетил другой сайт из группы через три дня. Мы хотим иметь возможность его опознать, то есть еще во время первого визиа нашпиговать браузер серфера куками со всех сайтов группы.

Базовые термины и технические моменты:

Есть сайты А, B и С. Страница сайта А содержит код . Однако файла pixel.gif на сайте B не существует и он отдает вместо него 30Х редирект на http://siteС.com/another_pixel.gif предварительно посадив серферу свои куки. В таком случае сайт C тоже получает возможность посадить уже и свои куки и, в зависимости от нашего настроения, отдать дальше цепочку редиректов или честно отдать наконец картинку. Таким образом мы получаем возможность затолкать кастомеру так много куков, как получится.

Вместо пикселя можно использовать и ява-скрипт, однако в некоторых случаях, если часть сайтов группы принадлежит постороннему человеку, то он может опеасаться поставить чужой скрипт. А поставить картинку не страшно, так как из тага img не выберешься.

Хотелось бы получить детали когда такое не сработает, так как насколько я знаю некоторые фаерволы и настройки безопасности рубят принятие куков от сайта чей урл не указан прямо в адресной строке браузера

Два вида первичных посещений:

1. когда серфер посещает один из сайтов группы и 2. когда серфер посещает поисковый сайт. В первом случае каждый сайт заранее приписан к той или иной группе сайтов и заражение куками будет идти куками сайтов из той же группы. Во втором случае пиксель должен быть с параметром – поисковым термином, на основании которого и подбирается группа сайтов.

На пальцах: есть группа ювелирных сайтов: A, B и C. Они получают пиксели www.systems_site.com/1.gif, 2.gif и 3.gif соответственно. Система помнит что существует группа «Ювелирные» в которую 1, 2 и 3 входят. Соответственно при первом посещении сайта А www.systems_site.com/1.gif втыкает серферу свои системные куки и делает редирект на siteB.com который появляется незаметно в однопиксельном окошке. При втором клике серфера на сайте А система видит свои куки, опознает что она этого кастомера на сайт B уже отправляла и второй раз открывает в однопиксельном окошке уже сайт C.

В случае с поиском пиксель системы будет выглядеть например так: www.systems_site.com/1.gif?q=search-term. Сверившись со своими базами система подберет группу сайтов на основе «search term» и так же как и в предыдущем примере начнет отдавать сайты из группы по очереди.

На первом этапе мы делаем только первый тип первичного посещения, но птом надо будет доделать и второй.

Профайлы куко-рассадников ака пользователей.

Планируется эксплуатировать систему совместно, деля пользу более менее справедливо. Соответственно надо иметь один каталог категорий, но наполнение категорий будет свое для каждого профайла. На паьцах: существует категория «Ювелирные» Пользователь Вася имеет сайты А и Б. Пользователь Коля имеет сайты В и Г. Серфер посещает сайт А принадлежащий Васе. Серфер определяется как «Ювелирный» так как сайт А из этой группы, однако по постороннему алгоритму (о нем дальше) серферу отдаются редиректы на Колины сайты В и Г. В целом назначение у этой опции очевидное: хозяин системы планирует брать плату с пользователей в виде процента кукопомечаемого трафика.

Очень важно не допускать пересечения групп. Если серфер был помечен как Ювелирный-Васин, то ему нельзя отдавать Ювелирные Колины сайты никогда. Сли по каким-то причинам это сложно или невозможно, то не ранее конца жизни куки (ниже про срок жизни куков)

Структура системы, основные компоненты:

1. Каталог категорий. Обычный каталог в несколько уровней, его структура управляется администратором системы. В каталоге фигурируют сайты. Каждый пользователь видит свои, администратор видит все.

2. Каталог линков. Его структура – копия предыдущего каталога, но в нем фигурируют не сайты, а полные УРЛы с сайтов куда надо редиректить этот наш пиксель. У каждого линка должно стоять время жизни. То есть как долго такая кука будет считаться живой.

3. Панель администратора. Администратор указывает какой процент просетителей сайтов пользователей будет получать его линки для редиректов и прочее полезное. Надо иметь уровень по умолчанию для всех и возможность указать свой уровень для конкретного пльзователя (все его сайтов) или для конкретного сайта. Скажем общий отъем стоит 10%, пользователю Васе льгота в 5%, однако на конкретный васин сайт А стоит 25%. Тогда с А будет отбираться 25%, с другого васиного сайта будет отбираться 5%, а со случайного пользователя коли – 10%. Администратор одновременно является и пользователем, то есть у него есть изначально полностью свои сайты.

4. Нужна какая-то статистика для просмотра результатов работы.

5. Часть про соответствие сайтов поисковым терминам пока пропускаем, потом делать будем.

Механизм раздачи линков:

В каталоге есть категория Ювелирные, подкатегория Бижютерия. Соответственно посетителю сайта А из этой подкатегории сперва отдаются остальные сайты по Бижютерии. Когда они заканчиваются, то начинаем отдавать сайты Ювелирные. Когда закончатся и они начинаем отдавать случайно из других мест (впоследствии, по мере наполнения статистики, мы узнаем что если человек ходил в категорию А, то потом нередко наведывался в Б. Тогда будем не случайно отдавать).

Общие слова и технические требования.

1. В принципе уже сейчас есть ресурсы на пол-миллиона кликов в день, так что система раздачи куков и учета чего кому отдали будет работать под большой нагрузкой. Возможно имеет смысл пойти на какие-то жертвы и допустить вероятность ошибок в пользу гарантированного быстродействия.

2. Надо писать ВСЕ. То есть свосем все. Единожды получивший куки серфер должен ходить помеченым и записываться до тех пор, пока он сепбе куки не потрет. Его повторные визиты, какие именно сайты и когда.

3. Возможна, в перспективе, пробема с перегрузкой на ДНС. То есть система долджна уметь жить с несколькими своими доменами что бы ее пиксели можно было запрашивать по www.systems_site_1.com/1.gif или по www.systems_site_2.com/2.gif

4. Интерфейс должен быть выполнен на английском языке.

Оплата, порядок работ и детали.

1. Работа должна делаться поэтапно: а) уяснение описания и составление по нему ТЗ, б) разработка интерфейсов управления и корректировака ТЗ по необходимости, в) собственно кодирование, г) тестирование и исправление ошибок, д) сдача проекта. Предопала за первый этап крайне нежелательна, но возможна если у вас есть примеры старых ТЗ. Остальная опата будет делаться по этапам. Если мы продолжаем работать после предыдущего этапа, то преплата за следующий возможна.

2. Оплата возможна Вебманями, фетом или переводом из американского банка по вашему выбору. Каждая сторона платит комиссии своего банка сама.

3. Заказчик живет в США, так что имейте ввиду разницу во времени.

4. Мой имейл mauserd(doggy)yandex.ru. От вас я попрошу вашей идентификации до начала работ. Я очень извиняюсь, но работать с анонимом я не буду.