Не нужно «суперкубок». Каждый сервер читает куки своего домена. Серверы передают информацию друг другу через URL-адреса. (Или, реже, через обратные каналы.)
Например, скажите, что вы идете на example.com. У вас есть файл example.com, который читает user=1032354. Вы получаете http://www.example.com. Конечно, вы посылаете печенье на веб-сервер, который выводит следующее на веб-странице:
<IMG href="http://www.advertiser.exmaple/add.cgi?source=example.com&user=1032354">
Конечно, когда ваш браузер переходит на www.advertiser.example, чтобы получить изображение, оно счастливо посылает advertiser.example печенье. Теперь сервер на advertiser.example знает, какой пользователь вы на своем сайте (из файла cookie, который вы его отправили), и какого пользователя вы на example.com (с URL-адреса).
С помощью метода backchannel, он работает больше, как это:
1) Вы идете в www.example.com и отправить ему ваш example.com печенье.
2) Веб-сервер в example.com получает ваш идентификатор пользователя из файла cookie и отправляет запрос JSON на адрес advertiser.example, чтобы создать сеанс для вас. Он передает ему свой идентификатор пользователя example.com.
3) Веб-сервер выдает ссылку на изображение для advertiser.example с идентификатором сеанса, созданный на шаге 2.
4) Когда ваш браузер подключается к advertiser.example, он посылает advertiser.example печенья в заголовках и идентификатор сеанса в URL.
5) Сервер advertiser.example теперь может связывать ваш сеанс со своей собственной записью пользователя и вашей учетной записью пользователя по адресу example.com и может выводить соответствующее объявление.
Это также может быть сделано через источники.
Обновление: На основных сайтах не требуется печенье. Один куки-файл рекламодателя будет делать.
1) Вы идете на сайт, вы не отправляете cookie. Сайт назначает вам новый сеанс.
2) Веб-страница имеет ссылку встроенного изображения на сайт рекламодателя с сеансом, встроенным в URL-адрес.
3) Вы получаете внедренное изображение, отправляя идентификатор сеанса (в URL-адрес) и свой файл cookie (для сайта рекламодателя).
4) Теперь рекламодатель связывает ваш сеанс с основным аккаунтом в своей базе данных. Он связывает это с веб-сервером сайта через обратный канал, встроенный в URL-адрес или другими способами.
Не эти два сценария по-прежнему подразумевают отслеживание «в сети»? То есть, чтобы рекламодатель выше отслеживал, что данный пользователь перешел на example1.com и example2.com, рекламодатель должен будет публиковать объявления на примерах example.com и example2.com? Я хочу знать, есть ли у рекламодателей какие-либо трюки/инструменты для просмотра истории пользователя, даже если они только служили файлу cookie в example1.com. – depthfirstdesigner
На примерах сайтов не требуется cookie. Процесс может работать точно так же без cookie. Сначала сайт просто назначает вам случайный сеанс, получает идентификатор пользователя от рекламодателя через обратный канал, а затем связывает случайный сеанс с учетной записью пользователя на сайте рекламодателя. –
Возможно, я неправильно формулирую/уточняю свой вопрос. Возможно ли, чтобы рекламодатель опубликовал объявления на «example2.com», чтобы убедиться, что я посетил конкретный сайт «example1.com», если они никогда не показывали объявление с «example1.com»? – depthfirstdesigner