Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Расскажите подробнее про 1-й и 2-й пункт. Какие именно данные вы собираете? Как их обрабатываете? По каким признакам отличаете от ботов? У меня браузерные онлайн игры. И хотелось бы принять полезнй опыт.
Отписал в ЛС.
А вы комментарии по 1-ому и 2-ому пункту только в ЛС отправляете? Ответьте здесь, пожалуйста. Мне и, я уверен, еще многим хабра пользователям интересно их послушать.
Если кратко, то по очевидным причинам деталей алгоритмов мы раскрывать не будем.
В самых общих чертах мы собираем движения мыши, ряд событий JSa и маршрут пользователя в рамках сайта(если коды стоят не только на целевых страницах) и анализируем все это по определенным алгоритмам(Так как алгоритмы чисто наша разработка, то выкладывать их в паблик мы пока не намерены. К тому же они постоянно дополняются исходя из анализа текущего трафика. Только не путайте с нейронной сетью, у нас все алгоритмы пишутся людьми)
В отдельных случаях, если пользователю требуется аудит трафика на своем сайте для целей отличных от анализа рекламных переходов, мы можем предложить определенные формы сотрудничества и взаимодействия, но нагло предлагать их в комментариях, в ответ на вопрос о принципах детектирования ботов, как минимум не корректно, потому и отписываем в ЛС.
В самых общих чертах мы собираем движения мыши, ряд событий JSa и маршрут пользователя в рамках сайта(если коды стоят не только на целевых страницах) и анализируем все это по определенным алгоритмам(Так как алгоритмы чисто наша разработка, то выкладывать их в паблик мы пока не намерены. К тому же они постоянно дополняются исходя из анализа текущего трафика. Только не путайте с нейронной сетью, у нас все алгоритмы пишутся людьми)
В отдельных случаях, если пользователю требуется аудит трафика на своем сайте для целей отличных от анализа рекламных переходов, мы можем предложить определенные формы сотрудничества и взаимодействия, но нагло предлагать их в комментариях, в ответ на вопрос о принципах детектирования ботов, как минимум не корректно, потому и отписываем в ЛС.
Немного более детально, хотя все так же без детальных алгоритмов, но с математикой вы можете глянуть в этой презентации с 6го по 19й слайд.
А вы сами каким образом зарабатываете на этом? Что-то на сайте не нашел информацию о стоимости услуг.
clickfrog.ru/index.php?page=faq
Сколько это стоит?
В случае, если через сервис запускаются рекламные кампании Яндекс.Директ и/или Бегун, пользование сервисом бесплатное. Комиссию за привлечение клиентов выплачивают сервисы контекстной рекламы. Если Вы используете инструмент «Аудит трафика», стоимость составляет 0,03 руб. за анализ одного уникального хоста. Если Вы используете инструмент «Аудит Яндекс Директа» или «Аудит Google Adwords» стоимость составляет 0,05 руб. за анализ одного уникального хоста.
То есть мы получаем пачку кликов на сайт и среди них вычисляются уникальные хосты, за которые мы платим. А что значит уникальные? За какой период? Или блокируемый хост единожды вносится в базу и мы за него уже не платим?
Уникальные хосты идентифицируются по цифровому отпечатку. Выше уже писал: иденты пишутся в кучу разных стораджев, куки и.т.п., если хотя бы один из них не очистился или цифровой отпечаток даже с пустыми стораджами позволяет с уверенностью идентифицировать пользователя — повторно средства не списываются.
Если хост единожды вносится в базу в рамках конкретно домена, в рамках этого домена плата за него больше не списывается.
Также обращу внимание, что плата списывается не за заблокированные хосты а за все хосты, которые посетили страницы с нашим кодом.
Предполагая вопрос, как не платить за анализ органического трафика, отвечу: ставить наши коды только на целевые для контекстной рекламы страницы.
Если хост единожды вносится в базу в рамках конкретно домена, в рамках этого домена плата за него больше не списывается.
Также обращу внимание, что плата списывается не за заблокированные хосты а за все хосты, которые посетили страницы с нашим кодом.
Предполагая вопрос, как не платить за анализ органического трафика, отвечу: ставить наши коды только на целевые для контекстной рекламы страницы.
Интересный нюанс однако… То есть анализировать скликивание вы научились, а отделить органический трафик не получилось? Каким образом тогда вы вообще определяете само событие «скликивание»? Может человек, который пришел через органический трафик, определиться как скликиватель и попасть в базу?
Как вы это себе представляете, если в коммерческой тематике целевые страницы органического и контекстного трафика часто (если не всегда) совпадают?
ставить наши коды только на целевые для контекстной рекламы страницы.
Как вы это себе представляете, если в коммерческой тематике целевые страницы органического и контекстного трафика часто (если не всегда) совпадают?
Тут все довольно просто, часть ботов, например, не передают реферер, таким образом узнать пришли они из рекламы или органического трафика невозможно. разделение органического трафика от рекламного у нас реализовано как раз на уровне целевых страниц.
разделение представляю очень просто: добавляете UTM метку, либо любой другой GET параметр не влияющий на отображение контента на страницах, и направляете рекламный трафик на этот урл. органический трафик на него попасть просто не сможет.
разделение представляю очень просто: добавляете UTM метку, либо любой другой GET параметр не влияющий на отображение контента на страницах, и направляете рекламный трафик на этот урл. органический трафик на него попасть просто не сможет.
Понятно. Если UTM метка решает вопрос, то претензии снимаются. Правда об этом придется помнить тем, кто будет настройкой заниматься. По хорошему стоило бы по умолчанию анализ наличия UTM-метки сделать.
У нас есть нечто типа анализа UTM-меток, эту часть писал не я, потому детальнее отвечу завтра.
В случае использования автоматического аудита Яндекс.Директа, система сама смотрит возможность установки Openstat меток(аналог UTM меток) и, если их сайт поддерживает, автоматически включает их для объявлений.
В API Google Adwords автоматическая пометка тегами не вынесена. Поэтому в модуле аудита Google Adwords, в случае отключенной автопометки целевых страниц показывается инструкция по ее включению. До ее включения аудит осуществляться не будет. Аналогично с МаркетГидом.
В API Google Adwords автоматическая пометка тегами не вынесена. Поэтому в модуле аудита Google Adwords, в случае отключенной автопометки целевых страниц показывается инструкция по ее включению. До ее включения аудит осуществляться не будет. Аналогично с МаркетГидом.
aalebedev уже ответил за меня, за что ему спасибо.
От себя добавлю, что аудит МаркетГида также бесплатен.
От себя добавлю, что аудит МаркетГида также бесплатен.
Как успехи с установкой third-party cookies при использовании adblock'а?
Только что проверил opera 12 + adblock plus — кука поставилась.
В других браузерах гляну завтра.
В других браузерах гляну завтра.
Глянул в других браузерах — с AdBlock проблем не наблюдается.
Да вобщем-то и не должно. Мы же не показываем рекламу, мы анализуем трафик из рекламных сетей на сайте покупателя этого трафика. Т.е. к рекламных сетям мы отношения не имеем, кроме разве что взаимодействия с ними по API для бана IP и площадок.
Да вобщем-то и не должно. Мы же не показываем рекламу, мы анализуем трафик из рекламных сетей на сайте покупателя этого трафика. Т.е. к рекламных сетям мы отношения не имеем, кроме разве что взаимодействия с ними по API для бана IP и площадок.
А каким образом пользователь с adblock вообще будет посчитан перешедшим? С какой стати он перейдёт?
Что-то совсем не понимаю, какой отношение имеет AdBlock к анализу трафика на сайте.
Выше уже писал, что мы его не детектим, так как не видим в этом смысла.
Аналитикс и Метрику он же не блокирует, почему нас должен?
Если вы намекаете, на функцию «Отключить слежение» в AdBlock, то она не мешает работе нашей системе на клиентских сайтах.
Выше уже писал, что мы его не детектим, так как не видим в этом смысла.
Аналитикс и Метрику он же не блокирует, почему нас должен?
Если вы намекаете, на функцию «Отключить слежение» в AdBlock, то она не мешает работе нашей системе на клиентских сайтах.
А Директ прислушивается к таким отчетам? Он отменяет трафик по определенному запросу?
Насколько я помню, в Бегуне при плотной интеграции получали подобные отчеты о трафике, но практически не принимали его в расчет. В большинстве случаев просто плевали на него, хотя по схожей технологии мы могли фильтровали весь трафик и даже больше, который они сами в итоге отменяли.
Насколько я помню, в Бегуне при плотной интеграции получали подобные отчеты о трафике, но практически не принимали его в расчет. В большинстве случаев просто плевали на него, хотя по схожей технологии мы могли фильтровали весь трафик и даже больше, который они сами в итоге отменяли.
Расскажите немного о вашем хранилище данных, пожалуйста. Насколько я понимаю, чтобы говорить об уникальности «посетителя» нужно где-то хранить о нем данные. Вы что-то храните на своей стороне или же сам посетитель приходит к вам и как бы говорит «я тут уже был, вот мой слепок, он это подтверждает»?
В случае если пользователь на сайте первый раз — JS делает запрос к серверу «выдай ID», после чего ИД пишется во все возможные места и в дальнейшем на сервер отправляются данные уже с привязкой к ИД.
Хранилище у нас Mysql база, на сервере с быстрыми дисками(тот что сервер сбора и обработки данных). Настраивал ее не я, потому тонкости настройки не расскажу, разве что могу конфиг скинуть, если интересно.
А вот про структуру — расскажу. Таблицы, в зависимости от характера операций работают на MyIsam(если производится практически исключительно чтение) и InnoDB(в случае если таблица в таблицу ведется интенсивная запись).
После того как запросы приходят на nginx+php-fpm, затем они отправляются в очередь на запись в базу отдельными воркерами.
Количество воркеров динамически регулируется в зависимости от длины очереди.
В качестве очередей используется Unix queue, так как все другие решения при тестировании очень сильно проигрывали ему в производительности, а отдельные так вообще не справлялись с потоками данных.
Воркеры забирают пачку данных из очереди и пишут эту пачку один запросом в первичную таблицу БД, где хранятся данные за все время, а так же в сокращенном виде в таблицы аудита трафика, в зависимости от типа аудита(Эдвордс, Директ, Бегун, просто аудит трафика). В данный момент в таблице несколько десятков миллионов записей. Пока БД справляется, но мы сейчас работаем над тем, что бы старые данные из нее сливать в отдельную таблицу, а в текущей хранить только последние.
Далее по крону запускается скрипт обработки данных который дергает необработанные данные из таблиц аудита, забирает более детальную информацию о певедении пользователя из первичной таблицы, производит их анализ пересчитывает рейтинги уникальных пользователей и площадок.
Собственно основная нагрузка у нас это запись в базу огромного количества данных. Тут нас спасает быстрая дисковая подсистема на SAS дисках(SSD не вариант, так как он бы довольно быстро умер под интенсивной записью), и корректно настроеный Mysql(настраивал не я, да и это немного не моя специализация, потому для меня это немного магия).
Также не малую часть нагрузки дают выборки для анализа данных. Тут важны корректно составленные индексы, запросы ну и MyIsam в таблицах с низкой интенсивностью записи. Настройка Mysql само-собой также играет свою роль.
Хранилище у нас Mysql база, на сервере с быстрыми дисками(тот что сервер сбора и обработки данных). Настраивал ее не я, потому тонкости настройки не расскажу, разве что могу конфиг скинуть, если интересно.
А вот про структуру — расскажу. Таблицы, в зависимости от характера операций работают на MyIsam(если производится практически исключительно чтение) и InnoDB(в случае если таблица в таблицу ведется интенсивная запись).
После того как запросы приходят на nginx+php-fpm, затем они отправляются в очередь на запись в базу отдельными воркерами.
Количество воркеров динамически регулируется в зависимости от длины очереди.
В качестве очередей используется Unix queue, так как все другие решения при тестировании очень сильно проигрывали ему в производительности, а отдельные так вообще не справлялись с потоками данных.
Воркеры забирают пачку данных из очереди и пишут эту пачку один запросом в первичную таблицу БД, где хранятся данные за все время, а так же в сокращенном виде в таблицы аудита трафика, в зависимости от типа аудита(Эдвордс, Директ, Бегун, просто аудит трафика). В данный момент в таблице несколько десятков миллионов записей. Пока БД справляется, но мы сейчас работаем над тем, что бы старые данные из нее сливать в отдельную таблицу, а в текущей хранить только последние.
Далее по крону запускается скрипт обработки данных который дергает необработанные данные из таблиц аудита, забирает более детальную информацию о певедении пользователя из первичной таблицы, производит их анализ пересчитывает рейтинги уникальных пользователей и площадок.
Собственно основная нагрузка у нас это запись в базу огромного количества данных. Тут нас спасает быстрая дисковая подсистема на SAS дисках(SSD не вариант, так как он бы довольно быстро умер под интенсивной записью), и корректно настроеный Mysql(настраивал не я, да и это немного не моя специализация, потому для меня это немного магия).
Также не малую часть нагрузки дают выборки для анализа данных. Тут важны корректно составленные индексы, запросы ну и MyIsam в таблицах с низкой интенсивностью записи. Настройка Mysql само-собой также играет свою роль.
Для получения наиболее полных данных мы используем 2 скрипта: серверный(PHP/Python/ASP.NET) и клиентский JS.
…
Следовательно, мы получаем существенно больше данных чем те же Метрика, Analytics и все прочие системы статистики с JS счетчиками.
А почему бы тому же ga.js не быть динамическим скриптом, отслеживающим пользователей на стороне сервера? Просто интересно, каким образом подтвердили это утверждение.
Потому что javascript выполняется на стороне клиента, и если страница закрывается раньше чем Javascript был подгружен, до Google Analytics данных доходит ровно 0.
Для того что бы отслеживать на стороне сервера скрипт требуется так же ставить на стороне сервера, это очевидно.
Для того что бы отслеживать на стороне сервера скрипт требуется так же ставить на стороне сервера, это очевидно.
Действительно, забыл, что ga.js вставляется на страницу с использованием JS. Хотя его можно вставить сразу тегом script, чтобы браузер начал загружать его ещё до конца загрузки страницы, а на случай отключенного JS можно попробовать использовать метод для мобильных устройств.
Тегом скрипт, по сути те же яйца, только в профиль. Если пользователи не дожидаются загрузки страницы то они обычно закрывают ее еще до начала загрузки любых JS скриптов, т.е. фактически get запрос на сервер уходит и едва-едва начинается подгрузка html, а порой и она не начинается.
Метод для мобильных устройств действительно будет получать необходимые данные. Однако не совсем понятно можно ли его использовать одновременно с JS скриптом. Если нет, то server-side получает гораздо меньше данных чем client-side. Гибридная технолия из JS+серверного скрипта одно из наших конкурентных преимуществ.
Также заметил что, метод для мобильных устройств находится в Legacy Libraries и предназначен вообще для трекинга WAP-сайтов. Т.е. непонятно как долго он будет поддерживаться и насколько корректно работать на web-сайтах в связке с JS скриптом. Например, допускаю, что при наличии 2х скриптов один посетитель банально будет считаться 2 раза.
Метод для мобильных устройств действительно будет получать необходимые данные. Однако не совсем понятно можно ли его использовать одновременно с JS скриптом. Если нет, то server-side получает гораздо меньше данных чем client-side. Гибридная технолия из JS+серверного скрипта одно из наших конкурентных преимуществ.
Также заметил что, метод для мобильных устройств находится в Legacy Libraries и предназначен вообще для трекинга WAP-сайтов. Т.е. непонятно как долго он будет поддерживаться и насколько корректно работать на web-сайтах в связке с JS скриптом. Например, допускаю, что при наличии 2х скриптов один посетитель банально будет считаться 2 раза.
После недолгих раздумий и ряда экспериментов мы начали писать не только в cookies, а также в хранилища всех возможных плагинов для браузеров, у которых такие хранилища имеются, ну и прочее по мелочам, third-party cookies, различные JS storage.
Вы знаете, нисколько не принижая задумку и цель данной системы, за такую реализацию хочется отбить руки! Я конечно, не знаток контекстной рекламы и способов обмана и борьбы, но проводя аналогию, если бы десктоп по писало во все доступные ветки реестра свои ключи со сроком истечения триала, это бы вызывало у меня лютую ненависть, не говоря уже о других программных продуктах, которые могут из-за лишнего/некорретного ключа отказаться работать или работать не правильно.
А можно ли вашу систему прикрутить для защиты трафика на кастомной баннерке? То есть не гуглы/яндексы, а вот собственная/сторонняя баннерокрутилка, но пропускать всё через вас.
Сторонние баннерки могут работать в полуавтоматическом режиме. Т.е. система сообщает вам какие IP и площадки необходимо добавить в блеклист и вы сами их добавляете. У нас так же есть API и, при желании, вы можете автоматизировать бан для любой сторонней системы.
Если вы представляете непосредственно баннерную сеть — свяжитесь с нами по контактам на сайте. Будем рады сотрудничеству. Мы сейчас интенсивно занимаемся интеграцией с различными баннерными сетями.
Если вы представляете непосредственно баннерную сеть — свяжитесь с нами по контактам на сайте. Будем рады сотрудничеству. Мы сейчас интенсивно занимаемся интеграцией с различными баннерными сетями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы писали систему защиты от скликивания