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

Web/сайты Прочее

Был(а) онлайн: 26.04.20 14:45
Umen 26 лет

1.0 Был(а) онлайн: 26.04.20 14:45

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

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

Базовые термины и технические моменты:
Есть сайты А, B и С. Страница сайта А содержит код <img src=”;. Впрочем файла 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 теснее отправляла и 2-й раз открывает в однопиксельном окошке теснее сайт C.
В случае с поиском пиксель системы будет выглядеть скажем так: www.systems_site.com/1.gif?q=search-term. Сверившись со своими базами система подберет группу сайтов на основе «search term» и так же как и в предыдущем примере начнет отдавать сайты из группы по очереди.
На первом этапе мы делаем только 1-й тип первичного посещения, но птом нужно будет доделать и 2-й.

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

Конструкция системы, основные компоненты:
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. Работа должна делаться поэтапно: а) уяснение изложения и составление по нему ТЗ, б) разработка интерфейсов управления и корректировака ТЗ по необходимости, в) собственно кодирование, г) тестирование и исправление ошибок, д) сдача плана. Предопала за 1-й этап весьма неугодна, но допустима если у вас есть примеры ветхих ТЗ. Остальная опата будет делаться по этапам. Если мы продолжаем трудиться позже предыдущего этапа, то преплата за дальнейший допустима.
2. Оплата допустима Вебманями, фетом либо переводом из заокеанского банка по вашему выбору. Всякая сторона платит комиссии своего банка сама.
3. Заказчик живет в США, так что имейте ввиду разницу во времени.
4. Мой имейл mauserd(doggy)yandex.ru. От вас я попрошу вашей идентификации до начала работ. Я дюже извиняюсь, но трудиться с анонимом я не буду.

Чтобы добавить заявку к этому заказу, нужно войти или зарегистрироваться

Мой блок

26.04.20 14:45
Umen 26