Новая архитектура
маркетинга
Содержание книги

Глава 18. Аналитика и прогнозирование

Вводный аппарат

Маркетинговая и коммерческая система становится управляемой только тогда, когда организация способна не просто регистрировать результат, но и восстанавливать механизм его возникновения, оценивать вероятное будущее и превращать аналитическое знание в решение.

В новой архитектуре маркетинга аналитика рассматривается не как отдельный уровень MOS и не как функция BI-подразделения. Это сквозная управленческая способность, проходящая через всю коммерческую цепочку:

Рынок → Спрос → цепочка создания маркетинговой ценности → MQL → Lead Lifecycle Management → SQL → Sales Operations → Opportunity → Deal → OWNER_ACCEPTED → Ownership Episode → новый Demand Episode.

Аналитическая система новой архитектуры маркетинга — это сквозная система регистрации, связывания, интерпретации и моделирования событий, состояний и результатов коммерческих объектов, обеспечивающая переход от факта к объяснению, прогнозу, управленческому сигналу, решению и проверке его результата.

Главный принцип главы:

Аналитика создаёт управленческую ценность не тогда, когда показывает больше показателей, а тогда, когда достаточно рано обнаруживает значимое изменение, правильно локализует его механизм, оценивает вероятное будущее и позволяет принять решение, способное изменить результат.

Сквозная логика:

Коммерческая реальность → События → Объекты → Состояния → Время и контекст → Семантический смысл → Аналитическое наблюдение → Диагностика → Экономическая и причинная оценка → Прогноз → Управленческий сигнал → Решение → Действие → Результат → Доказательство → Обучение → Изменение модели / стандарта.

Глава 17 определила экономический объект измерения. Глава 18 отвечает на вопрос: как аналитическая система должна надёжно наблюдать, измерять, объяснять и прогнозировать эту экономическую реальность.

18.1. От отчётности к аналитическому управлению

Отчётность отвечает прежде всего на вопрос: что произошло? Аналитическая система должна дополнительно отвечать: где возникло отклонение, чем оно объясняется, что вероятно произойдёт дальше и какое действие способно изменить результат.

Ключевые разграничения

  • Data ≠ Information;
  • Information ≠ Insight;
  • Metric ≠ Signal;
  • Report ≠ Analysis;
  • Dashboard ≠ Analytics System;
  • Signal ≠ Cause;
  • Diagnosis ≠ Decision;
  • Decision ≠ Action.

Dashboard — интерфейс представления информации, но не сама аналитическая система. Для полноценной аналитики дополнительно нужны объектная архитектура, история событий, семантика, диагностика, прогнозирование и механизм управленческих сигналов.

Условно можно выделить пять аналитических способностей:

  1. наблюдение — что произошло;
  2. диагностика — почему;
  3. прогноз — что вероятно произойдёт;
  4. поддержка решений — какие действия доступны;
  5. обучение — что изменилось после действия.

Эти способности не являются уровнями MOS.

Таблица 371. От отчётности к аналитическому управлению

Таблицу можно прокручивать по горизонтали.

Уровень Главный вопрос Типовой продукт
Отчётность Что произошло? отчёт
Наблюдение Где произошло изменение? dashboard
Диагностика Почему изменилось? аналитический разбор
Прогноз Что вероятно произойдёт? Прогноз
Сигнал Что требует внимания? alert / signal
Поддержка решений Что можно сделать? decision product
Обучение Что изменилось после действия? outcome review

Главный вывод: аналитика начинается там, где организация перестаёт только фиксировать прошлое и начинает системно объяснять, предвидеть и изменять коммерческий результат.

18.2. Аналитический объект, уровень детализации и правила наблюдения

Нельзя корректно рассчитывать показатель, пока не определено, что именно является объектом наблюдения.

Базовая аналитическая конструкция:

Коммерческий объект × Состояние × Время × Контекст.

Коммерческим объектом могут быть Demand Episode, MQL, SQL, Opportunity, Deal, Ownership Episode.

Уровень детализации (grain) определяет, чему соответствует одна аналитическая запись. Примеры: Demand Episode × Event Time; Opportunity × State Transition; Ownership Episode × Period.

Строка CRM не обязательно является коммерческим объектом. Техническая запись может дублировать объект, объединять разные объекты или отражать только часть истории.

В книге используется авторская конструкция Analytical Object Integrity — способность системы сохранять правильную коммерческую историю объекта через идентификаторы, события, состояния и handoff.

Ключевое различие:

Источник ≠ Канал ≠ Точка обращения.

Например: источник спроса — Search; размещение — Яндекс Директ; канал взаимодействия — Website; точка обращения — Credit Form.

Необходимо различать Creation Time, Event Time, Processing Time, Acceptance Time, Recognition Time и Close Time.

Для каждого домена данных следует определять собственный авторитетный источник, а не пытаться назначить одну систему универсальным «источником истины».

Таблица 372. Аналитические объекты и правила наблюдения

Таблицу можно прокручивать по горизонтали.

Элемент Контрольный вопрос
Объект Что именно наблюдаем?
Grain Чему соответствует одна запись?
Eligibility Какие объекты входят в расчёт?
Состояние В каком состоянии объект?
Event Time Когда событие произошло?
Recognition Rule Когда результат признаётся?
Context При каких условиях?
Source Где хранится авторитетный факт?
Version Какая версия определения действует?

Главный вывод: аналитическое измерение начинается не с формулы, а с корректного определения объекта, времени и допустимой совокупности.

18.3. Событийная модель и аналитическая история

Snapshot показывает текущее состояние, но не объясняет, как объект туда попал. Поэтому аналитическая система должна хранить историю событий.

Событие отвечает: что произошло? Состояние: где находится объект?

В книге используется авторская Commercial Event Model.

Минимальная структура события:

  • Event ID;
  • Event Type;
  • Event Timestamp;
  • Object ID;
  • Object Type;
  • Previous State;
  • New State;
  • Actor;
  • Channel;
  • Source System;
  • Attributes;
  • Data Version.

Система должна отделять техническую телеметрию от событий коммерческого процесса. Для late-arriving data необходимо хранить отдельно Event Timestamp и Processing Timestamp.

Rework должен оставаться видимой частью истории. Если система просто перезаписывает текущий статус, возвраты исчезают из аналитики.

Таблица 373. Событие и состояние

Таблицу можно прокручивать по горизонтали.

Характеристика Событие Состояние
Главный вопрос Что произошло? Где находится объект?
Время момент интервал
Пример SQL Accepted Active Opportunity
Использование переходы, история WIP, aging

18.4. Identity, Demand Episode и связность данных

Сквозная аналитика возможна только тогда, когда система понимает, какие события относятся к одной коммерческой истории.

Identity — физическое или юридическое лицо. Один Identity может иметь множество Demand Episode.

Demand Episode — отдельный эпизод спроса, имеющий собственный предмет, время и lifecycle.

Interaction — отдельное взаимодействие: звонок, форма, чат, сообщение, визит. Несколько Interaction могут относиться к одному Demand Episode.

Поэтому:

Identity ≠ Demand Episode ≠ Interaction.

Identity Resolution может быть детерминированным или вероятностным. Ошибки false merge и false split нарушают conversion, frequency, source attribution и customer economics.

Нормативная цепочка:

Identity → Demand Episode → MQL → SQL → Opportunity → Deal → OWNER_ACCEPTED → Ownership Episode.

При появлении нового спроса создаётся новый Demand Episode. Короткий цикл Owner → SQL не используется.

Таблица 374. Временная архитектура

Таблицу можно прокручивать по горизонтали.

Время Что означает
Creation Time создание записи
Event Time фактический момент события
Processing Time момент обработки системой
Acceptance Time момент принятия объекта
Recognition Time момент признания результата
Close Time момент завершения lifecycle

Таблица 375. Identity, Demand Episode и Interaction

Таблицу можно прокручивать по горизонтали.

Сущность Что представляет
Identity человек / организация
Эпизод потребности отдельный эпизод спроса
Interaction отдельное касание
MQL / SQL квалифицированные состояния
Opportunity / Deal объекты Sales Operations
Период владения продуктом эпизод владения после OWNER_ACCEPTED

Linkage ≠ Attribution ≠ Causality.

18.5. Когортная аналитика

Периодная аналитика отвечает: что произошло в периоде? Когортная: что произошло с объектами, вошедшими в систему в один и тот же момент или период?

Показатель Deals сентября / MQL сентября не является корректной когортной конверсией, если числитель и знаменатель относятся к разным поколениям объектов.

Когорта должна иметь общий entry event и сопоставимый horizon.

Возраст объекта:

A g e i ( t ) = t − t e n t r y , i

Формула (18.1).

Когортная конверсия:

C R C , S ( h ) = N C → S ( h ) N C , e l i g i b l e ( h )

Формула (18.2).

Зрелость когорты:

C o h o r t   M a t u r i t y = min ( 1 , O b s e r v e d   H o r i z o n R e f e r e n c e   H o r i z o n )

Формула (18.3).

Это авторская упрощённая характеристика зрелости окна наблюдения, а не доля уже реализованного результата.

Правое цензурирование означает, что часть объектов ещё не успела завершить lifecycle и не должна автоматически считаться неуспешной.

Таблица 376. Типы когорт

Таблицу можно прокручивать по горизонтали.

Тип Пример
По времени входа MQL сентября
По источнику MQL из классифайда
По бренду Demand Episode бренда X
По кампании объекты кампании A
По Ownership клиенты, вошедшие во владение в квартале

18.6. Аналитика переходов и коммерческого потока

Переход является самостоятельным аналитическим объектом.

Нормативные handoff:

  • MQL → accepted MQL;
  • accepted MQL → SQL;
  • SQL → accepted SQL;
  • accepted SQL → Opportunity;
  • Opportunity → Deal;
  • Deal → OWNER_ACCEPTED.
T r a n s i t i o n R a t e i → j = N i → j N i , e l i g i b l e

Формула (18.4).

A c c e p t a n c e R a t e = N a c c e p t e d N s u b m i t t e d

Формула (18.5).

R e j e c t i o n R a t e = N r e j e c t e d N s u b m i t t e d

Формула (18.6).

W I P t = W I P t − 1 + I n f l o w t − O u t f l o w t

Формула (18.7).

R e w o r k R a t e = N o b j e c t s   w i t h   r e w o r k N e l i g i b l e   o b j e c t s

Формула (18.8).

P i j = P ( S t + 1 = j ∣ S t = i )

Формула (18.9).

P = [ p 11 p 12 ⋯ p 1 n p 21 p 22 ⋯ p 2 n ⋮ ⋮ ⋱ ⋮ p n 1 p n 2 ⋯ p n n ]

Формула (18.10).

Матрица переходов не означает автоматически наличие марковского свойства.

Авторская Transition Analytics Matrix должна анализировать для каждого перехода: eligible population, inflow, acceptance, rejection, conversion, time, aging, rework, loss reason, economics.

Таблица 377. Матрица аналитики переходов

Таблицу можно прокручивать по горизонтали.

Переход Вход Принято Отклонено Конверсия Time Доработка Экономика
MQL → accepted MQL
accepted MQL → SQL
SQL → accepted SQL
accepted SQL → Opportunity
Opportunity → Deal
Deal → OWNER_ACCEPTED

Авторская Expected Transition Value:

E T V i → j = P i j × E V j − C i → j

Формула (18.14).

Коммерческий поток следует анализировать не как одну итоговую конверсию, а как систему отдельных переходов.

18.7. Временная аналитика: aging, velocity, WIP и time-to-transition

Время является самостоятельным аналитическим измерением. Одинаковое состояние может иметь разное управленческое значение в зависимости от возраста объекта и времени в состоянии.

Время до перехода:

T T T i → j = t j − t i

Формула (18.11).

Пропускная способность:

T h r o u g h p u t = N c o m p l e t e d Δ t

Формула (18.12).

При устойчивом процессе используется связь:

W I P = λ × C T

Формула (18.13), закон Литтла.

Она применима только при согласованной границе процесса, устойчивом потоке и согласованных единицах измерения.

Время в состоянии:

T i m e I n S t a t e i ( t ) = t − t s t a t e _ e n t r y , i

Формула (18.15).

Полное время цикла:

C y c l e T i m e i = t e x i t , i − t e n t r y , i

Формула (18.16).

Время до первого содержательного контакта:

T T C i = t c o n t a c t , i − t a c c e p t e d , i

Формула (18.17).

Попытка контакта не равна контакту.

Функция выживания:

S ( t ) = P ( T > t )

Формула (18.18).

Функция риска наступления события:

h ( t ) = lim Δ t → 0 P ( t ≤ T < t + Δ t ∣ T ≥ t ) Δ t

Формула (18.19).

Эффективность потока:

F l o w E f f i c i e n c y = P r o c e s s i n g T i m e C y c l e T i m e

Формула (18.20).

Ключевые разграничения:

  • Age ≠ Temperature;
  • WIP ≠ Backlog;
  • Processing Time ≠ Waiting Time;
  • Mean ≠ Median;
  • SLA ≠ аналитическая истина.

Для асимметричных временных распределений необходимо использовать не только среднее, но и медиану, P75, P90, P95.

Таблица 378. Временная аналитика

Таблицу можно прокручивать по горизонтали.

Показатель Что измеряет Управленческий смысл
Возраст объекта время с момента входа зрелость / риск зависания
Time-in-State длительность текущего состояния локализация задержки
Время до контакта скорость первичной реакции качество обработки входа
Time-to-Transition скорость перехода динамика потока
Cycle Time полный цикл общая скорость
WIP незавершённая работа нагрузка
Throughput завершённый поток пропускная способность
Flow Efficiency доля активной обработки структура времени

18.8. Аналитика коммерческих траекторий

Линейная воронка является агрегированной проекцией более сложной системы состояний и переходов.

Customer Journey описывает клиентский опыт. Коммерческая траектория — последовательность наблюдаемых взаимодействий, событий, состояний и переходов коммерческого объекта.

P a t h L e n g t h i = N e v e n t s , i

Формула (18.21).

C h a n n e l C o u n t i = N u n i q u e   c h a n n e l s , i

Формула (18.22).

P a t h D u r a t i o n i = t l a s t , i − t f i r s t , i

Формула (18.23).

Длинная траектория не обязательно хуже: она может быть следствием сложной покупки, но также может отражать rework, лишние касания или плохую маршрутизацию.

Last Touch — последняя наблюдаемая точка, а не доказанная причина Deal. First Touch — первая наблюдаемая точка доступной истории, а не доказанное начало спроса.

Таблица 379. Воронка, Customer Journey и коммерческая траектория

Таблицу можно прокручивать по горизонтали.

Модель Главный вопрос Сильная сторона Ограничение
Воронка Сколько дошло дальше? простота скрывает возвраты
Путь клиента Как клиент воспринимает взаимодействие? клиентская перспектива не всегда формализует states
State Model Где объект находится? управление lifecycle не показывает всю историю касаний
Коммерческая траектория Как объект реально прошёл систему? фактический маршрут требует event history

18.9. Диагностическая аналитика: почему изменился результат

Отклонение показателя является симптомом, а не причиной.

Нормативная последовательность:

Симптом → Локализация → Декомпозиция → Гипотеза → Доказательства → Альтернативные объяснения → Правдоподобный механизм.

Основные классы декомпозиции:

  • Volume;
  • Mix;
  • Conversion;
  • Time;
  • Capacity;
  • Economics;
  • Risk;
  • Data.
Δ Y = Δ Y V o l u m e + Δ Y M i x + Δ Y C o n v e r s i o n + Δ Y T i m e + Δ Y C a p a c i t y + Δ Y E c o n o m i c + Δ Y R i s k + Δ Y D a t a

Формула (18.24). Авторская диагностическая модель.

Δ C o n t r i b u t i o n = Δ V o l u m e + Δ M i x + Δ M a r g i n + Δ C o s t + Δ R i s k

Формула (18.25). Авторская концептуальная декомпозиция.

Таблица 380. Диагностическая декомпозиция

Таблицу можно прокручивать по горизонтали.

Компонент Диагностический вопрос
Volume Изменился ли объём входа?
Mix Изменилась ли структура?
Конверсия На каком переходе изменился результат?
Time Замедлилось ли движение?
Пропускная способность Возникло ли ограничение мощности?
Economics Изменилась ли ценность результата?
Риск Вырос ли риск?
Data Не является ли изменение артефактом измерения?

Correlation ≠ Causation. Benchmark ≠ Cause. Statistical Significance ≠ Economic Materiality.

18.10. Экономическая и причинная аналитика

Наблюдаемый результат не показывает автоматически эффект воздействия.

Необходимо различать:

  1. наблюдаемый;
  2. приписанный;
  3. прогнозируемый;
  4. дополнительный;
  5. скорректированный на риск результат.
τ i = Y i ( 1 ) − Y i ( 0 )

Формула (18.26).

A T E = E [ Y ( 1 ) − Y ( 0 ) ]

Формула (18.27).

I n c r e m e n t a l L i f t = O u t c o m e R a t e T − O u t c o m e R a t e C

Формула (18.28).

I n c r e m e n t a l O u t c o m e s = N T × ( O u t c o m e R a t e T − O u t c o m e R a t e C )

Формула (18.29).

I n c r e m e n t a l C o n t r i b u t i o n = I n c r e m e n t a l O u t c o m e s × C o n t r i b u t i o n p e r   O u t c o m e

Формула (18.30).

I n c r e m e n t a l E c o n o m i c E f f e c t = I n c r e m e n t a l C o n t r i b u t i o n − I n c r e m e n t a l C o s t

Формула (18.31).

D i D = ( Y T , a f t e r − Y T , b e f o r e ) − ( Y C , a f t e r − Y C , b e f o r e )

Формула (18.32).

U p l i f t i = P ( Y = 1 ∣ T = 1 , X i ) − P ( Y = 1 ∣ T = 0 , X i )

Формула (18.33).

Ключевые разграничения:

  • Attribution ≠ Incrementality;
  • Prediction ≠ Causality;
  • High Propensity ≠ High Uplift;
  • Before/After ≠ Causal Effect.

Таблица 381. Аналитические статусы результата

Таблицу можно прокручивать по горизонтали.

Статус Главный вопрос
Наблюдаемый Что произошло?
Приписанный К чему результат отнесён?
Прогнозируемый Что ожидалось?
Дополнительный Что возникло благодаря воздействию?
Скорректированный на риск Какова ожидаемая ценность с учётом риска?

Причинный вывод должен соответствовать силе исследовательского дизайна.

18.11. Качество данных, происхождение и аналитическое доверие

Data Quality ≠ Analytical Validity.

Шесть базовых измерений качества:

  1. полнота;
  2. правильность;
  3. согласованность;
  4. своевременность;
  5. уникальность;
  6. валидность.
C o m p l e t e n e s s = N n o n m i s s i n g N r e q u i r e d

Формула (18.34).

F r e s h n e s s = t a v a i l a b l e − t e v e n t

Формула (18.35).

D u p l i c a t e R a t e = N d u p l i c a t e s N r e c o r d s

Формула (18.36).

R e c o n c i l i a t i o n D i f f e r e n c e = V a l u e A − V a l u e B

Формула (18.37).

R e l a t i v e R e c o n c i l i a t i o n D i f f e r e n c e = | V a l u e A − V a l u e B | R e f e r e n c e V a l u e

Формула (18.38).

Таблица 382. Измерения качества данных

Таблицу можно прокручивать по горизонтали.

Измерение Контрольный вопрос
Полнота Всё ли необходимое присутствует?
Правильность Соответствует ли значение реальности?
Согласованность Не противоречат ли источники?
Своевременность Доступны ли данные вовремя?
Уникальность Нет ли ложных дублей?
Валидность Соответствует ли значение правилам?

Авторская Цепочка аналитического доверия:

Коммерческая реальность → Событие → Источник → Объектная целостность → Преобразование → Семантика → Аналитическая модель → Вывод → Решение.

Таблица 383. Цепочка аналитического доверия

Таблицу можно прокручивать по горизонтали.

Уровень Контрольный вопрос
Реальность Что произошло?
Событие Зарегистрировано ли это?
Источник Где хранится факт?
Объект К правильному ли объекту отнесено?
Преобразование Что изменено?
Семантика Что означает показатель?
Модель Как получен вывод?
Решение Можно ли использовать вывод для действия?

Авторские понятия:

Аналитическая утечка (Analytical Leakage) — потеря управленчески значимого знания вследствие неполной или неправильной регистрации и связывания коммерческой реальности.

Аналитический долг (Analytical Debt) — накопленная стоимость несогласованных определений, ручных отчётов, локальных файлов, дублирующихся показателей и непрозрачных преобразований.

18.12. Семантический слой и единый аналитический язык

Качество данных без единой семантики не создаёт единой аналитики.

В книге используется авторская модель Коммерческий семантический слой (Commercial Semantic Layer).

Он включает:

  1. бизнес-глоссарий;
  2. каталог объектов;
  3. словарь событий;
  4. словарь состояний;
  5. каталог показателей;
  6. справочники;
  7. правила признания;
  8. карту источников;
  9. происхождение данных;
  10. версионность.

Таблица 384. Структура коммерческого семантического слоя

Таблицу можно прокручивать по горизонтали.

Компонент Что фиксирует
Бизнес-глоссарий значение терминов
Каталог объектов сущности и связи
Словарь событий что произошло
Словарь состояний где находится объект
Каталог показателей правила расчёта
Справочники бренд, кластер, канал и др.
Правила признания когда факт считается возникшим
Карта источников где хранится авторитетный факт
Lineage как показатель получен
Реестр версий как менялось определение

Semantic Layer ≠ KPI System.

Semantic Layer отвечает: что означает показатель и как он рассчитывается? KPI System отвечает: каким показателем управлять, кто владелец и какое значение является целевым?

18.13. Прогнозная аналитика и неопределённость

Ключевое разграничение:

Прогноз ≠ План ≠ Цель ≠ Сценарий.

Таблица 385. Прогноз ≠ План ≠ Цель ≠ Сценарий

Таблицу можно прокручивать по горизонтали.

Понятие Главный вопрос
План Чего организация намерена достичь?
Цель Какой результат желателен?
Прогноз Что вероятнее всего произойдёт?
Сценарий Что произойдёт при заданных предпосылках?
Y t + h ∼ F t + h

Формула (18.39).

p i = P ( Y i = 1 ∣ X i )

Формула (18.40).

E [ Y ] = ∑ i = 1 N p i

Формула (18.41).

F o r e c a s t = f ( V o l u m e , M i x , T r a n s i t i o n , T i m e , C a p a c i t y , E c o n o m i c s , E x t e r n a l F a c t o r s )

Формула (18.42).

e t = y t − y ^ t

Формула (18.43).

M A E = 1 n ∑ t = 1 n | y t − y ^ t |

Формула (18.44).

R M S E = 1 n ∑ t = 1 n ( y t − y ^ t ) 2

Формула (18.45).

M A P E = 100 % n ∑ t = 1 n | y t − y ^ t y t |

Формула (18.46).

MAPE нестабилен при факте около нуля.

W A P E = ∑ | y t − y ^ t | ∑ | y t |

Формула (18.47).

B i a s = 1 n ∑ t = 1 n ( y ^ t − y t )

Формула (18.48).

P ( Y = 1 ∣ p ) = p

Формула (18.49).

B r i e r = 1 n ∑ i = 1 n ( p i − y i ) 2

Формула (18.50).

C o v e r a g e = N i n s i d e N t o t a l

Формула (18.51).

Таблица 386. Метрики качества прогноза

Таблицу можно прокручивать по горизонтали.

Метрика Что показывает Ограничение
MAE среднюю абсолютную ошибку зависит от масштаба
RMSE крупные ошибки чувствителен к выбросам
MAPE ошибку в процентах нестабилен около нуля
WAPE агрегированную относительную ошибку скрывает распределение
Bias систематическое смещение не показывает общий размер ошибки
Calibration качество вероятностей требует достаточной выборки
Brier Score качество вероятностного прогноза применим к бинарным исходам
Coverage качество интервала требует оценки ширины

Accuracy ≠ Calibration. AUC ≠ Forecast Accuracy.

Backtesting должен использовать только данные, доступные на Forecast Origin.

E E V ( a ) = ∑ s P ( s ∣ a ) × V ( s , a )

Формула (18.52).

18.14. Управленческие сигналы и поддержка принятия решений

Аналитический вывод не создаёт результат, пока не превращён в решение и действие.

Нормативная цепочка:

Наблюдение → Отклонение / Возможность → Диагностика → Ожидаемый эффект → Управленческий сигнал → Владелец решения → Альтернативы → Решение → Действие → Результат → Проверка эффекта → Обучение.

Metric ≠ Signal.

Сигнал должен содержать объект, время, условие, ожидаемый эффект, уверенность, приоритет, Decision Owner, класс возможной реакции и срок актуальности.

E D V ( a ) = E x p e c t e d E c o n o m i c V a l u e ( a ) − D e c i s i o n C o s t ( a ) − R i s k A d j u s t m e n t ( a )

Формула (18.53). Авторская концептуальная модель.

D e c i s i o n R e a c t i o n D e l a y = t d e c i s i o n − t s i g n a l

Формула (18.54).

Таблица 387. Паспорт аналитического утверждения и сигнала

Таблицу можно прокручивать по горизонтали.

Блок Содержание
Аналитическое утверждение объект, период, совокупность, доказательства, метод, уверенность, альтернативные объяснения
Управленческий сигнал ID, время, условие, эффект, приоритет, владелец, класс реакции, expiry, статус

Зрелая система должна хранить Decision Log. Learning Closure возникает тогда, когда результат действия возвращается в систему как новое доказательство и меняет модель, правило или стандарт.

18.15. Интегрированная эталонная модель коммерческой аналитики

Авторская Integrated Commercial Analytics Reference Model состоит из пяти слоёв:

  1. коммерческая реальность;
  2. доказательная основа;
  3. аналитика;
  4. поддержка решений;
  5. обучение.

Слой 1. Коммерческая реальность

Market → Demand → MVC → MQL → LLM → SQL → Sales Operations → Opportunity → Deal → OWNER_ACCEPTED → Ownership Episode → новый Demand Episode.

Слой 2. Доказательная основа

Identity → Demand Episode → Object → Event → State → Time → Context → Semantics.

Слой 3. Аналитика

Cohort → Transition → Time → Path → Diagnosis → Economics → Causality → Forecast.

Слой 4. Поддержка решений

Signal → Materiality → Confidence → Decision Owner → Alternatives → Decision → Action.

Слой 5. Обучение

Outcome → Evidence → Effect Review → Model Update → Standard Update.

Аналитический профиль здоровья

Авторская модель включает восемь осей:

  1. целостность данных;
  2. целостность объектов;
  3. своевременность;
  4. семантическая согласованность;
  5. диагностическая способность;
  6. качество прогнозов;
  7. интеграция с решениями;
  8. замыкание обучения.

Таблица 388. Аналитический профиль здоровья и интегрированная модель

Таблицу можно прокручивать по горизонтали.

Ось Контрольный вопрос
Целостность данных Можно ли доверять исходным фактам?
Целостность объектов Правильно ли связана история?
Своевременность Доступны ли данные вовремя?
Семантическая согласованность Одинаково ли понимаются показатели?
Диагностическая способность Можно ли объяснить отклонение?
Качество прогнозов Надёжно ли оценивается будущее?
Интеграция с решениями Превращается ли вывод в действие?
Замыкание обучения Изменяется ли система после результата?

Финальная логика:

Коммерческая реальность → Доказательство → Аналитика → Решение → Действие → Результат → Обучение.

Итоги главы 18

Ключевые выводы:

  1. Аналитика ≠ отчётность.
  2. Объект должен быть определён раньше показателя.
  3. Event ≠ State.
  4. Snapshot ≠ Event History.
  5. Identity ≠ Demand Episode.
  6. Interaction ≠ Lead.
  7. Source ≠ Channel ≠ Entry Point.
  8. Period Conversion ≠ Cohort Conversion.
  9. Переход является самостоятельным аналитическим объектом.
  10. Age ≠ Temperature.
  11. WIP ≠ Backlog.
  12. Воронка — только одна проекция коммерческой системы.
  13. Симптом ≠ Причина.
  14. Correlation ≠ Causation.
  15. Attribution ≠ Incrementality.
  16. Prediction ≠ Causality.
  17. Data Quality ≠ Analytical Validity.
  18. Semantic Layer ≠ KPI System.
  19. Forecast ≠ Plan ≠ Target ≠ Scenario.
  20. Metric ≠ Signal.
  21. Decision ≠ Action.
  22. Analytics должна завершаться Learning Closure.

Итоговая последовательность:

КОММЕРЧЕСКАЯ РЕАЛЬНОСТЬ → СОБЫТИЕ → ОБЪЕКТ → СОСТОЯНИЕ → ВРЕМЯ → СЕМАНТИЧЕСКИЙ СМЫСЛ → АНАЛИТИЧЕСКОЕ НАБЛЮДЕНИЕ → ДИАГНОСТИКА → ЭКОНОМИЧЕСКАЯ И ПРИЧИННАЯ ОЦЕНКА → ПРОГНОЗ → УПРАВЛЕНЧЕСКИЙ СИГНАЛ → РЕШЕНИЕ → ДЕЙСТВИЕ → РЕЗУЛЬТАТ → ДОКАЗАТЕЛЬСТВО → ОБУЧЕНИЕ → ИЗМЕНЕНИЕ МОДЕЛИ / СТАНДАРТА → НОВЫЙ ЦИКЛ.

Глава 17 определила экономический объект измерения.

Глава 18 определила аналитическую архитектуру доказательства, объяснения и предвидения.

Переход к главе 19

Глава 19. Организационная трансформация маркетинговой системы

Следующая задача:

как организационно изменить компанию, чтобы новая архитектура маркетинга и коммерческого управления действительно начала работать?

Глава 19 должна перевести разработанную архитектуру:

из модели — в работающую организационную способность.

В этой главе
  1. Вводный аппарат
  2. 18.1. От отчётности к аналитическому управлению
  3. 18.2. Аналитический объект, уровень детализации и правила наблюдения
  4. 18.3. Событийная модель и аналитическая история
  5. 18.4. Identity, Demand Episode и связность данных
  6. 18.5. Когортная аналитика
  7. 18.6. Аналитика переходов и коммерческого потока
  8. 18.7. Временная аналитика: aging, velocity, WIP и time-to-transition
  9. 18.8. Аналитика коммерческих траекторий
  10. 18.9. Диагностическая аналитика: почему изменился результат
  11. 18.10. Экономическая и причинная аналитика
  12. 18.11. Качество данных, происхождение и аналитическое доверие
  13. 18.12. Семантический слой и единый аналитический язык
  14. 18.13. Прогнозная аналитика и неопределённость
  15. 18.14. Управленческие сигналы и поддержка принятия решений
  16. 18.15. Интегрированная эталонная модель коммерческой аналитики
  17. Итоги главы 18
  18. Переход к главе 19

Поиск по книге

Поиск по заголовкам, тексту и таблицам.