Комментарии 62
Есть ли у вас открытый API для работы с вашими данными?
На морде okmetric из-за вот этого бага code.google.com/p/chromium/issues/detail?id=336403 в хроме бывает что вкладка падает совсем (со словами «Oh snap!» так что даже js`ом не поймаешь в чем проблема)
Поэтому с морды интерактивные графики для 32 хрома убрали.
Но если вам не трудно зайти на okmetric.com/ohsnap.html и посмотреть будет падать или нет.
И если падает — написать версию хрома («window.navigator.appVersion» в js консоли).
Поэтому с морды интерактивные графики для 32 хрома убрали.
Но если вам не трудно зайти на okmetric.com/ohsnap.html и посмотреть будет падать или нет.
И если падает — написать версию хрома («window.navigator.appVersion» в js консоли).
Кстати да, выкладывали бы датасеты по типам спорта и командам, было бы неплохо.
Мы уже третий год думаем о публичном API со спортивной статистикой и всякими индексами популярности, но пока что руки так и не дошли.
Эмм… 500 ГБ — это Big Data?
По поводу email-рассылок, поймал себя на мысли, что вы очень точно сформировали подборку, что я, таки, заходил на сайт.
Только вот что меня сильно отталкивает от действий на «Спортсах», так это странная система отображения комментариев.
Комментарии идут друг за другом, т.е. проследить дискуссию между пользователями — не реально! Постоянно нужно нажимать кнопку «Ответ на комментарий пользователя… ». Не комфортно читать — нет желания комментировать!
Не пробовали вы другой вариан отображения комментариев? Планируете? Теперь у вас есть отличный инструмент для АБ-тестирования))
Почитал бы про это на Хабре! )
Только вот что меня сильно отталкивает от действий на «Спортсах», так это странная система отображения комментариев.
Комментарии идут друг за другом, т.е. проследить дискуссию между пользователями — не реально! Постоянно нужно нажимать кнопку «Ответ на комментарий пользователя… ». Не комфортно читать — нет желания комментировать!
Не пробовали вы другой вариан отображения комментариев? Планируете? Теперь у вас есть отличный инструмент для АБ-тестирования))
Почитал бы про это на Хабре! )
Зато лучше, чем у ч.ру, где плагин комментариев грузится раз на 50 после обновления страницы с новостью.
Думаем про ветки с комментами для отдельных типов страниц, но опять же — не доходят руки =( Ну и эмоцианальное обсуждение спорта все-таки отличается от вдумчивых, ветвистых дискуссий на хабре. Так, например, выглядит топ комментариев для типичной новости:
Согласен, бывают разные типы материалов, например — обсуждение прошедшего матча или аналитика перед туром!
В первом посте будет больше коротких комментариев, во втором длинных комментариев с рассуждениями.
Но при любом варианте есть место дискуссии. Спорт это эммоции в чистом виде… Радость, злость, ирония или просто троллинг. Иногда удачный десятый ответ на комментарий собирает все плюсы и срывает овации. А сейчас вы прячете всю эту прелесть однородным столбом комментариев, где очень легко упустить все нюансы диалога.
Пример
В первом посте будет больше коротких комментариев, во втором длинных комментариев с рассуждениями.
Но при любом варианте есть место дискуссии. Спорт это эммоции в чистом виде… Радость, злость, ирония или просто троллинг. Иногда удачный десятый ответ на комментарий собирает все плюсы и срывает овации. А сейчас вы прячете всю эту прелесть однородным столбом комментариев, где очень легко упустить все нюансы диалога.
Пример
Не стоит забывать просто, что у веток коментов кроме плюсов есть масса минусов:
– они очень плохо себя чувствуют в мобайле (где уже почти половина аудитории) и в узких колонках – как у нас в новостях
– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru
– они очень плохо себя чувствуют в мобайле (где уже почти половина аудитории) и в узких колонках – как у нас в новостях
– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru
– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru – тут выпало «очень востребована»
– они очень плохо себя чувствуют в мобайле (где уже почти половина аудитории) и в узких колонках – как у нас в новостях
— Хабр не плохой пример отображения комментариев в мобайле. Это если смотреть через браузер. Если использовать приложение (у «Спортсов» оно есть), то та же история. Проблем нет в отображении.
– они не согласуются с идеей рейтинга лучших комментариев, которая аудиторией Sports.ru
Ну, если цель — вывести топ лучших комментариев, то может быть ситуация, когда лучшим может стать ответ на чей-то комментарий.
Я не знаю какие цели преследовали разработчики. Возможно, было желание сделать каждый комментарий «самостоятельным», т.е. уровнять диалоги, что бы даже у ответов были хорошие шансы на «плюс».
Я высказал свое мнение, почему я не оставляю комментариев на «Спортсах». Мне изначально не понравились комментарии на сайте, и поэтому, я читаю только статьи и редко комментарии. Т.к. в моей подписке, в основном, не самые популярные тематические блоги, то комментариев там не много. Я их быстро пролистываю и ухожу.
Но если мне попадается статья с большим количеством комментариев, то я на автомате ищу глазами самые «отличившиеся». ИМХО не правильный подход.
Ну как – «неправильный подход»? Когда под материалом или новостью 500-1000 комментариев (что на Sports.ru не редкость), прочесть самые рейтинговые – это как раз вполне логичный юзкейс, и, кстати, самый часто используемый.
Но о вкусах действительно не спорят – повторюсь, у веток комментариев свои несомненные тоже есть, и мы прекрасно понимаем, что кому-то они ближе. Я только пояснил, почему из двух вариантов выбран один, а не другой (совместить их не получится).
Ну и с «проблем нет в отображении веток в мобайле» я не совсем согласен. К сожалению, есть.
Но о вкусах действительно не спорят – повторюсь, у веток комментариев свои несомненные тоже есть, и мы прекрасно понимаем, что кому-то они ближе. Я только пояснил, почему из двух вариантов выбран один, а не другой (совместить их не получится).
Ну и с «проблем нет в отображении веток в мобайле» я не совсем согласен. К сожалению, есть.
Наверное, у «Спортсов» были причины на то, чтобы сделать именно такие комментарии. И раз у них такое кол-во аудитории, значит правы они, а не я. =)
Но я, к сожалению, бываю там проходом.
Ну так давайте обсудим их! У нас есть для этого «ветки» комментариев =) С какими проблемами вы столкнулись?
P.S. Сделал 2 скриншота из мобайла. Приложение для Реддит, Хабр через браузер
Но я, к сожалению, бываю там проходом.
Ну и с «проблем нет в отображении веток в мобайле» я не совсем согласен. К сожалению, есть.
Ну так давайте обсудим их! У нас есть для этого «ветки» комментариев =) С какими проблемами вы столкнулись?
P.S. Сделал 2 скриншота из мобайла. Приложение для Реддит, Хабр через браузер
Говорю же, это не тот случай, когда прав кто-то один. Есть два сопоставимых по популярности – но разных способа организовывать комментарии. Нельзя применить оба сразу, я лишь постарался пояснить наш выбор из этих двух ))
Кстати, все современные соцсети почему-то сделали такой же.
Также, наверное, и с вашими скриншотами – вам кажется, что проблемы в отъедании полезной площади (и без того небольшой у смартфона) «ветками» нету. Хотя она будет только нарастать с каждым новым ответом. Я не уверен, что готов с этим согласиться – но не настаиваю, чтобы вы меняли свою точку зрения.
Кстати, все современные соцсети почему-то сделали такой же.
Также, наверное, и с вашими скриншотами – вам кажется, что проблемы в отъедании полезной площади (и без того небольшой у смартфона) «ветками» нету. Хотя она будет только нарастать с каждым новым ответом. Я не уверен, что готов с этим согласиться – но не настаиваю, чтобы вы меняли свою точку зрения.
Говорю же, это не тот случай, когда прав кто-то один. Есть два сопоставимых по популярности – но разных способа организовывать комментарии. Нельзя применить оба сразу, я лишь постарался пояснить наш выбор из этих двух ))
Я вас понял. Ваш подход, видимо, отлично работает.
P.S.
Эпично вы вчера нас раскатали. Полурезервом. С победой =)
Лично мне не хватает возможности выбора главных статей по рейтингу (так же и по дате: хотелось бы удобно читать старые материалы сайта). Например, я провожу 90% времени в разделе sports.ru/football, но мне интересно также почитать качественные, одобренные пользователями материалы из других разделов сайта, а туда я редко лажу.
Спасибо за sports.ru!
Спасибо за sports.ru!
Мы считаем, что такими страницами являются главная сайта (редакционный отбор) www.sports.ru/ и главная трибуны (пользовательский отбор) www.sports.ru/tribuna/
И в то же время вяло ведете твиттер с моими желанными лучшими текстами: twitter.com/sportsrubest :)
У вас там на картинке, где пользователю предлагается вступить в группу/сообщество «Двигатель торговли», она два раза упомянута, сначала как та группа, где друзья пользователя сидят, а потом как та, которую он лайкал. Логичнее было бы это объединить и подавать в одном блоке.
Сначала все валите в один access.log, а потом разбираете по сессиям? Экие вы затейники.
access_log /mnt/tmpfs/$arg_sessionpid analytics;
вот такая одна строчка в ngxin.conf раскладывает сразу все сессии по файлам. Когда файл N минут не обновляется — уходит в обработку. Десятки тысяч файлов на рамдиске и те же миллионы хитов — нагрузки практически ноль. Ну и главное — дальнейшая обработка ну совсем простая.
access_log /mnt/tmpfs/$arg_sessionpid analytics;
вот такая одна строчка в ngxin.conf раскладывает сразу все сессии по файлам. Когда файл N минут не обновляется — уходит в обработку. Десятки тысяч файлов на рамдиске и те же миллионы хитов — нагрузки практически ноль. Ну и главное — дальнейшая обработка ну совсем простая.
Интересное решение, спасибо.
Мы храним не только сессии, но и кликстрим тоже, так что в любом случае все записи нужно отправлять в Redshift. Статистику по сессиям (длина, число страниц, источник и т.д.) считаем уже в нем, так что нет необходимости разбивать лог на отдельные файлы по сессиям.
Для нас важно иметь возможность иметь агрегированные данные не только по сессиям (как в Google Analytics или Метрике), но и по дням-неделям (например, число просмотров пользователя за день), поэтому при парсинге логов статистика не считается — все происходит уже в Redshift.
Мы храним не только сессии, но и кликстрим тоже, так что в любом случае все записи нужно отправлять в Redshift. Статистику по сессиям (длина, число страниц, источник и т.д.) считаем уже в нем, так что нет необходимости разбивать лог на отдельные файлы по сессиям.
Для нас важно иметь возможность иметь агрегированные данные не только по сессиям (как в Google Analytics или Метрике), но и по дням-неделям (например, число просмотров пользователя за день), поэтому при парсинге логов статистика не считается — все происходит уже в Redshift.
Я сейчас глянул первый попавшийся бэкенд одного проекта (чуть больше, чем сабж) и понял, что следуя вашим советам, я бы уперся в лимит инодов где-нибудь так дня через 3 (тоже на tmpfs), если не разгребать эти файлы. :)
Если 3 дня не разгребать, то да — понт защитан :)
А так среднее время жизни сессии редко больше 10 минут.
А так среднее время жизни сессии редко больше 10 минут.
Ну самое главное ограничение — у нас в ротации несколько бекендов для счетчика. Клиентские сессии собираются из хитов, накопленных на разных нодах счетчика. Считать это там же на нодах, перекладывая с ноды на ноды и склевая ClickStream — не кажется реальным. А так даже проще масштабировать: поставил еще одну ноду для счетчика и включил с нее заливку ClickStream в RedShift.
В этом место тоже как-то странно, зачем сессию разбрасывать рандомно по нодам? Ее же можно приклеить к одной ноде при первом попадании, такой функционал есть у любого балансера уже давно.
P.S. Несколько нод только для счетчика — ну это вы вообще жирно живете :)
P.S. Несколько нод только для счетчика — ну это вы вообще жирно живете :)
Классный пост! Не сказать, чтобы супер полезный в практическом смысле, но зато просто прикольный. Жду больше инфы про инфраструктуру и возникающие вопросы в процессе реализации.
Можете привести больше интересных или может даже парадоксальных фактов, которые выяснили после внедрения глубокой аналитики? Типа того, где магазин узнает о беременности девушки раньше ее отца.
Можете привести больше интересных или может даже парадоксальных фактов, которые выяснили после внедрения глубокой аналитики? Типа того, где магазин узнает о беременности девушки раньше ее отца.
Раз уж зашел разговор о том чего хватает/не хватает, то после редизайна не хватает какого выделения новых/непрочитанных новостей в личной ленте.
А сколько занимают места на диске ваши User Data, Site DB и NoSQL?
>>Мы же используем инфраструктуру данных для кампейнинга: выборке пользователей для отправки им персонализированных сообщений. Мы выявляем пользователей, которые не заходили несколько недель на сайт, чтобы рассказать им через email, что интересного у нас появилось, пока их не было. Мы напоминаем игрокам об их Fantasy-команде или турнире прогнозов, которые они забросили. Мы приглашаем болельщиков в тематические форумы по интересам.
так построили бы необходимую вам поведенческую модель юзера и делали бы выборки по ней. У нас поведенческие модели на 600 000 кастомеров хранятся в отдельной базе, занимают весьма мало места и апдейтятся 15 000 000 раз в сутки. Все живет на одном арендованном сервере. Разработка заняла одну неделю. Доделки под текущие бизнесзадачи занимают от 10 минут до дня.
так построили бы необходимую вам поведенческую модель юзера и делали бы выборки по ней. У нас поведенческие модели на 600 000 кастомеров хранятся в отдельной базе, занимают весьма мало места и апдейтятся 15 000 000 раз в сутки. Все живет на одном арендованном сервере. Разработка заняла одну неделю. Доделки под текущие бизнесзадачи занимают от 10 минут до дня.
А что включает в себя ваша модель?
опредеделенные данные о пользователе, график его суточной активности по часам и дням недели, взаимоотношения с другими пользователями, набор мест где он преимущественно находится, обращение к разным методам АПИ и т.д. Не пользовался он ни разу за неделю функционалом «сменить скин приложения» мы ему можем взять и выслать сообщение что такой функционал есть.
У нас мобильнео приложение гео-радар. i-am-app.ru
У нас мобильнео приложение гео-радар. i-am-app.ru
ну и понятно что модель эта спроектирована таким образом чтобы можно было лехко осуществлять поиск по нужным полям.
к примеру выбрать всех пользователй которые появлялись вблизи точки 34.23456, 12.232323 не менее 5ти раз, при этом зарегистрировались в мае, и ни разу не оправляли картинки другим пользователям.
это по монгоДб делается в один запрос по набору полей. Быстро, просто, красиво.
к примеру выбрать всех пользователй которые появлялись вблизи точки 34.23456, 12.232323 не менее 5ти раз, при этом зарегистрировались в мае, и ни разу не оправляли картинки другим пользователям.
это по монгоДб делается в один запрос по набору полей. Быстро, просто, красиво.
Отлично, напишите об этом пост!
это навернное самое неинтересное что у нас есть :)
вот толи дело распределенный по всем контитнетам децентрализованный серверный бекенд… это да, крутота. А мысль хранить данные в удобном для обработки виде вместо удобного для сбора — это тривиально.
В самом деле, зачем мне хранить огромное количество сырых данных, если их можно схлопнуть в 2-3 значения важных для бизнеса? Таким образом мегабайты серверных логов превращаются в байты.
вот толи дело распределенный по всем контитнетам децентрализованный серверный бекенд… это да, крутота. А мысль хранить данные в удобном для обработки виде вместо удобного для сбора — это тривиально.
В самом деле, зачем мне хранить огромное количество сырых данных, если их можно схлопнуть в 2-3 значения важных для бизнеса? Таким образом мегабайты серверных логов превращаются в байты.
Поддерживаю предыдущего комментатора — было бы очень интересно прочитать об этом пост.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы используем инфраструктуру обработки данных в Sports.ru и Tribuna.com?