[drive-download] ТОМ SSOT v1.docx

Google Docs neutral 2026-04-11 10 чанков ~13 мин чтения

Сущности

SSI ТВ EI MVP digital-first ТОМ SSOT Контур БД ТВ+ offline-first Primary Риск-контур Страта Страта Digital / Broadcast (ТВ-радио) / Field Primary-канал Primary-страта

ТОМ SSOT v1.0 (Единый стандарт стратификации, контуров, учёта достижимости и Effective Impact) Версия: 1.0 (операционная) Контур: внутренний инструмент штаба (узкий круг) Назначение: стандартизировать планирование/доставку коммуникаций по стратам и регионам; обеспечить управляемость и защищаемость решений (“как считали”) в период до дня референдума и в ретроспективе. Оглавление Общие положения Ключевые определения и модель SSOT Стратификация (42 страты) и укрупнение (6 страт для управления) Контуры каналов и правило “Primary” Метрика Effective Impact (EI): формула, порядок расчёта, интерпретация Управленческие правила применения SSOT/EI Операционный цикл штаба (ритм, роли, ежедневная записка) Риск-контур: SSI (индекс устойчивости), триггеры, стресс-тест “идеальный шторм” (MVP) Данные и архитектура: модель БД, источники, ретроспектива Приложения (таблицы для печати) Общие положения 1.1. Проблема, которую решает SSOT В госуправлении коммуникации часто ведутся как “перечень мероприятий” и выпусков материалов. Это создаёт иллюзию управляемости (“ресурсы есть, эфир есть, отчёты есть”), но не отвечает на главный управленческий вопрос: какие слои населения реально охвачены, какими каналами, с каким ожидаемым воздействием, и где остаются “слепые зоны”. В условиях референдума эта проблема превращается в риск результата и в риск управленческой незащищённости. SSOT вводит дисциплину: от “мероприятий” → к “достижимости слоёв” → к “управляемому влиянию” → к “доказуемости решений”. 1.2. Принцип «не ломаем старое — добавляем контур управления» SSOT не отменяет существующие форматы (ТВ, радио, встречи, публикации). SSOT добавляет над ними слой управления: целевая страта (Primary), контур канала, ожидаемый EI, и фиксация слепых зон. 1.3. Статус документа Это операционный стандарт штаба. Он может быть “пилотным” по формулировке (чтобы не включать аппаратную защиту), но фактически используется как единая методика. Ключевые определения и модель SSOT 2.1. SSOT (Single Source of Truth) в коммуникациях SSOT — это единая “карта реальности”, где любые действия планируются и учитываются в общих координатах: страта (кто) регион/тип среды (где) контур/канал (через что) ожидаемое воздействие (EI) факт исполнения и отклика (что получилось) 2.2. Страта Страта — минимальная управляемая единица аудитории, определяемая: возрастом, типом медиапотребления (A/B/C), локацией (город/село). В SSOT v1.0 — 42 страты (7 возрастных слоёв × 3 типа × 2 локации). 2.3. Типы медиапотребления (A/B/C) A — digital-first (цифровые) B — hybrid (смешанные) C — offline-first (офлайн-ориентированные) 2.4. Контур Контур — класс каналов доставки: Digital / Broadcast (ТВ-радио) / Field (встречи, обходы) / Messenger (WhatsApp/Telegram как отдельная “вертикаль”) / Institutional (госорганизации, бюджетные сети). В v1.0 допускается укрупнение до 3 контуров: Digital / Mass / Field, но мессенджеры лучше держать отдельным контуром как ключ к “закрытым сетям”. 2.5. Primary-страта и Primary-канал Любая активность обязана иметь Primary-страту (одну) и Primary-канал/контур (один). Всё остальное — вторичное/фоновое. Правило: если Primary-страта не назначена — активность считается “фоновой” и не может быть защищена как инструмент достижения результата. Стратификация и укрупнение 3.1. Полная модель: 42 страты Полный перечень и принципы кодировки (S1…S7 × A/B/C × U/R) у вас уже оформлен как таблица страт для планирования (в том числе языковые профили и операционные режимы по отдельным стратам). 3.2. Управленческое укрупнение: 6 страт для ежедневного управления Чтобы руководству и штабной оперативке не тонуть в 42 строках, вводим “управленную проекцию” — 6 укрупнённых страт: U1: 18–24 город (ядро цифровой повестки) U2: 25–40 город (ядро “активного населения”, ключ к массовой достижимости) U3: 41–55 город (ядро устойчивости/скепсиса, важна доказуемость и спокойный тон) U4: 56+ город (легитимация, ТВ+мессенджеры, снижать тревогу) R5: 25–55 село (главный слой полевой достижимости, сильный эффект от “человеческих” каналов) R6: 56+ село (самая чувствительная к уважению и офлайн-каналам группа, требует отдельного пакета) Примечание: это не отменяет 42-слойную модель. Это “панель приборов”. 3.3. Операционные карточки страт (что входит) Для каждой из 42 страт карточка обязана содержать: Идентификатор и профиль Языковой профиль Цель работы (что меняем: доверие/явка/снятие тревоги/объяснение) Канальная стратегия: основные и вторичные Сообщения и фрейминг (“говорить / не говорить”) Операционный режим (частота касаний, режимы Normal/Attention/Stress) Чек-лист качества Эта структура у вас уже фактически задана на примерах (например, S4-A-U, S5-C-R, S6-A-R). Контуры каналов и правило “функционального распределения” 4.1. Ключевой принцип для госресурсов Поскольку “деньги” как аргумент в аппарате часто не работают (“ресурсы государства и так есть”), SSOT вводит другой язык: КПД госмощностей = достижимость нужных страт. То есть мы не спорим “дорого/дёшево”. Мы фиксируем: “этот ресурс функционально закрывает вот эти слои; вот эти — нет”. 4.2. Функциональное распределение (матрица 6×3) Управленческая матрица (для печати на 1 странице): Контуры: Digital (таргет, соцсети, онлайн-медиа) Mass (ТВ/радио/наружка как фон) Field+Messenger (встречи/сходы/обход + упаковка в WhatsApp/Telegram) Правило: Mass = легитимация и спокойное объяснение (особенно 56+) Digital = охват активного ядра и сомневающихся в городах (18–40 / 25–40) Field+Messenger = “закрытие слепых зон” по селу и старшим Метрика Effective Impact (EI) 5.1. Формула EI = Reach × InfluenceCoef × Retention × Weight Смысл: EI — не “точная наука”, а стандартизированный способ сравнить альтернативы и выявить дублирование. EI считается “в порядке величины” (низкий/средний/высокий), чтобы управленчески принимать решения быстро. 5.2. Reach (достижимость) — базовые модели по контурам Digital Reach: N_pop × K_online × k_active × reach_rate TV/Radio Reach: N_pop × reach_rate Встречи Reach: Contacts × retransmission_factor (если есть “вертикаль” мессенджер-ретрансляции) 5.3. Компоненты EI: управленческие определения N_pop: численность страты в регионе K_online: доля страты с доступом к интернету (по региону/типу A/B/C) k_active: доля реально активных пользователей (не “имеют смартфон”, а “потребляют контент”) reach_rate: доля, которую конкретная активность может достать (кампания/эфир/встреча) InfluenceCoef: коэффициент влияния канала на данную страту (условно: доверяют/не доверяют; “может сдвинуть”) Retention: удержание/повторяемость (однократное касание vs серия) Weight: вес страты в задаче (например, по важности явки/легитимации/устойчивости) 5.4. Практическая интерпретация (как говорить на совещании) EI — это “паспорт управляемости”: почему мы делаем именно это; на кого это направлено; почему этот канал здесь Primary; где мы сознательно НЕ тратим внимание. Управленческие правила применения SSOT/EI 6.1. Обязательные атрибуты каждой активности Каждая активность должна иметь: Primary-страту, контур, ожидаемый EI. 6.2. Правило “слепой зоны” Страта без Primary-канала = слепая зона. Слепая зона должна закрываться “догоняющим пакетом” (список действий на 7–10 дней) либо формально фиксироваться как “принятый риск”. 6.3. Правило “дублирования” Если две активности бьют в одну и ту же Primary-страту одним и тем же контуром, а прирост Reach незначителен — это дублирование. Решение: либо объединить, либо перераспределить в слепую зону. 6.4. Аппаратно-безопасная рамка Запрещены формулировки “раньше считали неправильно”. Разрешённая рамка: “добавили слой управленческого учёта достижимости; обновили инструмент под текущую медиареальность”. Операционный цикл штаба 7.1. Минимальный ритм (MVP, без бюрократии) 08:30–08:45 “Сверка приборов”: SSI/тональность/слепые зоны за сутки 13:30–13:45 “Контент-чекап”: что упаковано под приоритетные страты (6 укрупнённых) 19:00–19:10 “Прогноз на завтра”: что меняем в Primary-стратах/контурах 7.2. Ежедневная записка в 5 строк (шаблон) SSI сегодня: (зел/жёлт/красн) + что изменилось за сутки Слепые зоны: 1–2 страты/региона, где недобор Reach Риск-сигналы: 1–2 темы/триггера (где растёт перегрев/скепсис) Решения на 24 часа: 2–3 действия (перераспределение контента/каналов) Что просим у руководства: 1 решение (санкция на пилот/перенастройку) 7.3. Роли (минимально необходимое распределение) Опер-аналитик SSOT (дежурный): собирает факты, считает EI “в порядке величины” Куратор контуров (Digital / Mass / Field+Messenger): обеспечивает доставку Куратор страт (6 укрупнённых): следит за “слепыми зонами” Тех-куратор (SSOT DB): загрузки, качество данных, витрины Риск-контур: SSI, триггеры, стресс-тест 8.1. SSI (System Stability Index) — смысл SSI — агрегированный показатель устойчивости кампании как системы доставки: “не перегрели ли лояльных”, “не оставили ли ключевые слои в вакууме”, “не потеряли ли управляемость”. В MVP SSI можно считать как взвешенную сумму трёх индексов: CoverageGap (слепые зоны) Overheat (перегрев/каннибализация) Volatility (волатильность тональности/сигналов) 8.2. Триггеры (простые правила) CoverageGap: если 2 дня подряд страта из U2/R5/R6 без Primary-доставки → “догоняющий пакет” Overheat: если рост негативных маркеров в лояльной страте при высокой частоте касаний → stop-loss на 24 часа в этом контуре Volatility: если за сутки резкий скачок негативных сигналов в одном регионе при стабильности по стране → региональный протокол 8.3. Стресс-тест “идеальный шторм” (MVP) Цель: проверить устойчивость SSOT-процесса, а не “политический результат”. Сценарий (одновременно): отказ SSOT/данных (нет обновления витрин 24 часа) 10 параллельных локальных инцидентов (S3-уровень) дисциплинарный кризис (задержка подтверждений/решений) Проверяем: где ломается принятие решений; какие минимальные данные нужны для восстановления; какие решения можно принимать “по укрупнению 6 страт”, не теряя управляемость. Данные и архитектура: модель БД, источники, ретроспектива 9.1. Что нужно хранить (SSOT как база для ретроспективы) Справочники: регионы, страты, каналы, контуры Коэффициенты: K_online, k_active, influence, retention, веса (в разрезе страт/регионов/каналов) План: активности (что, когда, где, Primary-страта, контур, ожидаемый Reach/EI) Факт: публикации/эфиры/встречи, метрики охвата/вовлечения/сигналов Расчёты: EI по активности и агрегаты по страте/региону/дате События: инциденты/триггеры/решения штаба (для “как управляли”) 9.2. Региональная группировка A/B/C (важное примечание) В ваших текущих черновиках присутствует концепт групп регионов A/B/C (языково-медийные различия), но явный список областей “какие куда” в предоставленных файлах я не вижу. Поэтому в SSOT v1.0 это оформляется как отдельная таблица-справочник, которую вы заполняете по принятому штабом стандарту (можно за 20 минут). Технарям: таблица dim_region_profile должна позволять переопределение классификации без миграций. Приложения (то, что печатается) Приложение A. Матрица 6 страт × 3 контура (1 стр.) Приложение B. Формула EI + пояснение компонент (1 стр.) Приложение C. “Правила применения SSOT” (1 стр.) Приложение D. 42 страты (большая таблица) Приложение E. Карта регионов (A/B/C; digital-first/hybrid/offline-first) — как отдельный лист (заполняется штабом) Часть 2. SQL-структура под PostgreSQL (SSOT v1.0) Ниже — рабочий DDL-скелет. Он намеренно “нормализован”, чтобы: хранить коэффициенты отдельно (пересчитывать без переписывания фактов), вести ретроспективу, строить витрины под Metabase. -- ========================= -- SSOT v1.0 (PostgreSQL) -- ========================= CREATE SCHEMA IF NOT EXISTS ssot; -- 1) Dimensions CREATE TABLE IF NOT EXISTS ssot.dim_region ( region_id SMALLSERIAL PRIMARY KEY, region_code TEXT UNIQUE NOT NULL, region_name_ru TEXT NOT NULL, region_name_kz TEXT, is_city_major BOOLEAN DEFAULT FALSE ); -- Региональный профиль (язык/тип среды A/B/C и т.п.) CREATE TABLE IF NOT EXISTS ssot.dim_region_profile ( region_id SMALLINT PRIMARY KEY REFERENCES ssot.dim_region(region_id), region_group CHAR(1) NOT NULL CHECK (region_group IN ('A','B','C')), -- языково-культурный профиль settlement_mix CHAR(1) NOT NULL CHECK (settlement_mix IN ('U','R','M')), -- U=город, R=село, M=смешанный notes TEXT ); CREATE TABLE IF NOT EXISTS ssot.dim_stratum ( stratum_id SMALLSERIAL PRIMARY KEY, stratum_code TEXT UNIQUE NOT NULL, -- e.g. S4-A-U age_band TEXT NOT NULL, -- e.g. 35-44 media_type CHAR(1) NOT NULL CHECK (media_type IN ('A','B','C')), location_type CHAR(1) NOT NULL CHECK (location_type IN ('U','R')), description TEXT ); -- Управленческое укрупнение (6 страт) CREATE TABLE IF NOT EXISTS ssot.dim_stratum6 ( stratum6_id SMALLSERIAL PRIMARY KEY, stratum6_code TEXT UNIQUE NOT NULL, -- U1..R6 stratum6_name TEXT NOT NULL ); -- Связь 42 -> 6 CREATE TABLE IF NOT EXISTS ssot.map_stratum_to_stratum6 ( stratum_id SMALLINT REFERENCES ssot.dim_stratum(stratum_id), stratum6_id SMALLINT REFERENCES ssot.dim_stratum6(stratum6_id), PRIMARY KEY (stratum_id, stratum6_id) ); CREATE TABLE IF NOT EXISTS ssot.dim_contour ( contour_id SMALLSERIAL PRIMARY KEY, contour_code TEXT UNIQUE NOT NULL, -- DIGITAL / MASS / FIELD / MESSENGER / INST contour_name TEXT NOT NULL ); CREATE TABLE IF NOT EXISTS ssot.dim_channel ( channel_id SMALLSERIAL PRIMARY KEY, channel_code TEXT UNIQUE NOT NULL, -- META_ADS / TIKTOK / TV / RADIO / MEETING / WHATSAPP / TELEGRAM / ... channel_name TEXT NOT NULL, contour_id SMALLINT NOT NULL REFERENCES ssot.dim_contour(contour_id) ); -- 2) Base population by stratum/region (N_pop) CREATE TABLE IF NOT EXISTS ssot.fact_population ( as_of_date DATE NOT NULL, region_id SMALLINT NOT NULL REFERENCES ssot.dim_region(region_id), stratum_id SMALLINT NOT NULL REFERENCES ssot.dim_stratum(stratum_id), n_pop INTEGER NOT NULL CHECK (n_pop >= 0), source TEXT, PRIMARY KEY (as_of_date, region_id, stratum_id) ); -- 3) Coefficients (versioned) CREATE TABLE IF NOT EXISTS ssot.coeff_online ( coeff_id BIGSERIAL PRIMARY KEY, valid_from DATE NOT NULL, valid_to DATE, region_id SMALLINT REFERENCES ssot.dim_region(region_id), stratum_id SMALLINT REFERENCES ssot.dim_stratum(stratum_id), k_online NUMERIC(6,4) NOT NULL CHECK (k_online BETWEEN 0 AND 1) ); CREATE TABLE IF NOT EXISTS ssot.coeff_active ( coeff_id BIGSERIAL PRIMARY KEY, valid_from DATE NOT NULL, valid_to DATE, region_id SMALLINT REFERENCES ssot.dim_region(region_id), stratum_id SMALLINT REFERENCES ssot.dim_stratum(stratum_id), k_active NUMERIC(6,4) NOT NULL CHECK (k_active BETWEEN 0 AND 1) ); CREATE TABLE IF NOT EXISTS ssot.coeff_influence ( coeff_id BIGSERIAL PRIMARY KEY, valid_from DATE NOT NULL, valid_to DATE, stratum_id SMALLINT NOT NULL REFERENCES ssot.dim_stratum(stratum_id), channel_id SMALLINT NOT NULL REFERENCES ssot.dim_channel(channel_id), influence_coef NUMERIC(7,4) NOT NULL CHECK (influence_coef >= 0) ); CREATE TABLE IF NOT EXISTS ssot.coeff_retention ( coeff_id BIGSERIAL PRIMARY KEY, valid_from DATE NOT NULL, valid_to DATE, stratum_id SMALLINT NOT NULL REFERENCES ssot.dim_stratum(stratum_id), channel_id SMALLINT NOT NULL REFERENCES ssot.dim_channel(channel_id), retention NUMERIC(6,4) NOT NULL CHECK (retention BETWEEN 0 AND 1) ); CREATE TABLE IF NOT EXISTS ssot.coeff_weight ( coeff_id BIGSERIAL PRIMARY KEY, valid_from DATE NOT NULL, valid_to DATE, region_id SMALLINT REFERENCES ssot.dim_region(region_id), stratum_id SMALLINT NOT NULL REFERENCES ssot.dim_stratum(stratum_id), weight NUMERIC(7,4) NOT NULL CHECK (weight >= 0) ); -- 4) Plan (activities) CREATE TABLE IF NOT EXISTS ssot.fact_activity_plan ( activity_id BIGSERIAL PRIMARY KEY, plan_date DATE NOT NULL, region_id SMALLINT REFERENCES ssot.dim_region(region_id), -- NULL = national primary_stratum_id SMALLINT NOT NULL REFERENCES ssot.dim_stratum(stratum_id), primary_channel_id SMALLINT NOT NULL REFERENCES ssot.dim_channel(channel_id), activity_type TEXT NOT NULL, -- POST / VIDEO / TV_SLOT / RADIO_SLOT / MEETING / ... title TEXT, notes TEXT, expected_reach_rate NUMERIC(7,4) CHECK (expected_reach_rate BETWEEN 0 AND 1), expected_contacts INTEGER CHECK (expected_contacts >= 0), expected_retransmission_factor NUMERIC(7,4) CHECK (expected_retransmission_factor >= 0), created_at TIMESTAMPTZ DEFAULT now() ); -- 5) Fact execution (what happened) CREATE TABLE IF NOT EXISTS ssot.fact_activity_fact ( activity_fact_id BIGSERIAL PRIMARY KEY, activity_id BIGINT REFERENCES ssot.fact_activity_plan(activity_id), fact_date DATE NOT NULL, region_id SMALLINT REFERENCES ssot.dim_region(region_id), channel_id SMALLINT NOT NULL REFERENCES ssot.dim_channel(channel_id), stratum_id SMALLINT REFERENCES ssot.dim_stratum(stratum_id), -- if measurable; else NULL impressions BIGINT, reach BIGINT, engagements BIGINT, contacts BIGINT, notes TEXT, loaded_at TIMESTAMPTZ DEFAULT now() ); -- 6) EI calculations (materialized results) CREATE TABLE IF NOT EXISTS ssot.fact_ei ( ei_id BIGSERIAL PRIMARY KEY, calc_date DATE NOT NULL, activity_id BIGINT REFERENCES ssot.fact_activity_plan(activity_id), region_id SMALLINT REFERENCES ssot.dim_region(region_id), stratum_id SMALLINT NOT NULL REFERENCES ssot.dim_stratum(stratum_id), channel_id SMALLINT NOT NULL REFERENCES ssot.dim_channel(channel_id), reach_value NUMERIC(20,4) NOT NULL, influence_coef NUMERIC(10,4) NOT NULL, retention NUMERIC(10,4) NOT NULL, weight NUMERIC(10,4) NOT NULL, ei_value NUMERIC(20,4) NOT NULL ); -- 7) Signals / incidents (for SSI & “how we managed”) CREATE TABLE IF NOT EXISTS ssot.fact_signal ( signal_id BIGSERIAL PRIMARY KEY, signal_date DATE NOT NULL, region_id SMALLINT REFERENCES ssot.dim_region(region_id), stratum6_id SMALLINT REFERENCES ssot.dim_stratum6(stratum6_id), signal_type TEXT NOT NULL, -- NEG_SPIKE / RUMOR / OVERHEAT / COVERAGE_GAP / ... severity SMALLINT NOT NULL CHECK (severity BETWEEN 1 AND 5), description TEXT, source TEXT, created_at TIMESTAMPTZ DEFAULT now() ); -- 8) Views (optional) - “blind zones” and “coverage” CREATE VIEW ssot.v_blind_zones AS SELECT p.plan_date, COALESCE(r.region_name_ru, 'NATIONAL') AS region, s.stratum_code, COUNT(*) AS planned_acts FROM ssot.fact_activity_plan p LEFT JOIN ssot.dim_region r ON r.region_id = p.region_id JOIN ssot.dim_stratum s ON s.stratum_id = p.primary_stratum_id GROUP BY 1,2,3; Примечание по коэффициентам: формула EI и расчёт Reach в ваших черновиках уже заданы (Digital/TV/Meetings). DDL выше делает их “параметризуемыми”, чтобы SSOT не был захардкожен. Часть 3. Управленческая презентация (5 слайдов) — содержание Слайд 1. “Переход 2026: управление достижимостью, а не перечнем мероприятий” У государства мощные медиаресурсы Но без стратификации нельзя ответить: кого реально закрыли SSOT = единый стандарт “страта–контур–EI–факт” Фраза: “Мы не меняем повестку. Мы вводим слой управляемости доставки.” Слайд 2. “42 страты (SSOT) → 6 страт (панель управления)” Показать 6 укрупнённых страт Показать, что 42 остаются “внизу” для точной настройки Фраза: “Руководство управляет 6 строками, штаб считает 42.” Слайд 3. “Матрица 6×3: кто чем реально закрывается” Таблица: 6 страт × 3 контура (Digital / Mass / Field+Messenger) Подсветить: где слепые зоны возникают при инерции Фраза: “Ресурс есть. Вопрос — функция ресурса по слоям.” Слайд 4. “EI: простой стандарт сравнения решений (без споров ‘верю/не верю’)” EI = Reach × Influence × Retention × Weight EI в порядке величины (низк/сред/выс) EI выявляет дублирование и оправдывает ‘догоняющий пакет’ Слайд 5. “Что делаем за 72 часа (без новых бюджетов)” Утвердить SSOT v1.0 (как пилотный стандарт) Разметить текущий план по 6 стратам Зафиксировать слепые зоны Запустить догоняющий пакет + ежедневная записка 5 строк Передать в техгруппу: БД + витрины + ретроспектива Часть 4. “Пакет передачи технарям” (единая архитектура) 4.1. Что технарям отдать одним архивом (структура) /ssot_v1/ 01_doc/ Tom_SSOT_v1.0.md (или .docx) Slides_5.md Daily_note_template.md 02_data_dictionary/ entities.md (описание таблиц и полей) coefficients.md (как обновлять k_online/k_active/influence/retention/weight) 03_sql/ 001_schema.sql (DDL) 010_seed_dimensions.sql (загрузка справочников: stratum, stratum6, contour, channel) 020_views.sql (витрины) 04_etl/ sources.md (откуда берём population/сигналы/факт активностей) load_rules.md (валидаторы, дедупликация, версии коэффициентов) 05_examples/ example_plan.csv example_fact.csv example_coeffs.csv 4.2. Обязательные витрины (минимум под Metabase) v_dashboard_today: SSI, слепые зоны, топ-сигналы v_stratum6_coverage_plan_fact: план/факт по 6 стратам (по дням) v_ei_by_region_stratum6: EI агрегаты (для сравнения решений) v_overheat_proxy: частота касаний × негативные маркеры (упрощённо) 4.3. Ретроспектива (то, что потом “спасает”) В БД обязательно хранить: версии коэффициентов (valid_from/valid_to) план/факт активностей принятые решения (связать signal → decision) Это позволяет через месяц/год восстановить: “какая была картина, что мы видели, почему так решили”.