GDPR, вступивший в силу в мае этого года, серьезно повлиял на рынок онлайн-маркетинга.
Его участники хотят создать максимально точную аудиторию для показа рекламы, но теперь для этого необходимо получить явное согласие пользователя, иначе даже небольшой нишевый ресурс может нарваться на многомиллионные штрафы.
Некоторые ресурсы закрылись, но многие трансформируются в соответствии с новыми требованиями.
И наш проект по услуге управления рекламной кампанией для клиента из США – отличный тому пример.
О сервисе
Наш клиент, американская компания из Лос-Анджелеса, занимается маркетингом в музыкальной индустрии.Ее сервис обеспечивает поддержку сложных рекламных кампаний для групп любого размера – от банды за углом до звезд мировой сцены.
По сути, сервис нашего клиента — это стартап, разрабатывающий специализированную маркетинговую платформу, сумевшую привлечь инвестиции звукозаписывающих компаний, поскольку учитывает особенности поведения аудитории в конкретной отрасли.
Платформа позволяет таргетировать рекламу, анализируя поведение пользователей, когда-то проявивших интерес к той или иной группе.
Основными пользователями ресурса являются музыканты и работники индустрии (менеджеры, сотрудники звукозаписывающих компаний, организаторы концертов и многие другие).
К моменту запуска нашего проекта сервис уже функционировал и успел занять определенную позицию на рынке.
Однако это был скорее прототип, проверявший основную бизнес-гипотезу, тем более что часть функционала была реализована через партнерские сервисы.
Мы включились в разработку для создания полноценной архитектуры, и GDPR стал толчком, запустившим все преобразования.
Перед нами была поставлена задача не просто обновить существующий сервис, а перестроить его с учетом нового законодательства, обновить пользовательский интерфейс и довести его до большего единообразия.
Выполнение
Весь проект был разделен на несколько этапов.
На первом этапе мы переписали с нуля ту часть, которая раньше работала на PHP — сокращатель ссылок и сервис авторизации.
Сокращатель ссылок — это функционал, который доступен бесплатно всем зарегистрированным пользователям и используется для привлечения клиентов к платным сервисам компании.
Сервис позволяет сократить длинную ссылку до короткой формы, чтобы опубликовать ее в социальных сетях.
При этом ссылку можно настроить, настроив, например, геотаргетинг: в зависимости от страны, из которой пришел пользователь, ему могут показываться разные целевые страницы.
При обновлении бэкенда мы использовали OpenJDK 1.8, Kotlin и Spring boot/data/web — стандартный фреймворк для проекта, не предполагающего высоких нагрузок.
Кстати, именно в этом проекте мы впервые попробовали Kotlin «в бою», и за счет его синтаксиса он позволил нам значительно ускорить разработку.
Мы обязательно будем использовать его в других проектах.
База данных сервиса авторизации и сокращателя, реализованная на первом этапе, построена на базе PostgreSQL — реляционная модель хранения данных хорошо подходит для решения этих задач.
На втором этапе мы взяли на себя управление рекламными кампаниями.
Этот функционал и раньше существовал на платформе клиента, но через партнерский сервис, за который нужно было платить.
Сейчас платформа заказчика выросла до масштабов, когда необходимо было позаботиться о ее инфраструктуре.
Гораздо проще развивать собственный сервис, в отличие от стороннего, в правильном направлении, быстро внося необходимые изменения.
В этой части проекта мы реализовали только внешний API для менеджера кампаний.
Но на третьем этапе мы разработали этот модуль — доработали API и создали полноценный UI для менеджера кампаний.
Параллельно мы разработали собственную небольшую DMP (платформу управления данными), которая управляет сбором данных о посетителях.
Данные DMP хранятся в MongoDB, так как мы решили оставить резерв для будущего горизонтального масштабирования этой базы данных.
На данный момент DMP обслуживает до 2 тысяч запросов в секунду (в пиках), при этом мы были ориентированы на хранение примерно терабайта данных.
Такой объем можно было бы сохранить в PostgreSQL, но в долгосрочной перспективе его масштабирование потребует больших усилий.
Тот же MongoDB используется в базе данных менеджера кампаний (Campaign DB) — здесь нам хорошо подошла документно-ориентированная модель базы данных.
Кампании запускаются как отдельные объекты и могут быть расширены.
Все кеши работают на Redis. Фронтенд: Angular 5, TypeScript, HTML5, Sass, Node.js, npm, Angular CLI. На последнем этапе проекта мы интегрировали системы клиента и сервис ключевого партнера, предоставив компании доступ к огромной базе музыкантов, что обеспечит увеличение количества пользователей.
В проекте были определенные трудности.
Заказчик хотел сохранить данные пользователей и регистрации, накопленные за время работы сервиса, немного изменив модель.
Параллельно с редизайном архитектуры мы перенесли регистрацию и изменили ее принципы — с имени пользователя на почту в качестве логина, что принесло нам много бессонных ночей из-за ограничений на количество пользователей с одним адресом электронной почты.
Изменилась и модель прав в системе.
Раньше сервис работал по двухуровневой модели, но мы реализовали модель прав без ограничений (в том числе с возможностью выдачи ограниченных прав).
При этом функционал был расширен.
Например, на одном этапе появился мультимагазин, с помощью которого конечные посетители, перешедшие по коротким ссылкам на конкретную композицию, могут создавать страницы со списком сервисов, где эти композиции доступны для легальной покупки или прослушивания.
Отдельно стоит упомянуть о GDPR.
Основной рынок нашего клиента — США, но около 10% трафика приходило из Европы, которую компания не хотела терять.С момента вступления нового постановления в силу (25 мая 2018 г.
) его таргетинг просто отключили.
Посоветовавшись с юристами, мы построили сервис таким образом, чтобы он не противоречил GDPR, и 16 августа снова запустили таргетинг.
Честно говоря, вся группа потратила две недели на изучение тонкостей регламента.
Сложность на этом этапе заключалась в том, что при общей неясности формулировок до сих пор нет правоприменительной практики - реальных случаев, которые могли бы показать, как правильно поступать, а как неправильно.
Однако теперь (после собственных исследований и консультаций с юристами) мы уверены в реализованной архитектуре решения.
Логика сервиса подразумевала отнесение пользователя, перешедшего по короткой ссылке, к определенной аудитории, чтобы потом ему можно было показывать рекламу.
С точки зрения GDPR, это невозможно сделать без явного согласия самого пользователя.
И мы реализовали запрос согласия — при нажатии на ссылку внизу страницы появляется поле с вопросом и двумя кнопками.
Запрос открывается пользователям, чей IP находится в Европе, а их ответ сохраняется в виде cookie, поэтому посетителям не придется каждый раз нажимать кнопки.
При отсутствии согласия пользователя (т.е.
cookie) мы просто не показываем ему пиксель, т.е.
факт посещения будет учтен в общей статистике сервиса, но данные пользователя не будут собираться и учитываться.
GDPR накладывает архитектурные ограничения — персональные данные должны не только правильно собираться, но и надежно храниться.
В нашем случае эти ограничения касаются реализованной DMP (несмотря на то, что там хранятся обезличенные данные с анонимными идентификаторами, которые лишь гипотетически позволяют их деанонимизировать) и базы сервиса авторизации.
В нашей архитектуре эти базы четко разделены на отдельные блоки.
В соответствии с регламентом доступ третьих лиц к этим «чувствительным» модулям, естественно, ограничен.
Доступ к авторизационной базе данных имеет только соответствующий сервис.
Все остальные сервисы ничего не знают о персональных данных пользователя платформы — им нужна только проверка со стороны сервиса авторизации.
В базу данных DMP также включен только одноименный сервис.
В этом случае из базы данных возвращаются только агрегаты данных об аудитории, а не сами данные.
Эти блоки составляют основу аналитики, которую пользователи сервиса из музыкальной индустрии получают в своих личных кабинетах.
Также у нас есть обязательная процедура загрузки и удаления пользовательских данных.
Вопрос здесь заключался в том, как проверить, что пользователь действительно законно запрашивал свои данные.
И мы используем «cookie», сохраненный пользователем, в качестве фактора проверки.
Проект завершился совсем недавно, поэтому о каких-либо численных результатах говорить пока рано.
Автор статьи: Николай Ерёмин P.S. Мы публикуем наши статьи на нескольких сайтах Рунета.
Подпишитесь на наши страницы по адресу ВК , ФБ или Telegram-канал Узнать обо всех наших публикациях и других новостях Максилекта.
Теги: #GDPR #Kotlin #postgresql #сокращение ссылок #управление рекламой #mongodb #музыкальный бизнес #сокращение ссылок #таргетинг #dmp #redis #Интернет-маркетинг #Реклама в СМИ #ИТ-законодательство #Медиа-менеджмент
-
Smarty Против Twig: Производительность
19 Oct, 24
