Как стать автором
Обновить

Комментарии 20

Интересная статья, спасибо!

Вопросы:
— поставщики данных как отдают такие потоки технически?
— по схеме непонятно (и не обозначено), где там Spark используется — как я понял, это PageIndexer и VisitorActionReceiver?
В догонку:
— на чем писали? scala?
— почему Solr, a не ElasticSearch какой-нить?
— Поставщики по-разному отдают: мы ставим коды (в этом случае в Kafka информация уходит с наших же серверов), присылают по протоколу zeromq, либо http протоколу. В общем маршрут до Kafka проходит в большинстве случаев еще через какие-нибудь сервисы.

— Spark — это VisitorActionReciever. Да не понятно, надо подправить.

— Spark на Java писали. Кстати, в статье есть кусок кода.

— Solr. Прямо скажем, из-за Cloudera. На уровне индекса Solr и ElasticSearch — это все Lucene. Возможно когда-нибудь попробуем ES для этой задачи, но если упремся в производительность Solr. На текущий момент все устраивает.
А не могли бы подробнее рассказать про интерфейс Solr-HBase? Там полностью автоматом данные переливаются в Solr этим Cloudera-вским коннектором или руками нужно писать?
Cloudera-Lily, автоматически реплицирует данные из HBase в Solr, необходимо лишь указать соответствие для типов и названий полей. Так же, при помощи этого сервиса можно делать запросы в Solr, а возвращать документы HBase. Руками писать не надо, но если очень хочется, то можно
… а на выходе получает аудиторию, состояющую из тех пользователей, которые посещали страницы с указанными ключевыми словами или искали эти слова в поиске....

1) А как ключевые слова извлекаются из текстов страниц? Словосочетаниями по одному слову, по два, по три и т.д.?
2) В поиске — в локальном поиске на сайте?
1. Текст вынимается целиком абзацами, фильтруется и сохраняется в Solr. Заботу по поиску он уже берет на себя. Solr поддерживает большое количество операторов поиска.
2. В поиске Google, Yandex, Mail. А как же шифровка referer? Не знаю, посмотрите в GA, увидите там небольшой процент нешифрованного трафика, 3-8%. В рамках тех объемов, что мы получаем количество поисковых запросов достаточно много. В статье мы намеренно опустили, как мы его обрабатываем, т.к. задача это простая, только текст усложнили бы.
Спасибо за статью! Возникло несколько вопросов:
1) Решаете ли вы как-нибудь проблемы, связанные с омонимией/синонимией ключевых слов?
2) В интернете есть страницы, содержание которых меняется со временем. По описанию функционала PageIndexer сложилось впечатление, что вы не обновляете ключевые слова страницы. Если это не так, сколько «живет» скачанная копия страницы или как вы определяете, что ее пора обновить?
3) Прошу короткий комментарий по поводу того, какие все-таки слова с веб-страницы считаются ключевыми? Есть ли какой-то статистический отбор токенов по их важности — ручной стоп-лист (если есть — насколько большой?) tf-idf или что-то еще?
1) Список синонимов можно задать в Solr. С омонимами никак не боремся.
2) Главные страницы, обкачиваются несколько раз в день, из-за частой смены контента. В остальном, наши исследования показали, что только 3% страниц меняют свой контент более чем на 20% в течении недели(не учитываем комментарии). По истечении недели, страница удаляется по TTL индексу, и если она всё ещё живая и с неё происходят показы, мы просто снова скачиваем её, как новую страницу.
3) Title, h1-h5, meta для всех страниц, если определяется что это статья или страница текстового содержания, то и его соответственно, если галереи то alt тег для картинок и т. д. То есть почти всё то есть на страницах, суть не столько в этих словах, сколько в весах, которые им задаются при составлении ключевого запроса (их мы раскрывать не будем).
Стоп-слова есть, опять же посредствам Solr, не очень большой список стандартные стоп слова русский + английский плюс 100-200 мусорных слов.
TF-IDF есть, но не в этой задаче, тут я что то и понять не могу, куда его прикрутить. Для увеличения веса страницы, пожалуй да, можно попробовать, но пока такое не внедрено.
Спасибо за ответ!
Я предполагал, что например tf-idf мог бы использоваться например при вычислении веса, формулу которого вы не хотите раскрывать )) В общем, вопросов больше нет
TF-IDF и прочие плюшки больше характерны для задачи классификации страниц. Здесь больше задача про пользователя.

Есть мысли попробовать следующее:
— Индексировать пользователей по LDA-топикам (то есть не все ключевые слова, а только те, что влияют на определение темы страницы)
— Сделать расширенный поиск. Рекламодатель вводит ключевые слова, а поиск осуществляется по тому, в какие топики входят эти слова.
А нет случайно задачи ранжировать пользователей? Например, когда нужны не все, которые читали про Ford Focus, а ТОП-100k по какому-то скорингу?
В первой версии нет такой задачи. Дальше будем пробовать, развивать, тестировать.
А как вы определаяете пользователей из разных источников? Это cookies или несколько «схем»?
С каждым поставщиком настроен cookie matching. Либо сразу наш пиксель на сайтах стоит
Не очень понятно как работает Segment Bulder.
Он собирает все интересы пользователя (т.е. теги), находит каких-то похожих по тегам пользователей, затем записывает в Aerospike id пользователя и список рекламных кампаний, которые ему надо показать, так чтобы, когда пользователь зайдет, AS отдал ему уже готовый список кампаний, которые надо показать этому пользователю?
Где можно подробнее про него почитать?
Да, вы всё верно написали, в aerospike хранятся записи вида {Visitor_id: [ audience_id ] }.
Так называемые «теги» это ключевые слова, которые искал или видел пользователь с определённой частотой, а аудитория создаётся не просто по подобию пользователей (так называемая кластеризация), а по заданным условиям. Эти условия задаются во время создания рекламной кампании.
Боюсь, что подробнее про Segment Bulder, кроме этой статьи, нигде не прочесть, я попробую ответить на ваши вопросы в комментариях
Спасибо. Очень интересно. Буду ждать статью.
Как понимаю, грубо это выглядит так: если пользователь искал велосипед, потом зашел на сайт про них, затем написал в велофоруме, то у него 3 срабатывания по тегу «велосипед», значит, он скорее всего заинтересован ими и его можно добавлять в соответствующую аудиторию.

А кластеризацию пробовали использовать?
Или она дает результат малопригодный для ваших целей? То есть кластеры-то выделит, но, что можно им продать не очень понятно? Пробовали анализировать результат?
Кластеризацию пробовали и даже используем, для уменьшения размерности вектора в предикте клика, для составления look-alike и прочих подобных задач. Но продать что то конкретное абстрактному кластеру, представляется мне малореализуемым.
Насколько хорошо повышает удается предсказывать? Какие алгоритмы используете?
У меня есть ощущение, что такие абстрактные кластеры будут состоят из пользователей, которым в целом тема интересна, но к покупке они еще не готовы — поэтому они смотрят очень широко и каждый интерес не является ярковыраженным на этом фоне. Возможно, это аудитория, которую можно «подогреть»?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий