AI-система рекламних кампаній — дизайнерський одяг на Shopify

Огляд

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

Сам магазин лишається недоторканим: жодного коду теми чи застосунку всередині. Система читає зі Shopify і пише в Meta, під жорсткими лімітами витрат.

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

Три етапи, кожен приймається окремо

Етап	Зміст	Статус
1. Фундамент	Синхронізація зі Shopify, генерація гіпотез, рендер креативів, ліміти витрат, таблиця для перегляду	Прийнято
2. Продукт	Чат; брифи, прев’ю- і фінальні рендери з монтажем; збірка в Meta та Insights; звірка й оцінка; ліміти на живих оголошеннях; посібник клієнта	Прийнято
3. Повна автоматизація	Запуск оголошень за підтвердженням і оптимізація на Purchase за Pixel клієнта вже працюють; авто-пауза аутсайдерів, масштабування переможців і варіації з переможців чекають на живі дані	На прийманні

Як створюється кампанія

Синхронізація. Товари, варіанти, склад і замовлення через Shopify GraphQL Admin API плюс живі вебхуки (перевірка HMAC, дедуплікація).
Гіпотези. Claude видає оффери, кути й гачки як структурований вихід зі схемою, спираючись на історію попередніх тестів.
Бриф. Чат опитує оператора, доки бриф не буде повним: товар, персонаж, кадри, сценарій, стиль камери. Кожна правка — нова версія.
Прев’ю. Дешевий рендер у 720p. Його вартість оцінюється до запуску, а кількість ітерацій обмежена. Оператор затверджує або переробляє.
Фінал. Рендер у 1080p, потім монтаж через ffmpeg: врізки, рухи камери, субтитри слово за словом. whisper.cpp розшифровує результат і перевіряє, що відео говорить затверджений текст.
Кампанія. Створюється із затвердженого відео: кампанія → ad set → креатив → оголошення, усе на паузі, ліміт витрат задано в запиті.
Вимірювання. Meta Insights за розкладом, у вигляді кумулятивних знімків із виявленням застарілих даних.
Звірка. Кожен рядок замовлення зіставляється з оголошенням за UTM, часом замовлення, варіантом і розподіленою сумою. Замовлення, які не вдається віднести (POS, прямі), лишаються в окремому кошику, а не примусово чіпляються до оголошення.
Вердикт. Спершу ранні сигнали (hold rate, outbound CTR, cost per add-to-cart), ROAS — коли накопичиться достатньо подій. Переможці й аутсайдери стають контекстом для наступного раунду гіпотез.

Архітектура

Shopify Admin API ──▶ internal/shopify     товари · варіанти · склад · замовлення
Shopify webhooks  ──▶ internal/webhooks    HMAC + dedup, далі в чергу
Claude API       ◀──▶ internal/claude      гіпотези зі схемою
Claude API       ◀──▶ internal/chat        чат: закритий реєстр інструментів, пропозиції
                      internal/brief       версійні брифи, рівні рендеру, гейти затвердження
Higgsfield       ◀──▶ internal/higgsfield  асинхронні image/video-завдання, vendor-neutral
                      internal/montage     композиція в ffmpeg, субтитри з whisper.cpp
Meta Marketing   ◀──▶ internal/meta        кампанія / ad set / оголошення — завжди PAUSED
Meta Insights     ──▶ internal/insights    знімки метрик
                              │
                    internal/store (PostgreSQL)
  Product → Variant → Offer → Angle → Hook → Hypothesis → Creative → Link → Placement → Metrics
                              │
        ┌─────────────────────┼──────────────────┬─────────────────┐
        ▼                     ▼                  ▼                 ▼
  internal/guard        internal/recon      internal/score    internal/sheets
  guardrails складу     реальні замовлення  ранній сигнал →   односторонній
  та витрат             vs. заявки Meta     вердикт за ROAS   review-sync

Один Go-бінарник, одна база PostgreSQL (31 міграція), один in-process планувальник (robfig/cron). Жодного брокера повідомлень, жодного Kubernetes, жодних мікросервісів — реальне навантаження це низькочастотна оркестрація API (десятки замовлень Shopify на місяць, кілька креативів на цикл), а важкі обчислення йдуть віддалено (Claude, Higgsfield). Виняток — монтаж: він працює на самому сервері з 2 vCPU, і 12-секундне відео компонується приблизно за 30 секунд. Кожен зовнішній виклик іде у власній обмеженій черзі з leased claim і експоненційним backoff-повтором, тож поганий день одного API не зупиняє решту.

Ключові рішення

Рішення	Чому
Чат, який може лише пропонувати	Реєстр інструментів закритий: жодного shell, файлів чи вебу. Інструменти, що щось змінюють (пауза оголошення, ліміт, створення кампанії, затвердження рендеру), лише створюють пропозицію; її підсумок і суму найгіршого випадку формує Go-код, а не модель, і `Confirm` має єдиного викликача, що перевіряє AST-тест
Звірка з реальними замовленнями Shopify, а не з піксельом Meta	UTM + час замовлення + variant GID + розподілена сума позиції; невіднесені замовлення йдуть в окремий кошик, а не примусово прив’язуються
Вердикт за ROAS, а не за похідною межею CPA	Межа CPA, виведена із середнього чека, помилково робила аутсайдером прибуткове оголошення з дорогим товаром: три продажі по $500 на $400 витрат — це ROAS 3.75, але CPA $133. Вердикт лише за ROAS; CPA лишається для інформації
Оцінка за раннім сигналом перед ROAS	Середній чек помірний, тож покупок на креатив справді мало. Спершу вирішують hold rate, outbound CTR і cost per add-to-cart; ROAS вмикається після налаштовуваного порогу подій, без змін у коді
Guard складу по варіанту, у момент перетину	Каталог поєднує унікальні речі зі звичайними складськими лініями. Guard стежить за кожним варіантом і спрацьовує, коли кількість перетинає межу з додатної до нуля — зокрема й при передпродажі чи великому замовленні, що перестрибує рівно 0
Рендер — це граф, а не один виклик	Рівень може стартувати зі згенерованого кадру; координатор подає залежні завдання по черзі й дотягує відстаючі, тож невдалий перший кадр повторюється, а не валить увесь рендер
Рівні креативів за вартістю за інтерфейсом `Provider`	Higgsfield стоїть за вузьким контрактом `Submit`/`Poll`. Коли фінали на Seedance коштували $14–23 і спотворювали напис на циферблаті, якщо рука наближалась до об’єктива, фінальний рівень перейшов на PixVerse 1080p приблизно за $1.64 — зміна конфігурації, а не переписування
Оголошення завжди створюються на паузі; тест закінчується, коли оголошення стартує	Система виставляє час завершення в момент, коли вперше бачить оголошення активним, тож клієнт може тримати кампанію на паузі скільки завгодно
Append-only журнал подій для оголошень і креативів	Поточний статус чи вердикт — проекція, записана в тій самій транзакції, тому повна історія рішень переживає кожну зміну стану
Слово «тест» ніколи не вживається голим	Воно означало чотири речі (рекламний тест, дешеве прев’ю-відео, автотести, пісочницю вендора). Промпт чату, описи інструментів, сторінка й підсумки пропозицій скануються Go-тестом на голе слово

Контроль витрат

Гарантія клієнту, забезпечена на чотирьох незалежних рівнях:

Кожне нове оголошення створюється на паузі. Нічого не витрачається, доки клієнт не активує.
Денний ліміт на оголошення і місячна стеля, на рівні системи — на живих об’єктах. Після стелі нові кампанії не створюються, а зниження ліміту чи стелі одразу запускає guard.
Кожен платний рендер показує оцінку до запуску, ітерації обмежені, а ціна входить до картки підтвердження.
Власний ліміт клієнта на рівні акаунту Meta — жорстка межа, яку контролює сама Meta, незалежно від того, що робить ця система.

Збудовано, щоб це можна було перевірити

Спершу специфікація. 102 вимоги, кожна простежується до функціональної, логічної чи фізичної вимоги й міряється Туманоміром — K_drift 0.00, жодної неприв’язаної.
Тести важать більше за код. Близько 26 900 рядків продакшн-коду на Go проти близько 30 900 рядків тестів у 164 тестових файлах, запуск із -race; golangci-lint показує 0 зауважень.
Кожен мілстоун закінчується рев’ю свого diff через fix-review. Мультиагентне рев’ю специфікації Етапу 2 знайшло зауваження, які звірили з кодом і виправили; ті, що не витримали перевірки, відхилили.
460+ комітів за сім тижнів — від першого каркаса до гейтів Етапу 2.
Збудовано з Claude Code. Код написано одним інженером у парі з Claude Code; diff кожного мілстоуна проходить мультимодельне рев’ю fix-review, а вимоги міряються Туманоміром.

Розгортання

Постачається як вихідний код плюс docker-compose-стек на власному VPS клієнта, за Caddy з автоматичним TLS, із нічним pg_dump і дисковим бекапом. Чат має власний піддомен, вхід на argon2id, серверні сесії, захист від CSRF і суворий CSP. Приймання кожного етапу включає оновлений посібник клієнта — зі скріншотами й діаграмами, у PDF і docx — та п’ятихвилинний шлях приймання для клієнта. Розробка велась на окремому рекламному акаунті під Business Manager клієнта: справжні об’єкти кампаній, усі на паузі, жодних живих витрат, доки клієнт сам не ввімкне оголошення.

Стек

Go · PostgreSQL · Shopify GraphQL Admin API · Claude API (tool use, структурований вихід) · Higgsfield · Meta Marketing API · Meta Insights · ffmpeg · whisper.cpp · Google Sheets API · robfig/cron · Docker Compose · Caddy