Платна реклама Meta (Facebook/Instagram)

Що це і навіщо

Платне залучення абітурієнтів на flagship-продукт «Симуляція вступу» (399 ₴) через Meta Marketing API. Мета — довести, що реклама сходиться економічно (CPA ≤ ціни) до піку сезону (подача заяв з 19.07).

Ключове ускладнення, що визначає всю роботу: атрибуція Meta в Abitly історично крива (див. Атрибуція), тож інструменти навмисно розділяють «керувати рекламою» і «вимірювати правду».

Інструментарій

Три локальні AI-інструменти оператора (живуть у ~/.claude/skills/, не задеплоєні сервіси — не входять у прод-топологію хабу):

Інструмент	Роль	Що робить
abitly-ads	оператор	CLI над Marketing API v25 (`ads.sh`): створює/змінює/активує кампанії, ad sets, креативи, аудиторії (custom/lookalike) і CRM-sync; тягне insights. Запобіжники вшиті в код: усе народжується `PAUSED`, активація вимагає явного підтвердження, бюджетний cap.
ads-report	аналітик (read-only)	Детермінований `analyze.py` (CSV або live) рахує CPA/ROAS/флаги малої вибірки → діагностичне дерево → стандартизований звіт. Нічого не змінює.
ads-manager	агент	Обгортка над обома для делегування задач.

Копію оголошень пишуть через бренд-скіли (brand-voice → brand-review) — канон у marketing/brand/. Червоні лінії (жодних «гарантій вступу») однаково ловляться і брендом, і Meta.

Доступ (назви, не секрети)

Рекламний акаунт: act_588584003723277 (Abitly, UAH). Meta App abitly (id 2557934751302228) у Live-режимі (Privacy URL /uk/privacy).
Ідентичність оголошень: Page + IG Abitly.org (ті самі активи, що для reels-публікацій). TODO: винести Page/IG id у environments, якщо знадобиться.
Токен: long-lived user token (~60 днів, до 2026-09-02); env-змінні USER_TOKEN / AD_ACCOUNT_ID / APP_ID / APP_SECRET / PIXEL_ID у локальному .env скіла (ніколи не комітяться). План на довго — non-expiring system user token у Business Manager.
Pixel: 4273494836207329 (живий, ~430k PageView/тиждень через GTM base-тег, Advanced Matching увімкнено).

Живий тест: sim2026 A/B/C

Запущено 2026-07-04 (ввечері). Мета — знайти, яка аудиторія дає найдешевшу покупку. Три кампанії OUTCOME_SALES, по 300 ₴/день (разом 900 ₴/день), оптимізація на конверсію-покупку:

Кампанія	Аудиторія
`sim2026-warm`	відвідувачі сайту 30 днів (website custom audience)
`sim2026-lal`	lookalike 3% від відвідувачів (виключає warm)
`sim2026-broad`	холодна 18–24, Instagram (виключає warm+lal)

Креативи: два наявні Reels (reel-launch «Симуляція вступу 2026», 595 орг. лайків; reel-timesaver») у кожній кампанії; розрізняються по utm_content`.
Чистота тесту: аудиторії взаємовиключні, Advantage-розширення вимкнено, креативи однакові → різниця в CPA = різниця аудиторій.
Лендінг: /uk/simulation з UTM (utm_source=instagram, utm_medium=paid_social, utm_campaign=sim2026-{warm|lal|broad}, utm_content={reel}).

Результат за 1-й день (05.07, ~15 год)

Метрика	Значення	Нотатка
Спенд	891 ₴	~300 ₴/арм
CTR	4.7–6.5%	у рази вище норми (~1%) — креатив резонує
CPC	1.7–2.1 ₴	дешево
Покупки	0	занадто рано: <доби, learning phase не стартувала

Meta миттєво перелила бюджет на reel-launch (~95%), задушивши reel-timesaver до <200 показів (по ньому судити не можна). Вердикт: не чіпати 2–3 дні (будь-яка зміна скидає learning phase); перший діагноз по CPA — коли набереться ≥8 конверсій або ≥1200 ₴ на арм (kill-поріг).

Фікс Purchase-пікселя

Проблема: подія simulation_purchase доходила лише до GA4 через GTM, а Meta Purchase-тег не був підключений → кампанії оптимізувались на проксі (перегляд success-сторінки, який завищує).

Рішення (SHIPPED → prod): на success-сторінці, всередині наявного isPaid-guard’а, додано прямий виклик fbq('track','Purchase', {value, currency:'UAH'}, {eventID: orderId}) — стріляє лише на реально підтверджену оплату, обходить незапаблішений GTM, eventID=orderId готує дедуплікацію з майбутнім CAPI.

Frontend PR #497 → development, cherry-pick #499 → main.
Прод-деплой підтверджено: CodePipeline abitly-prod-frontend (Build ✅) → ECS task-def abitly-prod-frontend:67, rollout COMPLETED (GH Actions заблокований білінгом, але фронт деплоїться CodePipeline’ом незалежно).

Ремаркетинг-контур (self-updating)

Налаштовано 2026-07-05: постійно свіжі аудиторії з власних даних + PAUSED-кампанія, готова до активації після вердикту A/B/C-тесту.

Аудиторії

CRM-аудиторії (хешовані емейли з прод-БД, щоденний sync):

Аудиторія	Джерело (SQL у скілі)	Розмір @ перший sync
`crm-registered-all`	всі зареєстровані з email	50 658
`crm-season-2026`	`enrollment_year >= 2026`	21 643
`crm-sim-interested`	почали checkout симуляції, не оплатили, не володіють	372
`crm-sim-owners`	покупці + grant + gift (пул виключення)	273

Pixel-аудиторії (website CA, заповнюються з історії пікселя): sim-visitors-30d (URL /simulation), sim-purchasers-180d (URL /simulation/success, виключення), nmt-calc-visitors-30d (URL /nmt-calculator), site-visitors-90d (PageView). Lookalike: lal-3pct-crm-registered-ua — 3% UA з 50k CRM-бази (значно якісніший seed, ніж старий 1.6k CSV).

Цикл автоматичного покращення

Щоденний CRM→Meta sync — в AWS, поруч із БД (репо cloud-infrastructure, стек terraform/envs/abitly-ads-audience-sync): EventBridge Scheduler о 06:47 (Europe/Kyiv) запускає Fargate-таску abitly-prod-ads-audience-sync на кластері abitly-prod-backend; та читає сегменти з прод-БД у read-only сесії і атомарно замінює склад аудиторій через usersreplace (SHA-256 у пам’яті, плейнтекст не логується і не пише на диск). ~230 нових реєстрацій/день самі втікають у пули; нові покупці самі випадають у виключення. Фейл → CloudWatch-алярми → Telegram «P0 Allarms Abitly»: …-failed (за хвилини) і …-stale (2 доби без успішного прогону). Ручний/ad-hoc прогін з ноутбука — sync-audiences.sh у скілі abitly-ads (з launchd знято 2026-07-05).
Lookalike self-refresh: Meta перебудовує LAL з оновлюваного seed автоматично.
Оптимізація на справжній Purchase: rmk-кампанія оптимізується на подію Purchase пікселя — кожна покупка донавчає деліверю Meta.
Щотижневий зріз (launchd org.abitly.ads-weekly-snapshot, пн 08:23): дамп insights + стан sync у logs/weekly-* і нагадування прогнати ads-report (діагноз + звірка з premium_orders).

PAUSED-кампанія `sim2026-rmk` (id 120247626135770208)

OUTCOME_SALES, оптимізація на Purchase, креативи ті самі два Reels, але з utm_campaign=sim2026-rmk (окрема атрибуція):

Ad set	Включення	Виключення	Бюджет
`rmk-hot-abandoned`	`crm-sim-interested` + `sim-visitors-30d`	owners + purchasers-180d	150 ₴/день
`rmk-warm-crm`	`crm-season-2026` + `nmt-calc-visitors-30d`	owners + purchasers + hot-сегменти	150 ₴/день

Не активувати до вердикту тесту sim2026 (~08.07): hot-сегмент зараз перекривається з sim2026-warm в аукціоні. Активація: ads.sh activate 120247626135770208 --yes після явного «так» на 300 ₴/день.

Застереження

Згоди на маркетинг у БД немає (у users немає consent-поля) — завантаження хешованих емейлів спирається на договірні відносини/legitimate interest; перевірити Privacy Policy на розкриття custom audiences.
Історія блоку 471: стара аудиторія emails_22_07_2025.csv (липень 2025) заблокована Meta як «prohibited information» — тому нові списки мають нейтральні назви і тільки EMAIL-схему. Якщо 471 повториться — ескалація, не пересоздання.
В акаунті висять легасі ACTIVE-кампанії («Bost Post - Traffic», «ФМФ КПІ» по 500 ₴/день) — сьогодні не витрачали, але варто вирішити їхню долю.

Атрибуція і довіра до цифр

Числа Meta досі трактуються як оцінка, не істина, поки:

Кампанії оптимізуються на стару проксі-конверсію (перегляд success), а не на новий Purchase-піксель — переключення після накопичення подій.
GTM-workspace не опублікований + pay.mbnk.biz (Monobank) не у referral-exclusions GA4 → редірект через Monobank рве атрибуцію.

Тому ads-report завжди звіряє покупки Meta з реальними premium_orders у прод-БД. Повний контекст воронки — у картці Симуляція вступу.