Анализ каналов продаж - сравнение эффективности различных каналов реализации продукции

Курс по BI DWH в Коммерческом департаменте: анализ продаж через различные каналы требует строгой методологии, где архитектура данных, временные вимеры, интеграции источников и методики атрибуции работают в единой системе. Глава посвящена тому, как спроектировать DWH и аналитическую среду так, чтобы можно было объективно сравнивать эффективность каналов продаж, выявлять узкие места воронки и принимать решения, ориентированные на ROI.

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

Архитектура данных и источники
Модели данных и атрибуции
Метрики, методы сравнения и контроль качества
Интеграция источников, пайплайны и управление данными
Практическая реализация: запросы, протоколы интеграции и примеры

Архитектура данных и источники

Базовая архитектура должна обеспечить четкое разделение культурно-исторических данных и оперативной информации, сохраняя при этом возможность кросс-файлового анализа. В классической реализации выделяют три слоя: staging, integration и presentation (presentation layer - представления и отчеты). Сама предметная область анализа каналов продаж требует расширенной модели, где фактовые таблицы несут измерения по продажам, а измерения по каналам, кампаниям и продуктам - в измерительных размерностях.

Staging-слой собирает сырые данные из нескольких источников: CRM (заказы, клиенты), ERP (финансы, запасы), онлайн-магазин, маркетинговые платформы и офлайн-каналы. В этом слое важно зафиксировать источник, временную метку и уникальные идентификаторы клиента или заказа.
Integration-слой реализует согласование идентификаторов и нормализацию данных. Здесь применяются механизмы сопоставления клиентских и транзакционных ключей, устранение дубликатов, привязка к календарю и валютам.
Presentation-слой содержит обучающие и аналитические схемы: витрины (data marts) по каналам, по кампаниям и по продуктам, а также агрегированные показатели ROI и атрибуции.

Типичные источники и способы их интеграции:

CRM-системы (например, Salesforce): заказы, контакты, стадии сделки, источники лидов.
ERP-системы (например, SAP): заказы, счета, маржинальность, себестоимость.
Онлайн-каналы: интернет-магазин, маркетплейсы, рекламные площадки; данные о кликах, привлечении, конверсиях, стоимости заказа и т.д.
Офлайн-каналы: розничная сеть, выручка по магазинам, звонки в колл-центр.
Информационные системы атрибуции: данные по взаимодействиям клиентов с каналами (touchpoints) в цепочке покупки.

Ключевые архитектурные принципы:

Архитектура на основе звездной схемы (star schema) с фактами продаж и размерностями: dim_date, dim_channel, dim_product, dim_campaign, dim_customer, dim_store.
Линия данных и прослеживаемость: каждое значение в факте продаж должно иметь ссылки на источники и источник изменений для целей аудита и регуляторной прозрачности.
Реализация данных о touchpoints: хранение истории взаимодействий по каждому заказу (order_id), включая канал, время и тип касания.
Поддержка различной задержки данных: пакетная загрузка для финансовых метрик и потоковая подгонка для оперативной аналитики.
Инструменты и протоколы интеграции: CDC/лог изменений, потоки событий (Kafka) для онлайн-источников, расписные загрузки для ERP и CRM через ETL/ELT-пайплайны.

Идеальная архитектура предусматривает гибкость для поддержки нескольких моделей атрибуции и согласования. Это достигается через модульную реализацию: ядро DWH, слой метаданных и контракты данных (data contracts), а также концепцию источников данных и их согласования в рамках единого бизнес-слоя атрибуции.

// Пример упрощенного DDL для базовой звездной схемы

CREATE TABLE dim_date (
  date_key INT PRIMARY KEY,
  date_value DATE,
  year INT,
  quarter INT,
  month INT,
  day INT
);

CREATE TABLE dim_channel (
  channel_id INT PRIMARY KEY,
  channel_name VARCHAR(100),
  channel_type VARCHAR(50),
  region VARCHAR(50)
);

CREATE TABLE dim_campaign (
  campaign_id INT PRIMARY KEY,
  campaign_name VARCHAR(100),
  campaign_type VARCHAR(50),
  start_date DATE,
  end_date DATE
);

CREATE TABLE dim_product (
  product_id INT PRIMARY KEY,
  product_name VARCHAR(100),
  category VARCHAR(50),
  sku VARCHAR(50)
);

CREATE TABLE dim_customer (
  customer_id BIGINT PRIMARY KEY,
  hashed_email VARCHAR(100),
  country VARCHAR(50),
  currency VARCHAR(3)
);

CREATE TABLE fact_sales (
  fact_id BIGINT PRIMARY KEY,
  order_id BIGINT,
  date_key INT REFERENCES dim_date(date_key),
  product_id INT REFERENCES dim_product(product_id),
  channel_id INT REFERENCES dim_channel(channel_id),
  campaign_id INT REFERENCES dim_campaign(campaign_id),
  customer_id BIGINT REFERENCES dim_customer(customer_id),
  revenue DECIMAL(18,2),
  units INT,
  cost DECIMAL(18,2),
  currency VARCHAR(3)
);

Примеры хранения touchpoints для атрибуции:

order_touches(order_id, touch_datetime, channel_id, touch_type, touch_rank)

// Пример упрощенного запроса для Last-Touch атрибуции
SELECT
  c.channel_name,
  SUM(f.revenue) AS revenue_by_channel
## FROM fact_sales f
JOIN dim_channel c ON f.channel_id = c.channel_id
GROUP BY c.channel_name
ORDER BY revenue_by_channel DESC;

Модели данных для анализа каналов

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

Channel dimensions: channel_id, channel_name, channel_type, region - позволяют сегментировать по типам каналов (direct, distributor, marketplace, affiliate, retailer) и по регионам.
Campaign dimension: campaign_id, campaign_name, campaign_type, start_date, end_date - для анализа влияния маркетинговых активностей на продажи через каналы.
Touchpoints: order_id, touch_datetime, channel_id, touch_type (online, offline, call), touch_rank - хранение последовательности касаний клиента в рамках заказа.
Fact_sales: основной фактовый слой с показателями revenue, units, cost, currency и ссылками на dimension таблицы.

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

Существуют сценарии, требующие расширения моделей:

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

Обобщение и полнота идентификаторов клиентов: сопоставление по email, телефону или cookie-коду, соблюдение приватности и сохранение линейной истории.

// Пример упрощенного SQL-запроса для атрибутивной модели с учетом всех касаний (time-aware, упрощенно)
WITH touches AS (
  SELECT
    o.order_id,
    ot.channel_id,
    ot.touch_datetime
## FROM order_touches ot
  JOIN orders o ON o.order_id = ot.order_id
),
weights AS (
  SELECT
    t.order_id,
    t.channel_id,
    t.touch_datetime,
    EXP(-0.15 * DATEDIFF(day, t.touch_datetime, CURRENT_DATE)) AS w
  FROM touches t
),
normalized AS (
  SELECT
    order_id,
    SUM(w) AS w_sum
  FROM weights
  GROUP BY order_id
),
attribution AS (
  SELECT
    n.order_id,
    w.channel_id,
    (o.revenue * w.w) / n.w_sum AS attributed_revenue
  FROM weights w
  JOIN orders o ON o.order_id = w.order_id
  JOIN normalized n ON n.order_id = w.order_id
)
SELECT channel_id, SUM(attributed_revenue) AS revenue_by_channel
FROM attribution
GROUP BY channel_id;

Методы атрибуции и сравнения эффективности

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

Last touch (последнее касание): простая и быстрая модель, где выручка приписывается последнему касанию. Преимущества - прозрачность и простота; минусы - игнорирует вклад предыдущих касаний и может завышать эффективность короткоигровых каналов.
First touch (первое касание): выручка приписывается первым касаниям. Подходит для оценки эффективности привлечения, но недооценивает влияние поздних взаимодействий.
Linear: равномерное распределение выручки между всеми касаниями в цепочке. Баланс между простотой и учётом мультиканальности.
Time-decay: учитывает тенденцию к тому, что близкие по времени касания более значимы. Этот подход требует точного учета дат касаний и вытягивает модель к реальной динамике принятия решения.
Position-based (U- или W-образная): доля выручки распределяется между первым и последующим касаниями, с наибольшей долей у первых и последних, что хорошо отражает стартовую и завершающую фазы воронки.
Data-driven attribution (например, на основе гипотезы Шэпли): предполагает обучение модели на исторических данных. Требует достаточного объема данных и вычислительных ресурсов, но обеспечивает адаптивность к структуре мультиканальности в конкретной бизнес-среде.

Преимущества и ограничения моделей:

Прозрачность: простые модели легче аудировать, что особенно важно в регуляторном контексте и для бизнес-пользователей.
Гибкость: time-decay и data-driven требуют более сложной настройки и возможно потребуют дополнительных источников данных и вычислительных мощностей.
Набор данных: для data-driven атрибуции необходимы полные траектории клиентов и корректные идентификаторы.
Контекст и цель: выбор модели зависит от бизнес-целей (например, привлечение vs удержание) и наличия мультиканальных взаимодействий.

Простой пример концептуального алгоритма time-decay атрибуции:

Собрать все touches для каждого order_id с датами и каналами.
Для каждого touch вычислить вес w_i = exp(-λ * days_since_touch_i).
Нормализовать веса: w_i_norm = w_i / sum_j w_j.
Распределить выручку заказа между каналами как revenue_order * w_i_norm.

Суммировать по каналам.

// Пример упрощенной реализации время-декей атрибуции (SQL-скелет)
## WITH touches AS (
  SELECT order_id, channel_id, touch_datetime
  FROM order_touches
),
weights AS (
## SELECT order_id, channel_id, touch_datetime,
         EXP(-0.1 * DATEDIFF(day, touch_datetime, CURRENT_DATE)) AS w
  FROM touches
),
normalized AS (
  SELECT order_id, SUM(w) AS w_sum
  FROM weights
  GROUP BY order_id
),
attribution AS (
## SELECT n.order_id, w.channel_id,
         (o.revenue * w.w) / n.w_sum AS attributed_revenue
## FROM weights w
  JOIN normalized n ON n.order_id = w.order_id
  JOIN orders o ON o.order_id = w.order_id
)
SELECT channel_id, SUM(attributed_revenue) AS revenue_by_channel
FROM attribution
GROUP BY channel_id;

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

В рамках технической архитектуры целесообразно поддерживать две параллельные линии атрибуции: оперативную - last/first touch для повседневной аналитики, и продвинутую - time-decay или data-driven для стратегических решений. Это требует согласованности коллекции touchpoints и единообразия в идентификаторах, чтобы не было расхождений в трассировке влияния каналов на конкретные транзакции.

Best practices по атрибуции:
- Соберите полную траекторию клиентов по каждому заказу: не ограничивайтесь последним касанием, даже если бизнес-решение ориентировано на продажи.
- Поддерживайте версии моделей атрибуции и фиксируйте временные рамки для сравнения.
- Используйте две поверхности: узел атрибуции и поверхность данных продаж для сверки и аудита.
- Обеспечьте прозрачность расчетов: храните параметры, используемые в моделях (λ для time-decay, коэффициенты для U-образной модели и т.д.).
- Протоколируйте качество данных: полной ли является траектория, правильно ли сопоставлены идентификаторы, нет ли пропусков в календарь и в величинах выручки.

Интеграция источников, пайплайны и качество данных

Для непрерывной эксплуатации аналитической среды по каналам продаж необходима выверенная инфраструктура ETL/ELT, управляемые пайплайны и механизмы контроля качества. В рамках технической главы важно обеспечить повторяемость процессов и возможность линейной эксплуатации моделей атрибуции на разных источниках данных.

Интеграция источников: необходимы коннекторы к CRM, ERP, электронной коммерции и рекламным платформам. Ключ к успешной интеграции - согласование идентификаторов и единиц измерения. В контексте мультиканальных продаж следует предусмотреть маппинг channel_id, campaign_id и product_id между системами.
Пайплайны: рекомендуются ELT-подходы с централизованной обработкой бизнес-логики в слоях трансформации. orchestrator-слой (например, Apache Airflow) обеспечивает планирование, зависимостями и мониторинг пайплайнов, а слой моделирования (dbt) - управление схемами и зависимостями трансформаций.
Качество данных: входит набор профилактических проверок (data quality checks), валидации связей между фактовыми и размерными таблицами, сверки сумм и правок, мониторинг задержек, согласование данных по источникам и данным траекторий. В случае мультиканальных данных особенно важна проверка дубликатов касаний и корректной идентификации уникальных заказов.
Данные и приватность: в рамках работы следует придерживаться политики минимизации данных и соответствовать требованиям регуляторных стандарт. При интеграции онлайн и офлайн источников важно обезличивать персональные данные там, где это возможно, сохраняя при этом возможность аудита и повторного сопоставления в бизнес-слоях.

Практические технологии, применяемые в такие архитектуры:

Хранилище и аналитика: ClickHouse как высокопроизводительная колоночная СУБД для оперативной аналитики и агрегирования на лету; PostgreSQL/Greenplum для некоторых слоёв обработки.
Моделирование данных: dbt для управления моделями, тестами и зависимостями между таблицами.
Оркестрация: Apache Airflow для планирования и мониторинга ETL/ELT-процессов; современные альтернативы - Dagster, Prefect.
Интеграция потоков: Kafka для передачи событий от онлайн-платформ к DWH и для реализации streaming-источников.
Интеграция источников: готовые коннекторы к Salesforce, Shopify и другим системам; применение CDC-инструментов для обеспечения актуальности данных.

Обзор российских и открытых решений в контексте данного раздела можно упомянуть ограниченно:

dbt как инструмент моделирования данных и тестирования моделей практически во всех современных BI-стэках.

ClickHouse как пример высокопроизводительного аналитического хранилища для больших объемов данных.

// Пример простого DDL для доп. таблиц touchpoints и агрегации
CREATE TABLE order_touches (
  order_id BIGINT,
  touch_datetime DATETIME,
  channel_id INT,
  touch_type VARCHAR(50),
  touch_rank INT
);

CREATE TABLE touch_aggregates AS
SELECT
  order_id,
  MAX(touch_datetime) AS last_touch_datetime,
  MAX(channel_id) AS last_touch_channel
FROM order_touches
GROUP BY order_id;

Практическая реализация: SQL-запросы, примеры и протоколы интеграции

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

Основные показатели для каналов:
- Выручка по каналу (revenue_by_channel)
- Маржинальность по каналам (margin_by_channel)
- Себестоимость привлечения клиента (CAC), стоимость продажи (Cost of Goods Sold)
- Доля повторных покупок по каналам
- Временная динамика эффективности по месяцам/кварталам

Примеры запросов и протоколов:

Last-touch атрибуция: привязать выручку к последнему касанию по заказу.
Time-decay атрибуция: распределить долю выручки по касаниям с учетом временной дистанции до даты покупки.

Сопоставление с кампаниями: анализ влияния конкретных рекламных кампаний на конверсии и выручку.

// 1) Last-touch атрибуция (простая версия)
SELECT
  c.channel_name,
  SUM(f.revenue) AS revenue_by_channel
## FROM fact_sales f
JOIN dim_channel c ON f.channel_id = c.channel_id
## JOIN (
  SELECT order_id, MAX(touch_datetime) AS last_touch
  FROM order_touches
  GROUP BY order_id
) lt ON lt.order_id = f.order_id
GROUP BY c.channel_name
ORDER BY revenue_by_channel DESC;

// 2) Time-decay атрибуция (упрощенная версия)
## WITH touches AS (
## SELECT o.order_id, ot.channel_id, ot.touch_datetime,
         EXP(-0.15 * DATEDIFF(DAY, ot.touch_datetime, CURRENT_DATE)) AS w
## FROM order_touches ot
  JOIN orders o ON o.order_id = ot.order_id
),
weights AS (
  SELECT order_id, SUM(w) AS w_sum
  FROM touches
  GROUP BY order_id
),
attribution AS (
## SELECT t.channel_id,
         SUM((o.revenue * t.w) / w_sum) AS attributed_revenue
  FROM touches t
  JOIN orders o ON o.order_id = t.order_id
  JOIN weights w ON w.order_id = t.order_id
  GROUP BY t.channel_id
)
SELECT a.channel_id, c.channel_name, a.attributed_revenue
## FROM attribution a
JOIN dim_channel c ON a.channel_id = c.channel_id
ORDER BY attributed_revenue DESC;

Протоколы интеграции данных:
- CDC-потоки для изменений в CRM/ERP с поддержкой снапшетов и обновлениями в реальном времени.
- Очереди сообщений для онлайн-источников и касаний (order_touches) с сохранением времени и типа касания.
- Регрессионные проверки согласования между датами и выручкой по источникам, а также сверки валидности кампаний (campaign_id) на всех слоях.
Контроль качества данных:
- Валидации целостности: каждое заказ-касание должно существовать в orders и в dimension-таблицах.
- Сверка сумм: сумма выручки в факт_Sales должна согласовываться с агрегированными данными по каналам за период.
- Наблюдение за задержками: задержка между датой события и загрузкой в DWH должна соответствовать SLA.
Архитектурные протоколы для версий моделей атрибуции:
- Ведение версий моделей атрибуции и параметров (λ для time-decay, распределение весов для U-образной модели).
- Фиксация параметров в метаданных и возможность отката к предыдущей версии в случае влияния изменений на отчеты.
- Непрерывное тестирование на истории, чтобы убедиться, что новая модель не ухудшает качество интерпретации.

Key takeaways

Эффективный анализ каналов продаж требует целостной архитектуры DWH с поддержкой мультиканальных источников и траекторий клиентов.
Модели данных должны учитывать касания клиента и хранить последовательность взаимодействий для корректной атрибуции.
Различные модели атрибуции имеют свои преимущества и ограничения; выбор модели должен основываться на бизнес-целях и доступных данных.
Интеграция источников и управление качеством данных критически важны для прозрачности и достоверности аналитики.
Практические SQL-решения и прототипные пайплайны должны обеспечивать повторяемость, аудитируемость и возможность эволюции в рамках регуляторных требований.
Важно сочетать простые операционные модели атрибуции с более продвинутыми подходами (time-decay, data-driven), сохраняя прозрачность расчетов.
Использование современных инструментов (dbt, Airflow, ClickHouse) упрощает поддержку моделей и ускоряет внедрение изменений.

FAQ

Какие источники данных считаются обязательными для анализа каналов продаж?

В рамках анализа каналов продаж обязательны данные по заказам и выручке (fact_sales), данные по каналам (dim_channel), а также данные по касаниям клиента (order_touches) для мультиканальной атрибуции. Дополнительно полезно иметь данные по кампаниям (dim_campaign) и по клиентам (dim_customer) для глубокого сегментирования и анализа LTV. В зависимости от бизнеса, важно подключить данные онлайн-источников (CRM, e-commerce), офлайн-торговые данные и данные по маркетинговым кампаниям. Наличие всех указанных источников обеспечивает полноту траекторий клиента и точность атрибуции.

Зачем нужна touch-point история и как она влияет на атрибуцию?

Touch-point история позволяет увидеть все взаимодействия клиента с каналами перед покупкой. Это критично для мультиканальной атрибуции, так как без истории сложно корректно распределить вклад каждого канала. Наличие последовательности касаний позволяет реализовать time-decay, position-based и data-driven модели атрибуции, что в целом повышает точность и устойчивость бизнес-решений.

Как выбрать модель атрибуции в рамках бизнес-задач?

Выбор модели следует основывать на цели анализа. Для оценки эффективности привлечения новых клиентов и влияния первых контактов полезны first-touch или U-образная модель. Для понимания вклада всех каналов в цепочке приобретения лучше time-decay или data-driven атрибуцию. В операционных отчетах часто применяют last-touch для простоты, но рекомендуется поддерживать альтернативную модель в качестве дополнительной панели анализа.

Какие этапы инсталляции архитектуры DWH для анализа каналов рекомендуется соблюдать?

Этапы включают проектирование звездной схемы с фактами продаж и размерностями каналов/кампаний; настройку источников и коннекторов; внедрение пайплайнов ETL/ELT; создание витрины по каналам и по кампаниям; реализацию атрибутивных моделей и рабочих дэшбордов; мониторинг качества данных и регламенты аудита. Важна документированная схема данных, данные контракты и версия модели атрибуции.

Какие базовые технические ограничения следует учитывать?

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

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

Наибольшую ценность дают time-decay и data-driven атрибуции, поскольку они учитывают многоканальные касания и динамику взаимоотношений с клиентом. Time-decay обеспечивает реалистичную оценку вклада каналов в краткосрочной перспективе, а data-driven может адаптироваться к конкретной мультиканальности вашего портфеля источников. Однако для оперативной аналитики часто применяют last-touch как быстрый индикатор, с последующим сравнением с продвинутыми моделями.

Как обеспечить прозрачность и аудит атрибутивных расчётов?

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

Каковы лучшие практики в управлении изменениями схемы данных?

Практики включают управление миграциями схемы через версии (DDL миграции), тестирование изменений на стейджинге перед выпуском в продакшн, сохранение совместимости таблиц, документирование схемы, а также поддержку обратной совместимости для витрин и дэшбордов. Регулярно проводите ревью зависимостей dbt-моделей и обновляйте тесты качества данных.

Какие технические риски существуют при реализации анализа каналов продаж?

Основные риски: неполные или несогласованные данные между источниками, неверная идентификация клиента и заказов, дублирование касаний, задержки загрузки данных и несоответствие между моделями атрибуции и фактическими бизнес-решениями. Риск повышается при переходе к data-driven атрибуции без достаточного объема данных и без контроля за данными траекторий.

Какую роль играют инструменты и технологии в реализации архитектуры?

Инструменты для моделирования данных (dbt) и оркестрации (Airflow) дают управляемость и повторяемость трансформаций. Колонко-ориентированные хранилища (например, ClickHouse) обеспечивают скоростное аггрегирование больших массивов данных в онлайн-аналитических режимах. Потоки данных через Kafka позволяют обрабатыватьTouchpoints практически в реальном времени, сохраняя историю и обеспечивая своевременную атрибуцию. Выбор конкретных технологий зависит от объема данных, требуемой скорости анализа и инфраструктурной стратегии компании.

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

← Предыдущая статья

Анализ маржинального вклада продукта - расчет вклада каждого продукта в прибыль компании

Следующая статья →

Анализ прибыльности каналов продаж - расчет маржи с учетом скидок логистики и коммерческих расходов