Как ошибки портят аналитику: примеры из практики
Оценить влияние ошибок HR-аналитики проще всего на реальных примерах. Рассмотрим самые распространенные кейсы.
Некорректные данные поля “Источник”
Представим, что в CRM-системе не настроена автоматическая передача источника отклика. Обрабатывая поступивший лид, рекрутер должен заполнить это поле вручную. Но в ходе собеседования он забывает задать этот вопрос соискателю и ставит случайный ответ. В результате лид, который на самом деле пришел из контекстной рекламы Яндекса, помечен как лид из job-борда, и это фиксируется в аналитике. Такие ошибки копятся, мы получаем совершенно необъективную картину, и вся стратегия, которая на нее опирается, заведомо провальна.
Ошибка CRM при определении “Источника отклика”
Представим, что человек увидел рекламу вакансии в социальной сети ВКонтакте, кликнул по ней, перешел на сайт компании и оставил заявку. По идее, в системе учета данных (CRM) должно отобразиться, что заявка пришла с рекламы в ВКонтакте. Но иногда в этих системах есть ошибка: все заявки с сайта записываются как пришедшие просто с сайта, без уточнения, что человек пришел из рекламы. Из-за этого кажется, что реклама не работает, потому что в отчетах по рекламе нет заявок. В результате компания может решить, что реклама неэффективна и перестать в нее инвестировать, хотя на самом деле она могла привести много кандидатов.
Ручная дедупликация
Еще один пример ошибки определения источника. Сегодня утром пришел лид от Васи Пупкина из рекламы Яндекса. Завтра Вася откликнулся еще раз, но уже с сайта работодателя. Еще через неделю — из таргетированной рекламы ВК. Вася очень хотел работать и в конце концов вышел на должность курьера, мы за него рады. Но перед нами встает сложность: к какому источнику отнести в заслуги его трудоустройство?
Для этого придумана система дедупликации, которая должна склеить отклики Васи в одну карточку (или, как часто называют, “сделку”) и определить, что он трудоустроился из источника под номером 1.
Если дедупликация настроена правильно, то она учитывает этапы сделки, на которых находился Вася в момент каждого отклика. Например, первый раз до Васи не дозвонились — это так называемый “закрытый” этап воронки. Такой источник будет заменен другим, соответствующим второму отклику с открытым этапом — например, “Приглашен на собеседование”. Когда сделка перешла на открытый этап, третий поступивший лид уже не сможет перетереть источник, потому что по Васе уже ведется активная работа по трудоустройству. Лид нужно засчитать тому источнику, на котором процесс пошел.
Это идеальный сценарий. Но зачастую склейка дублей происходит руками непосредственно в CRM или даже в Excel, если не настроена интеграция данных из разных источников. Такая склейка устроена по упрощенному принципу: какой лид последний, тот источник и засчитаем. Либо наоборот — чей первый, тому и запишем.
При ручной дедупликации практически невозможно выставить источник согласно активной / неактивной стадии сделки. Это отнимет слишком много времени у рекрутера, а иногда он вовсе не видит разные отклики по одному номеру. Такое решение в корне неверно — оно ведет к искажению картины конверсий по источникам и принятию неверных решений для бизнеса.
Чтобы строить объективную аналитику, нам нужно учитывать все источники для каждого касания — и при этом правильно засчитывать лид с учетом закрытого / открытого этапа. Важно продумать и настроить систему приоритизации, которая позволит оценивать вклад каждого источника.
Дополнительная сложность состоит в том, что такую задачу трудно решить без экспертизы и насмотренности в MarHR.