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

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

НЛО прилетело и опубликовало эту надпись здесь
На 17 минуте прыгает!
Вот это кот — целый час мышь выжидал, но молодец — поймал таки! Не зря час на кота смотрел, подозревал, что не просто так он сидит.
Есть ли у вас открытый API для работы с вашими данными?
Публичного API нет и вроде не планируеются, а в этом может быть потребность? Кажется, что наши данные могут быть интересны только конкурентам =)
На морде okmetric из-за вот этого бага code.google.com/p/chromium/issues/detail?id=336403 в хроме бывает что вкладка падает совсем (со словами «Oh snap!» так что даже js`ом не поймаешь в чем проблема)
Поэтому с морды интерактивные графики для 32 хрома убрали.

Но если вам не трудно зайти на okmetric.com/ohsnap.html и посмотреть будет падать или нет.
И если падает — написать версию хрома («window.navigator.appVersion» в js консоли).
Кстати да, выкладывали бы датасеты по типам спорта и командам, было бы неплохо.
Мы уже третий год думаем о публичном API со спортивной статистикой и всякими индексами популярности, но пока что руки так и не дошли.
Какого рода данные вы готовы отдавать бесплатно через API? Я, кстати, пытался найти результаты футбольных матчей + таблицы чемпионатов в свободном доступе, через API. Бесплатных не смог найти (

Бесплатных и нет: сырые данные мы сами покупаем у провайдеров статистики. Но мы часто делимся агрегированной статистикой с партнерами на условиях: «Трафик в обмен на продовольствие».
Эмм… 500 ГБ — это Big Data?
Прикинь, какие наглецы! Без петабайтов, Map Reduce и Hadoop называют свою поделку Big Data!


Конечно у вас big data, не вздумайте даже сомневаться.
Круть!
Если картинками, то нет, а вот если текстами…
По поводу email-рассылок, поймал себя на мысли, что вы очень точно сформировали подборку, что я, таки, заходил на сайт.

Только вот что меня сильно отталкивает от действий на «Спортсах», так это странная система отображения комментариев.
Комментарии идут друг за другом, т.е. проследить дискуссию между пользователями — не реально! Постоянно нужно нажимать кнопку «Ответ на комментарий пользователя… ». Не комфортно читать — нет желания комментировать!

Не пробовали вы другой вариан отображения комментариев? Планируете? Теперь у вас есть отличный инструмент для АБ-тестирования))
Почитал бы про это на Хабре! )
Зато лучше, чем у ч.ру, где плагин комментариев грузится раз на 50 после обновления страницы с новостью.
Ну так это проблема я.ру (если я вас правильно понял), а не подобного типа комментариев!
На Хабре, вот, отлично все грузится.
Да, это их проблема с их сторонним сервисом fanat.ru. Лучше бы они всё оставили как было раньше…
Если честно, то не знаю как было раньше.
Я имел ввиду, что нет разницы, какого вида комментарии, древовидные или в 1 колонку. Грузиться он должны одинаково быстро. Все остальные вопросы к разработчикам =)
Думаем про ветки с комментами для отдельных типов страниц, но опять же — не доходят руки =( Ну и эмоцианальное обсуждение спорта все-таки отличается от вдумчивых, ветвистых дискуссий на хабре. Так, например, выглядит топ комментариев для типичной новости:
image
Согласен, бывают разные типы материалов, например — обсуждение прошедшего матча или аналитика перед туром!
В первом посте будет больше коротких комментариев, во втором длинных комментариев с рассуждениями.

Но при любом варианте есть место дискуссии. Спорт это эммоции в чистом виде… Радость, злость, ирония или просто троллинг. Иногда удачный десятый ответ на комментарий собирает все плюсы и срывает овации. А сейчас вы прячете всю эту прелесть однородным столбом комментариев, где очень легко упустить все нюансы диалога.

Пример
Не стоит забывать просто, что у веток коментов кроме плюсов есть масса минусов:
– они очень плохо себя чувствуют в мобайле (где уже почти половина аудитории) и в узких колонках – как у нас в новостях
– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru
– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru – тут выпало «очень востребована»
– они очень плохо себя чувствуют в мобайле (где уже почти половина аудитории) и в узких колонках – как у нас в новостях

— Хабр не плохой пример отображения комментариев в мобайле. Это если смотреть через браузер. Если использовать приложение (у «Спортсов» оно есть), то та же история. Проблем нет в отображении.

– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru

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

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

Я высказал свое мнение, почему я не оставляю комментариев на «Спортсах». Мне изначально не понравились комментарии на сайте, и поэтому, я читаю только статьи и редко комментарии. Т.к. в моей подписке, в основном, не самые популярные тематические блоги, то комментариев там не много. Я их быстро пролистываю и ухожу.

Но если мне попадается статья с большим количеством комментариев, то я на автомате ищу глазами самые «отличившиеся». ИМХО не правильный подход.
Ну как – «неправильный подход»? Когда под материалом или новостью 500-1000 комментариев (что на Sports.ru не редкость), прочесть самые рейтинговые – это как раз вполне логичный юзкейс, и, кстати, самый часто используемый.

Но о вкусах действительно не спорят – повторюсь, у веток комментариев свои несомненные тоже есть, и мы прекрасно понимаем, что кому-то они ближе. Я только пояснил, почему из двух вариантов выбран один, а не другой (совместить их не получится).

Ну и с «проблем нет в отображении веток в мобайле» я не совсем согласен. К сожалению, есть.
Наверное, у «Спортсов» были причины на то, чтобы сделать именно такие комментарии. И раз у них такое кол-во аудитории, значит правы они, а не я. =)

Но я, к сожалению, бываю там проходом.

Ну и с «проблем нет в отображении веток в мобайле» я не совсем согласен. К сожалению, есть.

Ну так давайте обсудим их! У нас есть для этого «ветки» комментариев =) С какими проблемами вы столкнулись?

P.S. Сделал 2 скриншота из мобайла. Приложение для Реддит, Хабр через браузер
Говорю же, это не тот случай, когда прав кто-то один. Есть два сопоставимых по популярности – но разных способа организовывать комментарии. Нельзя применить оба сразу, я лишь постарался пояснить наш выбор из этих двух ))

Кстати, все современные соцсети почему-то сделали такой же.

Также, наверное, и с вашими скриншотами – вам кажется, что проблемы в отъедании полезной площади (и без того небольшой у смартфона) «ветками» нету. Хотя она будет только нарастать с каждым новым ответом. Я не уверен, что готов с этим согласиться – но не настаиваю, чтобы вы меняли свою точку зрения.
Говорю же, это не тот случай, когда прав кто-то один. Есть два сопоставимых по популярности – но разных способа организовывать комментарии. Нельзя применить оба сразу, я лишь постарался пояснить наш выбор из этих двух ))

Я вас понял. Ваш подход, видимо, отлично работает.

P.S.
Эпично вы вчера нас раскатали. Полурезервом. С победой =)
Я лого в вашем аватаре сразу заметил, но не нашел возможным использовать вчерашний матч как аргумент в дискуссии ))
Ну, если что, у меня тоже есть аргумент недельной давности! ;)
Опять ничья!
Ну, прямо скажем, не «раскатали» ;)
«Раскатали» — это мы за неделю до этого на «Энфилде» ;)
Лично мне не хватает возможности выбора главных статей по рейтингу (так же и по дате: хотелось бы удобно читать старые материалы сайта). Например, я провожу 90% времени в разделе sports.ru/football, но мне интересно также почитать качественные, одобренные пользователями материалы из других разделов сайта, а туда я редко лажу.
Спасибо за sports.ru!
Мы считаем, что такими страницами являются главная сайта (редакционный отбор) www.sports.ru/ и главная трибуны (пользовательский отбор) www.sports.ru/tribuna/
И в то же время вяло ведете твиттер с моими желанными лучшими текстами: twitter.com/sportsrubest :)
Исправимся, спасибо за напоминание
У вас там на картинке, где пользователю предлагается вступить в группу/сообщество «Двигатель торговли», она два раза упомянута, сначала как та группа, где друзья пользователя сидят, а потом как та, которую он лайкал. Логичнее было бы это объединить и подавать в одном блоке.
В данном случае, это не скриншот реальной рекомендации, а макет прототипа. Ну и мы заметили, что когда рекомендуешь человеку что-то и поясняешь, почему это что-то попало в рекомендации, конверсия оказывается в разы выше. И чем проще это объяснение, тем оно работает лучше.
Простота простотой, но на мой скромный взгляд пользователя предложение два раза одного и того же скорее всего будет все-таки неуместно выглядеть, да и нет никакой сложности в двух текстовых блоках и одной картинке к ним с заголовком о чем все это.
Сначала все валите в один access.log, а потом разбираете по сессиям? Экие вы затейники.

access_log /mnt/tmpfs/$arg_sessionpid analytics;

вот такая одна строчка в ngxin.conf раскладывает сразу все сессии по файлам. Когда файл N минут не обновляется — уходит в обработку. Десятки тысяч файлов на рамдиске и те же миллионы хитов — нагрузки практически ноль. Ну и главное — дальнейшая обработка ну совсем простая.
Интересное решение, спасибо.
Мы храним не только сессии, но и кликстрим тоже, так что в любом случае все записи нужно отправлять в Redshift. Статистику по сессиям (длина, число страниц, источник и т.д.) считаем уже в нем, так что нет необходимости разбивать лог на отдельные файлы по сессиям.
Для нас важно иметь возможность иметь агрегированные данные не только по сессиям (как в Google Analytics или Метрике), но и по дням-неделям (например, число просмотров пользователя за день), поэтому при парсинге логов статистика не считается — все происходит уже в Redshift.
Я сейчас глянул первый попавшийся бэкенд одного проекта (чуть больше, чем сабж) и понял, что следуя вашим советам, я бы уперся в лимит инодов где-нибудь так дня через 3 (тоже на tmpfs), если не разгребать эти файлы. :)
Если 3 дня не разгребать, то да — понт защитан :)
А так среднее время жизни сессии редко больше 10 минут.
Я это написал, чтобы имели в виду те, кто вдруг захочет сделать как вы предложили. :) А то многие склонны применять советы не подумав (иногда и за собой этот недостаток замечаю).

Кстати, есть еще один минус такого подхода: ротация таких логов будет крайне неудобной.
У них нет ротации. Сессия уникальна и неповторима. После ее завершения лог обрабатывается и удаляется.
Ну самое главное ограничение — у нас в ротации несколько бекендов для счетчика. Клиентские сессии собираются из хитов, накопленных на разных нодах счетчика. Считать это там же на нодах, перекладывая с ноды на ноды и склевая ClickStream — не кажется реальным. А так даже проще масштабировать: поставил еще одну ноду для счетчика и включил с нее заливку ClickStream в RedShift.
В этом место тоже как-то странно, зачем сессию разбрасывать рандомно по нодам? Ее же можно приклеить к одной ноде при первом попадании, такой функционал есть у любого балансера уже давно.
P.S. Несколько нод только для счетчика — ну это вы вообще жирно живете :)
А зачем приклеивать, если можно не приклеивать? =)
Этим можно оптимизировать многие процессы. Улучшить производительность. Но я смотрю кол-во серверов просто не проблема. Тогда да — можно «не приклеивать». )) Но так можно и вообще дойти вопроса — зачем думать, если можно не думать и просто покупать много серверов…
Классный пост! Не сказать, чтобы супер полезный в практическом смысле, но зато просто прикольный. Жду больше инфы про инфраструктуру и возникающие вопросы в процессе реализации.

Можете привести больше интересных или может даже парадоксальных фактов, которые выяснили после внедрения глубокой аналитики? Типа того, где магазин узнает о беременности девушки раньше ее отца.
… или раньше самой девушки. В момент, когда она жалуется подруге на «непонятные симптомы».
Раз уж зашел разговор о том чего хватает/не хватает, то после редизайна не хватает какого выделения новых/непрочитанных новостей в личной ленте.
А сколько занимают места на диске ваши User Data, Site DB и NoSQL?
600 Гб занимает статистика, 130 PostgreSQL и 35 MongoDB — это не считая реплик.
>>Мы же используем инфраструктуру данных для кампейнинга: выборке пользователей для отправки им персонализированных сообщений. Мы выявляем пользователей, которые не заходили несколько недель на сайт, чтобы рассказать им через email, что интересного у нас появилось, пока их не было. Мы напоминаем игрокам об их Fantasy-команде или турнире прогнозов, которые они забросили. Мы приглашаем болельщиков в тематические форумы по интересам.

так построили бы необходимую вам поведенческую модель юзера и делали бы выборки по ней. У нас поведенческие модели на 600 000 кастомеров хранятся в отдельной базе, занимают весьма мало места и апдейтятся 15 000 000 раз в сутки. Все живет на одном арендованном сервере. Разработка заняла одну неделю. Доделки под текущие бизнесзадачи занимают от 10 минут до дня.
А что включает в себя ваша модель?
опредеделенные данные о пользователе, график его суточной активности по часам и дням недели, взаимоотношения с другими пользователями, набор мест где он преимущественно находится, обращение к разным методам АПИ и т.д. Не пользовался он ни разу за неделю функционалом «сменить скин приложения» мы ему можем взять и выслать сообщение что такой функционал есть.

У нас мобильнео приложение гео-радар. i-am-app.ru
ну и понятно что модель эта спроектирована таким образом чтобы можно было лехко осуществлять поиск по нужным полям.

к примеру выбрать всех пользователй которые появлялись вблизи точки 34.23456, 12.232323 не менее 5ти раз, при этом зарегистрировались в мае, и ни разу не оправляли картинки другим пользователям.

это по монгоДб делается в один запрос по набору полей. Быстро, просто, красиво.
Отлично, напишите об этом пост!
это навернное самое неинтересное что у нас есть :)

вот толи дело распределенный по всем контитнетам децентрализованный серверный бекенд… это да, крутота. А мысль хранить данные в удобном для обработки виде вместо удобного для сбора — это тривиально.

В самом деле, зачем мне хранить огромное количество сырых данных, если их можно схлопнуть в 2-3 значения важных для бизнеса? Таким образом мегабайты серверных логов превращаются в байты.
Поддерживаю предыдущего комментатора — было бы очень интересно прочитать об этом пост.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий