← всі звіти · meta-integration-3-projects-2026-04-22.md

Meta інтеграції — план налаштування для 3 проектів

Дата: 2026-04-22 Запит: безпечна архітектура + покрокові інструкції для 3 Meta-залежних проектів

Задачі

  1. FB Ad Library моніторинг конкурентів (Market Research Auto) — read-only доступ до Ad Library API для відстежування активних кампаній конкурентів у фарм-сегменті UA.
  2. Pediatric News → Threads публікація — автопостинг 3×/день у @smart_pediatric_news threads-акаунт.
  3. Meta Ads аудит наших кабінетів — read-only доступ до Marketing API для автоматичного аудиту campaign performance, структури, креативів.

🚫 Блокери (вирішити ПЕРЕД будь-якою технічною роботою)

B1. Facebook акаунт Андрія Савченка — заблоковано 2026-04-16

B2. Business Verification (компанія)

B3. Ad Accounts — де вони (MCC структура)

Висновок по блокерах

Якщо B1 не вирішений — ми не починаємо Phase 1. Альтернативи:


🏗 Архітектура — 3 варіанти

Варіант A: Один App з усіма product'ами

Структура: 1 Business Manager → 1 App → 3 products (Marketing API, Ad Library, Threads) → 1 System User

Pros Cons
Один App ID, один System User — простіше ротувати Якщо App блокують — падають ВСІ 3 сервіси
Єдина точка моніторингу usage App Review з широким scope'ом складніший
Менше рутинної адміністрації Компроміс безпеки (один токен = вся поверхня)

Варіант B: 3 окремих Apps під одним Business Manager

Структура: 1 BM → 3 Apps (один product кожен) → 3 System Users (або один shared)

Pros Cons
Повна ізоляція: бан одного App не торкається інших 3× більше налаштувань
Окремі rate limits на кожен сервіс 3 App Reviews
Вужчий App Review для кожного App Більше токенів зберігати й ротувати

Варіант C: Гібрид — 1 App для Graph API + окремий для Threads ⭐

Структура: 1 BM → 2 Apps:

→ 2 System Users (один на Graph, один на Threads)

Pros Cons
Логічне розділення — Threads все одно окремий сервіс Meta 2 App Reviews (але швидші за 3)
Graph API + Ad Library природно комплементарні (Marketing та Ad Library використовують той самий auth flow) На 1 токен/сервіс більше ніж у варіанті A
Bан Threads App не зачіпає Ads аудит

📌 Рекомендація: Варіант C


🔐 Безпекові принципи (всі варіанти)

1. System User замість User Access Token

2. Scope мінімальності

Проект Мінімально необхідні scope
FB Ad Library ads_read (достатньо для /ads_archive endpoint)
Threads publish threads_basic, threads_content_publish, (опц.) threads_manage_replies
Marketing API audit ads_read, business_management (без ads_management — це write scope)

3. Зберігання токенів

4. Long-lived vs short-lived

5. App secret

6. Rate limit моніторинг


📋 Покрокові інструкції (для Варіанту C)

Phase 0: Pre-requisites (блокери)

Phase 1: Створення Apps (після BV verified)

App 1: delta-graph (Marketing + Ad Library)

App 2: delta-threads (Pediatric News)

Phase 2: System Users

System User "graph-reader" (App 1)

System User "threads-publisher" (App 2)

Phase 3: Інтеграція в проекти

Project: Market Research Auto (FB Ad Library)

Project: Pediatric News → Threads

Project: Google Ads Crew → extend на Meta (audit наших кабінетів)

Phase 4: Моніторинг та ротація


⏱ Часова оцінка

Phase Блокована чим ETA
0 Pre-requisites FB Андрія + BV 2-14 днів (чекаємо Meta)
1 Apps Phase 0 1 день на обидва Apps
2 System Users Phase 1 2 години
3 Integration Phase 2 1 день на проект (3 проекти paralleled)
App Review Meta 3-10 днів
Total realistic 2-4 тижні до повної готовності всіх 3 проектів

App Review для threads_content_publish — окрема довга пісня (тиждень+). Для ads_read зазвичай швидко (24-72 години).


❓ Питання, на які потрібна відповідь від Сергія, щоб рухатись

  1. Статус апеляції FB Андрія — чекаємо або пробуємо альтернативу?
  2. Юрособа для BV — Delta Medical ТОВ, чи окрема маркетингова юрособа?
  3. Ad Accounts scope — тільки наші (Delta Medical) чи клієнтські теж (тоді Partner Request)?
  4. Threads profile@smart_pediatric_news вже існує? Переведений на Business? Прив'язаний до Instagram?
  5. Terms/Privacy URL — можемо використати medizine.ua/privacy чи треба окремий для Delta Medical?

Поточна готовність до старту