Почему Data-as-a-Product не работает и что приходит на смену
Data-as-a-Product (данные как продукт), data mesh, semantic layer, каталоги данных, SLA - за последние годы вокруг этих концепций сформировался устойчивый консенсус: если начать относиться к данным как к продукту, компании станут по-настоящему “data-driven”.
Но если спуститься с конференций в повседневность продуктовых команд, картина оказывается заметно сложнее: инфраструктура взрослеет, а качество и скорость решений - не всегда. Организации инвестируют в хранилища, витрины, пайплайны, назначают владельцев данных, запускают каталоги, инфраструктура становится более комплексной. Однако значимая часть продуктовых и управленческих решений по-прежнему принимается на основе интуиции, разовых выгрузок и противоречивых отчетов. Разрыв между зрелой инфраструктурой и качеством решений никуда не исчезает.
Как сформировалась идея Data-as-a-Product?
Подход “данные как продукт” вырос из нескольких параллельных линий:
- Data Mesh (Dehghani, 2022). Переход от централизованного DWH-отдела к доменным командам, которые выпускают свои дата-продукты - с понятным назначением, качеством, владельцем, интерфейсами, SLA и ответственностью.
- Data product thinking (Eckerson Group, 2022). Eckerson Group и другие консультанты предложили делать данные нужно делать удобными, понятными и применимыми, с ориентацией на потребителя, а не скрыты в глубинах хранилища. Пользователь данных рассматривается как клиент, как пользователь приложения.
- Осознание технического долга аналитики и ML (Sculley et al., 2015) Индустрия устала от скрытого технического долга в ML и аналитике. Работы Google показали, как быстрые модели и одноразовые витрины приводят к хрупким пайплайнам, расхождению метрик и высокой стоимости поддержки.
- Развитие modern data stack и self-service аналитики. BI-платформы, оркестраторы, каталоги, quality checks сделали инфраструктуру гибче и доступнее.
В итоге сложился подход по которому к данным нужно относиться как к продуктам: с назначением, владельцем, SLA и понятным интерфейсом - бизнесу будет проще опираться на них в принятии решений.
Но проблема в том, что в классической модели Data-as-a-Product фокус смещен на инфраструктуру и поставку данных, а не на ценность данных для принятия решений и их архитектуру.
Где возникает разрыв в классическом DaaP
Во многих компаниях “data-as-a-product” выглядит так:
- перечислены и задокументированы источники;
- созданы витрины и “data products”;
- назначены ответственные;
- настроены SLA по свежести и доступности;
- внедрен каталог данных и онбординг для аналитиков и продуктовых менеджеров.
Это действительно важные шаги, которые имеют огромную ценность. Но ключевой фокус остается инфраструктурным: “как мы поставляем корректные данные”.
В результате:
- Есть идеальный слой витрин, но продуктовые гипотезы по-прежнему формируются вручную и часто ситуативно;
- A/B-тесты не всегда доводятся до решения на уровне продукта и процессов;
- одни и те же метрики (CR, LTV, churn) по-разному считаются в разных системах;
- руководители и продакты продолжают запрашивать “ещё одну выгрузку для проверки”.
В Insight AI мы часто сталкиваемся с тем, что компании выстраивают зрелую инфраструктуру DWH и витрин, но решения по-прежнему принимаются на основе разрозненных данных. Decision-Oriented DaaP — это попытка закрыть этот разрыв и связать архитектуру данных с управленческой практикой.
Decision-Oriented Data-as-a-Product Framework
Decision-Oriented DaaP Framework - это надстройка над классическим Data-as-a-Product, в которой исходной единицей проектирования становятся управленческие решения, а под них в свою очередь собираются дата-продукты.
Более формально:
Decision-Oriented Data-as-a-Product - это такой способ организации данных, при котором каждый дата-продукт определен через набор поддерживаемых им решений и оценивается по влиянию на качество и скорость этих решений, а не только по техническим SLA.
Эту идею можно разложить на четыре связанных элемента.
От реестра источников к карте решений (Decisions map)
Первый шаг - зафиксировать не только, какие данные есть, а какие решения регулярно принимаются: что в этой компании реально выбирают каждый день
- кого и как таргетировать;
- какие офферы и промо показывать;
- как ранжировать товары и контент;
- какие лимиты и условия выдавать;
- кого и какими способами пытаться удержать;
- какие сегменты считать приоритетными.
Для каждого решения фиксируются: business owner (владелец решения), ритм пересмотра (ежедневно/недельно/по событию), SLA на time-to-decision (за сколько часов/дней решение должно быть принято), уровень допустимого риска/уверенности(например, требуемый uplift или доверительный интервал) и требования к данным (источники, разрезы, свежесть, точность).
Analytical Data Products - базовые блоки
В рамках Decision-Oriented подхода мы выделяем класс Analytical Data Products.
Analytical Data Product — это стандартизированное и документированное представление данных и логики (аналитические блоки), предназначенное для непосредственного использования в управленческих решениях и ML-моделях.
Вместо большой таблицы с множеством колонок и аккуратными описаниями и документацией в Confluence, которая выглядит как дополнительный слой над сырыми данными, требующий ручной расшифровки перед каждым решением, создается Analytical Data Product - более честная и приземленная сущность. Это такой кусок данных и логики, который можно взять и использовать для конкретного управленческого действия: запустить кампанию, изменить приоритеты, настроить таргетинг, пересчитать цены, собрать список “кого спасать”.
Характерные признаки:
- четкое назначение (какие решения он поддерживает);
- единая методология расчетов и метрик;
- владелец (analytic owner / команда);
- технические SLA (свежесть, полнота, стабильность);
- понятные интерфейсы (view, API, semantic layer).
Примеры
1. Когорты и LTV не для отчёта, а для решений по маркетингу
Вместо таблицы всех транзакций за три года аккуратно собранный аналитический продукт:
- каждая когорта определена одинаково;
- есть прогноз LTV по сегментам;
- видно, какие каналы приводят “одноразовых”, а какие — “своих”.
На основе этого продукта маркетинг:
- режет бюджеты там, где когорта мертвая;
- реинвестирует в источники с высоким LTV;
- честно защищает решения перед финансами, потому что входные данные стабильны и воспроизводимы.
2. “Риск оттока”
Не разрозненные признаки по пользователям, а единый Analytical Data Product:
- рассчитанный скоринг риска ухода;
- признаки, которые его формируют;
- понятные группы: “критический риск”, “можно дожать”, “все ок”.
На этом уже можно строить: кампанию удержания, прокидывание сигналов в CRM, автоматические триггеры, работу команды success-менеджеров.
3. “Здоровье продавца” для маркетплейса
Вместо нескольких справочников и отчетов — один продукт:
- рейтинг селлера,
- качество ассортимента,
- процент отмен, просрочек,
- вклад в GMV и маржу.
Вместо сырых чисел готовый сигнал: кого развивать, кого ограничивать, кого подключать к акциям.
Во всех этих примерах Analytical Data Product отличает понятные правила использования, и встроенность в реальные процессы. Analytical Data Product изначально проектируется как готовый инструмент для действий, а не как “богатая витрина, из которой можно когда-нибудь что-нибудь посчитать”.
Product Brain: контур, который связывает данные, модели и действия
Product Brain — это архитектурный контур, который объединяет Analytical Data Products, ML-модели, бизнес-правила и операционные системы, обеспечивая единообразие логики принятия решений и сбор обратной связи.
Чтобы данные, модели и операции не жили в разных вселенных, контур Product Brain соединяет их в единую логику:
Практически это означает, что:
- модели обучаются на тех же стандартизированных аналитических продуктах, что используются в отчётности и оперативном анализе;
- признаки и определения метрик консистентны;
- результаты моделей (рекомендации, лимиты, офферы) однозначно связываются с используемыми дата-продуктами;
- эффект решений (изменение CR, ARPU, churn и др.) возвращается в контур и используется для переобучения и пересмотра логики.
Impact Metrics: измеримость влияния дата-продуктов
Ключевое отличие Decision-Oriented DaaP от инфраструктурного подхода - введение Impact Metrics для дата-продуктов, его вклад в реальные изменения.
Impact Metrics отвечают на вопрос: что изменилось в бизнесе благодаря этому дата-продукту и связанным с ним решениям.
Пример 1. Сегментация пользователей по ценности.
Технические метрики:
- ежедневное обновление данных;
- контроль качества
- доступность до необходимых систем.
Impact Metrics:
- доля маркетинговых кампаний, которые используют эту сегментацию;
- uplift по CR / ARPU в кампаниях, где она применялась;
- снижение ручного таргетинга;
- изменение скорости запуска кампании: с 10 дней до 1–2.
Если по итогам нескольких месяцев сегментация не используется или не дает эффекта, - это сигнал пересобрать продукт или признать его бесполезным.
Пример 2. Риск оттока.
Impact Metrics:
- снижение churn в целевых сегментах,
- увеличение охвата retention-активностей
- рост точности таргетинга.
Как это работает в реальных компаниях
E-commerce / маркетплейс.
Разрозненные отчеты по промо заменены набором Analytical Data Products: эластичности, эффективность механик, “здоровье продавца”.
Через Product Brain рекомендации по промо и размещению товаров строятся только на этих продуктах; Impact Metrics показывают вклад в маржу и GMV.
Результат - прозрачная связь между архитектурой данных и финансовым эффектом.
Подписочный сервис.
Вместо трех разных определений churn введен единый Analytical Data Product по статусам и когортам, на его основе - скоринг оттока.
Решения по удержанию интегрированы в CRM через Product Brain, измеряются по Impact Metrics (churn, отклик, стоимость удержания).
Эффект - снижение количества конфликтующих цифр и рост управляемости.
B2B-платформа.
Часть кастомной отчетности для клиентов заменена библиотекой стандартизированных Analytical Data Products с четкими SLA и Impact Metrics (adoption, снижение затрат на кастомные проекты, рост прозрачности).
Это превращает аналитику из сервиса ручной работы в тиражируемый продукт.
Такой подход меняет культуру. Аналитики перестают быть поставщиками выгрузок, а дата-продукты перестают быть “инфраструктурой ради инфраструктуры”; data-as-a-product привязывается к четко измеримому влиянию на решения, а не просто хорошо выстроенной архитектуре, уменьшает технический долг аналитики и ML.
Вся конструкция - Decision-Oriented Data-as-a-Product, Analytical Data Products, Product Brain, Impact Metrics — это способ довести существующие подходы (Data Mesh, DaaP, data product thinking) до прикладной жизни продуктовой команды, и повысить доверие к данным на уровне C-level.