СводкаГлавные показатели канала за выбранный период. Изменение — к такому же отрезку перед периодом, если за него есть статистика. Наведите на диаграмму плитки, чтобы увидеть число в каждой точке периода.
Главные числа
ПодписчикиСколько подписчиков у канала сейчас. Волна — число подписчиков в каждой точке периода. Изменение — к началу периода.40,0 %+0 за период
ПросмотрыСколько сейчас просмотров у постов, вышедших за период. Это не просмотры за день: сколько посмотрели вчера, MAX не сообщает.17▲ 32,0 %было 13
РеакцииСколько реакций у постов, вышедших за период.1было 0
УпоминанияСколько раз канал упомянули другие каналы: ссылки и репосты, без рекламных постов. Чем крупнее круг, тем больше упоминаний в этой точке периода.58▼ 19,3 %было 72по подписке
РепостыСколько раз другие каналы сделали репост постов этого канала (без рекламных постов). Репосты входят и в число упоминаний.26▼ 3,5 %было 27после входа
Средний охват постаСколько просмотров в среднем набирает один пост. Считаем по постам старше двух суток: у свежих просмотры ещё растут. Точки, где есть свежие посты, — пунктиром и полыми кружками: охват всех постов на сейчас, он ещё вырастет.3▼ 21,5 %было 4
ERRКакая доля подписчиков видит средний пост: средний охват ÷ подписчики × 100 %. Линия — ERR в каждой точке периода, пунктир — ERR прошлого такого же периода. Точки с постами моложе двух суток — полые кружки на пунктирном конце линии.85,0 %▼ 23,3 п. п.пунктир — было 108,3 %
Вовлечённость ERКак часто читатели реагируют на посты: реакции ÷ просмотры × 100 %. Засечка на полосе — прошлый период.5,88 %
реакций на 100 просмотров
Постов в деньСколько публикаций в среднем выходит за день. Клетка — точка периода: чем темнее, тем больше постов в день.0,7▲ 68,3 %было 0,4
Доля рекламыКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Шкала — рекламная нагрузка по порогам индекса качества: до 10 % — низкая, до 25 % — умеренная, до 50 % — высокая, дальше — очень высокая. Рост доли отмечается красным.2,5 %▼ 0,9 п. п.
ДинамикаСверху — число подписчиков на конец каждой точки периода, снизу — прирост за точку: зелёный — подписчиков стало больше, красный — меньше. Над графиком прироста — самый большой прирост и самая большая убыль. Сколько подписалось и отписалось по отдельности, MAX не сообщает.
Рост аудитории
0подписчиков за период
Число подписчиков за период не менялось
Оценка каналаОценка канала от 0 до 100 из пяти частей: аудитория, честность роста, рекламная нагрузка, доверие и достоверность расчёта. Полоса — сколько баллов часть набрала из своего максимума. Индекс пересчитывается каждую ночь; каналы сравниваются с похожими — той же категории и размера.
Индекс качества пока не рассчитан. Он появляется у каналов от 500 подписчиков, которые публикуют посты хотя бы раз в неделю, после недели наблюдения.
ОхватыСколько сейчас просмотров у постов, вышедших в каждой точке периода (а не просмотры за день). Подписан рекорд; точка с сегодняшним днём бледнее — день ещё идёт. Средний охват поста — по постам старше двух суток.
Просмотры и охват
17просмотров за период▲ 32,0 %
Средний охват поста — 3 просмотров (посты старше двух суток).
ВовлечённостьER — реакции, делённые на просмотры, в процентах — у постов каждой точки периода. Пунктир — ER за весь период. Изменение — в процентных пунктах к прошлому такому же периоду.
Вовлечённость подписчиков
5,88 %ER = реакции ÷ просмотры
ER каналав среднем за период
ЦитируемостьИндекс цитируемости (ИЦ) — насколько часто и какими каналами упоминают этот канал за последние 30 дней, без рекламных постов. Уровень — место среди похожих каналов. Линия — ИЦ в каждой точке периода (в неделе и месяце — средний за её дни).
Индекс цитируемости пока не рассчитан: он появится после ночного расчёта, когда канал упомянут другие каналы.
РитмСколько постов в среднем выходит в каждый час каждого дня недели, время московское: чем темнее клетка, тем больше публикаций. «Лучшее время» — часы, в которые у постов старше двух суток самый высокий средний охват.
Когда и сколько публикует
ПнВтСрЧтПтСбВс
036912151821
Лучшее время:09:0018:00часы, в которые у постов самый высокий средний охват
ФорматыИз чего состоит лента. У каждого поста один формат — по старшинству: репост, видео, фото, ссылка, текст. Полоса и проценты — доля постов формата; справа — средний охват одного поста формата (по постам старше двух суток), полоска — сравнение с самым просматриваемым форматом.
ПубликацииКаждая точка — пост за период: по горизонтали — дата выхода, по вертикали — просмотры, размер точки — реакции, цвет — формат. Так видно хиты, провалы и то, как меняется охват. У крупных каналов показаны 100 самых просматриваемых постов и равномерная выборка остальных — не больше 1 500 точек.
Каждый пост — точка
Выше — больше просмотров, крупнее — больше реакций. Нажмите на точку, чтобы открыть пост.
ВидеоФотоДругоеразмер — реакцииПриближение — кнопками «+» и «−», щипком или Ctrl + колесо мыши; приближенный график сдвигается перетаскиванием
СводкаИтоги выбранного периода: сколько вышло публикаций, сколько у них сейчас просмотров и реакций и средний охват поста. Просмотры — текущие у постов, вышедших в эти дни, а не просмотры за день. Изменение — к такому же отрезку перед периодом, если за него есть статистика.
Итоги периода
Нажмите на показатель — ниже он появится по точкам периода
Просмотрысегодня — день ещё идётТочки с постами моложе двух суток — бледные с пунктиром: их просмотры ещё растут.
РекламаКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Детектор осторожный, поэтому настоящая доля обычно выше. Шкала — рекламная нагрузка по порогам индекса качества. Ниже — средний охват рекламного и обычного поста и кого рекламирует канал (сайты, на которые ведут ссылки из рекламы).
Что работаетПосты периода с наибольшим числом просмотров. Полоса — просмотры относительно первого места. Превью — картинка поста, у поста без картинки — аватар канала. Просмотры — сколько у поста сейчас.
РитмСколько постов вышло в каждый день периода (бледные столбики) и среднее за 7 дней (линия): видно, разгоняется канал или затихает. Сегодняшний день ещё идёт, поэтому среднее для него считается по вчерашний день.
Публикации по дням
Бледные столбики — дни, линия — среднее за 7 дней: видно, разгоняется канал или затихает
Публикации за деньСреднее за 7 дней
Данные обновлены в 22:24 по Москве. Просмотры — текущие у постов, вышедших в эти дни; средний охват — по постам старше двух суток.
Как считается индекс качества
ТЗ ещё согласовывается, а архитектура уже уточняется
Сегодня начинаем согласование технического задания с нашим первым коммерческим заказчиком.И параллельно вносим в документ изменения.
Причина — нашли новый вариант решения задачи аутентификации пользователей: связку MAX + Passkey. Для нашей платформы это важная часть архитектуры.Системой будут пользоваться родители, специалисты и координаторы.
При этом мы работаем с персональными данными, поэтому недостаточно просто придумать удобный способ входа. Нужно понять, как подтверждается личность пользователя, как он связывается со своей учётной записью, что происходит при смене устройства и как восстанавливается доступ.
Passkey интересен нам как технология входа без привычного пароля. А MAX рассматриваем как один из каналов взаимодействия пользователя с системой.
Но между «выглядит подходящим решением» и «можно включать в техническое задание» есть обязательный этап — проверка. Поэтому сегодня у нас ещё одна задача: регистрация нашего ООО в MAX как юридического лица, подготовка тестового бота и взаимодействие с технической поддержкой платформы.
Нужно выяснить, какие сценарии действительно поддерживаются API и что потребуется реализовать на нашей стороне. Это нормальная часть бизнес-анализа и проектирования.
Техническое задание не должно фиксировать красивую идею, техническая реализуемость которой ещё не подтверждена.
Сначала проверяем возможности и ограничения. Затем уточняем требования и согласовываем решение с заказчиком.
Иногда одна новая связка технологий заставляет пересмотреть целый раздел ТЗ. И лучше сделать это сейчас, чем обнаружить ограничения уже после разработки.
От технического решения — к коммерческому предложению
На этой неделе у нас появился ещё один небольшой, но важный этап в работе над платформой.
По программе в Ульяновске согласовали подготовленный нами технический документ и попросили оформить ответ в виде официального коммерческого предложения.
Казалось бы, что здесь сложного? Перенести описание функций и стоимость на бланк — и готово.
Но для нас коммерческое предложение начинается гораздо раньше. Сначала нужно разобраться в задачах организации, понять, как устроены её процессы, какие данные потребуется учитывать и что система должна делать.
Затем — определить, какие возможности уже предусмотрены общей архитектурой платформы, а какие потребуют отдельной настройки или разработки.
И только после этого можно обоснованно оценивать объём работ.
Особенно интересно это становится в проектах, где есть универсальная технологическая основа, но разные программы требуют собственной бизнес-логики.
Для Ульяновска, например, важны индивидуальные маршруты сопровождения, профили ребёнка и семьи, фиксация результатов и аналитика изменений.
Поэтому в коммерческом предложении важно разделить то, что предоставляет технологический партнёр, и то, что необходимо адаптировать под конкретную программу.
Сейчас нам предстоит оформить согласованные технические решения в официальный документ.
И это хороший пример того, что бизнес-анализ заканчивается не на схеме процесса или техническом задании.
Его результат должен быть понятен не только разработчику, но и человеку, который принимает решение о реализации проекта.
152-ФЗ — это не только про документы. Это ещё и про архитектуру.
Сейчас мы выбираем новую облачную инфраструктуру для нашей платформы.
И выясняется, что найти сервер с нужными характеристиками — далеко не вся задача. 🙂
Нам предстоит работать с данными семей и детей: анкетами, индивидуальными особенностями, результатами обследований, рекомендациями специалистов.
Часть этой информации может относиться к специальным категориям персональных данных.
А значит, ещё на этапе проектирования нужно учитывать требования 152-ФЗ «О персональных данных». Что это означает для разработчика?
Недостаточно поставить пароль на базу данных и выбрать российский дата-центр. Нужно заранее продумать: 🔹 Где и как будут храниться данные. 🔹 Кто и к какой информации получит доступ. 🔹 Как защищаются данные при передаче и хранении. 🔹 Как фиксируются действия пользователей. 🔹 Как организовать резервное копирование и восстановление. 🔹 Что происходит с данными, когда срок их хранения заканчивается.
И всё это влияет на архитектуру: структуру системы, роли пользователей, интеграции, инфраструктуру и процессы сопровождения.
Поэтому выбор облака для нас — не просто поиск нового хостинга.
Мы оцениваем, насколько выбранная инфраструктура позволит реализовать необходимые меры защиты и выполнить требования законодательства.
При этом сама по себе аренда сервера у российского провайдера ещё не делает систему соответствующей 152-ФЗ.
Соответствие складывается из технических решений, организационных мер и правильно оформленных процессов обработки данных.
Сейчас мы как раз на этапе такого выбора. Безопасность персональных данных — не функция, которую можно добавить в конце разработки. Её нужно закладывать в систему с самого начала.
В разработке не всё всегда идёт в той последовательности, которую красиво нарисовали в плане. 🙂
Первый этап нового проекта мы завершили: развернули базу данных, подготовили её структуру и заполнили справочники.
Следующий шаг — разворачивать уже собранные компоненты системы и проверять их совместную работу.
Но здесь у нас изменились инфраструктурные планы. От первоначально выбранного облака решили отказаться. Регистрация аккаунта у другого провайдера пока в процессе, а останавливать разработку из-за этого не хочется.
Поэтому рассматриваем временное решение — развернуть dev-среду на домашнем сервере.
И здесь важный момент. Мы не переносим туда готовую промышленную систему с реальными данными пользователей. Речь именно о среде разработки, где можно проверять код, соединять компоненты и отрабатывать взаимодействие с базой данных. А когда облачная инфраструктура будет готова, перенесём систему в целевую среду.
Собственно, для этого мы и стараемся отделять архитектуру приложения от конкретного места его размещения.
Система не должна зависеть от одного сервера настолько, чтобы его замена превращалась в новый проект.
Конечно, сам перенос тоже требует настройки и проверки. Но менять инфраструктуру — не то же самое, что переписывать всю бизнес-логику.
Так что сегодня у нас в планах не новые кнопки и интерфейсы, а вполне практичная задача: подготовить временную среду для продолжения разработки.
Иногда движение проекта вперёд выглядит именно так. 🙂
Одна платформа. Две программы. Разная логика работы.
Сегодня у нас снова день бизнес-анализа. 🙂
Грантовый специалист заказчика прислала два документа с вопросами о цифровизации и технологическом партнёрстве.
Один — для проекта в Пятигорске, второй — для Ульяновска.
Казалось бы, организация одна, технологическая платформа тоже одна. Можно подготовить универсальное описание и немного адаптировать формулировки. Но нет. 😄
За двумя грантовыми программами стоят разные процессы.
В Пятигорске основной акцент — на сопровождении семьи: первичное обращение, анкетирование, цифровой помощник мамы, расписание, напоминания и история участия в программах.
В Ульяновске задача шире в части диагностики и аналитики: отдельные профили ребёнка и семьи, индивидуальные маршруты, фиксация пройденных этапов, повторные обследования и оценка динамики.
Поэтому мы готовили два самостоятельных ответа. Разбирали, какие функции нужны каждой программе, какие компоненты можно использовать из общего ядра платформы, а какие потребуют индивидуальной настройки.
Отдельно проработали модель технологического партнёрства: базовая платформа предоставляется как вклад партнёра, а грантовые средства предполагается направлять на адаптацию и внедрение под конкретную программу, развертывание инфраструктуры
И здесь хорошо видно, зачем мы изначально проектируем систему модульной.
Не нужно создавать отдельный программный продукт для каждой новой задачи. Но и заставлять разные организации и программы работать по одному жёсткому сценарию тоже неправильно. Общая технологическая основа. Разные процессы. Разная конфигурация. Именно так мы и хотим развивать SmartFlow.
