252 → 36 годин роботи команди на місяць: як ми оптимізували процес роботи з Google Ads для OLX

Сім годин на одну ітерацію. Шість ітерацій на місяць. Шість спеціалістів. Разом 252 години, які команда витрачала лише на те, щоб вирішити, на скільки змінити ставки в Google Ads для OLX Group.

Ми формалізували логіку PPC-спеціалістів, перетворили її на матрицю з 3600 сценаріїв і додали ШІ як додатковий рівень перевірки. У результаті цей процес скоротився до 36 годин на місяць. У кейсі показуємо, як працює така гібридна система, чому розрахунок ставок ми не передали ШІ та де в процесі все ще потрібне рішення спеціаліста.

Хто наш партнер

OLX Group — міжнародна група онлайн-платформ для купівлі та продажу товарів, послуг, автомобілів і нерухомості.

Контекст і ціль 

Netpeak співпрацює з OLX у напрямі PPC з 2015 року. Спочатку команда відповідала за ринки України, Казахстану та Узбекистану. У 2022 році до них додалися європейські країни — Польща, Румунія, Болгарія та Португалія.

Наразі основним рекламним каналом є Google Ads — на нього припадає понад 90% витрат. Решта бюджету здебільшого розподіляється між Meta Ads, а також тестовими каналами, зокрема Criteo, TikTok Ads і RTB House.

У Google Ads одночасно працюють тисячі кампаній і десятки акаунтів для різних ринків і категорій. Така структура дає змогу окремо керувати навіть невеликими сегментами, але водночас суттєво збільшує обсяг даних, які потрібно аналізувати під час оптимізації.

OLX відрізняється від класичного ecommerce-проєкту тим, що цілі та стратегії можуть змінюватися залежно від ринку, категорії і продукту. Один із ключових напрямів роботи — залучення користувачів, які шукають товари або послуги на платформі й формують попит на пропозиції продавців. Водночас команда може працювати й з іншими задачами, наприклад, залучати приватних і бізнес-продавців або збільшувати кількість встановлень застосунку.

У міру масштабування проєкту ручний аналіз такої кількості кампаній і сегментів ставав дедалі складнішим. Особливо це стосувалося біддингу — процесу визначення та коригування ставок, який напряму впливає на ефективність рекламних кампаній.

Як влаштований процес оптимізації ставок на OLX

Більшість кампаній у Google Ads оптимізується під liquid replies — якісні дії користувачів після взаємодії з рекламою, наприклад, звернення до продавця. Далі в кейсі називатимемо їх конверсіями.

Ефективність просування команда оцінює за допомогою внутрішнього аналітичного інструменту, який розробила MarTech-команда OLX Group. Він показує не лише кількість конверсій після взаємодії з рекламою, а й їхню інкрементальність — те, яка частина відбулася саме завдяки впливу просування.

Структура Google Ads досить розгалужена. Кампанії та сегменти розділені:

• за категоріями сайту, наприклад, «Запчастини», «Електроніка», «Сервіси»;
• типами кампаній — Search, Performance Max, Shopping;
• платформами — App і Web;
• стратегіями — CPA і Max Clicks;
• пристроями — Desktop і Mobile;
• аудиторіями — новими та наявними користувачами OLX.

Через таку структуру команда одночасно працює з великою кількістю сегментів, а дані для оцінювання їхньої ефективності надходять не лише з Google Ads чи GA4, а й із внутрішньої аналітичної системи OLX.

Тому для кожної зміни ставки недостатньо просто подивитися на один показник у рекламному кабінеті. Спеціалісту потрібно зіставити дані з кількох джерел і визначити, чи варто змінювати ставку та наскільки.

Щоб спростити цей процес, ще до впровадження нового алгоритму ми створили інфраструктуру для біддингу, яка збирала ключові дані в одному місці:

• параметри сегмента;
• кількість інкрементальних конверсій і їхню вартість за два останні закриті тижні*;
• витрати за останні три тижні;
• поточну ставку;
• окреме поле для нової ставки.

*Дані про конверсії ми брали саме за два останні закриті тижні через особливості атрибуції у внутрішній системі OLX: останні сім днів містять неповні дані, тому їх не можна використовувати для стабільної оцінки.

Робоча таблиця для біддингу, де зібрані параметри сегментів, ставки та ключові показники ефективності

Така інфраструктура вже значно спрощувала роботу: спеціаліст бачив усі основні показники в одному місці, міг порівняти ефективність сегментів і визначити, де ставку варто підвищити, а де — знизити.

Навіщо нам потрібна автоматизація біддингу

Орієнтуватися лише на поточну вартість конверсії було недостатньо. На рішення впливав додатковий контекст:

1. Історія змін ставки. Якщо ставку коригували кілька днів тому, нову зміну іноді варто відкласти або зробити меншою, щоби попереднє рішення встигло вплинути на результат.
2. Темп витрат у категорії. Якщо за поточної динаміки категорія може перевищити місячний бюджет, ставки частини сегментів потрібно знижувати, навіть якщо окремо вони демонструють хорошу ефективність.
3. Стратегія кампанії. У Max Clicks ставки зазвичай значно нижчі, ніж у Target CPA. Тому однакова зміна, наприклад, на 10%, має зовсім різний вплив на кампанію. Через це для кожної стратегії ми визначили окремі пороги та кроки коригування.
4. Розмір сегмента. Один сегмент може формувати 20% загального обсягу, а інший — менш як 1%. Відповідно, однакова зміна ставки по-різному впливатиме на загальний результат, тому сила коригування має залежати й від масштабу сегмента.

Отже, оптимальна ставка залежала не від одного показника, а від комбінації кількох чинників. Саме цю логіку ми вирішили формалізувати в алгоритмі.

Ручний аналіз усіх даних для сегментів у зоні відповідальності одного спеціаліста займав від шести годин до повного робочого дня — залежно від кількості акаунтів і кампаній.

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

Тому ми розробили алгоритм із наперед визначеними правилами зміни ставок для різних сценаріїв. Він аналізує ті самі чинники за єдиною логікою та формує рекомендовані ставки для всіх сегментів.

Нова система автоматизованого біддингу

Щоб автоматизувати прийняття рішень, ми формалізували логіку PPC-спеціаліста: визначили, за яких умов ставку потрібно підвищувати або знижувати та наскільки сильно її можна коригувати.

В основу алгоритму заклали шість чинників.

1. Ефективність сегмента

Спочатку система порівнює вартість однієї конверсії (CPA) у конкретному сегменті із середнім показником у категорії.

Якщо відхилення перебуває в межах ±5%, ставка не змінюється. Якщо сегмент, наприклад, дешевший за середнє значення на 15–25%, алгоритм рекомендує збільшити ставку на 10%. Для дорожчих сегментів логіка працює у зворотний бік.

Загалом ми визначили дев’ять діапазонів відхилення — від мінімального до 40% і більше в кожен бік — та встановили крок зміни ставки для кожного з них.

2. Темп витрат

Далі алгоритм перевіряє, наскільки фактичні витрати відповідають запланованим.

Якщо відхилення перебуває в межах від -10% до +10%, система використовує стандартний крок зміни ставки. Якщо витрати суттєво випереджають або відстають від плану, крок збільшується, щоб швидше скоригувати темп.

На основі ефективності сегмента та темпу витрат формується базова матриця, яка визначає напрям і силу зміни ставки для кожної комбінації умов.

Базова матриця зміни ставок для кампаній зі стратегією Max Conversions

Для кампаній зі стратегією Max Clicks силу зміни ми додатково збільшили вдвічі. Ставки в таких кампаніях зазвичай значно нижчі, тому однаковий відсотковий крок має менший практичний вплив.

Базова матриця зміни ставок для кампаній зі стратегією Max Clicks

3. Давність попередньої зміни

Алгоритм враховує, скільки часу минуло після останнього коригування ставки.

Якщо її змінили лише день тому, система застосовує 35% від розрахованого нового кроку. Через два дні — 50%. Далі коефіцієнт поступово зростає, а через шість і більше днів може становити 100%.

Так ми не дозволяємо системі надто швидко реагувати на результати попередньої зміни, ефект якої ще не встиг повністю проявитися.

Шкала послаблення зміни ставки залежно від давності попереднього коригування

4. Розмір сегмента

Ще один чинник — частка сегмента в загальній кількості конверсій.

Наприклад, якщо кампанія генерує 25% усіх конверсій, навіть невелике коригування ставки може суттєво вплинути на загальний результат. Тому для великих сегментів алгоритм діє обережніше.

Для невеликих, але ефективних сегментів крок може бути більшим, щоб дати їм більше можливостей для масштабування.

Шкала зміни сили коригування залежно від частки сегмента

5. Тижневий ліміт змін

Для кожного сегмента ми встановили максимальну сумарну зміну ставки протягом тижня: не більше +50% у бік збільшення та -60% у бік зменшення.

Це додатковий запобіжник, який не дає алгоритму надто різко змінити роботу кампанії за короткий період.

6. Мінімальний поріг

Рекомендації зі зміною ставки менше ніж на 3% система відкидає. Ми вважаємо такі коригування недостатньо суттєвими, щоб вони помітно вплинули на роботу кампанії.

У підсумку логіка враховує:

Для Target CPA та Max Clicks ми використовуємо окремі матриці, оскільки механіка й масштаб ставок у цих стратегіях відрізняються.

Кінцева CPA матриця

Maxclick матриця

Як алгоритм, ШІ та спеціаліст працюють разом

Сам розрахунок ставки ми не передали ШІ. Його виконує алгоритм із чітко заданими правилами: за однакових вхідних даних він щоразу дає однаковий результат, а кожен крок розрахунку можна перевірити й пояснити.

Увесь процес складається з чотирьох етапів:

1. Збір даних. 

Система отримує актуальні показники акаунта, історію попередніх змін ставок і перевіряє дані на розриви.

2. Розрахунок.

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

3. Перевірка ШІ.

Розрахована рекомендація передається ШІ-моделі, яка працює як додатковий рецензент. Вона не розраховує нову ставку й не змінює отримане число, а перевіряє, чи відповідає рекомендація контексту.

Наприклад, модель оцінює, чи:

• достатньо даних для рішення;
• узгоджується напрямок зміни з динамікою сегмента; 
• не суперечать показники один одному. 

Якщо аргументація недостатня або дані суперечливі, рекомендацію можна відхилити. Якщо все коректно, ШІ підтверджує її та формує коротке пояснення для спеціаліста.

4. Фіксація результату.

Усі перевірені сегменти потрапляють в аудит-лог, зокрема ті, для яких ставку вирішили не змінювати. Для кожного рішення система зберігає причину.

Логіку системи можна звести до трьох ролей:

Як із системою працює PPC-спеціаліст

Для нашої команди процес складається з трьох кроків:

1. Запустити розрахунок. Спеціаліст запускає його безпосередньо в Google Таблицях. Обробка однієї категорії займає кілька хвилин, після чого система формує рекомендовані ставки.
2. Перевірити рекомендації. ШІ додає свою оцінку й пояснення, а ми переглядаємо результат. За потреби можемо відхилити рекомендацію та встановити власну ставку, хоча це радше виняток.
3. Опублікувати зміни. Після фінальної перевірки спеціаліст переносить список кампаній і нових ставок у Google Ads Editor та публікує їх.

Ми свідомо залишили human check як фінальний рівень контролю. За такого масштабу кампаній повністю передавати процес ШІ без участі людини ризиковано: у разі помилки важливо швидко виявити її та зрозуміти, яка логіка або набір даних призвели до неправильного рішення.

Результати та ефект від автоматизації

Щоб оцінити ефект, ми порівняли ручний процес із нашим гібридним підходом — алгоритмом, ШІ-перевіркою та фінальним контролем спеціаліста.

1. До автоматизації: 252 години і близько $10 080 на місяць.

За накопиченою статистикою, повний аналіз портфеля та підготовка ставок вручну займають 6–8 годин за одну ітерацію. Для розрахунку взяли середнє значення — сім годин.

У середньому команда проводить шість таких ітерацій на місяць. Для шести спеціалістів це:

За розрахункової вартості робочого часу $40 за годину такий процес коштує близько $10 080 на місяць.

2. Після автоматизації: 36 годин і близько $1457 на місяць.

Після впровадження системи спеціаліст витрачає на одну ітерацію до години: перевіряє рекомендації та завантажує нові ставки в акаунти. Для розрахунку ми взяли верхню межу, хоча на практиці процес може займати приблизно 30 хвилин.

Для тієї самої команди це:

Один повний запуск алгоритму коштує приблизно $2,80. За шість ітерацій це ще близько $17 на місяць.

Отже, загальна розрахункова вартість процесу після автоматизації становить близько $1457 на місяць проти $10 080 вручну.

Крім економії часу й ресурсів, алгоритм щоразу застосовує однакову логіку до великого обсягу даних, зменшує залежність від навантаження та індивідуального підходу спеціаліста, а фінальний human check залишається частиною процесу.

Висновки: що ми зрозуміли під час розробки

1. Ключовою частиною автоматизації стала не сама ШІ-модель, а формалізація експертизи PPC-спеціаліста. Спочатку нам потрібно було розкласти процес прийняття рішень на конкретні фактори, правила та обмеження — і лише після цього переносити його в алгоритм.
2. Критичний розрахунок ставки ми свідомо не передали ШІ. Його виконує детермінований алгоритм, результат якого можна відтворити й пояснити. Натомість LLM використовуємо як додатковий рівень перевірки: модель оцінює контекст, шукає суперечності в даних і може відхилити рекомендацію, якщо для неї недостатньо підстав.
3. Фінальне рішення залишається за PPC-спеціалістом. За такого масштабу кампаній помилка автоматизації може мати суттєві наслідки, тому можливість швидко перевірити рішення та зрозуміти його логіку для нас важливіша за повну автономність системи.
4. У результаті ми отримали гібридну модель, у якій алгоритм масштабує експертизу спеціаліста, ШІ допомагає перевіряти рішення, а людина зберігає контроль там, де ціна помилки найвища.