iBoost/Портфоліо/AdPilot

Маркетинг·2026 — зараз

AdPilot

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

Наша роль

Архітектура, розробка, експлуатація

Статус

Активна розробка

Період

2026 — зараз

Платформа

Web-дашборд · фонові воркери

МАРКЕТИНГ AdPilot 01Збірстатистики зGoogle Ads02Розрахунокконверсій ібюджету03Детермінованіправила йгейти04Виконаннязмін05Реконсиляціята звіт PYTHON 3.12 · FASTAPI · POSTGRESQL · TIMESCALEDB · CELERY · REDIS · GOOGLE ADS API IBOOST.UA · 2026 — зараз

Схема системи · внутрішній контур, доступ за NDA

01

Що це

Більшість «AI-платформ для реклами» роблять одну й ту саму помилку: просять модель вирішити, скільки поставити за клік. AdPilot побудований на протилежному принципі. Ми не пишемо власного аукціонного бідера — ми будуємо тонкий детермінований шар контролю й захисту поверх Smart Bidding самого Google. Уся грошова математика й запобіжники — звичайний код, який можна протестувати й пояснити аудитору.

LLM у системі є, але має чітку роль: писати тексти оголошень і людські пояснення до рішень.

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

02

можливості

Що воно вміє

01

Побудова кампаній

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

02

Двотемпова збірка статистики

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

03

Конверсії з поправкою на лаг

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

04

Запобіжники й бюджет

Детерміновані ліміти на витрату, окремий watchdog-процес як незалежний вимикач — він працює, навіть якщо основний воркер завис.

05

Реконсиляція

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

06

Дашборд і ролі

React-панель із розмежуванням прав, журнал рішень: кожна зміна має причину, автора й людське пояснення.

03

архітектура

Як влаштовано

01

Збір статистики з Google Ads

02

Розрахунок конверсій і бюджету

03

Детерміновані правила й гейти

04

Виконання змін

05

Реконсиляція та звіт

Під капотом

  • Python 3.12 + FastAPI, SQLAlchemy 2.0; PostgreSQL 16 з TimescaleDB для часових рядів метрик.
  • Celery-воркер, окремий beat-планувальник на два темпи й незалежний watchdog як kill-switch.
  • Домени розділені за призначенням: guardrails, budget, decision_engine, fsm, rbac, ingestion, reconciliation, policy, executor.
  • Детерміновані тести на грошову математику — окремий обов’язковий набір.
  • Життєвий цикл токенів і секрети винесені з коду; чотири systemd-юніти на проді.
  • Принцип №1 зафіксовано письмово: LLM не викликає mutate. Ніколи.
Python 3.12FastAPIPostgreSQL · TimescaleDBCeleryRedisGoogle Ads APIReact

04

масштаб

Цифри

0

ставок, що їх ставить LLM

2

темпи збору статистики

4

процеси на проді

100%

рішень із журналом причин