🔧 Як працює Live-трекер — до кінця
Пояснення для Max · без агентів, без LLM · детермінований конвеєр на таймері
Головна думка: у цій системі немає жодного агента і жодного штучного інтелекту в роботі.
Це 5 простих програм, з'єднаних у конвеєр, які запускає системний таймер раз на годину.
«Розум» був витрачений один раз — коли реверсилась логіка конкурента й писався код.
Далі рантайм «тупий»: виконує той самий рецепт щогодини, як верстат на заводі. Тому система коштує
$0 у Claude-токенах і працює сама, без участі будь-якого AI.
[1 launchd]──смикає──▶[2 run_live_tracker.sh]──запускає по черзі──▶
│
├─▶ [3 live_tracker.py] ◀── СЕРЦЕ. дістає дані 2 способами:
│ ├── Meta Graph API (HTTP-запити) → spend / ROAS / конверсії / зміни
│ └── Chrome + проксі (Playwright) → ходить по лендингах, бере ключі
│ ↓ усе складає в campaigns.json (пам'ять)
├─▶ [4 build_live_dashboard.py] → малює index.html зі state-файлу
└─▶ [5 wrangler] → заливає сторінку на Cloudflare → ти відкрив сайт
① launchd — системний будильник
1
Що це. launchd — вбудований у macOS планувальник (аналог cron). Він тримає список «завдань»
і запускає їх за розкладом. Наше завдання описане у файлі-конфізі (
.plist):
// ~/Library/LaunchAgents/com.iamaximus.sbc-live-tracker.plist
ProgramArguments: [ "/bin/zsh", ".../run_live_tracker.sh" ]
StartCalendarInterval: { Minute: 7 } // щогодини о хвилині :07
StandardOutPath: ".../run_live_launchd.log"
Як працює. Кожну годину о
HH:07 launchd сам запускає скрипт. Нічого не треба тримати
відкритим — він живе у системі, переживає перезавантаження Mac, стартує завдання навіть якщо ноут щойно
прокинувся. Це і є весь «тригер»: один рядок розкладу.
Перевірити живий він чи ні: launchctl list | grep sbc-live-tracker.
② run_live_tracker.sh — диригент
2
Що це. Маленький
zsh-скрипт, який launchd запускає. Його єдина робота — виконати
3 кроки
по черзі і записати лог. Він нічого не вирішує, просто диригує:
# 1. підтягнути токени з оточення (Cloudflare), виставити PATH
source ~/.zshenv
# 2. ЗІБРАТИ дані (Meta API + браузер) → оновлює campaigns.json
./venv/bin/python live_tracker.py 2026-06-23 1 120 20
# 3. НАМАЛЮВАТИ сторінку зі зібраного state
./venv/bin/python build_live_dashboard.py
# 4. ЗАЛИТИ сторінку на Cloudflare
npx wrangler pages deploy live --project-name=sbc-live-tracker
Навіщо окремий диригент. Щоб кожен крок був незалежним і його можна було запустити/полагодити
окремо. Якщо впав деплой — збір даних уже відбувся й лежить у state-файлі; наступний запуск просто
домалює й заллє.
Аргументи 2026-06-23 1 120 20 = старт-дата трекінгу ·
1 = вмикати браузер-резолв · 120 = максимум нових кампаній за прогін · 20 = скільки
лендингів обходити браузером за прогін.
③ live_tracker.py — збирач (серце системи)
Тут відбувається 90% роботи. Дістає дані двома різними способами ⤵
🅰️ Як ми беремо дані від Meta (HTTP-запити до Graph API)
Що таке Meta Graph API. Це офіційний «вхід» Facebook для програм. Ти надсилаєш звичайний
веб-запит з токеном доступу — у відповідь приходить
текст у форматі JSON (структуровані дані,
не картинка). Жодного браузера: як відкрити сторінку, але замість дизайну — чисті цифри.
# спрощено, що реально шле колектор:
GET https://graph.facebook.com/v21.0/act_1489…/insights
?access_token=EAAB…(живий токен)
&level=campaign
&fields=campaign_id,spend,actions,action_values
&time_range={since:2026-06-23, until:today}
Три «ендпоінти» (адреси), звідки беремо дані:
| Адреса | Що віддає |
|---|
/campaigns | список кампаній + коли створені, бюджет, тип ставки → так знаходимо нові кампанії |
/insights | spend, ROAS, конверсії, revenue по кожній кампанії |
/activities | журнал дій — коли підняли/зрізали бюджет, поставили на паузу (з точним часом) |
Важливі деталі, як саме тягнемо:
- Токен. Один живий access-токен дає дозвіл читати ці 117 рекламних акаунтів. Лежить у
.env.
- Тільки читання. У коді стоїть жорсткий запобіжник:
POST/PUT/DELETE заборонені —
фізично не можемо нічого змінити в їхній рекламі, лише дивитись.
- Пачками по 50. Просимо метрики одразу для 50 кампаній за запит — швидше й менше запитів.
- Пагінація. Якщо даних багато, Facebook віддає сторінками — код сам гортає всі сторінки.
- Тротлінг. Між запитами пауза ~2с + автостоп, якщо Meta каже «забагато» — щоб не впертись у ліміт.
Що означає spend на сайті. Це сумарний spend з 23.06 (старту трекінгу) до зараз —
тобто фактично за весь час життя кампанії, бо вони створені 23-го. Це НЕ «за останню годину» і
не «за сьогодні». Тому в нових кампаній віком ~1.5 дня зі стартовим бюджетом $20–30 spend поки малий
($20–45) — їх ще не масштабували. Цифра реальна.
🅱️ Хто «ходить по сайтах» — браузер через проксі
Навіщо. Рекламне посилання часто
заклоачене (
.click/
.xyz з макросами
{{ad.id}}) — воно ховає справжній лендинг. Через API його не видно. Тому туди треба реально
«сходити» браузером, як живий користувач.
Хто йде. Справжній
Google Chrome (не емуляція), яким керує Python-бібліотека
Playwright.
Він прикидається американцем, що клікнув з реклами у Facebook:
| US-IP | через проксі — наче трафік зі США |
Referer: facebook.com | наче перейшов саме з Facebook |
фейковий fbclid | наче справжній рекламний клік |
| відбиток Chrome + вимк. автоматизацію | щоб виглядати як жива людина |
Саме це обманює cloaker — він бачить «реальний FB-трафік зі США» і віддає справжній лендинг
замість пустишки. Chrome скролить, дочікується редіректу, зчитує фінальний URL +
RSOC-ключі
(платні пошукові ключі зі сторінки) — і
закривається. Не висить 24/7, вантажиться ~15с на лендинг.
🗄️ campaigns.json — пам'ять (щоб не переробляти)
Усе зібране лягає в один файл-стан
tracker/campaigns.json. Він живе між запусками. Завдяки
йому ми
не обробляємо одне й те саме двічі:
- ключ та рекламне посилання дістаємо раз на кампанію;
- на лендинг браузером заходимо раз (далі беремо з пам'яті);
- журнал змін доповнюємо тільки новими подіями;
- важкий скан 117 акаунтів — лише в їхні робочі години (6–12 та 17–21 UTC); поза ними просто оновлюємо вже відомі.
кеш = економія API, трафіку й часу
④ build_live_dashboard.py — маляр
4
Що робить. Бере готовий campaigns.json і малює з нього одну статичну HTML-сторінку
(index.html): KPI-бар, таблицю кампаній, розкривні деталі, журнал змін. Жодних запитів —
просто «дані → дизайн». Сторінка статична (швидка, нічого не ламається), тому в неї вшито
авто-перезавантаження кожні 15 хв, щоб ти бачив свіже без F5.
⑤ wrangler — кур'єр на Cloudflare
5
Що робить. wrangler — це CLI Cloudflare. Однією командою заливає готовий
index.html на хостинг Cloudflare Pages → сторінка одразу доступна за адресою
sbc-live-tracker.pages.dev. Безкоштовно, без сервера, відкривається будь-де.
🔄 Повний цикл за один прогін
- launchd о :07 будить скрипт.
- run_live_tracker.sh запускає збирач.
- live_tracker.py тягне цифри з Meta API + ганяє Chrome через проксі по лендингах → пише
campaigns.json.
- build_live_dashboard.py малює
index.html.
- wrangler кладе сторінку на Cloudflare.
- Ти відкрив sbc-live-tracker.pages.dev і бачиш свіже.
Через годину — те саме. Нічого не треба натискати.
💰 Скільки це коштує
| Ресурс | Споживання | Кошт |
|---|
| Claude-токени | 0 — в рантаймі немає LLM | $0 |
| Meta API | ~1.5–2k запитів/добу (тротлінг, лише читання) | $0 |
| Mac CPU/RAM | ~5 хв CPU/год; 1 Chrome на ~15с/лендинг, закривається | $0 |
| Cloudflare Pages | 24 деплої/добу × ~150 КБ | $0 (free) |
| US-проксі | трафік на обхід лендингів | єдиний платний ресурс |