Calibra

Процеси компанії нашого клієнта

Багато компаній на ринках з невеликим зростанням віддають перевагу стандартним методам конкурування, а саме, скороченню операційних видатків, наймання більш продуктивних співробітників чи оптимізація податків. Наш клієнт у цьому кейсі не тільки добре володів цими способами, але й був достатньо сміливим, щоби перевірити своє бачення ринку та інвестувати у більш інноваційні методи розвитку власної компанії.

У цьому кейсі ми розробили BPMS для маркетингової агенції – продукт, що систематизував і оптимізував більшу частину процесів компанії. Задача нашого клієнта – надавати своїм клієнтам якісних лідів за моделлю СРА, себто його клієнти платять за фактом здійснення користувачем цільової дії, наприклад, реєстрації. Для цього потрібно купувати трафік на таких майданчиках як Google Ads, Bing Ads чи Facebook Ads. Взаємодія з такими майданчиками, налаштування аналітики, запуск і контроль мобільних застосунків – це тільки верхівка айсбергу щоденної рутини такої компанії.

Головна мета продукту – усунути повністю технічні задачі з порядку денного співробітників, щоби надати їм можливість зосередитися саме на маркетингових задачах. Управління лендингами, побудова звітів, керування платіжними засобами наших клієнтів – важливі завдання для бізнесу. Ці задачі повинна вирішувати система. Продукт, який ми розробили, розв'язав більшу частину рутинних задач і дозволив нашому клієнту сфокусуватися на питаннях маркетингу, а не технологій. Наш продукт став стратегічним для клієнта, а наше співробітництво – по-справжньому партнерським.

Перед початком тривалої співпраці ми пропонуємо клієнтам пілотні ітерації, в рамках яких ми можемо узнати один одного в роботі й більш якісно підготуватися до системного процесу роботи. В рамках пілота ми вивчаємо домен майбутнього продукту, готуємо пропозицію угоди про співробітництво й зміцнюємо команду потрібною експертизою. Для нас також важливо у цьому процесі показати справжній рівень нашого delivery, не завищуючи і не занижуючи сподівання клієнта перед укладанням серйозних домовленостей. Відтак, обираючи предмет пілотної ітерації, дуже важливо зробити не лише те, що принесе кінцеву цінність клієнту, але й забезпечить максимально зручні умови для розуміння робочих можливостей один одного.

У цьому кейсі пілотним проєктом був модуль збору й відображення маркетингової статистики для однієї з рекламних платформ. Проблема клієнта полягала у тому, що кожен замовник мав кілька рекламних кабінетів (РК) на цих платформах. Відтак, навіть для звичайного місячного звіту про продуктивність реклами треба було зайти у кожний рекламний кабінет окремо, вивантажити статистику й потім звести усе в одну таблицю. Ще один приклад: реакція на неефективні запуски нових креативів чи аудиторій має бути швидкою. Тому потрібно негайно змінювати чи зупиняти рекламні кампанії, якщо вони не показують потрібних результатів. Ми написали вимоги до цього модуля на бізнес-рівні, узгодили їх з клієнтом, визначили бюджет і почали працювати.

Одночасно ми продовжували переговори щодо системної співпраці, розбиралися у ринку клієнта і вивчали специфіку його компанії. Наш клієнт з самого початку був орієнтований на довготривалу співпрацю. Відтак, для планування архітектури продукту треба було врахувати багато факторів, наприклад:

• 

  Обравши основними технології, що застарівають, ми би збільшили ризик того, що найняти нових розробників буде доволі складно.

• 

  Неправильний вибір архітектурних принципів системи може досить швидко призвести до технічної деградації продукту.

• 

  Недостатньо точна оцінка стратегічних пріоритетів може призвести до того, що дослідження будуть забирати забагато часу або прийдеться випускати сирі рішення.

В запланований час ми завершили роботу над функціоналом пілотної ітерації. Для нас найважливішим після випуску пілотного продукту є обмін зворотним зв'язком. Оцінка результатів від нашого клієнта була конкретною і повністю ґрунтувалась на фактах. Найцінніші з оцінок клієнта:

В підсумку, наше рішення перевершило очікування клієнта. За результатами тестової ітерації ми переконались, що наші робочі підходи є схожими і цілі продукту цілком зрозумілі. Відтак, ми запропонували клієнту нашу версію угоди про системне співробітництво, план архітектури продукту і формулювання стратегічних цілей. Останні виглядали так:

• Продукт має максимально автоматизувати усю ручну роботу співробітників компанії. Ми прагнемо не просто оптимізувати процеси, а розв'язувати задачі, для яких ці процеси були створені. Для клієнта було б ідеально, щоби всі технічні задачі вирішувалися автоматизовано, і не потребували участі людини.
• Продукт має бути безпечним для клієнтів нашого клієнта. Усі випадки, де продукт може нанести гіпотетичну шкоду мають бути ретельно опрацьовані. Приклади гіпотетичної шкоди від продукту: продукт самостійно запускає неправильну рекламу, витрачаючи даремно бюджет клієнта, продукт автоматично зупиняє правильно працюючу рекламу, продукт надає недостовірну статистику.

Проробка сценаріїв гіпотетичних проблемних ситуацій

Нижче ми наводимо дві підсистеми в якості прикладу. Ми розробили десятки подібних модулів та побудували досить великий продукт.

Трекінг доходів і видатків

Однією з частин системи була інтеграція з 3rd-party software – маркетинговим трекером Binom , за допомогою якого клієнт працював зі статистикою конверсій на рівні своїх лендингів та отриманих лідів. Задача інтеграції – синхронізувати видатки і доходи. Calibra має безперервно отримувати дані про доходи, що міститься в Binom, а в Binom мають з'явитися дані видатків з Calibra.

Ми узгодили з клієнтом, що треба синхронізувати дані з затримкою не більше 1 хвилини. На перший погляд, на стороні Binom такої частоти досягти неможливо. При перших тестах ми з'ясували, що при відправці даних в два одночасні потоки, ми часто отримуємо помилку про статус з кодом 500 з боку Binom. Для швидкості оновлення, що вимагалася, і стабільності рішення нам треба було відправляти дані на API як мінімум у 5 одночасних потоків, для мінімального запасу на майбутнє потрібно було 10-20.

Binom – продукт, що встановлюється на сервер клієнта. Тому детально описавши проблему у службу підтримки, ми вирішили вивчити продукт самостійно. За нашими оцінками технік, за допомогою яких Binom взаємодіє з базою даних MySQL не передбачали одночасної обробки кількох запитів. Там створювались database locks, які, при великій кількості одночасних запитів, стабільно спричиняли відмову БД від обслуговування таких запитів. Служба підтримки підтвердила наші побоювання: в чинному стані архітектура продукту не закладала можливостей множини одночасних клієнтів API. Схоже, ми були першим клієнтом їх продукту, хто зіткнувся з цією проблемою.

Спочатку ми вирішили переконатися, що кількість запитів на нашій стороні мінімальна. Виявилося, що ми можемо її зменшити, записуючи при кожному статистичному даному дату і час його останньої синхронізації. Якщо у попередній версії рішення ми завжди відправляли кожне дане раз на хвилину, то тепер ми будемо відправляти його тільки якщо воно змінилося з моменту останнього відправлення.

Ця оптимізація виявилася недостатньою, ми як і раніше не змогли досягнути потрібної частоти синхронізації через проблеми 3rd-party. Через те, що Binom не уможливлював горизонтальне масштабування, альтернатива була у вертикальному масштабуванні. Відтак, ми узяли потужний сервер, підібраний під максимально продуктивну роботу MySQL, перевірили наше рішення й переконалися, що проходимо за нашими обмеженнями.

Автоправила

Так ми назвали пресети автоматичних дій з рекламою при виникненні певної ситуації. Найпростіший випадок: якщо при витрачанні певного бюджету ми отримуємо ROI менше 0%, то рекламу потрібно вимкнути. Виконання таких сценаріїв поглинає суттєву частину часу співробітників компанії нашого клієнта.

На момент розробки цього функціонала ми вже реалізували ввімкнення і вимкнення реклами через інтерфейси Calibra на більшості рекламних платформ. Відтак, ми могли використати вже існуючі абстракції і ця частина роботи була готовою. Залишалось спроєктувати і реалізувати самі пресети дій та надати користувачам Calibra можливість вмикати ці пресети для активних рекламних кампаній. Головні функції цього блоку були такими:

• Список дій: зупинка реклами, перезапуск реклами і збільшення бюджету.
• Умова дії повинна враховувати статистику за конкретний інтервал, наприклад: сьогодні, останні 3 дні чи весь час реклами. Формула прийняття рішення може складатися з набору правил, об'єднаних через I. Змінні у формулі – усі статистичні показники, такі як ROI, Сумарні видатки, Сумарний дохід.
• Пресети можуть бути особистими – тільки для одного користувача чи доступними усім користувачам.
• Кожна дія має докладно логуватися в системі, і ці записи мають бути доступні користувачам і читабельними для них. Інакше неможливо буде визначати, чи помилялась система.

У цьому модулі ціна помилки була особливо високою, тому помилятися на рівні проєктування було абсолютно неприпустимо. Тому значну частину часу ми витратили саме на збирання і формалізацію вимог, а також прототипування UI. Ці інтерфейси призначалися для повсякденного використання, тому потребували ретельного опрацювання.

Продукт почав оптимізувати витрати в тих ситуаціях, коли співробітники не могли цього зробити. Наприклад, реклама втрачала свою рентабельність після завершення робочого дня. Раніше вона продовжувала витрачати бюджет до початку нового робочого дня. Тепер ми миттєво зупиняємо її, оптимізуючи рекламний бюджет. Також це рішення суттєво скоротило витрати часу співробітників компанії клієнта на щоденні рутини.

Тривалі співпраці, в яких ми чітко розуміємо цінність, яку ми приносимо клієнту, є найважливішими для нас. Побудова таких продуктів можлива тільки в атмосфері максимальної довіри і взаєморозуміння. Тому ми прикладаємо усі зусилля до створення такої атмосфери з перших днів співпраці. Нині цей наш клієнт бачить себе не тільки маркетинговою компанією, але й технологічною, а Calibra тепер – стратегічно важлива технологія його компанії. Ми глибоко цінуємо цю співпрацю і переконані у подальшому успіху продукту.