3 ошибки при внедрении сквозной аналитики. Опыт девелопера

Рассказываем, с какими проблемами столкнулись, пока настраивали весь процесс. Спойлер: первая проблема — мы сами.

Есть мнение, что сквозная аналитика — это «коробка», некая CRM, которая делает всё сама. На самом деле это методология, которая помогает нам оценить эффективность всех каналов привлечения и интерфейсов, работу офлайновых точек — например, офисов продаж и агентств. Благодаря этому можно увидеть, в какой точке воронки продаж что-то сломалось и нужно срочно чинить. Но это в идеале.

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

На клиента может быть несколько клиентских идентификаторов — cookie, аудиозаписи звонков, записи в CRM. Из-за этого мы можем принять одного человека за разных людей, «клонировать» покупателя, неправильно оценить каналы привлечения и убить те, которые реально приносят сделки.

Да, такое тоже бывает. На старте проекта по сквозной аналитике мы не продумали подробную карту «склейки» клиента, если он касался компании в разных цифровых точках. В общем, как заказчик мы не поставили нормальную задачу для исполнителя.

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

Например: клиент может оставить номер телефона в заявке на сайте, может позвонить с этого номера телефона через систему кол-трекинга, а может прийти в офис на живую встречу без предварительной записи. И все такие случаи должны объединяться в одну карточку клиента — по номеру телефона.

Для сквозной аналитики мы пользуемся тремя системами:

На этапе внедрения мы поняли, что cookie стандартных систем статистики — Google Analytics и Яндекс.Метрики — недостаточно точные.

Ежедневная частичная блокировка или потеря cookie «замыливала» до 25% посетителей сайта на временном окне в три месяца. По некоторым потенциальным клиентам у нас была только часть истории их посещений сайта, и мы неправильно оценивали работу рекламных каналов в разрезе клиентского пути.

«Замыливание» происходит по разным причинам. Одна из них — регулярная очистка cookie у мобильных пользователей. Например, для безопасности. Если человек посещал сайт реже, чем очищал историю на устройстве, то каждый раз мы видели его как нового клиента.

Также ряд устройств, браузеров и расширений удаляет cookie общеизвестных систем трекинга (Google Analytics, Яндекс.Метрика) сразу после закрытия сайта, чтобы повысить анонимность пользователя. Для нас это было чревато неточными данными.

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

Ещё одна сложность была исключительно инженерной. Сейчас объясним.

Нужно было корректно связать событие поступающего звонка в CRM с событием звонка в системе кол-трекинга. И это важно было сделать именно на уровне CRM. Почему так?

CRM обменивается с кол-трекингом данными (тегами) по каждому звонку — это используют агентства и команда цифровой рекламы, чтобы оценить эффективность каналов рекламы. Если с каких-то рекламных кампаний массово приходят нецелевые звонки, нужно срочно оптимизировать кампании.

Решение принимается, в частности, на основании записей звонков, которые есть в системе кол-трекинга, поэтому логично иметь отдельную мини-аналитику на базе кол-трекинга. Для этого требовалась глубокая интеграция кол-трекинга и CRM.

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

С рекламными кампаниями и целевыми звонками точно так же. Важно максимально точно знать всю историю взаимодействия с рекламой каждого клиента. Иначе есть риск оптимизировать рекламу «на глазок».

Такую работу с данными называют Data Mesh. Фактически это последовательное развитие цифровых сервисов внутри компании. Сначала есть только CRM, с появлением кол-трекинга добавляется обмен данными между системами. Потом внедряется сквозная аналитика: это позволяет собирать данные из CRM и кол-трекинга в одном месте.

Потенциально это увеличивает объем интеграций между сервисами, но снижает риски простоя всех сервисов разом из-за отказа одной из частей в архитектуре Data Lake.

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

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

В итоге 98% звонков смогли отметить всеми нужными параметрами: источники заходов, cookie клиентов, рекламные кампании.

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

Поделитесь в комментариях вашими ошибками и проблемами при работе с данными: возможно, это поможет нам и коллегам.