Золотой фейл: как мы за 8 месяцев настроили сквозную аналитику, а потом вернули за это деньги

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

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

Если бы эта история стала пьесой, то точно трагикомедией «Женитьба 7 сервисов или безумная настройка веб-аналитики». А главные роли в ней исполняли бы:

— Оптимистичный клиент

— Замученный веб-аналитик

— Наивный аккаунт-менеджер

— Неутомимый программист

— Плачущий хор техподдержки Callibri

— Хор ответственного саппорта amoCRM

— Нервный хор интегратора «Интроверт»

— Молчаливый прохожий Venyoo

На заднем плане перекидываются репликами Яндекс Директ, Google Adwords и Google Analytics.

Мы обожаем веб-аналитику! Настраиваем её всем клиентам, которые приходят за продвижением — а как ещё отследить эффективность этого самого продвижения? Поэтому когда в 2017 году к нам пришёл завод металлоизделий за настройкой аналитики, мы не видели особых проблем.

Клиент поставил перед нами следующую задачу: сделать так, чтобы все поступающие в CRM заявки передавались в отчёт Google Analytics с правильными статусами: «Оплачен», «В производстве» и т. д. Плюс в отчёте должны были отображаться стоимость заявки и бюджет на отдельные рекламные кампании — то, что помогает оценить эффективность рекламы.

В работе клиент использовал Яндекс Директ, Google Adwords, amoCRM, интегратор «Интроверт», онлайн-консультант Venyoo. Все данные о заявках из этих источников должны были передаваться в отчёт Google Analytics.

Берём CRM, настраиваем передачу данных из неё в GA, готово — что может быть проще? Но уже здесь нас ждала проблемка: на тот момент ни в amoCRM, ни в сервисе-интеграторе «Интроверт» не было базовой интеграции с Google Analytics. А ещё не была настроена передача cookie Гугла (client ID) из «Интроверта» в amoCRM.

В первую очередь настроили передачу cookie Гугла из «Интроверта» в amoCRM — уже что-то! Далее началась программистская магия. Нам нужно было:

1. Настроить в AmoCRM webhooks: хуки позволяют интегрировать одну систему в другую. Когда в CRM происходит какое-то событие, данные о нём автоматически передаются в другую систему. С помощью webhooks мы передавали данные о созданных в amoCRM заявках в Measurement Protocol.
2. Настроить выгрузку заказов с разными статусами через Measurement Protocol. Measurement Protocol — платформа Гугл, позволяющая передавать данные из подключённых к интернету устройств в Google Analytics. С помощью этого сервиса мы передавали данные в итоговый отчёт.
3. Настроить формирование отчётов по UTM-меткам. Метки позволяли определить, с какой рекламной кампании, с какого объявления и ключевого слова пришел тот или иной заказ. В итоговом отчёте Google Analytics заявки распределялись по источникам как раз по UTM-меткам.

Клиенту было необходимо, чтобы в итоговый отчёт передавались заявки со статусами «Оплата получена», «Согласованы чертежи», «Отправлено на производство», «Доплата получена», «Успешно реализовано», «Претензия» — учли это при настройке webhooks и Measurement Protocol.

Параллельно подключили передачу данных о рекламных бюджетах из Яндекс Директа и Гугл Ads. Проверяем: данные передаются, вроде всё работает.

Что дальше? Тестирование!

Мы обещали клиенту завершить тестирование за 3 дня, и уже на второй день обнаружили, что примерно 10% заявок не отображаются в Google Analytics. Начали искать причину такого несоответствия:

• Проверили передачу статусов заявок — всё ок.
• Проверили отображение данных CRM — всё ок.
  
• Проверили запросы webhooks — тоже всё ок!
  

Ладно… пытаемся отловить ошибки по логам — это файлы с записями о происходящих на сервере событиях в хронологическом порядке. По сути мы изучали летопись жизни нашего отчёта. Работа кропотливая и занимает много времени. И самое обидное, что и в логах ошибки не было.

Ларчик открывался как никогда просто: Google Analytics обрабатывает данные в течение 24 часов. Как оказалось, наши «потеряшки» просто доходили в отчёт позже остальных заявок.

Мы обнаружили этот факт, предупредили клиента и продолжили тестирование. На этом этапе все заявки собирались в отчёт с правильными статусами и бюджетами:

Но появилась новая проблема. Клиент хотел, чтобы в отчёте автоматически определялся ROI — показатель рентабельности рекламных кампаний. Чтобы он рассчитывался корректно, в Google Analytics должны были передаваться данные о рекламном канале. Информация передавалась через utm-метки, каналы обозначались cpc для контекстной рекламы и cpm для охватной рекламы.

В amoCRM не было поля «Канал», входящие заявки соотносились с рекламными каналами по-другому. Мы указали на этот момент клиенту и решили созвониться, чтобы обсудить дальнейшие действия.

Решение с определением рекламных каналов было простым: нужно было добавить в amoCRM поле с меткой рекламного канала и настроить передачу информации из него в Google Analytics — no problem, поставили задачу программисту, и всё заработало!

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

Что нужно было сделать:

1. Установить счетчики Яндекс Метрики и Google Analytics на 3 лендинга по продаже отдельных видов продукции.

2. Подключить коллтрекинг и емейл-трекинг Callibri, настроить передачу данных в общий отчёт по utm-меткам.
   

3. Настроить передачу данных по заявкам из онлайн-чата Venyoo в тот же гугловский отчёт.
4. Настроить отправку транзакций на разных этапах: от заявки (в виде цели) до закрытия сделки. Добавить в отчёт параметры качество заявки и качество лидов.
5. Провести тестирование в течение 10 рабочих дней, отловить и устранить ошибки.

Дополнительно подготовили чек-лист для тестирования итоговых отчётов:

1. Отправка тестовой заявки на электронную почту. Заявка должна отобразиться в аналитике с нужным рекламным источником (тестовой меткой). После того, как цель отобразилась, прогнать тестовую заявку в AmoCRM по всем этапам, проверить, чтобы на всех этапах всё ушло корректно с нужными показателями и параметрами.
2. Заявка через звонок из Callibri. Заявка должна отобразиться в аналитике с нужным рекламным источником. После того, как цель отобразилась, прогнать тестовую заявку в AmoCRM по всем этапам.
   
3. Заявка через чат Venyoo. Заявка должна отобразиться в аналитике с нужным рекламным источником. После того, как цель отобразилась, прогнать тестовую заявку в AmoCRM.
   
4. Отправка заявки через формы на лендингах. Заявка должна отобразиться в аналитике с нужным рекламным источником. После того, как цель отобразилась, прогнать тестовую заявку в AmoCRM по всем этапам.
   

В качестве онлайн-консультанта на сайте клиента использовался сервис Venyoo, он был интегрирован с amoCRM через тот же «Интроверт». Но заявки из онлайн-чата не передавались в наш отчёт Google Analytics автоматически — нужно было настроить импорт cookie Гугла. Начали разбираться с настройкой и тут выясняется, что на платформа в принципе не импортирует cookie в другие сервисы.

Мы люди боевые: когда нам не хватает какого-то функционала в сервисе, мы активно сигнализируем владельцам платформ, что для комфортной работы спецам нужна ВОТ ТАКАЯ ШТУКА.

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

Здесь решили поступить также и написали личному менеджеру клиента в Venyoo. Но, к сожалению, в этот раз нам навстречу не пошли (а в итоге вообще заигнорили):

Клиент был не готов поменять онлайн-чат. Да и мы, посмотрев на результаты внедрения тоже не стали это советовать. Формы Venyoo давали хорошую конверсию — а кто в здравом уме захочет терять покупателей? На тот момент мы могли предложить один рабочий вариант: интегрировать данные из Venyoo через Roistat. Но тогда пришлось бы подключать к отчёту восьмой сервис (!), а это могло усложнить интеграцию и привести к ошибкам в данных.

Мы настроили частичную передачу заявок из онлайн-чата. На протяжении всего проекта писали в техподдержку Venyoo, пытаясь найти способ передать все данные из сервиса в аналитику (честно: так и не нашли). Параллельно настраивали email- и коллтрекинг, чтобы не задерживать работу.

Спойлер: всё равно проект нереально затянулся.

Мы хотели подключить и email- и коллтрекинг на базе Callibri. И сразу обнаружилось, что «есть один нюанс», о котором нужно предупредить клиента:

1. Сервис выделял клиентам городские номера в любом регионе, но выбрать сам номер было нельзя — радуйтесь тому, что дадут.
2. При подключении email-трекинга на сайте размещались адреса вида [email protected], где ХХХХ — номер клиента в сервисе email-трекинга, YYYYYY — уникальный ID сессии пользователя, dr-mail.com - сервисный почтовый домен. То есть адрес почты выглядел так: [email protected]. Естественно, такой адрес мог снизить количество отправленных на почту заявок.
   

С телефоном не было проблемы, а вот email вида [email protected], как можно догадаться, не устроил клиента. Мы уже говорили, что любим предлагать улучшения сервисов нашим коллегам. Поэтому в поисках альтернативного решения, мы дошли до директора Callibri, чтобы узнать, получится ли подключить email-трекинг как-то иначе. И, о чудо! Оказалось, что сервис как раз начал внедрять отслеживание по предоставленным клиентами адресам.

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

Мы выбрали ящики с адресом вида sales+1@домен-клиента.com, sales+2@домен-клиента.com и т. д. и приступили к подключению отслеживания звонков и писем.

Клиент хотел подключить отслеживание на свой корпоративный номер, который обслуживался сервисом IP-телефонии «Телфин». Callibri позволял подключить к коллтрекингу свой номер, но фича срабатывала не в 100% случаев. На тот момент в нашей практике было 5 случаев подключение к коллтрекингу внешнего клиентского номера, из них успешных — 3 штуки.

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

К номеру завода был привязан не только «Телфин», но и АТС onlinePBX.ru. Причём АТС перестала бы работать, если бы мы подключили к номеру коллтрекинг. Рабочая связка Телфин+OnlinePBX+«Интроверт» была интегрирована с CRM. Нужно было добавить в связку ещё и трекинг от Calibri, ничего не сломав при этом.

Мы предложили два варианта решения проблемы:

1. Вывести номер из «Телфина» и переключить его на Callibri. При этом под угрозу попадала связка Телфин+OnlinePBX+«Интроверт». Мы могли настроить новую связку Callibri+OnlinePBX+«Интроверт», но предупредили клиента, что подобного опыта у нас не было, а значит мы не сможем дать точный прогноз по срокам настройки.
2. Не нарушая текущую связку, просто подключить номер Callibri и настроить с него переадресацию на АТС. При этом немного вырастала абонентская плата, зато в будущем клиенту было бы проще добавить номера для отслеживания отдельных рекламных каналов.
   

Второй вариант понравился нашему оптимистичному клиенту больше (слава всем святым!) Мы настроили переадресацию, и связка всех наших сервисов успешно заработала: номер покупателей отображались, звонки записывались, UTM-метки Яндекс Директа не терялись.

Мы ещё не знали, сколько проблем ждёт впереди, поэтому эта маленькая победа нас очень порадовала (и добавила оптимизма).

Одновременно с настройкой коллтрекинга мы занимались и email-трекингом. Так как отслеживанием писем по адресам клиентов был новинкой Callibri, подключать сервис приходилось ручками. Из-за этого сроки заметно так выросли: с 5 рабочих дней до 2 недель.

Увеличение сроков клиента устраивало — главное, чтобы всё работало. Но увы, работало не всё.

Когда письмо падало на почту, в «Интроверте» автоматически создавалась задача на обработку сделки. Далее задача попадала в CRM, где с ней работали менеджеры. После подключения email-трекинга в «Интроверте» и CRM перестала формироваться задача. При этом в почте входящие письма доходили до адресата.

Окей, функция новая, ошибки были ожидаемы. Разбираемся, где проблема.

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

Техподдержка предложила для корректного отображения писем настроить передачу данных из Callibri в «Интроверт» через API. Так мы не нарушили бы связку «Письмо → «Интроверт» → amoCRM → менеджер», но для реализации такого функционала нашему программисту нужно было написать скрипт.

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

Когда технические работы были завершены, мы решили оттестировать отслеживание звонков и email-трекинг поочередно — отлаживать процессы лучше так.

С коллтрекингом сразу возникла проблема. Для правильной передачи данных мы сделали скрипт, который добавлял данные из звонков в amoCRM — в теории всё работало. Но в amoCRM информация не обновлялась. Вопрос передали в техподдержку CRM и специалисты сервиса начали искать ошибку на своей стороне.

Техподдержка занималась нашей задачей около 2 недель. Оказалось, что amoCRM неправильно воспринимает данные о GoogleID пользователя, поэтому сделки создавались с ошибкой. Мы переделали способ передачи GoogleID вместе со специалистами amoCRM.

Нам удалось настроить передачу звонков без ошибок, но, к сожалению, на решение вопросов со сторонними сервисами ушло много времени — больше 2 месяцев. Изначально мы планировали потратить на настройку и тестирование 12 дней. Суперкласс, не правда ли?

Окей, переходим к проверке email-трекинга. Настраиваем пересылку на тестовую почту и обнаруживаем, что письма не доходят, задача в CRM не формируется (да сколько можно-то?!)

Мы написали в техподдержку Яндекс Почты — оказалось, что Яндекс воспринял нашу активность как «подозрительную» и заблокировал переадресацию. Мы поклялись, что спамом не балуемся, и с ящиков сняли ограничения. Попросили клиента заполнить Яндекс Паспорт на корпоративном аккаунте, чтобы в будущем профиль не выглядел мошенническим.

На тестовой почте email-трекинг заработал корректно, переходим к нашим боевым почтам. Так как для отслеживания клиентов использовалось несколько ящиков, все письма с них нужно было переадресовать на основной ящик, привязанный к amoCRM. Настроили пересылку и… у клиента отвалилась почта! Письма перестали отправляться в принципе.

Снова атакуем техподдержку Яндекса, и получаем такой ответ:

«Почтовый сервер получателя при приёме писем проверяет SPF-запись на домене отправителя, чтобы убедиться, какие серверы имеют право отправлять письма от имени домена. На данный момент SPF-запись на домене @завод-металлоизделий.com не настроена».

SPF — по сути список доверенных доменов, с которых может отправляться почта. Так как SPF-запись не была настроена, письма клиента автоматически считались недоверенными и отмечались как спам. Проблема небольшая (наш программист сразу настроил SPF), но столкнуться с ней после всех предыдущих косяков было… скажем так — неприятно.

Окей, Callibri закончили настройку email-трекинга на своей стороне, мы — на своей. Осталось только финальное тестирование!

Итог проверки: НАКОНЕЦ-ТО! Тестовые письма дошли, задачи в CRM появились и распределились на менеджеров. Открываем шампанское, празднуем, пишем кейс, хвастаемся… или нет?

Колл- и email-трекинг настроены, сделки по входящим заявкам отображаются в CRM, данные передаются в отчёт Гугла. ВСЁ ГОТОВО! УРА!

Мы сдали (как мы думали) проект клиенту, дали инструкции к отчётам, предложили попользоваться ими и задать нам вопросы, если они появятся. Клиент кивнул и перестал выходить на связь. Мы несколько раз попушили его, но не получив результата успокоились. «Видимо разобрался со всем сам», — подумали мы.

8 месяцев вместо 12 дней. Не особо впечатляющая скорость. Но мы были горды тем, что СМОГЛИ!

Мы завершили работы в январе 2018 года, в мае (да почти в июне, если честно) клиент написал нам вновь.

Он обнаружил в отчётах Google Analytics множество заявок с неопределённым источником (none). Созваниваемся, начинаем разбираться.

Сразу было несколько предположений, почему система не определяет источники, из которых пришли покупатели:

• В none падают пользователи с блокировщиками рекламы — приложение конфликтует с системами отслеживания клиентов. Для проверки гипотезы нужен был доступ к Яндекс Метрике, но она подсчитывала пользователей с блокировщиками некорректно.
• В none падают люди, которые сначала переходят по рекламе, потом оставляют вкладку с сайтом открытой и отправляют заявку через несколько часов или на следующий день, когда сессия с рекламным источником уже закрыта. Эту версию подтверждал отчёт по ассоциированным конверсиям. Большое количество none в этом случае говорит о том, что люди долго принимают решение об отправке заявки: не с первых минут, а с первых часов или даже дней.
  
• В none попадает часть заявок с Venyoo — неудивительно, передачу данных из онлайн-чата так и не получилось до конца настроить. Написали в техподдержку сервиса ещё раз, вдруг функция передачи cookie таки появилась, но нет, саппорт так и продолжал нас игнорить.
  

Клиент указал на конкретную рекламную кампанию, по которой заявки передавались в отчёт с неопределённым источником. Мы прошлись по ней вдоль и поперёк, с нашей стороны ошибок не было: данные отправлялись корректно, значит метки источников либо отметали блокировщики рекламы, либо сам сайт завода. Мы отписались клиенту, и… он снова пропал. На 3 года.

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

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

Стоит, наверное, сказать и о деньгах. Всю эту работу мы на старте оценили (только не смейтесь) в 34 000 рублей. Столько и получили. А потом половину вернули. Итого, мы проработали с проектом 8 месяцев (без учета первой пропажи на полгода), получили 17 000 рублей. Получается 2125 рублей в месяц. «Вери гуд бизнес». Не делайте так.

Негативный опыт — тоже опыт. И полученные в таком длинном и сложном проекте выводы особенно ценны. И лучше всего откладываются в памяти.

Чтобы вам не пришлось проходить через все круги ада, как нам, делимся несколькими советами:

• Сквозная аналитика — это 6–9 месяцев работ (а не 12 дней, как думали мы). Причём 95% работ — это сбор данных и тестирование.
• Для правильной работы сквозной аналитики требуется постоянная техподдержка и доработка отчётов — настроенные на старте отчеты не будут актуальны вечно. Вы связываете вместе кучу сервисов, которые со временем развиваются и меняются, добавляют в функционал новые фичи. За этим нужно следить и обновлять интеграции.
  
• Важно договариваться о составе внезапных работ на берегу. Мы взяли на себя море задач, непредусмотренных заранее, например, писали скрипты для интеграции, чинили почтовые настройки. Команда не скажет вам «спасибо» за дополнительную бесполезную нагрузку.
  
• Документы нужно вовремя подписывать и обмениваться ими с клиентами, чтобы спустя 4 года не пришлось возвращать деньги за готовый проект. Очень банально, но напомнить ещё раз не будет лишним =)