Reverse Engineering ціноутворення: Як працюють алгоритми Big Data Discrimination

📌 Архітектура системи: загальний огляд

Перш ніж заглиблюватися в деталі, важливо зрозуміти загальну картину. Сучасна система dynamic pricing в OTA — це не один алгоритм, а ланцюжок із щонайменше п'яти незалежних підсистем, кожна з яких отримує свій шматок даних і передає результат далі.

Типовий шлях запиту від моменту, коли користувач відкриває додаток, до моменту, коли він бачить ціну:

1. Signal Collection Layer — збір сигналів з пристрою (fingerprint, геолокація, тип з'єднання)
2. Identity Resolution Service — зіставлення поточного сесійного профілю з довгостроковим профілем користувача
3. Pricing Engine — обрахунок базової ціни з урахуванням попиту і пропозиції
4. Personalization Layer — коригування ціни на основі ML-профілю конкретного користувача
5. Ranking Service — впорядкування результатів з урахуванням комісії та бізнес-правил

Весь цей ланцюжок має укластися в 200–400 мс — бо саме такий час очікування вважається прийнятним для мобільного застосунку. Саме тому архітектура побудована на мікросервісах з агресивним кешуванням і асинхронною обробкою.

Схема взаємодії компонентів:

[Клієнт: iOS/Android/Web]
        |
        | HTTP/2 + TLS
        v
[API Gateway]  ←→  [Auth & Session Service]
        |
        | gRPC (внутрішня мережа)
        v
[Orchestration Service]
    /       |        \
   /        |         \
[Signal   [Identity   [Pricing
Collection] Resolution] Engine]
   \        |         /
    \       |        /
     v      v       v
  [Personalization ML Service]
              |
              v
        [Ranking Service]
              |
              v
     [API Response Builder]
              |
              v
  {"hotels": [...], "price": X}

Зверніть увагу: ціна, яку бачить користувач у JSON-відповіді, — це вже результат роботи щонайменше чотирьох сервісів. Жоден із них окремо не «дискримінує» — але разом вони можуть повернути різну ціну для двох людей, що шукають один і той самий готель в одну і ту ж ніч.

📌 Архітектура динамічного прайсингу: мікросервіси в реальному часі

Pricing Engine — серце системи. Його завдання — встановити базову ціну до того, як персоналізація внесе свої корективи. Ця базова ціна вже є динамічною: вона змінюється щохвилини або навіть щосекунди залежно від ринкових умов.

Джерела даних для Pricing Engine:

Система одночасно обробляє кілька потоків даних. Historical demand data — це агреговані дані про бронювання за аналогічні періоди попередніх років з урахуванням сезонності, свят і локальних подій. Real-time demand signals — поточна кількість активних сесій і пошуків, частота запитів до конкретного готелю, кількість переглядів сторінки готелю за останню годину. Competitor monitoring — автоматичне сканування цін конкурентів (Meituan, Fliggy, Booking.com) через парсинг їхніх публічних API або веб-сторінок; саме це і стало предметом звинувачень у справі Trip.com.

Математична модель:

В основі більшості сучасних систем dynamic pricing лежить концепція price elasticity — чутливості попиту до зміни ціни. Базова формула:

Price_optimal = Base_cost × (1 + margin_target) × Demand_multiplier × Competitive_index

де:
  Base_cost       = собівартість номера для OTA (net rate від готелю)
  margin_target   = цільова маржа платформи (зазвичай 10–25%)
  Demand_multiplier = поточний попит / середній попит (1.0 = норма)
  Competitive_index = коригування відносно цін конкурентів

Але це лише перший рівень. Demand_multiplier сам є результатом роботи окремої ML-моделі, що прогнозує попит на основі десятків факторів: погода, локальні події, авіарейси в місто, активність у соцмережах. Наприклад, якщо в Instagram різко зростає кількість постів з хештегом певного міста — система розцінює це як сигнал підвищеного попиту і збільшує мультиплікатор.

Мікросервісна архітектура та latency:

Кожен мікросервіс у ланцюжку додає затримку. Щоб вкластися в 200–400 мс, платформи використовують кілька стратегій. Pre-computation — ціни для популярних дат і готелів розраховуються заздалегідь і кешуються в Redis або Memcached; при запиті система просто повертає кешоване значення, не запускаючи повний ланцюжок. Async enrichment — відповідь повертається з базовою ціною, а персоналізація «доважується» асинхронно і оновлює UI через WebSocket або при наступному запиті. Feature store — ML-фічі користувача (його цінова категорія, score платоспроможності) зберігаються в окремому сховищі і оновлюються не в реальному часі, а пакетно — раз на кілька годин.

Саме через feature store одна і та сама людина може бачити різні ціни в різних сесіях: якщо між сесіями відбулося пакетне оновлення ML-профілю — наприклад, через нові дані про клік на преміум-готель — система перевела її в іншу цінову категорію.

Джерело: Kitrum: AI-Powered Dynamic Pricing in Travel, AIMultiple: Dynamic Pricing Algorithms.

📌 Device Fingerprinting: чому iOS коштує дорожче за Android

Це найбільш дискутована і найменш публічно документована частина системи. Дослідження Чиказького університету та аналіз Wall Street Journal показали: тип пристрою і операційна система статистично корелюють із готовністю платити. Власники iPhone в середньому мають вищий дохід, ніж власники Android-пристроїв середнього цінового сегменту. Алгоритм це знає.

Що збирає Signal Collection Layer:

На рівні мобільного SDK система збирає такі сигнали:

// iOS SDK збирає:
{
  "idfv": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",  // Identifier for Vendor
  "device_model": "iPhone15,4",    // iPhone 15 Pro Max
  "os_version": "17.4.1",
  "screen_resolution": "2796x1290",
  "timezone": "Asia/Shanghai",
  "language": "zh-Hans-CN",
  "network_type": "wifi",          // wifi vs cellular
  "carrier": "China Mobile",
  "app_version": "8.56.0",
  "jailbreak_detected": false
}

// Android SDK збирає:
{
  "gsf_id": "XXXXXXXXXXXXXXXX",    // Google Services Framework ID
  "device_model": "Redmi Note 12", // mid-range device
  "manufacturer": "Xiaomi",
  "os_version": "13",
  "screen_resolution": "2400x1080",
  ...
}

Зверніть увагу: iOS повертає IDFV (Identifier for Vendor), Android — GSF ID (Google Services Framework Identifier). Обидва є стабільними ідентифікаторами, які не змінюються при перезапуску застосунку і зберігаються навіть після очищення кешу.

Як device model потрапляє в цінову логіку:

Безпосередньо — ніколи. Жоден розробник не напише if (device == "iPhone15") price *= 1.15. Це було б занадто очевидно і легко довести. Замість цього device model стає однією з фічей у ML-моделі, яка навчається на реальних даних бронювань.

Логіка така: система навчається на мільйонах транзакцій і виявляє паттерн:

Користувачі з iPhone 14 Pro і вище + Wifi + локація "Pudong, Shanghai"
  → конверсія в бронювання при ціні $150: 34%
  → конверсія в бронювання при ціні $180: 31%
  → дельта незначна → можна показувати $180

Користувачі з Redmi Note 11 + Cellular + локація "Putuo, Shanghai"
  → конверсія при $150: 28%
  → конверсія при $180: 14%
  → дельта суттєва → оптимальна ціна $150

Ніхто не «дискримінує» за пристроєм. Модель просто оптимізує конверсію — і виявляє, що різні пристрої відповідають різній ціновій чутливості. Результат той самий: власники дорогих iPhone бачать вищі ціни. Джерело: University of Chicago Law Review: Algorithmic Price Discrimination.

Browser fingerprinting для веб-версії:

На веб-платформі замість SDK-ідентифікаторів використовується комбінація браузерних сигналів. Система збирає User-Agent, роздільну здатність екрану та глибину кольору, список встановлених шрифтів через Canvas API, WebGL renderer (дозволяє визначити модель GPU), часовий пояс і мову браузера, наявність блокувальника реклами. Комбінація цих параметрів дає унікальний «відбиток браузера», що зберігається навіть після очищення cookies. Точність сучасних систем fingerprinting сягає 99% для повторної ідентифікації — це означає, що система з ймовірністю 99% впізнає той самий браузер навіть після повного очищення даних. Джерело: Group-IB: Device Fingerprinting.

📌 Персоналізація через ML: як рахують «поріг болю» ціни

«Поріг болю» — неформальна назва концепції Willingness To Pay (WTP): максимальна ціна, яку конкретний користувач готовий заплатити, не відмовившись від покупки. Визначення цього порогу для кожного користувача — і є ключовим завданням персоналізаційного шару.

Які дані формують WTP-профіль:

Поведінкові сигнали поточної сесії: кількість повторних переглядів одного готелю (чим більше — тим вища WTP), час, проведений на сторінці готелю, прокрутка до розділу «відгуки» або «деталі номера» (сигнал серйозного інтересу), клік на «порівняти номери» або «переглянути всі фото», відкриття сторінки бронювання без завершення покупки (abandoned checkout — потужний сигнал).

Довгострокові сигнали з профілю: середній чек попередніх бронювань (якщо є акаунт), клас готелів, які переглядав раніше, частота бронювань (лояльний клієнт vs разовий), реакція на минулі знижки (брав знижку 5%? — WTP трохи нижча).

Зовнішні сигнали: IP-адреса і геолокація — дохід у районі проживання, модель пристрою і його ринкова вартість, тип тарифного плану мобільного оператора (якщо доступно через SDK).

Як це реалізовано технічно:

Найпоширеніший підхід — gradient boosting моделі (XGBoost, LightGBM) або нейронні мережі, навчені на даних про реальні конверсії. Модель отримує вектор фічей і повертає скор — умовну «цінову категорію» користувача:

Input features vector:
[device_tier, session_depth, repeat_views, booking_history_avg,
geolocation_income_index, time_to_checkin, group_size, ...]
Output:
{
"price_tier": "premium",        // або "standard", "budget"
"wtp_score": 0.82,              // 0.0 = дуже чутливий до ціни, 1.0 = нечутливий
"discount_sensitivity": 0.23,  // наскільки знижка впливає на конверсію
"urgency_factor": 0.61         // чи є ознаки термінового пошуку
}

Цей скор передається в Pricing Engine, який застосовує до базової ціни мультиплікатор. Наприклад, при wtp_score > 0.75 система може показати ціну на 8–15% вищу за базову; при wtp_score < 0.3 — автоматично показати знижку або «спеціальну пропозицію».

Abandoned checkout як пастка:

Один із найдискутованіших патернів — реакція на незавершене бронювання. Дослідження показують дві протилежні стратегії. Стратегія «приманки»: після незавершеного бронювання система надсилає push-повідомлення зі знижкою 5–10% — це підтверджує, що «справжня» ціна насправді була нижчою. Стратегія «тиску»: натомість система підвищує ціну або показує «залишився 1 номер» — знаючи, що користувач вже зацікавлений і з меншою ймовірністю піде до конкурента. Яку стратегію застосовувати — вирішує A/B-тестування на рівні конфігурації сервісу. Джерело: Personalized Pricing: History, Economics, and Impact of AI-Driven Price Discrimination.

📌 Ranking Bias: технічні методи маніпуляції видачею

Навіть якщо ціна «чесна», результат пошуку може бути маніпульований. Ranking Bias — це практика, коли алгоритм ранжування готелів у видачі враховує не лише релевантність для користувача, але й комерційні інтереси платформи.

Як офіційно пояснюють фактори ранжування:

Більшість OTA публічно заявляють, що ранжування залежить від: відповідності критеріям пошуку, рейтингу та кількості відгуків, ціни відносно аналогічних готелів, швидкості підтвердження бронювання, конверсії (CTR + booking rate). Дослідження SpringerLink підтверджує: готель на першій позиції отримує в рази більше кліків, ніж на п'ятій. 80–90% бронювань відбуваються з перших двох сторінок видачі. Джерело: SpringerLink: A Re-rank Algorithm for Online Hotel Search.

Що не згадується в публічній документації:

Commission boost — готелі, що погоджуються на вищу комісію, отримують підвищений ранговий скор. Це відкрито визнається деякими платформами як «Preferred Partner Program», але механізм не розкривається. Дослідження Cloudbeds підтверджує: «деякі канали дозволяють opt-in на вищі комісії, щоб підняти готель вище у результатах — практика, яку називають OTA bias». Джерело: Cloudbeds: OTA Ranking Optimization.

«Dimming» — зниження видимості готелю без явного повідомлення. Готель, який пропонує нижчу ціну на власному сайті або відмовляється від акції, може отримати: знижений ранг у пошуку, приховування спеціальних іконок і бейджів «Популярний вибір», зменшення кількості відображуваних фото в картці, виключення з email-розсилок і push-рекомендацій. Джерело: MyLighthouse: OTA Ranking Factors.

Promotional participation weight — участь у знижкових акціях платформи є неявним фактором ранжування. Готелі, що не беруть участь у «Flash Sale» або «Early Bird» кампаніях, систематично отримують нижчий ранг в алгоритмі. Це і є суть звинувачень проти Trip.com: «примус до участі в акціях під загрозою зниження трафіку».

Технічна реалізація в API:

На рівні коду Ranking Service зазвичай реалізований як Learning-to-Rank (LTR) модель — різновид supervised learning, де модель навчається ранжувати об'єкти відносно одне одного. Для кожного готелю формується ranking score:

ranking_score = w1 * relevance_score
+ w2 * review_score
+ w3 * price_competitiveness
+ w4 * conversion_rate_historical
+ w5 * commission_tier          // ← прихований комерційний фактор
+ w6 * promotion_participation  // ← участь в акціях платформи
+ w7 * platform_exclusivity     // ← ексклюзивність угоди
// Вагові коефіцієнти w1..w7 — власність платформи,
// не розкриваються партнерам

Партнери-готелі бачать лише фінальний ранг. Вагові коефіцієнти і склад факторів — комерційна таємниця. Саме через цю непрозорість регулятори і вимагають Algorithm Transparency: право партнерів знати, чому їхній готель опустився в рейтингу.

💼 Від теорії до практики: що показав кейс Trip.com

Справа Trip.com унікальна тим, що вперше в Азії регулятор отримав доступ до внутрішньої документації ШІ-системи ціноутворення і кваліфікував її роботу як антимонопольне порушення.

«AI Price Adjustment Assistant» Trip.com — це саме той Pricing Engine із Competitive Monitoring, що ми описали вище, але з одним критичним доповненням: автоматичне виконання без згоди партнера. Система не тільки моніторила ціни Meituan — вона автоматично знижувала ціни готелів-партнерів, щоб Trip.com завжди виглядав дешевше. Готель дізнавався про зниження ціни вже після того, як воно відбулося — якщо взагалі дізнавався.

Технічно це виглядало приблизно так:

// Псевдокод логіки Trip.com AI Price Adjustment
function adjustHotelPrice(hotelId, currentPrice) {
const competitorPrice = scrapeCompetitorPrice(hotelId, "meituan");
if (currentPrice > competitorPrice) {
const newPrice = competitorPrice - DELTA; // наприклад, -10 юанів
updateHotelPrice(hotelId, newPrice);      // ← без підтвердження готелю
logAdjustment(hotelId, currentPrice, newPrice, "auto_competitive");
}
}
// Функція викликається автоматично кожні N хвилин
// для всіх готелів, що підписали угоду про участь
// в "автоматичному ціновому інструменті"

Проблема не в логіці алгоритму — вона технічно коректна. Проблема в умовах угоди: готелям не пояснювали, що «підписка на інструмент» означає повну передачу контролю над ціноутворенням. А відмова від інструменту каралась зниженням рангу — що і є визначенням примусу. Джерело: Pandaily: Trip.com AI Price Adjustment Assistant Shutdown.

💼 Етика коду: чи можна запрограмувати «справедливість»

Питання не риторичне. Після кейсів Alibaba, Meituan і тепер Trip.com у галузі йде серйозна дискусія про те, як технічно реалізувати «справедливе» ціноутворення.

Проблема 1: Fairness у ML — математично складне завдання

У machine learning існує кілька формальних визначень «справедливості», і вони математично суперечать одне одному. Individual fairness вимагає, щоб схожі користувачі отримували схожі ціни. Group fairness вимагає, щоб різні демографічні групи в середньому платили однаково. Counterfactual fairness вимагає, щоб ціна не залежала від захищених атрибутів (раса, стать, місце проживання). Досягти всіх трьох одночасно — математично неможливо. Будь-яка реалізація «справедливості» — це компроміс між цими визначеннями.

Проблема 2: Proxy discrimination

Навіть якщо прибрати «несправедливі» фічі (device model, геолокація) з моделі — інші фічі можуть бути їх проксі. Час доби пошуку корелює з часовим поясом і локацією. Мова застосунку корелює з рівнем доходу. Тип тарифного плану оператора корелює з демографічним профілем. ML-модель «знайде» кореляцію навіть після видалення явних дискримінаційних змінних. Це і є найскладніша технічна проблема «чесного ціноутворення».

Практичні підходи до Algorithm Transparency:

Кілька технічних напрямків, що активно розробляються. Explainable AI (XAI) — такі інструменти, як LIME або SHAP, дозволяють «пояснити» рішення моделі для конкретного прикладу: які фічі найбільше вплинули на ціну. Це не усуває дискримінацію, але робить її видимою. Differential Privacy — техніка додавання контрольованого шуму до навчальних даних, що знижує здатність моделі «запам'ятовувати» індивідуальні патерни. Adversarial debiasing — навчання моделі так, щоб вона не могла передбачити захищений атрибут з результату ціноутворення. Джерело: ScienceDirect: Algorithmic pricing — Implications for marketing strategy and regulation.

Регуляторна відповідь: від звинувачень до стандартів

Після кейсу Trip.com SAMR сигналізує про намір розробити технічні стандарти для алгоритмів ціноутворення. Ймовірно, вони включатимуть: обов'язковий аудит алгоритмів для платформ із часткою ринку понад 30%, право партнерів на пояснення причин зміни ціни або рангу, заборону автоматичного коригування без підтвердження партнера, логування всіх цінових рішень з можливістю перевірки регулятором.

💼 Регуляторний вектор: що змінюється для розробників

Якщо ви розробляєте системи ціноутворення або персоналізації — ось що вже зараз варто враховувати в архітектурних рішеннях.

EU AI Act (набрав чинності 2024):

Системи, що використовують біометричні дані або поведінкові патерни для «маніпулювання поведінкою користувачів у спосіб, що завдає їм шкоди» — класифіковані як High Risk або Unacceptable Risk. Персоналізоване ціноутворення поки що не потрапляє в заборонену зону, але вже вимагає документації та аудиту для платформ у ЄС.

Китайські «Правила рекомендаційних алгоритмів» (2022, оновлено 2024):

Вимагають від платформ: надавати користувачам можливість відмовитись від персоналізованих рекомендацій, пояснювати принципи роботи алгоритму на запит, не використовувати Big Data для дискримінаційного ціноутворення («殺熟» — «вбивство лояльних клієнтів» вищими цінами). Саме остання вимога і стала правовою основою розслідування Trip.com.

❓ Часті питання (FAQ)

Чи всі OTA використовують персоналізоване ціноутворення?

Технічна можливість є у більшості великих OTA (Booking.com, Expedia, Airbnb, Trip.com). Наскільки агресивно вони її використовують — різниться. Найбільш задокументовані кейси стосуються авіаквитків (Delta, American Airlines) та туристичних платформ в Китаї.

Чи законне персоналізоване ціноутворення?

В більшості юрисдикцій — так, якщо не порушує антидискримінаційне законодавство і не є результатом зловживання домінуючим становищем. Китайські «Правила рекомендаційних алгоритмів» і EU AI Act створюють нові обмеження, але повної заборони немає.

Що таке «殺熟» (shā shú) і чому це важливо?

«Вбивство лояльних» — китайський термін для практики, коли платформа показує вищі ціни постійним клієнтам, знаючи, що вони з меншою ймовірністю порівнюють ціни. Технічно реалізується через WTP-модель: висока частота бронювань → високий wtp_score → вища ціна. Саме ця практика є предметом спеціальної заборони в китайському законодавстві.

Як перевірити, чи застосовується до мене персоналізація?

Найпростіший метод — порівняти ціну в авторизованому і неавторизованому стані, з різних пристроїв або через VPN з іншою геолокацією. Якщо різниця суттєва (понад 5–10%) — це сигнал персоналізації. Детальний технічний гайд — у нашій статті «Як обійти туристичні алгоритми».

Чи може розробник «побудувати» справедливий алгоритм ціноутворення?

Технічно — частково. Можна прибрати явно чутливі фічі, додати fairness constraints у функцію втрат, провести регулярний demographic parity audit. Але через proxy discrimination і математичні суперечності між визначеннями fairness — повна «справедливість» залишається відкритою дослідницькою проблемою.

✅ Висновки

Dynamic pricing у сучасних OTA — це не один алгоритм, а екосистема взаємопов'язаних сервісів, кожен із яких окремо виглядає нешкідливо, але разом вони можуть формувати систематичну цінову дискримінацію.

Три технічні висновки для розробників:

1. Device fingerprinting — це вже не лише fraud prevention. Ті самі сигнали, що збираються для ідентифікації шахраїв, використовуються для побудови цінового профілю. Архітектурно ці системи часто використовують спільну інфраструктуру — що робить межу між безпекою і дискримінацією розмитою.
2. «Алгоритм вирішив» — не аргумент. Регулятори все частіше вимагають пояснення не лише результату, а й механізму. Audit trail і XAI — вже не nice-to-have, а архітектурна вимога для платформ із значною ринковою часткою.
3. Згода партнера — технічна вимога, не лише юридична. Кейс Trip.com показав: автоматизація без явної згоди стає юридичним ризиком навіть якщо технічно система працює коректно.

Якщо вас цікавить практична сторона — як захистити себе від цих алгоритмів при бронюванні — читайте наш наступний матеріал: «Як обійти туристичні алгоритми: технічний гайд із захисту від переплат».