Частые вопросыо трекинге и данных

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

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

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

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

sGTM — это серверный Google Tag Manager, инструмент Google для настройки обработки и передачи данных на сервере. Он принимает события с сайта, приложения или других систем и по заданным правилам отправляет их в аналитику и рекламные кабинеты. Например, получает сведения о покупке и передает в нужные сервисы номер заказа и сумму. Серверный трекинг — это подход к передаче данных, а sGTM — один из инструментов для его реализации.

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

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

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

Потому что сервисы могут считать разные действия, по-разному связывать их с рекламой и получать не все данные. Представьте: в рекламном кабинете — 30 заявок, в аналитике — 25, а в CRM, системе учета клиентов, — 20. Где правильная цифра? Сначала нужно разобраться, что каждый сервис считает заявкой: отправку формы, созданное обращение или только заявку, которую он связал с рекламой. Затем проверить период отчета, задержки передачи, пропуски и повторы. Для этого сравнивают конкретные заявки: где каждая появилась и до какого сервиса дошла.

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

Пройти путь клиента и проверить, что произошло с данными на каждом шаге. Отправили тестовую заявку — появилась ли она в CRM? Дошла ли до аналитики и рекламного кабинета? Один раз или два? Для покупки дополнительно проверяют номер заказа, сумму, валюту и статус оплаты, а если настроен учет возвратов — и возврат. Затем сверяют реальные заявки и заказы за один период.

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

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

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

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

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

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

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

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

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

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

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

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

Если заказ отменили или товар вернули, первоначальная сумма покупки уже не отражает результат для бизнеса. Например, реклама привела заказ на 10 000 рублей, но клиент вернул товары на 5 000 рублей: фактическая выручка — 5 000. В аналитике нужно учесть возврат, а в рекламном кабинете — скорректировать покупку, если он поддерживает такие изменения. При оптимизации по ценности это позволяет учитывать скорректированную сумму вместо первоначальной.

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

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

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

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

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

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

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

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

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

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

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

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