Як ми розробили автопілот для прийняття маркетингових рішень: шлях від Google Sheets до Grafana
Привіт! Мене звати Антон Пінкевич, я Engineering Team Lead в українській продуктовій ІТ-компанії Universe Group. Уже три роки я допомагаю створювати та масштабувати один з наших бізнесів — сервіс Wisey для підвищення персональної продуктивності користувачів зі всього світу.
Зі зростанням бізнесу завжди виникає питання масштабування процесів. Так було і в нас, коли витрати на маркетинг досягли семизначних чисел. Наразі всі рекламні кампанії підтримує дві людини, а технічна команда постачає їм інструменти для автоматизації.
💡 Перша конференція DOU Front-end Day 2025
Про один із таких інструментів я розповім у цій статті. Вона написана в художньому стилі з описом деяких принципів, за якими ми приймаємо рішення. Думаю, це цінніше, ніж просто констатація фінального результату. Матеріал буде корисним Back-end розробникам і розробницям рівня Middle+, а також технічним i UAM лідам.
TL;DR: ми підключили графану безпосередньо до бази даних і налаштували правила алертів, що редагують дані в рекламних кабінетах.
Проблема
Перший принцип, яким ми керуємося у Wisey: «Treat everything as a code» («Стався до всього, як до коду»). Це стосується навіть підходів до маркетингу. Тож коли постало питання масштабування команди чи створення автоматизації — команда підтримала другий варіант. Спочатку потрібно було сформулювати проблему, яку ми хочемо вирішити за допомогою коду.
На початку спільно з маркетологами ми сформулювали проблему так: «Необхідно створити адмінку для моніторингу та редагування рекламних кампаній». Це формулювання чітко фокусується на технічному рішенні, тому ми перефразували: «Необхідна штука, яка дасть змогу моніторити маркетингові показники та модифікувати рекламні кампанії в режимі реального часу». Використання абстрактних слів, наприклад «штука», допомагає мозку у свободі мислення.
Крок 1. Первинна реалізація (MVP)
За своєю натурою ми «ледачі» інженери і хочемо розв’язувати подібні завдання мінімальними зусиллями. Це співвідноситься з нашим другим принципом «Write a minimum possible amount of code to solve a problem» («Пиши мінімально можливу кількість коду для розв’язання проблеми»). Тому ми почали шукати існуючі інструменти, які допомогли б нам досягти мети з мінімальними витратами часу та зусиль.
Зупинилися на простому рішенні: створити Google Sheets таблицю з вбудованим Google Apps Script’ом, що звертається до API рекламних кабінетів (FB, Google, TikTok) для збору даних і агрегації звітів у табличку.
Маркетолог зі свого боку налаштовує правила для автоматичних дій в reveal bot’і або вказує в колонці потрібну дію для запуску команди, що змінює дані в рекламних кабінетах.
Для зручності ми створили набір коротких команд-позначень:
- зміна бюджету;
- зміна ставки;
- зміна бідінгової стратегії;
- зупинка кампанії.
Знахідки щодо роботи з Google Apps Scripts
Для зручної спільної роботи середовище Google не підходить: немає нормальної історії змін, незручно працювати з вбудованим редактором коду, не кажучи про TypeScript типізацію.
Для нашої команди стандартне рішення — підняти свій репозиторій та побудувати build pipeline, що ми і зробили. Таким чином ми з коробки отримуємо доступ до колаборації, CI/CD для перевірки коду та інших інженерних інструментів (типізації, лінтерів, форматтерів і т.д.).
Залишилося питання, як розв’язати проблему деплою. Після недовгого пошуку ми знайшли цікавий інструмент: https://github.com/google/clasp. З недоліків: у ньому немає можливості нормального налаштування CI/CD (токени гугла постійно протухають і немає офіційної підтримки токенів, що довго живуть). Тобто деплої подібних скриптів можна робити тільки вручну. Але коротка документація розв’язала цю проблему. Будь-який член команди може за допомогою невеликого скрипта згенерувати тимчасовий токен і зробити деплой. Працює це через дві команди:
Крок 2. Виділений мікросервіс
Рішення з таблицями було зроблено за пару робочих днів і прослужило нам досить довгий час. Проблеми почалися з масштабуванням: таблички не справляються з великими обсягами даних, і виникли складнощі з отриманням інформації з рекламних кабінетів через Google Apps Script. Вирішили, що потрібно «розвантажити» отримання даних і зробити стримінг. Підняли окремий мікросервіс, у який винесли агрегацію даних і застосування дій до рекламних кампаній.
Через великі обсяги дані почали витягуватися з нового мікросервісу поступово, але це все одно працювало нестабільно і Google таблиця періодично відвалювалась.
Крок 3. Grafana
Писати свою адмінку дуже не хотілося, UI-related open source рішення не підходили до потрібних вимог. І з’явилася ідея застосувати нестандартне рішення — використовувати Grafana як засіб візуалізації даних.
Ми вже використовували Grafana для моніторингу логів, тому підключили PostgreSQL-плагін для отримання даних.
Це рішення чудово спрацювало: звіти стали швидкими та стабільними. Grafana дозволила нам отримати величезний набір можливостей для візуалізації, і все працює набагато ефективніше.
Приклад налаштування звітів (прості SQL-запити):
Який вигляд мають звіти:
Grafana Alerts
Проблема редагування рекламних кампаній залишалася.
Спочатку думали про те, щоб створити плагін у Grafana, який дасть змогу редагувати дані вручну. Але це суперечить головному закону вирішення винахідницьких завдань — системи немає, але дія виконується. Тому від цієї ідеї відмовилися на користь, як нам здається, більш грамотного підходу — розроблення фреймворка ухвалення рішень. Тобто ідея полягала в тому, щоб маркетологи могли декларувати правила, за якими система працюватиме. Механізмом перевірки цих правил стали алерти графани.
Працює система дуже просто: декларується набір даних і умов, у разі їхнього виконання графана повідомляє мікросервіс за допомогою вебхука. І вже мікросервіс за старою схемою йде застосовувати дії через REST API рекламних кабінетів.
Приклад налаштування алерта в Grafana:
А це приклад «вистрілу» алерта:
В результаті фінальна архітектура рішення має такий вигляд:
Висновки
Іноді неочевидні рішення працюють набагато краще за очевидні. Для цього потрібно вміти правильно сформулювати проблему, створити мінімально робоче рішення, зібрати зворотний зв’язок і повторювати цикл. Що швидше проходить цей цикл, то якісніші винаходи створює команда.
Сподіваюся, вам сподобався цей екскурс в один із наших процесів. Якщо так, я можу написати ще кілька статей про інші сервіси та процеси в нашій команді.
1 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів