Клієнт Дизайнерський одяг на Shopify (NDA)
Роль Freelance Backend Engineer / AI Integration
Період Sep 2026 — ongoing (Stage 1 of 3)
Стек
Go Shopify Shopify GraphQL Admin API PostgreSQL Meta Marketing API Meta Ads Claude API Higgsfield E-commerce AI robfig/cron Docker Compose Caddy
AI-тестування реклами — дизайнерський одяг на Shopify preview

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

Огляд

Система AI-тестування реклами для Shopify-магазину лімітованого дизайнерського одягу. Цикл замкнений повністю: дані Shopify про товари/замовлення/склад → Claude генерує гіпотези офферів/кутів/гачків → Higgsfield рендерить креативи → система збирає Meta-кампанії, створені на паузі з жорсткими лімітами витрат → результати звіряються з реальними замовленнями Shopify, а не з піксельною аналітикою рекламної платформи → переможці отримують оцінку і породжують нові варіації.

Статус: Stage 1 з 3-етапного контракту, у процесі з вересня 2026. Stage 1 доставляє повний пайплайн до генерації через Claude/Higgsfield включно, guardrails по складу та витратах, і review-поверхню через Google Sheets. Збірка Meta-кампаній, збір метрик і автоматична оцінка переможців/програвших — це Stage 2.


Архітектура

Shopify Admin API (товари/замовлення/склад) ──▶ internal/shopify
Shopify webhooks (live, 6 топіків)          ──▶ internal/webhooks   HMAC + dedup
Claude API          ◀──▶ internal/claude       оффер / кут / гачок, зі схемою
Higgsfield          ◀──▶ internal/higgsfield   асинхронні креативи, vendor-neutral
Meta Marketing API  ◀──▶ internal/meta         кампанія/adset/ad — завжди PAUSED (S2)
                              │
                    internal/store (PostgreSQL)
        Product → Variant → Offer → Angle → Hook → Creative → Link → MetaPlacement
                              │
        ┌─────────────────────┼──────────────────┬─────────────────┐
        ▼                     ▼                  ▼                 ▼
  internal/guard        internal/recon      internal/score    internal/sheets
  guardrails складу      реальні замовлення   ранній сигнал →    односторонній
  та витрат              vs. заявки Meta       вердикт CPA/ROAS   review-sync

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


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

Рішення Чому
Звірка з реальними замовленнями Shopify, а не з піксельом Meta UTM + час замовлення + variant GID + розподілена сума позиції; невіднесені замовлення (POS, прямі) йдуть в окремий кошик, а не примусово прив’язуються
Оцінка за раннім сигналом перед CPA/ROAS Середній чек магазину помірний — покупок на креатив справді мало. Спершу вирішують hold rate, outbound CTR і cost-per-ATC; CPA/ROAS вмикається лише після налаштовуваного порогу подій
Per-variant guard по складу, а не універсальне правило “все — 1 екземпляр” Каталог поєднує справжні one-off речі зі звичайними складськими лініями — наївне припущення про один екземпляр помилялось би на других
Higgsfield за vendor-neutral інтерфейсом Provider Лише контракт Submit/Poll — другий постачальник креативів стає новою імплементацією і конфіг-прапорцем, а не переписом черги, схеми чи викликів
Append-only журнал подій для лінків і креативів LinkEvent/CreativeEvent; поточний статус/вердикт — проекція, записана в тій самій транзакції, тому повна історія рішень переживає кожну зміну стану
Оголошення завжди створюються на паузі Нічого не витрачається, доки клієнт не активує вручну — контроль витрат це гарантія клієнту, вбудована в саму збірку, а не політика, накладена згодом

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

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

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

Розгортання

Постачається як вихідний код + двосервісний стек docker-compose, що працює на власному VPS клієнта (не на спільному акаунті), з окремим субдоменом системи, Caddy для автоматичного TLS і нічним pg_dump плюс поза-дисковим бекапом. Розробка використовує тестовий рекламний акаунт Meta під Business Manager клієнта — реальні об’єкти кампаній, нуль живих витрат, до прийомки.


Стек

Go · PostgreSQL · Shopify GraphQL Admin API · Claude API · Higgsfield · Meta Marketing API · robfig/cron · Docker Compose · Caddy