Как сверить конверсии в аналитике с данными CRM

Как сверить конверсии в веб-аналитике с данными CRM

Веб-аналитика и CRM учитывают разные события. Аналитика может фиксировать отправку формы, а CRM — создавать лид только после проверки, удаления дублей или успешной передачи данных. Расхождение между итоговыми числами не всегда означает, что отслеживание работает неправильно. Но оно говорит о том, что нужен единый способ сравнения данных.

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

1. Определите, какие конверсию и лид вы сверяете

Выберите одну конверсию в аналитике и соответствующий ей результат в CRM. Например, сопоставьте событие на сайте demo_request_submit с новыми лидами в CRM, созданными по запросам на демонстрацию. Не объединяйте это событие с подписками на рассылку или звонками: это разные действия клиентов, которые могут обрабатываться по-разному.

Зафиксируйте, что именно считается результатом в каждой системе. Конверсией в аналитике может считаться успешная отправка формы — событие, которое срабатывает после подтверждения получения данных сервером. Лидом в CRM может считаться новая запись с действительным адресом электронной почты, а не обновленный контакт, уже существовавший в системе. От этого различия зависит, что покажет сравнение.

Укажите отчетный период и статусы, которые нужно учитывать. Если вы анализируете первую неделю месяца, задайте точные время начала и окончания, а также решите, включать ли открытые, квалифицированные, дисквалифицированные и удаленные лиды. Ограничьте задачу так, чтобы результат можно было объяснить. Формулировка «все конверсии и все действия в CRM» обычно слишком расплывчата для диагностики.

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

2. Задайте правила сравнения до выгрузки данных

Сначала договоритесь о часовом поясе. Аналитика и CRM могут хранить временные метки в разных часовых поясах или отображать их согласно разным настройкам аккаунта. Приведите оба набора данных к одному часовому поясу — например, UTC — прежде чем сравнивать дневные итоги. Иначе отправка формы незадолго до полуночи может попасть в разные даты.

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

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

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

3. Сравните конверсии в аналитике с лидами в CRM

Чтобы сравнить конверсии в аналитике с лидами в CRM, создайте строку для каждой конверсии за выбранный период и найдите соответствующую запись в CRM. Если обе системы сохраняют общий ID отправки или события, это самый надежный способ сопоставления. Передавайте этот идентификатор через форму и записывайте его в поле CRM, чтобы можно было проверить совпадение позже. Такой подход помогает понять, как сопоставить лиды CRM с конверсиями, не полагаясь только на приблизительное совпадение времени.

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

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

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

4. Найдите причину расхождения данных веб-аналитики и CRM

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

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

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

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

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

• Удаление дублей: CRM может обновить существующий контакт вместо создания нового лида. Найдите идентификатор среди существующих записей и проверьте, зарегистрировала ли система обновление или объединение записей.

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

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

5. Учтите дубли, задержки и изменения статуса

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

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

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

Для каждого исключения указывайте краткую причину, например: «дубль объединен», «создан на следующий день» или «отклонен из-за обязательного поля». Так результаты сверки будут полезны команде, которой предстоит действовать дальше. Если в ходе проверки возникнут вопросы о конфиденциальности или доступе, обратитесь к утвержденным в вашей организации рекомендациям по безопасности сайтов и работе с данными.

6. Исправьте расхождения, не переписывая историю

Устраняйте источник проблемы, когда у вас появятся подтверждающие данные. Если тег срабатывает до успешного ответа, измените условие запуска и проверьте подтвержденную отправку. Если CRM отклоняет корректное значение из формы, исправьте сопоставление полей или правило проверки в соответствии с обычным процессом внесения изменений. Исправление должно устранять подтвержденный сбой, а не просто выравнивать итоги.

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

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

7. Регулярно проверяйте результаты сверки

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

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

Согласуйте с ответственными за аналитику и CRM допустимый порог расхождения для эскалации. Он должен учитывать обычные колебания в работе системы, поэтому определите его заранее, прежде чем использовать в оповещениях. Если расхождение превышает установленный порог, сообщите ответственным за какой период и какую форму идет речь, сколько записей не удалось сопоставить и какие проверки уже выполнены. Конкретное оповещение помогает действовать; фраза «цифры выглядят неправильно» — нет.