СводкаГлавные показатели канала за выбранный период. Изменение — к такому же отрезку перед периодом, если за него есть статистика. Наведите на диаграмму плитки, чтобы увидеть число в каждой точке периода.
Главные числа
ПодписчикиСколько подписчиков у канала сейчас. Волна — число подписчиков в каждой точке периода. Изменение — к началу периода.6▼ 14,3 %−1 за период
ПросмотрыСколько сейчас просмотров у постов, вышедших за период. Это не просмотры за день: сколько посмотрели вчера, MAX не сообщает.9▼ 51,3 %было 19
РеакцииСколько реакций у постов, вышедших за период.1▼ 48,6 %было 2
УпоминанияСколько раз канал упомянули другие каналы: ссылки и репосты, без рекламных постов. Чем крупнее круг, тем больше упоминаний в этой точке периода.58▼ 18,9 %было 72по подписке
РепостыСколько раз другие каналы сделали репост постов этого канала (без рекламных постов). Репосты входят и в число упоминаний.26▼ 3,1 %было 27после входа
Средний охват постаСколько просмотров в среднем набирает один пост. Считаем по постам старше двух суток: у свежих просмотры ещё растут. Точки, где есть свежие посты, — пунктиром и полыми кружками: охват всех постов на сейчас, он ещё вырастет.4▼ 76,3 %было 19
ERRКакая доля подписчиков видит средний пост: средний охват ÷ подписчики × 100 %. Линия — ERR в каждой точке периода, пунктир — ERR прошлого такого же периода. Точки с постами моложе двух суток — полые кружки на пунктирном конце линии.75,0 %▼ 196,4 п. п.пунктир — было 271,4 %
Вовлечённость ERКак часто читатели реагируют на посты: реакции ÷ просмотры × 100 %. Засечка на полосе — прошлый период.11,11 %▲ 0,6 п. п.
было 10,53 %
Постов в деньСколько публикаций в среднем выходит за день. Клетка — точка периода: чем темнее, тем больше постов в день.0,3▲ 105,5 %было 0,1
Доля рекламыКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Шкала — рекламная нагрузка по порогам индекса качества: до 10 % — низкая, до 25 % — умеренная, до 50 % — высокая, дальше — очень высокая. Рост доли отмечается красным.2,5 %▼ 1,8 п. п.
ДинамикаСверху — число подписчиков на конец каждой точки периода, снизу — прирост за точку: зелёный — подписчиков стало больше, красный — меньше. Над графиком прироста — самый большой прирост и самая большая убыль. Сколько подписалось и отписалось по отдельности, MAX не сообщает.
Рост аудитории
−1подписчиков за период
−1 самая большая убыль · 13 окт 2026
Оценка каналаОценка канала от 0 до 100 из пяти частей: аудитория, честность роста, рекламная нагрузка, доверие и достоверность расчёта. Полоса — сколько баллов часть набрала из своего максимума. Индекс пересчитывается каждую ночь; каналы сравниваются с похожими — той же категории и размера.
Индекс качества пока не рассчитан. Он появляется у каналов от 500 подписчиков, которые публикуют посты хотя бы раз в неделю, после недели наблюдения.
ОхватыСколько сейчас просмотров у постов, вышедших в каждой точке периода (а не просмотры за день). Подписан рекорд; точка с сегодняшним днём бледнее — день ещё идёт. Средний охват поста — по постам старше двух суток.
Просмотры и охват
9просмотров за период▼ 51,3 %
Средний охват поста — 4 просмотров (посты старше двух суток).
ВовлечённостьER — реакции, делённые на просмотры, в процентах — у постов каждой точки периода. Пунктир — ER за весь период. Изменение — в процентных пунктах к прошлому такому же периоду.
Вовлечённость подписчиков
11,11 %ER = реакции ÷ просмотры▲ 0,6 п. п.
ER каналав среднем за период
ЦитируемостьИндекс цитируемости (ИЦ) — насколько часто и какими каналами упоминают этот канал за последние 30 дней, без рекламных постов. Уровень — место среди похожих каналов. Линия — ИЦ в каждой точке периода (в неделе и месяце — средний за её дни).
Индекс цитируемости пока не рассчитан: он появится после ночного расчёта, когда канал упомянут другие каналы.
РитмСколько постов в среднем выходит в каждый час каждого дня недели, время московское: чем темнее клетка, тем больше публикаций. «Лучшее время» — часы, в которые у постов старше двух суток самый высокий средний охват.
Когда и сколько публикует
ПнВтСрЧтПтСбВс
036912151821
Лучшее время:09:0018:00часы, в которые у постов самый высокий средний охват
ФорматыИз чего состоит лента. У каждого поста один формат — по старшинству: репост, видео, фото, ссылка, текст. Полоса и проценты — доля постов формата; справа — средний охват одного поста формата (по постам старше двух суток), полоска — сравнение с самым просматриваемым форматом.
ПубликацииКаждая точка — пост за период: по горизонтали — дата выхода, по вертикали — просмотры, размер точки — реакции, цвет — формат. Так видно хиты, провалы и то, как меняется охват. У крупных каналов показаны 100 самых просматриваемых постов и равномерная выборка остальных — не больше 1 500 точек.
Каждый пост — точка
Выше — больше просмотров, крупнее — больше реакций. Нажмите на точку, чтобы открыть пост.
ВидеоФотоДругоеразмер — реакцииПриближение — кнопками «+» и «−», щипком или Ctrl + колесо мыши; приближенный график сдвигается перетаскиванием
СводкаИтоги выбранного периода: сколько вышло публикаций, сколько у них сейчас просмотров и реакций и средний охват поста. Просмотры — текущие у постов, вышедших в эти дни, а не просмотры за день. Изменение — к такому же отрезку перед периодом, если за него есть статистика.
Итоги периода
Нажмите на показатель — ниже он появится по точкам периода
Просмотрысегодня — день ещё идётТочки с постами моложе двух суток — бледные с пунктиром: их просмотры ещё растут.
РекламаКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Детектор осторожный, поэтому настоящая доля обычно выше. Шкала — рекламная нагрузка по порогам индекса качества. Ниже — средний охват рекламного и обычного поста и кого рекламирует канал (сайты, на которые ведут ссылки из рекламы).
Что работаетПосты периода с наибольшим числом просмотров. Полоса — просмотры относительно первого места. Превью — картинка поста, у поста без картинки — аватар канала. Просмотры — сколько у поста сейчас.
РитмСколько постов вышло в каждый день периода (бледные столбики) и среднее за 7 дней (линия): видно, разгоняется канал или затихает. Сегодняшний день ещё идёт, поэтому среднее для него считается по вчерашний день.
Публикации по дням
Бледные столбики — дни, линия — среднее за 7 дней: видно, разгоняется канал или затихает
Публикации за деньСреднее за 7 дней
Данные обновлены в 19:30 по Москве. Просмотры — текущие у постов, вышедших в эти дни; средний охват — по постам старше двух суток.
Как считается индекс качества
тельность, надёжность, безопасность. Вспоминают о них, когда система падает. - Передача требований без контекста. Вендор не знает ваш процесс. Приложите схему BPMN и регламент.
Как это связано с генеральной линией
Наша генеральная линия: сначала процесс — потом автоматизация. Управление требованиями — это мост между процессом и системой. Если процесс описан, требования вытекают из него естественно. Если процесса нет, требования превращаются в список хотелок, а система — в лоскутное одеяло.
Не автоматизируйте бардак. Опишите процесс, оптимизируйте, регламентируйте. Затем соберите требования. И только после этого выбирайте софт. Требования — это не формальность. Это способ убедиться, что система поддержит ваш порядок, а не создаст новый хаос.
Что должно быть готово до общения с вендором
- Описанный процесс «как должно быть» (BPMN или блок-схема). - Регламент и матрица согласования по ролям. - Реестр требований с приоритетами и критериями приёмки. - Список исключений и нестандартных ситуаций. - Понимание, какие требования критичны, а какие можно отложить.
С этим пакетом вы говорите с вендором на одном языке. Вы не просите «сделайте красиво», а показываете, что именно должна делать система.
Управление требованиями: как не потерять суть процесса при автоматизации
В прошлых материалах мы разобрали, почему нельзя автоматизировать бардак, как подготовиться к внедрению и зачем описывать процесс в BPMN. Но есть ещё один слой, который часто пропускают. Даже если процесс описан, а данные почищены, автоматизация может пойти не туда. Причина — требования. Точнее, их отсутствие, размытость или потеря связи с реальным процессом. Что такое требование и чем оно отличается от хотелки
Требование — это формализованное описание того, что система должна делать, вытекающее из процесса и потребностей бизнеса. Хотелка — это «сделайте красиво» или «как у конкурентов».
Пример: - Хотелка: «Хотим удобный интерфейс для закупщика». - Требование: «Закупщик должен видеть все заявки, срок согласования которых истекает сегодня, и иметь возможность отправить напоминание согласующему в один клик».
Требование проверяемо. Хотелку нельзя проверить. Классификация, которая помогает не утонуть: Функциональные — что система делает. «Система должна автоматически создавать заявку на основе данных MRP». «Система должна поддерживать параллельное согласование». Нефункциональные — как делает. «Время отклика при поиске позиции — не более 2 секунд». «Система должна поддерживать 50 одновременных пользователей». Бизнес-правила — ограничения из процесса. «Заявка на сумму свыше 100 000 рублей требует согласования финансового директора». «Закупка у единственного поставщика допускается только при наличии обоснования». Требования к данным — что должно быть в справочниках. «Код материала обязателен для всех позиций, кроме услуг». «Единица измерения выбирается из справочника, а не вводится вручную».
Если вы описали процесс в BPMN, многие требования уже видны: шлюзы становятся бизнес-правилами, дорожки — ролями и правами доступа, задачи — функциями системы.
Почему теряется суть процесса
Три главные причины. 1. требования собирают с менеджеров, а не с исполнителей. Руководитель скажет, как должно быть, но не всегда знает, как есть на самом деле. Закупщик расскажет, где реально застревает заявка. Спрашивайте всех, кто участвует в процессе. 2. требования пишут «на будущее», а не под текущий процесс. «Давайте сразу заложим возможность тендеров на 10 этапов». В итоге система становится сложной, а текущий процесс — не поддерживается. Сначала автоматизируйте то, что есть. Потом расширяйте. 3. требования не проверяют на полноту и непротиворечивость. Один отдел просит одно, другой — противоположное. Если это не выявить до внедрения, система будет метаться или не работать вовсе.
Как собирать требования: практический подход
Шаг 1. Возьмите процесс «как должно быть». Это ваша основа. Каждый шаг процесса — потенциальное требование.
Шаг 2. Проведите интервью с исполнителями. Не один общий воркшоп, а отдельно с каждой ролью. Вопросы: - Что вы делаете на этом шаге? - Какие данные вводите, откуда берёте? - Что вас замедляет или раздражает? - Что будет, если этот шаг не сделать? - Как вы понимаете, что всё готово?
Шаг 3. Зафиксируйте требования в едином реестре. Формат простой: Смотри рисунок.
Шаг 4. Проверьте на полноту. Пройдитесь по процессу и убедитесь, что для каждого шага есть требования. Не забудьте про исключения: возврат, отказ, срочная закупка, отмена.
Шаг 5. Согласуйте с участниками. Требования должны быть понятны и приняты теми, кто будет работать в системе. Иначе саботаж.
Шаг 6. Передайте вендору и проверьте. Не отдавайте требования «как есть» и не ждите, что вендор сам разберётся. Проговорите, как он их реализует. Попросите демонстрацию по каждому пункту.
Типичные ошибки
- Требования без приоритетов. Всё «важно». В итоге либо не делают ничего, либо делают всё, но плохо. - Требования без критериев приёмки. Как понять, что требование выполнено? «Система должна быть удобной» — не критерий. - Требования, которые противоречат процессу. Если процесс изменился, требования нужно обновить. Реестр — живой документ. - Игнорирование нефункциональных требований. Производи
