Разработали платформу партнёрского маркетинга для Quints

Существует множество различных виртуальных гемблинг-заведений, от казино до тотализаторов. Чаще всего игроки узнают об этих казино и тотализаторах не напрямую, а через посредников, которые распространяют ссылки на них, обычно с помощью баннерной рекламы.

Если игрок регистрируется в казино через такую ссылку, процент от прибыли с этого игрока уходит к посреднику. Quints даёт возможность автоматического отслеживания реферальных ссылок, чтобы точно знать, откуда и через какого посредника пришли игроки.

В платформе для аффилиатного маркетинга Quints существует три вида пользователей:

• Заказчики — брокеры онлайн-казино, букмекеры, или даже интернет-магазины.
• Игроки — лица, которые играют в онлайн-казино, делают ставки на тотализаторе или покупают товары в интернете.
• Партнёры — посредники, которые приводят игроков на площадку заказчика, в основном с помощью рекламы. Заказчики пользуются услугами различных рефералов и выплачивают им вознаграждение.

Чтобы правильно выплачивать вознаграждение, заказчикам нужно знать, как много игроков пришло от каждого партнёра, и сколько денег они потратили. Именно эту задачу решает Quints.

Это система сбора статистики реферального маркетинга и обработки данных, которая может строить разнообразные графики и отчёты об отслеживании партнёрских ссылок. Quints пользуются как заказчики, так и партнёры, поэтому в системе существует два разных вида аккаунтов.

Задача — доработать продукт и улучшить кодовую базу

Quints генерирует реферальные ссылки, которые используются в рекламе. Когда пользователь переходит по такой ссылке, он сначала попадает в Quints, которая записывает данные о посещении и перенаправляет пользователя на сайт заказчика.

На основе этих данных система рассчитывает вознаграждение за каждого приведённого пользователя. В этом смысле Quints — своего рода агрегатор игровой статистики для онлайн-казино.

Владельцы Quints обратились в Evrone, когда их проекту системы управления реферальным маркетингом было уже два года. В приложении было много легаси-кода, а готово оно было на 70–80 процентов. Совместными усилиями мы улучшили этот код и закончили проект. Сейчас наша команда работает над оптимизацией и новыми фичами, которые позволят сделать проект по-настоящему впечатляющим.

Главная сложность для Quints была в том, что для каждого нового заказчика создавался отдельный форк исходного кода, и из него развертывалось новое приложение с некоторыми изменениями специально для этого клиента.

Проще говоря, для десяти клиентов у них было десять разных систем. Каждый клиент хотел иметь возможность изменять и улучшать свой проект в будущем. Таким образом вместо одного проекта мы были вынуждены поддерживать и разрабатывать десять, и это число продолжало бы расти по мере появления новых клиентов.

Внедрять новые фичи было очень сложно, поскольку все форки немного отличались друг от друга, и приходилось учитывать эти различия. Дальнейшая работа с такой архитектурой была бы невозможной. Quints хотели привлекать новых клиентов, но каждый клиент добавлял ещё больше работы.

Решение

Когда мы включились в этот проект, то в первую очередь сменили подход к архитектуре. Мы начали (и продолжаем) двигаться в сторону единого проекта. Все клиенты будут использовать один и тот же код, а кастомизировать систему будут настройками.

В ходе работы над проектом мы также пришли к выводу, что в нём недостаёт дополнительного слоя между заказчиком и самим приложением. Мы создали сервис, который позволяет клиентам отправлять нам сырые данные. Мы их собираем и обрабатываем с помощью системы хранения данных и переводим в нужный для Quints формат. Теперь клиентам не приходится агрегировать и обрабатывать информацию у себя. С этим справляется сервис, который обрабатывает большие объёмы данных без падений и проблем.

Совместно с командой Quints мы с нуля разработали документацию к проекту. Мы также стараемся поддерживать все тесты проекта в актуальном состоянии. В целом, проект сейчас находится в фазе активного рефакторинга функциональности.

Стек технологий

Проект не монолитен, а разделен на фронтенд и бэкенд. Бэкенд написан на Ruby on Rails, а фронтенд — на Angular.js. Это отдельные приложения, которые взаимодействуют через API.

Инфраструктура: Kuber, DO, Prometheus (self-hosted), ELK (self-hosted), Amazon, CloudFlare

Фронтенд: SPA (single page application) на Angular.js

Бэкенд: Ruby 2.3, Rails 4.2, Postgres 9.x, ClickHouse и Sidekiq Enterprise

Дополнительно: Gitlab (self-hosted), Jira, Confluence, Sentry (self-hosted), Mailgun, Testrail, Quints VPN

Сначала для развертывания проекта на серверах мы использовали Capistrano, но затем постепенно перешли на Docker и Docker-compose, а позже — на Kubernetes. Чтобы у клиента не было проблем с поддержкой инфраструктуры, мы помогли запустить DevOps-направление в Quints и подобрать персонал.

Для мониторинга состояния приложения мы используем:

• Sentry — для отслеживания исключений в приложении;
• Grafana — для мониторинга потребления ресурсов.

Проект сильно зависит от gitflow. Для каждого клиента создаётся форк основного проекта. Мы написали специальный скрипт для синхронизации дочерних проектов с основным. Это временное и не слишком удобное решение, но мы уходим от этого подхода.

Проект также много раз подвергался DDoS-атакам. Для защиты от перебора паролей и прочих атак грубой силы мы использовали библиотеку rack-attack.

Постепенно внедряем новые решения для улучшения работы с приложением. Логика обработки данных разбросана по коду и SQL-запросам, так что оптимизация затрагивает оба этих компонента. Для оптимизации мы используем стандартные инструменты, такие, как RSPec-benchmark, RubyProf, StackProf и MemoryProfiler.

Поскольку данные приходят от клиентов, мы реализовали поддержку различных источников данных. Сначала приложение поддерживало только SFTP, но теперь может работать также с облачным хранилищем Google и получать данные напрямую через API клиентов.

Выстраиваем проверку качества

Для координации всего процесса тестирования на проекте мы выбрали TestRail. Это комплексное решение для хранения тест-кейсов и анализа результатов прогонов, и инструмент, который позволяет делать индивидуальные наборы кейсов для проверок под разные типы тестирования, наглядно показывает связь с автоматизацией.

Основной упор в QA был на бэкэнд и проверку математических формул, по которым рассчитываются параметры для каждого отдельного клиента. Часть тестов была универсальной для разных типов клиентов и партнёров, но большая часть кейсов уникальна. Это связано с тем, что на бэкенде для них предусмотрена разная логика расчёта ставок. 

Основная стратегия тестирования заключалась в создании пользователей с заданными параметрами и картами их дальнейших взаимодействий с сайтом. Мы проверяли корректность расчета комиссии за приглашение новых клиентов, корректировку вознаграждения в зависимости от активности и длительности использования системы и т.д.. Нужно предусмотреть несколько десятков подобных сценариев, описать их и связать друг с другом. Количество таких ролевых моделей напрямую зависит от масштабов проекта и его функционала. 

От Evrone на проекте фуллтайм работают два QA-инженера, также в команде обеспечения качества есть автоматизатор со стороны заказчика. Наши специалисты оказывают ему поддержку в разборе логики работы системы и приоритезируют тест- кейсы для автоматизации.

Исправляем ключевые функции сервиса

Одной из проблем, с которыми мы столкнулись, было неверное вычисление статистических параметров либо из-за ошибок в клиентских данных, либо из-за ошибки в приложении. Например, в конце прошлого года нагрузка на многие подпроекты существенно возросла, и они уже не справлялись с объёмом вычислений. Нам приходилось целыми днями наблюдать за приложениями, а в экстренных случаях и обрабатывать поступившие данные вручную.

Кроме того, Quints периодически подвергалась DDoS-атакам. Однако команда DevOps и её тим-лид быстро справлялись с этими попытками положить проект, и он никогда не становился недоступным. У нас также была проблема со злоумышленником, который зарегистрировался в системе и начал отправлять автоматически сгенерированный трафик. Мы это быстро обнаружили и заблокировали нарушителя.

Строим систему распределения трафика

Поначалу монолитное приложение на Rails едва могло обработать 600 запросов в секунду (речь о показе баннеров и кликах на них). К тому же база данных Postgres по мере роста также перестала справляться с объёмом данных, и секционирование не слишком помогало.

Один из ключевых корпоративных клиентов Quints потребовал новую функциональность и уровень нагрузки. Ему понадобилась возможность гибкой настройки перенаправления трафика в соответствии с правилами. Например, пользователь мог быть направлен на определённый ресурс в зависимости от географического положения, времени рекламной кампании и других параметров. По этой причине мы добавили систему распределения трафика, которая служит посредником по продаже и покупке трафика между сайтами.

Нам хотелось, чтобы эта система справлялась как минимум с 2000 запросов в секунду, и мы выделили её в отдельный сервис, а не включили в монолитное приложение. Часть архитектуры мы разработали с нуля, а часть перенесли из старого монолитного приложения.

Систему распределения трафика мы разработали на основе микросервисной архитектуры с использованием микрофреймворка Roda для Ruby. Для хранения данных о кликах и просмотрах мы использовали систему управления базами данных Clickhouse, которая способна обрабатывать большие объёмы данных в секунду и очень быстро выполнять аналитические запросы. Для отправки данных в Clickhouse и доставки агрегированных данных обратно в Quints мы использовали Kafka.

В результате:

• Реализована функциональность распределения трафика.
• Каждый компонент этой системы является горизонтально масштабируемым.
• Каждый узел системы способен обработать 4000 запросов в секунду и добавление новых узлов повышает общую производительность.
• Из монолитного приложения мы вынесли часть функциональности, что сделало его более простым в модификации, поддержке и расширении.
• Уменьшена нагрузка на монолитное приложение.
• Уменьшена нагрузка на базу данных Postgres.

Результат

Кроме разработки и поддержки непосредственно сервиса мониторинга партнёрских ссылок, мы также участвовали в разработке следующих процессов:

• написания технической документации;
• оценки сроков разработки и внедрения новых фич;
• подбора персонала;
• онбординга, включая текстовую и видео-документацию, обучение и работу с обратной связью;
• оффбординга;
• подготовки месячных отчётов для конечных клиентов.

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

Мы добились отличных результатов, заказчики остались довольны и решили расширить участие Evrone в проекте. Сейчас команда Evrone для проекта Quints включает 10 бэкенд-разработчиков, трёх тестировщиков, а также аккаунт-менеджера и project-менеджера, который напрямую участвует в руководстве всей командой проекта из двадцати с лишним сотрудников.

Если вам нужно программное обеспечение для онлайн-казино или отслеживания партнёрских программ, или вы хотите узнать больше о том, как отслеживать партнёрские ссылки и использовать инструменты партнёрского маркетинга, обращайтесь к нам через форму обратной связи.