СводкаГлавные показатели канала за выбранный период. Изменение — к такому же отрезку перед периодом, если за него есть статистика. Наведите на диаграмму плитки, чтобы увидеть число в каждой точке периода.
Главные числа
ПодписчикиСколько подписчиков у канала сейчас. Волна — число подписчиков в каждой точке периода. Изменение — к началу периода.3 026▲ 1,3 %+39 за период
ПросмотрыСколько сейчас просмотров у постов, вышедших за период. Это не просмотры за день: сколько посмотрели вчера, MAX не сообщает.320▼ 90,3 %было 3 789
РеакцииСколько реакций у постов, вышедших за период.5▼ 80,8 %было 30
УпоминанияСколько раз канал упомянули другие каналы: ссылки и репосты, без рекламных постов. Чем крупнее круг, тем больше упоминаний в этой точке периода.61▼ 17,2 %было 76по подписке
РепостыСколько раз другие каналы сделали репост постов этого канала (без рекламных постов). Репосты входят и в число упоминаний.28▲ 15,5 %было 25после входа
Средний охват постаСколько просмотров в среднем набирает один пост. Считаем по постам старше двух суток: у свежих просмотры ещё растут. Точки, где есть свежие посты, — пунктиром и полыми кружками: охват всех постов на сейчас, он ещё вырастет.—просмотров на пост
ERRКакая доля подписчиков видит средний пост: средний охват ÷ подписчики × 100 %. Линия — ERR в каждой точке периода, пунктир — ERR прошлого такого же периода. Точки с постами моложе двух суток — полые кружки на пунктирном конце линии.—подписчиков видят пост
Вовлечённость ERКак часто читатели реагируют на посты: реакции ÷ просмотры × 100 %. Засечка на полосе — прошлый период.1,56 %▲ 0,8 п. п.
было 0,79 %
Постов в деньСколько публикаций в среднем выходит за день. Клетка — точка периода: чем темнее, тем больше постов в день.0,1▼ 77,0 %было 0,7
Доля рекламыКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Шкала — рекламная нагрузка по порогам индекса качества: до 10 % — низкая, до 25 % — умеренная, до 50 % — высокая, дальше — очень высокая. Рост доли отмечается красным.4,2 %▲ 0,8 п. п.
ДинамикаСверху — число подписчиков на конец каждой точки периода, снизу — прирост за точку: зелёный — подписчиков стало больше, красный — меньше. Над графиком прироста — самый большой прирост и самая большая убыль. Сколько подписалось и отписалось по отдельности, MAX не сообщает.
Рост аудитории
+39подписчиков за период
+10 самый большой прирост · 15 окт 2026
Оценка каналаОценка канала от 0 до 100 из пяти частей: аудитория, честность роста, рекламная нагрузка, доверие и достоверность расчёта. Полоса — сколько баллов часть набрала из своего максимума. Индекс пересчитывается каждую ночь; каналы сравниваются с похожими — той же категории и размера.
IT и программирование, 1–5 тыс. подписчиков · каналов в группе: 39
ОхватыСколько сейчас просмотров у постов, вышедших в каждой точке периода (а не просмотры за день). Подписан рекорд; точка с сегодняшним днём бледнее — день ещё идёт. Средний охват поста — по постам старше двух суток.
Просмотры и охват
320просмотров за период▼ 90,3 %
ВовлечённостьER — реакции, делённые на просмотры, в процентах — у постов каждой точки периода. Пунктир — ER за весь период. Изменение — в процентных пунктах к прошлому такому же периоду.
Вовлечённость подписчиков
1,56 %ER = реакции ÷ просмотры▲ 0,8 п. п.
ER каналав среднем за период
ЦитируемостьИндекс цитируемости (ИЦ) — насколько часто и какими каналами упоминают этот канал за последние 30 дней, без рекламных постов. Уровень — место среди похожих каналов. Линия — ИЦ в каждой точке периода (в неделе и месяце — средний за её дни).
РитмСколько постов в среднем выходит в каждый час каждого дня недели, время московское: чем темнее клетка, тем больше публикаций. «Лучшее время» — часы, в которые у постов старше двух суток самый высокий средний охват.
Когда и сколько публикует
ПнВтСрЧтПтСбВс
036912151821
Лучшее время:09:0018:00часы, в которые у постов самый высокий средний охват
ФорматыИз чего состоит лента. У каждого поста один формат — по старшинству: репост, видео, фото, ссылка, текст. Полоса и проценты — доля постов формата; справа — средний охват одного поста формата (по постам старше двух суток), полоска — сравнение с самым просматриваемым форматом.
ПубликацииКаждая точка — пост за период: по горизонтали — дата выхода, по вертикали — просмотры, размер точки — реакции, цвет — формат. Так видно хиты, провалы и то, как меняется охват. У крупных каналов показаны 100 самых просматриваемых постов и равномерная выборка остальных — не больше 1 500 точек.
Каждый пост — точка
Выше — больше просмотров, крупнее — больше реакций. Нажмите на точку, чтобы открыть пост.
ВидеоФотоДругоеразмер — реакцииПриближение — кнопками «+» и «−», щипком или Ctrl + колесо мыши; приближенный график сдвигается перетаскиванием
СводкаИтоги выбранного периода: сколько вышло публикаций, сколько у них сейчас просмотров и реакций и средний охват поста. Просмотры — текущие у постов, вышедших в эти дни, а не просмотры за день. Изменение — к такому же отрезку перед периодом, если за него есть статистика.
Итоги периода
Нажмите на показатель — ниже он появится по точкам периода
Просмотрысегодня — день ещё идётТочки с постами моложе двух суток — бледные с пунктиром: их просмотры ещё растут.
РекламаКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Детектор осторожный, поэтому настоящая доля обычно выше. Шкала — рекламная нагрузка по порогам индекса качества. Ниже — средний охват рекламного и обычного поста и кого рекламирует канал (сайты, на которые ведут ссылки из рекламы).
Что работаетПосты периода с наибольшим числом просмотров. Полоса — просмотры относительно первого места. Превью — картинка поста, у поста без картинки — аватар канала. Просмотры — сколько у поста сейчас.
РитмСколько постов вышло в каждый день периода (бледные столбики) и среднее за 7 дней (линия): видно, разгоняется канал или затихает. Сегодняшний день ещё идёт, поэтому среднее для него считается по вчерашний день.
Публикации по дням
Бледные столбики — дни, линия — среднее за 7 дней: видно, разгоняется канал или затихает
Публикации за деньСреднее за 7 дней
Данные обновлены в 02:07 по Москве. Просмотры — текущие у постов, вышедших в эти дни; средний охват — по постам старше двух суток.
Как считается индекс качества
⚡️ Индексы в базах данных: как заставить запросы летать
Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.
Как это работает под капотом? Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.
✅ Зачем нужны:
* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз. * Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).
❌ Чем платим (минусы):
* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс. * Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.
🛠 Чек-лист: индексировать или нет?
🟢 Обязательно индексируем:
1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY. 2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически. 3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).
🔴 НЕ индексируем:
1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс). 2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен). 3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.
💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.
🦾 LLM умеют генерировать тексты, отвечать на вопросы и работать с документами. Но чтобы использовать их в реальных задачах, важно понимать, как модели принимают решения и почему иногда дают неожиданный результат.
🚀 На открытом уроке разберём, как устроены большие языковые модели и как применять эти знания на практике. Вы узнаете:
— как модель выбирает слова и формирует ответ; — как развернуть LLM локально и проверить её работу через API; — как модели используют контекст из документов и почему это важно для RAG-систем.
Урок подойдет начинающим разработчикам, аналитикам и менеджерам продукта, которые хотят понимать ИИ глубже и использовать его в рабочих задачах. Открытый урок проходит в преддверии старта курса «LLM-инженер».
📋 27 октября в 20:00 МСК. ➡️ Все участники получат скидку на обучение. Принять участие: https://vk.cc/d2Romz
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
– Дублирование данных — имя клиента повторяется в каждом заказе. – Нет масштабируемости — максимум 2 продукта? А если будет 3? – Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи. – Адские апдейты — изменить email клиента надо во всех заказах.
✅ Как правильно:
1. Нормализуй. Раздели данные на сущности: customers, orders, products, order_items. 2. Используй внешние ключи. 3. Не бойся JOIN'ов — они для этого и придуманы.
Пример нормализованной структуры:
-- Таблица клиентов CREATE TABLE customers ( id SERIAL PRIMARY KEY, name TEXT, email TEXT );
-- Таблица заказов CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT REFERENCES customers(id) );
-- Таблица товаров CREATE TABLE products ( id SERIAL PRIMARY KEY, name TEXT, price NUMERIC );
-- Связка товаров и заказов CREATE TABLE order_items ( order_id INT REFERENCES orders(id), product_id INT REFERENCES products(id), quantity INT );
📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.
Сохрани, чтобы не забыть — и не повторять чужих ошибок.
🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД
Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё. Спойлер: потом будет больно.
Вот как этого избежать 👇
1. Начинай с нормализации – Смотри, какие поля повторяются. – Разделяй по сущностям: клиент ≠ заказ ≠ товар. – Нормальные формы — не академикам, а тебе на пользу.
2. Определи связи заранее – Один ко многим? Многие ко многим? – Используй FOREIGN KEY, чтобы база помогала тебе, а не мешала.
3. Не бойся JOIN-ов – Да, их становится больше. – Но это лучше, чем сотни NULL - ов и "status_1", "status_2" в одной колонке.
4. Планируй под рост – Временные костыли становятся постоянными. – Заложи масштабируемость: разнос сущностей, отдельные таблицы для логов, истории, связей.
5. Назначь ID-шки как бог велел – PRIMARY KEY + автоинкремент или UUID. – Не делай email или name ключом — это путь в баги.
🧠 Помни: хорошо спроектированная схема ускоряет разработку, а не тормозит её. А переделывать схему сложнее, чем сделать нормально с самого начала.
Когда бизнес-логика усложняется, а структура БД остаётся в духе Excel — жди беды.
🔴 Что это такое? Проектировщик (часто на раннем этапе) создаёт одну большую таблицу, где: – сотни колонок на все случаи жизни, – куча NULL-ов, – смешаны данные разных сущностей (например, и клиенты, и заказы, и статусы).
Так проще… пока не начнётся работа с реальными данными.
💥 Что пойдёт не так: – Производительность падает: индексы не работают эффективно. – Сложность валидации и бизнес-логики. – Трудно расширять: каждое изменение — как операция на открытом сердце. – Нельзя нормально нормализовать: всё связано со всем.
✅ Как избежать: – Используй нормализацию: выноси повторяющиеся и логически независимые данные в отдельные таблицы. – Не бойся JOIN-ов — это не зло, а инструмент. – Планируй схему БД под задачи, а не наоборот.
CREATE TABLE orders ( id SERIAL PRIMARY KEY, order_date VARCHAR(20) );
На первый взгляд — всё ок: дата есть, строка хранит. Но на практике — сплошные проблемы:
🔴 Нет гарантии формата '2024-12-01', '12/01/2024', '01.12.24', 'вчера' — всё ляжет, но работать с этим потом боль.
🔴 Сложность фильтрации и сортировки Сравнение строк ≠ сравнение дат. Запросы типа WHERE order_date > '2024-01-01' могут вести себя непредсказуемо. 🔴 Нельзя использовать функции времени Ни DATE_TRUNC, ни AGE(), ни агрегаты по времени не работают нормально с VARCHAR.
✅ Как правильно Используйте типы DATE, TIMESTAMP, TIMESTAMPTZ — они:
* валидируют данные на вставке; * дают мощный инструментарий для анализа; * упрощают работу с часовыми поясами и интервалами.
CREATE TABLE orders ( id SERIAL PRIMARY KEY, order_date TIMESTAMPTZ DEFAULT now() );
💡 Если данные приходят в виде строк — парси их при загрузке, а не храни как есть.
🔎 Мини-гайд: Индексы в PostgreSQL — быстро и по делу
Индексы — главный инструмент для ускорения запросов. Но неправильное использование может только навредить.
Основные типы индексов в PostgreSQL: - B-tree — по умолчанию. Идеален для поиска по равенству и диапазону (=, <, >, BETWEEN). - Hash — только для поиска по точному равенству (=). Становится актуальным реже. - GIN — для массивов, JSONB, полнотекстового поиска. - GiST — геоданные, поиск по диапазонам, сложные типы. - BRIN — для очень больших таблиц с упорядоченными данными (например, логи).
Практические советы: - Не злоупотребляй индексами: каждый индекс замедляет INSERT/UPDATE/DELETE. - Следи за актуальностью: периодически проверяй и удаляй неиспользуемые (pg_stat_user_indexes поможет). - Составные индексы ((col1, col2)) эффективны, только если условия WHERE учитывают порядок колонок. - Используй EXPLAIN ANALYZE, чтобы понять, работает ли индекс в реальности.
Типичная ошибка: Создать индекс на всё подряд без анализа запросов. Итог — тормоза на записи и огромный размер базы.
✅ Индексы — это как специи: мало — пресно, много — несъедобно.
Вывод: Хотите быструю базу — планируйте индексацию так же внимательно, как сами запросы.
Сегодня я хочу рассказать вам про одну часто недооцененную фишку в PostgreSQL - partial indexes (частичные индексы).
Обычно мы создаём индексы на всю таблицу, но что если нам нужно ускорить только небольшую часть данных? Например, часто выбираются только активные пользователи (status = 'active'). Вместо полного индекса можно создать индекс только для нужного поднабора данных:
CREATE INDEX idx_active_users ON users (last_login) WHERE status = 'active';
Что это даёт: - Индекс меньше по размеру → быстрее поиск и обновление. - Используется только тогда, когда запрос соответствует условию status = 'active'. - Меньше нагрузка на диск при обновлениях таблицы.
🛠 Где это реально помогает: - Таблицы с миллионами записей, где активно работают только с частью строк. - Сценарии "горячих" и "холодных" данных.
Рекомендую попробовать partial indexes там, где обычные индексы слишком тяжелы или тормозят обновления!
