Привет! Мы Collect

Представьте, что человек пришел по рекламе и оставил заявку. Менеджер позвонил, договорился, продал. Все довольны: и бизнес, и клиент. Потом открыли аналитику. А заявки там нет.

Менеджер говорит: «Была!». Отчет говорит: «Не было!». Покупатель, к счастью, в этом споре не участвует. Он уже купил. Ему хорошо.

Тут можно было бы и посмеяться. Но по отчету руководство будет решать, какую рекламу оставить, а какую отключить. И тут уже хочется, чтобы данные все-таки дошли. Иначе получится, что продажа есть, а реклама, которая к ней привела, будто зря потратила деньги. Ей сократят бюджет. Потом заявок станет меньше, и все будут думать, что же случилось. Хотя случилось-то раньше. Просто в отчете этого не было видно.

Мы работаем с аналитикой и передачей данных и такие расхождения регулярно встречаем в проектах. Причем как в белорусских, так и в зарубежных. Иногда за ними стоит небольшая ошибка. А вот последствия, как видите, могут быть совсем не маленькими. Поэтому нам важно, чтобы компания могла проверить, что происходит с ее данными, прежде чем принимать по ним решения. Собственно, это и есть основная задача, которую мы решаем и вокруг которой строим бренд Collect.

Теперь познакомимся

Мы инженерная команда. Почти все из БГУИР, только профессиональные дороги у нас получились разные. У одних за плечами больше 15 лет в аналитике, у других — 20 лет в программировании. Есть специалисты по защите информации и бизнес-коммуникациям. Друг друга знаем не одно десятилетие и теперь работаем вместе под брендом Collect.

Этой же командой мы проектируем решения для клиентов, внедряем их и сопровождаем после запуска. Если возник вопрос, клиенту не нужно выяснять, к кому с ним идти: к разработчику, интегратору или поддержке. Все сидят рядом, и по каждому этапу понятно, кто за него отвечает.

Свои данные тоже можно потерять

Вернемся к заявке. На сайте, как вы помните, она была. А вот до аналитики сведения о ней не добрались. Может, помешал блокировщик. Может, после обновления сайта изменился сбор. Бывает и обратная история: событие отправилось дважды, и отчет стал даже лучше. Только вот продаж от этого не прибавилось.

Сам отчет причину не объяснит. Он посчитал то, что получил. Чтобы понять, где возникла ошибка, нужно видеть путь данных. А путь этот часто проходит через несколько инструментов (закрытых и зарубежных), каждый со своими настройками. Компания вроде бы знает, что происходит на ее сайте. Но стоит спросить, что именно ушло в рекламный кабинет, и… тут возникает неловкая пауза. Потому что на этот вопрос у бизнеса ответа нет.

Это касается данных, которые появляются из прямых взаимодействий клиентов с бизнесом: на сайте, в приложении, CRM, кассах. Их еще называют данными первой стороны. Они есть у самой компании, но возможности управлять их сбором и передачей порой не хватает. И получается странно: данные о своем бизнесе есть, а проверить их путь бизнес не может. Нет контроля.

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

Отдельный вопрос — трансграничная передача персональных данных. Просто отправлять их за рубеж в общем потоке нельзя: для этого нужны законные основания. Без них это нарушение. Причем на пустом месте. Ведь по сути персональные данные рекламному кабинету знать не нужно. Алгоритму покупателей искать, а не звонить им. Покупка была? Была. На какую сумму? Вот сумма. А имя, телефон и прочее должны оставаться у компании. Для этого у нас, кстати, есть фильтр персональных данных. Он убирает или хэширует информацию перед отправкой.

В основе серверной части — серверный Google Tag Manager (sGTM). Вокруг него мы построили свои сервисы и интеграции. Бизнесу не нужно собирать все это по частям, искать исполнителя для подключения и потом еще кого-то для поддержки. Подключаем, внедряем и сопровождаем мы. Под ключ.

Выглядит это примерно так:

Заявка пришла. А дальше?

Допустим, с передачей вопрос решили и все хорошо. Рекламный алгоритм узнал, что человек оставил заявку, и пошел искать похожих людей. Но что делать, если этот человек потом ничего не купил? И похожие на него люди тоже оказались специфическими: заявки оставляют, но деньги в кассу не приносят. Получается конфуз, однако: алгоритм свою задачу честно выполнил — заявки принес. Но компания-то хотела продаж. Выручку. Маржу. И что теперь?

А теперь ему надо об этом сообщить. Заявка была, но покупки не случилось. А вот по другой заявке человек заплатил. И по третьей тоже. Эти данные есть в CRM, и платформа Collect может передать их в рекламную систему. Иначе алгоритм так и будет искать любителей оставлять заявки. Ему же сказали, что это хорошо. Вот он и старается.

Или еще пример. Человек оформил заказ на сайте, а оплатил позже в магазине. На сайте заказ, в кассе деньги. Все на месте. Только в рекламную систему сведения об оплате не попали, и там покупателя до сих пор нет. Хотя он уже с товаром домой ушел. Если данные заказа и рекламные метки сохранены, Collect может связать оплату с заказом и передать ее дальше. Чтобы покупка была учтена и там, где по ней будут оценивать рекламу.

Но тут возникает следующий вопрос. До покупки человек мог прийти по рекламе несколько раз. Из разных каналов. Кому теперь засчитать продажу? Рекламные кабинеты обычно не стесняются: каждый записывает ее себе по своим правилам. Один по первому клику, другой — по последнему. Основания есть у обоих. Только покупка-то одна. И деньги за нее компания получила один раз.

Вот для таких задач у нас есть хаб атрибуции — отдельный модуль платформы. Он работает с историей рекламных касаний и оценивает вклад каналов в выручку по выбранной модели. Этой разработкой мы особенно гордимся. Но здесь уже нужен отдельный пост. С примерами. Потому что одной фразой «каждый считает по-своему» вопрос с бюджетом не решишь.

И еще. Про людей

Мы много говорим о данных, но за ними стоят люди. У них есть права, а у компании — обязанности. Даже если маркетингу очень-очень нужны конверсии и горит план. Поэтому требования Закона РБ № 99-З «О защите персональных данных» касаются и нашей работы.

У Collect есть собственный виджет согласий. Человек может отказаться от необязательной обработки, и система должна учитывать его выбор. А то спросили разрешения, получили «нет» и все равно сделали по-своему. Тогда это был не вопрос, а просто декорация, за которую бизнес могут сильно наказать.

Где будет работать платформа, тоже зависит от требований компании. Можно в облаке Collect в аттестованном ЦОД (центре обработки данных). Тогда инфраструктуру обслуживают инженеры из нашей команды. Если банку или другой компании нужно размещение внутри собственной инфраструктуры, есть вариант серверного развертывания. Тогда доступы остаются под контролем ИТ-команды заказчика.

Но поставить сервер в надежном месте — еще не вся защита. Есть требования к самой системе, в том числе предусмотренные приказом ОАЦ № 66. Поэтому специалисты по защите информации у нас тоже есть.

О чем этот блог

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

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

Будем показывать на примерах и картинках. И объяснять простым языком. Чтобы после поста можно было проверить что-то у себя, задать вопрос подрядчику или наконец понять, почему два отчета не сходятся. Иногда понадобится код. Его тоже покажем и объясним, что он делает. Да, не всем он нужен, но это, как-никак, блог инженеров. Тут только понять и простить.

Важный момент: конфиденциальность клиентов для нас в приоритете, поэтому названий компаний и закрытой информации в кейсах может не быть. Но останутся сама задача, решение и результаты, которыми можно поделиться. Чтобы было понятно, что произошло, почему и как решение сработало.

Если у вас уже есть вопрос, напишите нам. Мы почти всегда на связи. Работаем. Правда, за излишний трудоголизм часто получаем от домочадцев по шапке, но это уже совсем другая история…