Название проекта: Динамическое ценообразование в Телекоме
Постановка задачи: Построить user‑tariff based систему динамического ценообразования и персональных офферов для тарифов/опций на основе признаков пользователя, региона и конкурентов (временные ряды), с доставкой через App/Push/SMS/оффлайн/Voice (звонок по телефону) и триггерную платформу; динамика на опциях, репрайс/миграции для архивных тарифов с целью поддержания долгосрочных планов по доходам, доле рынка, KPI и удержания пользователей. Текущее решение не обладает должной степенью автоматизации, что приводит к необходимости ручной обработке данных и ручному ценообразованию, что приводит к ежедневной просадке прибыли компании и высокому риску человеческого фактора в виде потенциально необоснованных и неправильных решений и неверной трактовке обратной связи от пользователей.
Бизнес‑эффект: Рост ARPU/LTV, снижение оттока, контроль GMV при фиксированной марже, удержание доли рынка; KPI: ARPU, churn, конверсия офферов, маржа, доля рынка, QoS/нагрузка сети.
Таймлайн: ???
I. Определение проблемы
Истоки:
Суть: линейка базовых тарифов и множество архивных (≈5–10k); частые изменения абонплаты недопустимы; тренд к персонализации; различия по регионам и каналам.
Ограничения: лимит повышения для архивных (регулятор ≤10%), цены/ассортимент зависят от региона и канала, определение реального пользователя SIM, нагрузка сети. Сейчас нет истории наценок на многие из опций, так как они традиционно всегда стоили одинаково. Такое же ограничения для ввода персональных тарифов в новый канал или в существующий канал, но с новыми условиями – сначала собирается история покупок, затем подключается dynamic pricing.
Происхождение тарифов: базовые тарифы создаёт маркетинг; под задачи ЦО согласуются персональные/сегментные тарифы; для миграций с архивных тарифов также запускаются новые планы. Персональные и персонализированные тарифы - разное, персональные/ползунковые (далее везде будет ползунковые) тарифы, пользователь самостоятельно определяет нужные ему параметры и цена автоматически пересчитывается, персонализированный - это компания самостоятельно предлагает тариф, либо выбор из базовых тарифов, в них допустима динамика.
Целеполагание: долгосрочный план доходов до 2028 года; квартальное планирование с заказчиками; между циклами поддерживаем текущие KPI.
Текущий процесс: 1–2 раза в год репрайс архивов или миграции; динамика разрешена на опциях; для разовых интернет‑пакетов используется uplift‑моделирование + бандиты; промо часто по правилам (триггерная платформа).
Триггеры: существует триггерная платформа (event → offer); напр., при 90% исчерпании пакета сразу отправляется SMS с опцией со скидкой.
Важность и причины:
Цели: рост ARPU/LTV, снижение оттока, удержание доли рынка, улучшение юнит‑экономики, балансировка нагрузки сети.
Таргеты: max ARPU, churn prevention, контроль GMV при фиксированной марже.
Польза: выше конверсия персональных предложений, меньше массовых скидок, таргетированные региональные акции, лучшее покрытие сегментов пользователей.
Стоимость текущей проблемы: потеря маржи от массовых скидок, недоизвлечение willingness‑to‑pay, churn к конкурентам, неэффективные промо.
Предыдущие попытки:
Базовая тарифная система с большим архивом; периодический репрайс; миграции на новые тарифы; частичная персонализация.
На опциях: динамическое ценообразование для разовых интернет‑пакетов через uplift‑моделирование и бандитов.
Что сработало: персонализация тарифа в приложении > массовые SMS; миграции увеличивают ARPU; бандиты дают uplift.
Что не сработало: частые изменения абонплаты вызывают негатив; массовые промо бьют по марже.
Улучшения: расширить динамику на больше опций, автоматизировать региональные кампании, увязать решения с нагрузкой сети и активностью конкурентов end‑to‑end.
Режимы отказа: неверные цены/правила → санкции/PR‑риски; перегруз сети; коллизии каналов; дрейф моделей; ошибки в идентификации владельца SIM; утечки данных.
Стоимость ошибок: штрафы и регуляторные риски, рост оттока, потеря маржи, рост нагрузки на поддержку.
Контроли: guardrails по ценам (для архивных ≤10%), eligibility/правила справедливости, регион/канал‑скоупинг, rate‑limits, канареечные релизы, офлайн/онлайн‑валидация, алерты по KPI, ручной override, объяснимость решений.
Текущая реализация:
Базовые тарифы (тарифы из открытой линейки) — продвигаются оператором, позиционируются под разные сегменты (студенты, пенсионеры, семьи). Выбираем не мы, ими занимается команда маркетинга.
Архивные тарифы — тысячи исторически накопленных продуктов, которые нельзя динамически менять.
Для них либо применяется репрайс 1 раз в год: обучается бустинг, таргет – активность абонента, предиктим отток, оптимизируем arpu с ограничением на размер репрайса.
Если делаем репрайс персональных тарифов: учим модель для предсказания “справедливой цен” (сколько должен платить абонент за его лимиты), подтягиваем цену, если она ниже “справедливой” и ниже цен конкурентов
Миграции на персональные тарифы (в целях повышения arpu).
Формируются в заданных бизнесом границах: min/max/step по GB, минутам, SMS. Стоимость считается по фиксированной региональной формуле вида k_min * min + k_gb * gb^2 + k_sms * sms + k_base. Коэффициенты фиксированы и не изменяются командой ценообразования; управляемая переменная — скидка поверх рассчитанной цены (типично 5–70%).
По истории строится модель вероятности взятия персонального тарифа; далее делается сетка параметров (gb, min, sms, скидка), выполняется скоринг и выбор оптимума по целевой функции (например, max ARPU/GMV при маржинальных/регуляторных ограничениях). Эластичность по скидке получается эмпирически: для фиксированного (gb, min, sms) варьируем скидку и наблюдаем изменение score/конверсии.
Пример1. Модель по подбору следующего тарифа. Учим модель, в которой таргет - 1 - абонент в течение некоторого времени сменит текущий тариф на более дорогой, 0 - иначе. Скорим всех активных абонентов, берём топ и для них готовим персональный оффер. Оффер предлагается в голосовм канале. Обновление предсказаний раз в неделю.
Пример2. Модель по подбору персонального тарифа в салонах связи. Учим модель, в которй таргет - тариф из открытой линейки. Скорим всех активных абонентов, подбираем исходя из его текущих персональный оффер. Оффер предлагается только в салонах связи. Обновление предсказаний раз в неделю.
Опции.
По опциям можем управлять: ценой, объёмом (“чиселкой” гигабайтов) и персональными скидками.
Большинство опций используется при исчерпании пакета, может быть несколько сценариев, разовый пакет, подписка на доп интернет, если потребление стабильно выше, апгрейд разового пакета, если закончились изначальные. Могут быть краткосрочные сценарии, когда клиент покупает пакет на несколько месяцев. Некоторые из опций направлены на качество (скорость) интернета.
Рекомендации опций (триггеры): при исчерпании трафика предлагаем варианты — (1) разовый пакет, (2) подписка на доп‑интернет, если потребление стабильно выше, (3) апгрейд пакета, если у клиента также кончаются минуты/SMS или они нерелевантны. Учитываем краткосрочные сценарии 1–3 месяца (командировки/сезонность), когда клиенту выгоднее временные опции, чем постоянный переход на более дорогой тариф.
Существует широкий набор опций, но ЦО внедрено только на одну из них.
Ежедневно собираем пул абонентов у которых израсходован лимит более чем X%, определеяем кто из абонентов склонен взять опцию, строим модель, которая предсказывает какой объём опции возьмет клиент, бандитами подбирается оптимальная скидка. Скоринг ежедневный.
GMV‑декомпозиция: GMV_Total = GMV_Tariffs + GMV_Options. Для тарифов тюним сегментные эластичности через сетку персональных предложений; для опций — динамическое ценообразование и управление ассортиментом рекомендаций.
Каннибализация: мониторим взаимное влияние тарифов и опций, а также продуктов (напр., классическое ТВ vs интернет‑ТВ; модемы/«свистки» vs раздача с телефона). Вводим guardrails и мониторинги, чтобы ловить неожиданные просадки.
Способы управления: (1) скидка на персональный тариф, (2) параметры и цены опций (включая объём), (3) логика рекомендаций/триггеры и каналы доставки (App/Push/SMS/оффлайн/Voice).
II. Метрики и функции потерь
i. Метрики
Бизнес: ARPU (Average Revenue per User), GMV (Gross Merchandise Value), маржа, LTV (Lifetime Value), churn, конверсия офферов, доля рынка, выручка от опций, NPS (Net Promoter Score)/CSAT (Customer Satisfaction Score).
Модель: ROC‑AUC/PR-AUC/LogLoss (take‑rate); Brier Score, ECE для калибровки, uplift@K/CATE (для промо/опций), mean regret (бандиты).
Связь с бизнес целями: оптимизируем ARPU/GMV при ограничениях на маржу и конверсию; снижаем churn за счёт апгрейдов/персональных тарифов; контролируем каннибализацию между различными каналами продаж.
Trade-offs: ARPU vs churn; GMV vs маржа; краткосрочный GMV vs LTV; персонализация vs справедливость/регуляторика.
ii. Функции потерь
Take‑rate: Focal;
Uplift/промо: S/T/DR‑learner; цель — uplift@K/инкрементальная выручка.
Бандиты: regret .
III. Датасет
i. Источники данных
Внутренние: биллинг/CDR/балансы/остатки, история тарифов/опций/каталог/ограничения, CRM/триггеры/кампании, логи App/Push/SMS/оффлайн, отклики/продажи, A/B‑платформа, QoS сети (нагрузка/покрытие), регион/канал.
Модель спроса должна описывать/предсказывать метрики на прошедших периодах промо/не промо в разрезах различных сезонов на выбранных сегментах пользователей
Если для создания кривых эластичности использовались данные подготовленные конкретным ETL пайплайном, до данные на которых они будут тестироваться должны выходить из точно такого же ETL пайплайна
Может ли быть утечка данных?:
В случае создания модели на кривых эластичности - дата лика быть не может. Проговорили отдельно - действительно лика не будет, т.к. мы просто создаем кривую эластичности в моменте, а не пытаемся “спрогнозировать” в моменте в будущем. Если мы говорим про природу кривой - она нестационарна в контексте времени (существуют отдельные кривые для сезонов).
Какие временные ограничения существуют?:
Чем больше данных - тем лучше, поэтому стоит взять все имеющиеся данные до момента существующих пивотов в стратегиях компаний.
Кривые эластичности нестационарны, необходимо учитывать сезонность.
ii. Инференс
Как модель делает предсказания?:
Возможно два режима предсказаний: в абсолютах и в пропорциях
Режим в абсолютах:
Берем существующие кривые эластичности как функции спроса от наценки на персонализированный тариф
Считаем сетку спроса/наценку для каждого персонализированного тарифа/опции
Считаем методом Лагранжа оптимальное решение для заданного набора ограничений
Полученное решение и является итоговым выходом пайплайна
Режим в пропорциях:
Берем существующие нормализованные кривые эластичности как функции спроса от наценки на персонализированный тариф
Выбираем из истории нужный похожий участок времени для оценки пропорций продаж, либо используем модель предсказания пропорций в будущем в зависимости от скидок и прочих внешних факторов
Считаем методом Лагранжа оптимальное решение для заданного набора ограничений
Полученное решение и является итоговым выходом пайплайна
Каков горизонт предсказания
Квартал
Какие ограничения учитывать?:
В таком формате мы работаем в разрезе групп людей, а не индивидуально для каждого
Не можем менять слишком часто наценки - пользователи негативно реагируют
Наценка в пределах 10%
iii. Внутренние и внешние циклы
Как будем валидировать модель?:
Сопоставляем с историческими данными, мы валидируем как модель описывает поведение, т.е. соответствуют ли кривые эластичности тому, что было на истории, так и расчет интересующих нас метрик, т.е. соответствуют ли аплифты метрик тому, что мы реально наблюдали. В том числе можно бутстрапить метрики для получения оценки доверительного интервала интересующих нас метрик.
Какую стратегию кросс‑валидации используем?:
Кажется что никакую
Как обрабатываем временные ряды?
Для построения кривых эластичностей необходимы изменчивые последовательности, где наценка меняется и меняется соответственно спрос
Нас также интересует влияние временных рядов друг на друга, один тариф может не меняться, но параллельно ему какой-то может ценообразовываться, поэтому скорее всего надо делать матрицу влияния временных рядов тарифов друг на друга, благо это можно сделать т.к. тарифов малое число
iv. Частота обновления
Как часто обновляем модель?:
Как только бизнес готов принимать результаты из АБ тестов (обычно через несколько последовательных запусков одной и той же модели), предварительно нужно убедиться, что модель стареет/не стареет за счет перманентного дефолтного бакета
Что является триггером обновления?:
Набор условий, который должен появиться из EDA модели, если модель имеет свойство стареть. Мы должны определить необходимый порог по сроку использования модели. Если модель не склонна к старению - только в результате выкатки новой модели.
Как обрабатываем дрейф данных?
Отслеживаем, что дрейф данных не приводит к изменению метрик модели, если дрейф является причиной изменения показателей модели - вводим какие-то компенсирующие механизмы (чаще обновляем, добавляем дополнительные фичи, какие-то ограничения на аутпуты, прокси ограничения в лагранже)
V. Baseline
i. Константный baseline
Какие простые бейзлайны используем?:
В данном случае константным бейзлайном будет текущий продовый вариант наценок
Как будем с ними сравниваться?
На оффлайне - относительно него мы будем считать аплифты метрик в лагранже
В онлайне в АБ тесте мы будем считать аплифты метрик
Каков минимально приемлемый результат?:
Серый непрокрашенный тест
ii. Базовые модели
Какие архитектуры попробуем?:
Кривые эластичности + лагранж (эластичности можно строить различными способами, дуговая эластичность, кривые обученные катбустом)
Каковы компромиссы?
Минимальное время на разработку, высокая интерпретируемость, простая модель
Как будем сравнивать?
Сравнивать будем с текущим решением, которое уже используется
iii. Базовые признаки
С какими признаками начнём?
GMV в моменте нормированный на GMV оконный средний на квартал
Как измерим важность признаков?
Для кривой эластичности нет как таковых важности признаков
Какой feature‑инжиниринг нужен?
Фичей как таковых нет, нужно очень аккуратно построить методологию расчета кривой эластичности
