Некоторое время назад я решил оживить мой аккаунт на Хабре. В 2008 году, когда я ещё только его зарегистрировал, было принято фармить сначала комментариями карму и только потом писать статьи. Я так делал, насколько помню. Забегая вперёд скажу, что то ли я помню неправильно, то ли всё поменялось, то ли и то и то, но сейчас фармить комментариями не нужно, хочешь статью - просто пиши (хотя у меня немного кармы с тех времён оставалось, может, поэтому я могу писать статью без проблем).
Неважно.
Покомментировав с умным видом здесь и тут, я решил подвести научную базу. Не сразу, сначала думал, что мой блестящий интеллект сразу заметят и под моими комментариями будет собираться очередная сходка фан-клуба имени меня. К сожалению, несколько моих абсолютно удачных (на мой беспристрастный взгляд) комментариев были полностью проигнорированы мировой общественностью.
Чтош.jpg. Зря, что ли, я всякие курсы на ютубе проходил и сертификаты на kaggle.com получал. “Иди сюда, биг дата, сейчас я тебя проанализирую”, - сказал я себе, засучивая рукава.
Я поставил себе задачу понять: когда и где надо оставить комментарий, чтобы он набрал максимум лайков.
И ещё один дисклеймер: все свои публичные выступления и статьи я отрабатываю на своей жене. Если я могу объяснить что-то абсолютно не техническому человеку, значит, я понимаю это хорошо. Однако кому-то может показаться, что я уж слишком разжёвываю, сорян.
Как я считал
Откуда данные
Никакого скрапинга HTML - у Хабра есть внутренний JSON API, тот самый, которым пользуется фронтенд: habr.com/kek/v2/. Он не документирован, но стабилен и отдаёт всё, что видно на странице, плюс кое-что, чего не видно (точные счётчики голосов). Я просто попялился в dev-панель в браузере и посмотрел, как оно работает, когда я хожу по страничкам.
Выборка собиралась в два прохода:
Весь недельный фид свежих статей -
GET /kek/v2/articles/?sort=date&period=weekly, постранично, пока страницы не кончатся. Получилось 545 статей за неделю.Для каждой статьи, у которой набралось хотя бы 4 комментария (таких оказалось 250 - да, медианная статья на Хабре собирает всего 3 комментария), забирал весь тред:
GET /kek/v2/articles/<id>/comments/.
Из тредов выкинул:
комментарии автора статьи - им голосуют по другим законам, автор в своём треде не конкурент чужим комментаторам;
комментарии со скрытым score (их единицы).
Осталось 4404 комментария. По каждому: score, время, позиция в треде (по времени публикации), автор, длина текста. По статье-носителю: просмотры, рейтинг, размер треда, время выхода.
Два технических момента, которые сэкономят вам вечер, если решите повторить:
с дефолтным curl-овским User-Agent Хабр не ругается, а молча отдаёт урезанные ответы - ставьте браузерный UA;
между запросами - пауза 0.6-0.7 секунды. 800 запросов за 10 минут никому не мешают, а бан вы себе за вечер не заработаете.
Что и как мерил
Наивный подход - сгруппировать комментарии по часу суток и сравнить средние. Так я и сделал сначала и получил красивую ерунду - о ней ниже.
Проблема наивного подхода: час суток тащит за собой всё остальное. Вечером свежими оказываются одни статьи, днём - другие; у ранних комментариев позиция в треде лучше просто потому, что они ранние.
Чтобы отделить мух от котлет, я построил две модели. Звучит страшно, идея простая.
Представьте, что мы взяли два одинаковых комментария - одинаково удачных, под одинаково популярными статьями - и различаются они только одним: один написан вторым в треде, другой сороковым. Регрессия - это способ математически изобразить такое сравнение, когда живых пар-близнецов у тебя нет, а есть 4404 разных комментария. Модель смотрит на все факторы сразу и отвечает: сколько плюсов “стоит” каждый фактор сам по себе, если остальные заморозить.
Моделей две, потому что вопроса два:
“Сколько плюсов наберёт комментарий?” - здесь предсказываем количество плюсов.
“Будет ли он вообще в плюсе?” - здесь предсказываем только да/нет. Эта модель грубее, но устойчивее: ей всё равно, набрал комментарий +2 или +20.
Факторы в обеих одни и те же:
позиция в треде (вторым ты пишешь или сороковым);
сколько часов прошло с выхода статьи;
насколько статья вообще живая: размер треда, просмотры, рейтинг;
и, наконец, время суток - не одним числом, а набором “переключателей”: комментарий написан утром? днём? вечером? ночью? Каждый блок в три часа получает свой переключатель, и модель для каждого честно считает отдельную надбавку или штраф.
Все количественные факторы я брал не как есть, а через логарифм. Причина житейская: разница между 2-м и 10-м комментарием огромна, а между 102-м и 110-м - никакой, хотя в штуках это те же восемь позиций. Логарифм ровно это и выражает - важны разы, а не штуки.
А дальше самое интересное. Если “вечером голосуют щедрее” - правда, то вечерние переключатели покажут заметную надбавку даже после учёта всего остального. Если же вечерний эффект - иллюзия, которая на самом деле объясняется тем, что вечером ты просто чаще попадаешь в свежий тред на ранней позиции, - то надбавка исчезнет, как только позиция и свежесть учтены отдельно. Спойлер: исчезла.
И ещё одна проверка на дурака. Когда сравниваешь “вечер против дня”, всегда есть шанс, что разница - просто везение: ну выпало на этой неделе вечером несколько удачных комментариев, бывает. Проверяется это тупо и честно: я взял те же комментарии, перемешал у них метки “вечер”/“день” случайным образом - пять тысяч раз подряд (единственный момент за весь анализ, когда мой макбук вспомнил, что у него есть вентилятор) - и посмотрел, как часто случайное перемешивание даёт разницу не хуже настоящей. Если “не хуже” получается у каждой пятой случайной тасовки - грош цена такой разнице, это шум. Именно так вечерний эффект и рассыпался на второй неделе замера.
И главное - весь замер сделан дважды на двух независимых неделях (27.07-02.08: 528 статей / 4353 комментария, и 04-11.08: 545 / 4404). Всё, что не воспроизвелось на второй неделе, в выводы не попало. Одна такая жертва по ходу текста будет - следите за вечерним эффектом.
Вывод №1: кто раньше встал - того и тапки
Чем ближе твой комментарий к началу треда, тем лучше ему живётся:
Позиция |
сколько таких |
в плюсе |
плюсов в среднем |
|---|---|---|---|
#1-3 |
617 |
61% |
3.3 |
#4-10 |
932 |
49% |
2.0 |
#11-25 |
952 |
45% |
2.0 |
#26-50 |
643 |
45% |
1.6 |
#51+ |
1260 |
39% |
0.9 |
Первая тройка живёт втрое лучше хвоста. Неделей раньше картина была та же (69% против 42%). А комментарий в хвосте треда - это как в том анекдоте. Взбунтовались крестьяне, пришли толпой к усадьбе барина. Барин вышел на крыльцо с ружьём: “Ну что?” Все молча разошлись. Вечером один сидит дома, хлебает щи, вдруг как стукнет кулаком по столу: “Чо, чо, а ничо!”
Вывод №2: сутки - и поезд ушёл
Смотрим не на позицию, а на время: сколько часов прошло от выхода статьи до твоего комментария.
Прошло времени |
сколько таких |
в плюсе |
плюсов в среднем |
|---|---|---|---|
до 3 часов |
646 |
66% |
4.9 |
3-6 часов |
497 |
58% |
2.9 |
6-12 часов |
515 |
59% |
2.2 |
12-24 часа |
1229 |
45% |
1.2 |
1-2 суток |
1019 |
35% |
0.7 |
старше 2 суток |
498 |
21% |
0.3 |
Никакого плавного угасания - обрыв. Комментарий в первые три часа в плюсе у двух третей, после двух суток - у каждого пятого, и средний урожай падает в шестнадцать раз. Прошлая неделя: то же самое, вплоть до десятых. Причина, скорее всего, механическая: комментариям голосуют читатели статьи, а основная масса читателей приходит в первые сутки, пока статья висит в ленте.
Вывод №3: час на часах не важен
Если тупо сгруппировать комментарии по времени суток, кажется, что вечер чуть лучше: в 21-24 в плюсе 53%, утром в 06-09 - 40%.
Но это обман зрения. Вечерние комментарии чаще оказываются ранними в свежих тредах - выигрывает не час, а позиция и свежесть, которые за ним прячутся. Как только сравниваешь честно (одинаковая позиция, одинаковая свежесть, одинаковая статья - см. “Для душнил” в конце), от времени суток не остаётся ничего.
Больше того. На первой неделе замера вечер выглядел лучше дня даже в сырых цифрах - я уже почти написал “комментируйте после ужина”. А на второй неделе вечер оказался хуже дня: 3.5 плюса против 4.6 у свежих комментариев. Народная примета “постить вечером” не пережила даже двух недель наблюдений.
Вывод №4: важно не “когда голосуют”, а “когда есть куда писать”
Статьи выходят волной с 11:00 до 17:00 МСК (6-11 штук в час), разгон с девяти утра, после семи вечера ручеёк, ночью пусто. И только 1-4 статьи в час доживают до живого треда.
Так что “сиди на Хабре днём” - совет не про щедрых голосующих, а про ассортимент: днём просто есть из чего выбирать свежее.
Практический итог
Комментируй статьи моложе 12 часов. Старше суток - лотерея против тебя.
Целься в первую десятку комментариев, лучше - в тройку.
На часы не смотри вообще. Работаешь вечером - ок, просто бери статьи, вышедшие после обеда, а не утренние.
Крупная читаемая статья умножает всё: лучше пятый коммент под будущим хитом, чем первый под статьёй-невидимкой.
Другими словами - угадай, какая из свежих статей, имеющих пока столько комментариев, что их можно пересчитать по пальцам одной руки фрезеровщика с 50-летним стажем, взлетит - и ты победил.
Ограничения, или честный дисклеймер
Это наблюдения, а не эксперимент. Рандомизации нет: я не заставлял одних людей писать в час ночи, а других в полдень. Всё, что здесь есть - корреляции с контролями. Там, где напрашивается причинность, я это оговариваю отдельно.
Score снят в момент сбора, а не “навсегда”. Поздние комментарии моложе ранних и теоретически ещё могли добрать голосов. Смягчает это то, что голоса комментариям прилетают в основном пока статья свежая - но полностью проблему не снимает. Для параноиков: я пересчитал таблицу лагов только по статьям старше трёх суток - картина та же.
Выборка - две недели лета 2026. Сезонность (сентябрь, праздники, релизы Apple) может двигать абсолютные цифры. Мой прогноз - соотношения устоят, но это прогноз, а не факт.
Голоса за комментарии дают рейтинг, а не карму - статья не про фарм кармы, а про то, чтобы написанное вами вообще было прочитано.
Этичность
Самый больной вопрос. Всё вышесказанное можно рассмотреть под таким углом, что я механистически отношусь к Хабру и пытаюсь живое, дышащее сообщество с эмоциями, трендами и своими правилами загнать в датасет и препарировать классификатором.
Это не так. Я по-прежнему иногда бомблю с некоторых тейков и начинаю строчить гневные отповеди, хотя чаще не отправляю. Я по-прежнему читаю не то, что быстро набирает, а то, что лично мне интересно.
Просто когда у тебя в руках молоток, всё кажется гвоздём. Вот и мне захотелось свежеприобретённый набор знаний применить к любимому Хабру.
Для душнил (весь матан здесь)
Выборка: фид /kek/v2/articles/?sort=date&period=weekly, 545 статей (~04-11.08.2026), 250 тредов >=4 комментариев, N=4404 после исключения авторских и скрытых score. Прошлая неделя (27.07-02.08): 528 статей, 231 тред, N=4353.
OLS на log(1+score), отрицательные score клипнуты нулём:
фактор |
коэффициент |
t |
|---|---|---|
log(позиция в треде) |
-0.427 |
-19.8 |
log(лаг, ч) |
-0.082 |
-5.2 |
log(размер треда) |
+0.283 |
+10.4 |
log(просмотры статьи) |
+0.165 |
+9.4 |
signed log(рейтинг статьи) |
+0.095 |
+5.8 |
все дамми часов (база 06-09) |
от -0.037 до +0.051 |
все |t| <= 1.2 |
LPM P(score>0): log_pos -0.134 (t=-9.0), log_lag -0.077 (t=-7.1), log_tsize +0.051 (t=2.7), log_reads +0.065 (t=5.3), slog_tscore +0.074 (t=6.6), часы все |t| <= 1.4.
Перестановочный тест (5000 перестановок, seed=42) для “вечер 18-21 vs день 12-18” на свежих комментариях (<6ч): разница -1.06 плюса (вечер хуже!), p=0.18 - шум. Неделей раньше сырое преимущество вечера было +1.9 с p=0.002, но убивалось контролем состава статей. Итого: как корреляция нестабилен, как эффект - отсутствует.
Проверка обрыва на прочность: пересчёт только по статьям старше 3 суток на момент сбора (N=3373), чтобы поздние комментарии не были “недоголосованными”: 0-3ч -> 67.5% в плюсе (ср. 5.86), 48ч+ -> 22.1% (ср. 0.32). Картина не изменилась.
День недели: с контролем лага устойчивой картины нет, межнедельный разброс похож на шум отдельных статей-хитов.
Медиана комментариев у статьи - 3. Живых тредов (10+) за неделю - около четверти от статей с тредами.
Скрипты сбора и анализа - в гисте, всё воспроизводится за ~15 минут и один вечер разглядывания таблиц. Если прогоните на своей неделе и что-то не совпадёт - обязательно напишите в комментариях. Желательно в первые три часа и поближе к началу треда.
Комментарии (29)
Iscander_Che
12.08.2026 08:06А где в дев-панели глядеть, куда смотрит фронт в API? Есть мысль запилить сборщик ссылок на статьи, которые ещё не видел, пока в отпуске и без доступа в сеть. Напоролся на это в этот отпуск, блин. Две недели в сети не было - и на тебе. Уехал 24 июля, а долистать ленту постов по возвращению смог только до 28 июля. Всё, что было ранее - привет. И техподдержка сказала, что ничем помочь не может. Даже календаря постов нет. Что странно. Так что "помоги себе сам".
k41n Автор
12.08.2026 08:06DevTools -> вкладка Network -> фильтр Fetch/XHR, дальше просто листаете ленту и смотрите, что уходит на habr.com/kek/v2/. Всё, что видно на странице, там же и лежит в JSON.
Конкретно под вашу задачу: GET https://habr.com/kek/v2/articles/?fl=ru&hl=ru&sort=date&period=monthly&page=N
В ответе publicationRefs - id, заголовок, время, статистика; pagesCount - сколько всего страниц. Два подводных камня, оба стоили мне вечера: без period прилетает 422, а с дефолтным curl-овским User-Agent Хабр не ругается, а молча отдаёт урезанный ответ - ставьте браузерный UA.
Плохая новость: pagesCount упирается в 50, это 1000 статей за проход, дальше 400. period=monthly сейчас достаёт до 15 июля - ваш отпуск бы закрыл впритык, но окно едет каждый день, так что архив за прошлое уже не собрать.
Хорошая: на будущее это ровно то, что вам нужно. Раз в пару дней дёргать period=weekly (32 страницы), складывать id в локальный файл - и никакого «долистал только до 28-го». Заготовка есть в гисте из статьи, collect_habr.py делает ровно этот постраничный обход с паузой 0.6-0.7 с между запросами: https://gist.github.com/k41n/973a7593738393e21ce7165be2e9c8f3
Iscander_Che
12.08.2026 08:06О! Ништяк. Сердечно кланяюсь за помощь. Не ожидал от дрг Мрзд такого быстрого ответа в вашем лице. :) Позавчера проблема, сегодня - практически решение. Осталось только хостинг для этого дела подобрать. Селф-хостинг как-то стрёмно оставлять на две недели.
k41n Автор
12.08.2026 08:06Дык, GitHub Actions - халява же. Репа со скриптом, workflow по расписанию (on: schedule, cron), скрипт складывает свежие id в JSON и коммитит его обратно в репу. Из отпуска открываете файл прямо в вебе с телефона, когда сеть появится. Для публичного репозитория это бесплатно, а лимитов хватает с запасом: пара минут раз в день.
Один попадос есть: GitHub отключает scheduled workflows в репке, где 60 дней не было активности. Но раз наш workflow сам коммитит результат, активность есть каждый день, и отключать его не за что.
Я часто так делаю для целей самообновляющихся файликов в вебе, тащемтаIscander_Che
12.08.2026 08:06Ок. Надо будет при случае покурить всё это.
Про девтулз не впитал только. Я на ФФ сижу и за Каспом. Он мне по F12 в разделе XHR только общую инфу показывает.
k41n Автор
12.08.2026 08:06Ссылку из моего прошлого комментария просто вставьте в адресную строку - у ФФ вроде есть встроенный просмотрщик JSON, откроется деревом, с поиском и кнопкой “Необработанные данные”. Меняете page=1 на page=2 и смотрите, что приходит. Девтулз нужен только чтобы подсмотреть незнакомую ручку, а я уже всё спалил.
Iscander_Che
12.08.2026 08:06Всё это ок. А если API изменится, чего делать? Вот перейдут на v3, к примеру, и?
k41n Автор
12.08.2026 08:06У вас тоже всё сломается, и никто не предупредит. API недокументированный, никаких гарантий обратной совместимости у нас с вами нет.
Но без паники! Первая: это не публичное API для сторонних разработчиков, а внутреннее для собственного фронта, и меняется оно тогда, когда переписывают фронт. v2 живет годами, я на него натыкался еще до того, как взялся за статью. Вторая: при переезде на v3 старую версию обычно какое-то время не выключают, потому что на нее завязаны и мобильные приложения, и закешированный у людей фронт.
Практически нужно одно - чтобы поломка была громкой, а не тихой. Я бы сделал, если бы это была не поделка для себя, а кровавый энтерпрайз, проверку, что в ответе действительно есть publicationRefs и он непустой, а если нет - падать с шумом. GitHub Actions на упавший workflow сам пришлет письмо, и вы узнаете о поломке в тот же день, а не через месяц пустого файла. Чинится это потом теми же пятью минутами в девтулзах: открыли ленту, посмотрели, куда фронт ходит теперь, поправили URL.
Iscander_Che
12.08.2026 08:06Скрытый текст
И ещё (надеюсь) последний вопрос: json отдельными файлами сохраняется или обновляется каждый раз один и тот же файл?
k41n Автор
12.08.2026 08:06Один файл, и пусть он копится. Словарь вида id статьи - заголовок, ссылка, дата, и на каждом запуске вы просто дописываете в него то, чего там еще нет.
Отдельные файлы по датам смысла не имеют ровно потому, что вы уже в гите: историю за вас ведет он. Более того, это и есть главный бонус такой схемы - в диффе очередного коммита лежит ровно список того, что появилось с прошлого запуска. Из отпуска можно даже не открывать сам файл, достаточно пролистать коммиты за две недели, каждый со своим списком новинок.
Единственное, что стоит сделать сразу: сортируйте ключи при записи (json.dump с sort_keys=True, indent=2). Иначе питон будет тасовать порядок, и каждый дифф превратится в шрапнельные правки вместо аккуратного списка
naky
12.08.2026 08:06Eсли я правильно понял, вашу проблему мог бы решить self-hosted rss-сервер (есть и арендуемые сервисы, но я лично не любитель)
Примеры feed-ов habr-а:
https://habr.com/ru/rss/news
https://habr.com/ru/rss/users/k41n/publications/articles/?fl=ru
k41n Автор
12.08.2026 08:06Спасибо, полез проверять и заодно померил, насколько этого хватает. Результат интереснее, чем я ожидал.
Потолок у всех фидов Хабра одинаковый и жесткий - 41 запись. Пагинации нет вообще: ?page=2 и /page2/ отдают тот же ответ байт в байт. А вот глубина этого окна зависит только от того, сколько в фид сыплется:
общая свежая лента - около 4.5 часов новости - около 15 часов top/daily - сутки, top/weekly - неделя, top/monthly - до 20 июля хаб programming - 4 дня хаб cpp - с 24 июля хаб ruby - аж с апреля 2024
Отсюда и ответ на исходный вопрос. Общая лента для двухнедельного отпуска бесполезна, за 4 часа окно уезжает. А вот подписка на конкретные хабы работает как надо, и никакого сервера для этого не надо: узкий хаб держит месяцы, широкий - несколько дней. Плюс top/monthly для общей картины, если не хочется совсем ничего пропустить из громкого.
Так что для чтения RSS явно удобнее моей возни с JSON. JSON остается нужен, только если хочется полную ленту без отбора по хабам и топам.
Но без GHA или своей арендованной железки всё равно не обойтись...
naky
12.08.2026 08:06Да, я это сбросил именно для чтения как решение проблемы пропущенных во время отпуска постов: RSS-лента обновляется RSS-сервером по расписанию, поэтому попадёт туда вообще всё. Для аналитики это бесполезно, т.к. у всех RSS-лент есть лимиты (обычно это 50 item-ов).
Из плюсов своего сервера, кроме regex фильтров, - синхронизация прочитанного между устройствами.
k41n Автор
12.08.2026 08:06Согласен, так и есть: с сервером, который копит у себя, лимит перестает что-либо значить. Мое замечание работало только потому что исконный спрашиватель писал такое: "Селф-хостинг как-то стрёмно оставлять на две недели." Есть железка или VPS - ваш вариант однозначно лучше, синхронизация прочитанного и regex-фильтры в самодельном скрипте не появятся никогда. Не готовы - остаются хабовые фиды, которые за счет низкого трафика держат окно неделями, или GitHub Actions в роли того же накопителя, только бесплатного и чужого.
Про бесполезность для аналитики полностью подписываюсь (хотя и не потому, что лимиты): там нужны score и время каждого комментария, а в RSS этого нет и быть не должно.
naky
12.08.2026 08:06Без своего сервера есть feedly, inoreader, публичные инстансы freshrss, newsblur, - тысячи их, есть и бесплатные.
k41n Автор
12.08.2026 08:06Точно, про хостинговые читалки я и забыл - там вообще ничего поднимать не надо. Тогда у человека полный набор вариантов на любой вкус, от feedly в один клик до Actions с гитом. Спасибо, ветка получилась полезнее самой статьи.
Feedly, кстати, огонь, сам юзаю
pnetmon
12.08.2026 08:06А взаимосвязь между авторами комментаторов и автором статей учитывалась? А то прогревы статей типа "Мужики, я 15 лет в айти" соберут плюсы просто из-за своей специфики.
k41n Автор
12.08.2026 08:06Нет, как и качество комментариев. Вопрос стоит как: при равном качестве комментариев и одинаково популярном авторе комментария куда выгоднее его поставить? Понятное дело, что если придёт на Хабр Карпатый какой-нибудь, то его любой коммент наберёт лайков. Так же с качеством: коммент может завируситься, например. Но это выбросы.
Я решал задачу для себя. Я - тот, кто я есть и писать комменты умею так, как умею. На это повлиять я не могу. Могу повлиять лишь на то куда и когда писать.
k41n Автор
12.08.2026 08:06Взаимосвязь не учитывал, но ваш вопрос заставил пойти и посчитать. Смотрел пары “автор статьи - комментатор”, которые за неделю встретились больше одного раза.
Таких пар 11 из 2481, это 40 комментариев из 4399, меньше процента. И живут они хуже среднего: в плюсе 40% против 46.4%, средний score 0.75 против 1.84. Постоянных групп поддержки, которые ходят за автором из треда в тред, в недельном срезе просто нет в товарных количествах.
Две честные оговорки. Голоса анонимны, так что кружок, который молча плюсует и не пишет, этим способом не поймать никак. И в моделях контроли на уровне статьи - просмотры, рейтинг, размер треда, - но не поправка на каждую конкретную статью. Специфика жанра “мужики, я 15 лет в айти” учтена ровно настолько, насколько она видна в этих трёх числах.
LinkToOS
12.08.2026 08:06Комментируй статьи моложе 12 часов. Старше суток - лотерея против тебя.
Потому что читатели статьи к ней уже не возвращаются. Прочитал, в закладки не добавил, забыл, конец истории.
Но между теми кого тема серьезно заинтересовала, диалог может продолжаться еще долго. Причем отсутствие посторонних может быть даже плюсом (меньше вероятность что у кого-то из “прохожих” подгорит от комментария,и он поставит минус в карму)насколько статья вообще живая: размер треда, просмотры, рейтинг
Если просмотров много, то комментировать уже поздно. Читатель статьи не вернется чтобы почитать комментарии. Зритель уехал, клоуны остались.
В 2008 году, когда я ещё только его зарегистрировал, было принято фармить сначала комментариями карму и только потом писать статьи
Это было очень логично. Сначала тренируйся на кошках, смотри реакцию, делай выводы. “Комментарии” служили “лягушатником” для начинающих авторов. Теперь это больше похоже на “пикабушник” для выплескивания эмоций.
Целься в первую десятку комментариев, лучше - в тройку.
Это означает стрелять быстро. Но в спешке можно попасть себе в ногу.
Иногда перед комментарием статью все же требуется прочитать. Иначе можно ляпнуть такое, что карма покраснеет (от стыда).
Но чтение статьи и обдумывание комментария отнимает время, и попасть в тройку уже сложно. Пока бегаешь за ружьем, чистишь его и заряжаешь, все уже закончено. Слон убежал, поляна засыпана мусором и мертвыми туристами.k41n Автор
12.08.2026 08:06Про просмотры не соглашусь, тут мухи с котлетами склеились. Просмотры это не "статья остыла", а "статью много читают", и на свежих комментариях это прям видно: среди тех, что написаны в первые три часа, у статей выше медианы по просмотрам средний урожай 8.3 плюса и 78% в плюсе, у статей ниже медианы - 1.4 плюса и 54%. Одинаковая свежесть, разница почти шестикратная. В регрессии то же самое: log(просмотров) даёт +0.165 при t=9.4, и это уже с учётом лага.
Так что правило не "беги от популярных", а "беги от несвежих, беги к популярным". Пятый комментарий под будущим хитом лучше первого под статьёй-невидимкой.
Со всем остальным согласен, и особенно с последним. Скорость против качества это реальный размен, и мои данные его не разрешают: качество комментария я не мерил вообще. Единственный честный выход из него не "печатай быстрее", а "комментируй то, в чём и так разбираешься". Тогда чтение статьи занимает пять минут, а не полчаса, и в первую десятку успеваешь без стрельбы по ногам.
Про "лягушатник" точное наблюдение. Похоже, эта функция отвалилась вместе с обязательным фармом кармы: тренироваться теперь негде, а сразу писать статью страшно. Ну мне, например, после возврата, страшно было...
SlFed
12.08.2026 08:06Добавлю. Еще важен уровень комментария в диалоге. Коммент который находится на первом уровне, набирает больше лайков, чем коммент отвечающий на другой коммент.
k41n Автор
12.08.2026 08:06Проверил на данных - вы правы, и этого фактора в статье нет, спасибо. Сырые цифры по глубине вложенности:
уровень 0 (корневой): 55.6% в плюсе, средний 2.71 уровень 1: 48.9%, 2.03 уровень 2: 43.5%, 1.34 уровень 3: 38.6%, 1.18 уровень 4 и глубже: 33.7%, 0.83
Но тут та же ловушка, что и с временем суток, поэтому сразу проверил на свежих комментариях, моложе трех часов: 5.36 у корневых, 4.29 на первом уровне, 3.47 на втором. Разрыв остается, но заметно ужимается - значит бОльшая часть сырой разницы это опять свежесть и позиция, которые прячутся за глубиной. Ответ по определению приходит позже того, на что отвечает.
Механика, судя по всему, простая: корневой комментарий видят все, кто открыл статью, а ответ на пятом уровне - только те, кто дочитал ветку. Читателей меньше, голосов меньше.
SlFed
12.08.2026 08:06Да, конечно, удаленность от начала комментариев влияет гораздо больше чем уровень вложенности. Но вот что характерно, когда я пишу этот комментарий, у всех комментов первого уровня стоят лайки, и только у 3 из 12 следующих уровней есть лайки.
k41n Автор
12.08.2026 08:06Это потому что я пока тут сижу и всем кто мою статью заметил и комментирует в награду лайк отсыпаю :)
TsarS
Первый комментарий!
k41n Автор
Четыре минуты и первая позиция - вы только что собрали лучший из возможных раскладов по моей же статье. Осталось выяснить, работает ли она.
exTvr
Чуть дополнил.
k41n Автор
Проверил, любопытно вышло: риск-то как раз не подтверждается. Первые в треде короткие однострочники (меньше 60 знаков, тексты я не хранил, так что мерил длиной) набирают в среднем 4.38 плюса против 3.59 у развернутых, и в минусе оба варианта одинаково редко, около 4%.
А вот в общей массе, не на первой позиции, короткие ощутимо хуже длинных: 38.7% в плюсе против 47.1%. То есть однострочник наказывается везде, кроме одного места - самого начала треда. Похоже, позиция вытягивает даже “Первый комментарий!”, и в этом есть своя жестокая справедливость. Видимо, многие из нас ещё помнят олбанскей.