Q&A 9 октября 

📎 Запись эфира

• Леонтий Васьковский — менеджер продукта Яндекс Метрика
• Андрей Дёмин — эксперт по обучению Яндекс Рекламы

Андрей Дёмин: Традиционно расскажу, чем мы тут занимаемся. Каждую среду в 12:00 по московскому времени мы проводим Q&A-сессии, на которых мы разбираем ваши вопросы, которые вы накидываете нам под анонсом в телеграм-канале.

Наши Q&A-сессии делятся на два типа. Есть Q&A-сессии без какой-либо конкретной темы. Кажется, на прошлой неделе как раз была именно такая, когда вы просто приносите любые вопросы, и мы пытаемся дать на них ответ. Но бывают Q&A-сессии тематические, когда мы, во-первых, зовём в гости эксперта по какой-то определённой теме, во-вторых, отдаём приоритет вопросам, которые связаны с этой темой, потому что наш гость может подробнее раскрыть эту самую тему через серию ответов на ваши вопросы.

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

Сегодня Q&A-сессия также будет немножко отличаться тем, что мы хотели бы поговорить о различных новинках, которые связаны с передачей офлайн-конверсий, и у нас будет немножко теоретического материала, после чего мы перейдём к разбору ваших вопросов.

Лео, расскажи, наверное, в целом про офлайн-конверсии.

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

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

На самом деле нет. Принцип работы офлайн-конверсий позволяет охватить кейсы намного шире, чем этот. Самый банальный пример: у вас на сайте есть форма, которую заполняют пользователи. Заполнение формы без проблем трекается счётчиком Метрики. Здесь всё хорошо. Форма заполнена, вы увидите эту конверсию, здесь всё окей. А вот что дальше происходит с этой формой, с теми данными, которые вы получили из этой формы — про это Метрика ничего не знает. Это уже лежит вне счётчика Метрики. И тот момент, когда вы в своей CRM, получив данные из формы, передвигаете заявку дальше, например ставите статус хорошего лида, плохого лида и так далее, или даже вне CRM просто берёте и обзваниваете после заполнения формы пользователей, которые оставили контакты, тот момент, когда вы уже понимаете, хороший это лид или нет — это опять лежит вне счётчика Метрики.

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

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

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

Давайте посмотрим про то, что мы в итоге сделали для офлайн-конверсий. Потом будем разбирать вопросы.

Большое обновление офлайн-конверсий

Обработка данных становится быстрее

У нас произошло большое обновление офлайн-конверсий. Что хорошего мы сделали? Во-первых, мы решили большую боль юзеров, и не только юзеров, но и сервисов, которые присылали в нас офлайн-конверсии — мы ускорили обработку данных. Она стала значительно быстрее. С 24 часов... но по факту в последнее время было даже больше, потому что очень большой поток данных в Метрику, который постоянно увеличивается. Старый конвейер не мог его нормально обработать. У нас была очень долгая работа по переписыванию большого количества кода, но самое главное, что произошло — у нас значительно ускорилась обработка данных: с 24 часов до одного часа, в среднем. Это актуально для всех наших форматов отправки данных: и для офлайн-конверсий, и для CRM-данных, и для звонков. Всё это теперь привязывается к визитам намного быстрее. В среднем это действительно плюс-минус час.

Ещё у нас есть Центр конверсий. В Центре конверсий есть один момент, который не позволит так быстро привязывать данные, как нам бы хотелось. В Центре конверсий данные забираются у вас раз в день, и этот раз в день как раз таки не позволяет использовать преимущество привязки одного часа. То есть у вас раз в день всё привяжется за один час, но всё равно для Центра конверсий это остаётся раз в день. Я думаю, что в ближайшее время коллеги смогут что-то с этим сделать, чтобы данные Центра конверсий отправлялись в Метрику не один раз в день, а чаще, в зависимости, например, от изменения данных в файле, которые у вас есть в Центре конверсий.

Загружать исторические данные проще

Загружать исторические данные стало проще. Как было раньше для форматов всех офлайн-данных? Нужно было включать опцию учёта офлайн-конверсий. Это опция, которую вы включали в настройках счётчика Метрики, либо когда первый раз отправляли данные. С того момента, как вы её включили, Метрика запоминала все визиты, то есть делала их доступными для изменения, дополнения какими-то офлайн-конверсиями и постепенно увеличила этот период до 21 дня. То есть сначала я включил эту опцию, у меня там доступны визиты за один час, за два, за три, потом за день, за неделю. В конце концов этот период доходил до 21 дня, и в тот момент я мог загрузить все визиты в периоде 21 дня. То есть самые старые данные постепенно удалялись — за 22-й день, за 23-й. Не данные, которые вы отправляли, а визиты, которые доступны для изменения с помощью офлайн-конверсий.

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

Собственно, вот что изменилось. Мы включили учёт офлайн-конверсий 21 день от визита. Конверсии привязываются к визитам и отображаются в Метрике. В любой момент для всех визитов можно привязать конверсии в окне 21 дня.

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

Кастомные цели теперь и в CRM-форматах

Кастомные цели теперь и в CRM-форматах. У нас есть формат загрузки данных из CRM. Там в качестве основной единицы привязки используется заказ. Заказ — это какие-то данные, которые вы отправляете. Заказ обычно равен вашей сделке в CRM. Естественно, у заказа могут быть какие-то статусы. Раньше у нас существовало четыре основных статуса заказа. Это «Заказ оплачен», «Заказ в работе», «Заказ отменён» и «Спам».

Всё бы хорошо, но ни один бизнес не укладывается в две цели, которые выполнялись у нас на этих статусах. Для «Заказ отменён» и «Спам» у нас не было выполнения цели. Были цели «Заказ в CRM», «Заказ оплачен» и «CRM: Заказ в работе», In Progress. На этих статусах выполнялась CRM-ная цель «Заказ оплачен» и «Заказ в работе».

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

Что это значит? Кроме Paid и In Progress, этих вот двух целей, которые использовались раньше, вы теперь можете использовать в качестве статуса идентификатор вашей цели, и у вас в этом заказе выполнится цель. То есть вы банально можете под каждый статус вашей CRM создать свою джаваскриптовую цель и отправлять эти идентификаторы джаваскриптовых целей в качестве статуса заказа. Пожалуйста, у вас сразу же расширяется ваша воронка. Не просто заказ создан и оплачен, как было раньше, а абсолютно любые статусы. Сколько у вас в CRM статусов есть, столько вы можете сделать джаваскриптовых целей и отправлять их в нас. Опять же, это расширяет возможности анализа того, что у вас происходит, возможность построения какой-то воронки продаж. Всё это здесь. По сути, мы объединили CRM-формат и наши основные офлайн-конверсии.

Новые возможности формата офлайн-конверсий

Что ещё произошло? Что мы добавили в офлайн-конверсиях? Раньше у нас была возможность загружать офлайн-конверсии через три идентификатора: ClientID, UserID и Yclid. ClientID — это ID посетителя в Метрике. UserID — это кастомный ID клиента, который вы можете задать во время его визита, например, на сайте. Например, при залогине у вас есть какие-то свои ID. Вы можете их отправить, и это будет UsedID, прямо номера ваших клиентов. И Yclid — это ID клика Директа, тоже можно было отправить и привязать какую-то офлайн-конверсию.

Мы добавили PurchaseID. Это ID заказа в электронной коммерции. Это новый идентификатор для офлайн-конверсий. Чем он крут, чем он хорош? Если у вас уже настроен еком, для того чтобы отправить какую-то дополнительную цель, вы можете использовать идентификатор заказа в электронной коммерции, который у вас уже есть. Вам не надо вместе с заказом добавлять в него ClientID или UserID или Yclid. Мы без проблем привяжем к визиту, в котором была какая-то покупка, электронная коммерция, конверсию из офлайн-формата. Это, например, упростит возможность отправки в нас конверсий. Например, если у вас еком-покупки вызываются до того, как пользователь перешёл на страницу эквайринга, или у него изменилась сумма заказа, вы без проблем можете отправить какую-то кастомную джаваскрипт-цель, которая уже будет, к примеру, скорректирована с доходом. Если у вас что-то поменялось в этой покупке, вы можете скорректировать этот доход и отправлять по PurchaseID конверсию со скорректированным доходом.

Тоже неплохая новинка. Теперь не нужно указывать какой-то формат файла, вы можете одновременно отправлять сразу четыре айдишника, этих вот новых ClientID, UserID, Yclid и PurchaseID. Хоть на одну конверсию сразу указать четыре ID. Это повышает вероятность того, что мы корректно привяжем его к визиту, который вас интересует, то есть больше ID — больше шанс того, что мы корректно привяжем к визиту. Если рассматривать, какой ID будет использоваться для привязки, всегда будет использоваться тот ID, в котором время визита ближе всего к времени вашей конверсии, которую вы отправляете.

Коннектор к amoCRM

Ещё из новинок. У нас вышел коннектор к amoCRM. Помните, я рассказал про то, что у нас кастомные цели в CRM-форматах? В коннекторе к amoCRM мы дали возможность указывать ваши джаваскриптовые цели в качестве связки статусов с этой джаваскриптовой целью. Вы можете создать какие-нибудь цели, равные вашим статусам в amoCRM, и связать с ними эти статусы. И на каждом статусе, когда у вас, например, происходит сделка, в amoCRM она переходит в нужный статус, на который вы замапили цель Яндекс Метрики. Эта цель будет выполняться. Настройка происходит из интерфейса Метрики. Окно атрибуции, опять же, — 21 день, окно на обновление информации — 21 плюс 90. Скорость такая же высокая.

Всё, в общем, очень круто. Принимаем идентификаторы ClientID, телефоны, имейлы. Пожалуйста, используйте. Я думаю, что мы этим коннектором значительно упростили подключение amoCRM к Метрике. Надеюсь, что вам понравится.

Вопросы

Андрей Дёмин: Давай буду в первую очередь зачитывать вопросы, которые пришли по теме сегодняшней встречи.

Леонтий Васьковский: Статистика отличается от данных CRM — это, наверное, про как раз таки про формат клиентов и заказов из CRM. Это значит, что для атрибутирования используются либо ClientID Метрики, либо имейлы и телефоны, которые есть у вас в CRM. Мой совет — всё-таки по максимуму использовать ClientID. Почему? Потому что в нём возможность атрибутирования к визиту… [помехи]

Андрей Дёмин: Пока коллега подключается, я попробую ответить на следующий вопрос, а потом вернёмся к этому.

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

И, пожалуй, вторая особенность, но она, наверное, больше связана не конкретно с этим вопросом, не с отсутствием исторической статистики, а скорее с моделью оплаты за конверсии. Есть кейс, о котором я регулярно всем напоминаю и про который вам тоже важно знать. Когда вы используете модель оплаты за конверсии в настройках рекламных кампаний, будьте внимательны, какие именно офлайн-конверсии вы передаёте, потому что я лично знаю историю, когда рекламодатель долго фильтровал офлайн-конверсии, передавал только нужные, а потом в какой-то момент забыл отфильтровать, и у него в том файлике, в котором содержались офлайн-конверсии, было вообще всё: и целевые заявки, и нецелевые. Он всё это грузанул, и у него в рамках окна в 21 день произошло списание задним числом за все строчки, какие у него там были. Практически весь месячный бюджет был сожжён, потому что, очевидно, нецелевых заявок там было намного больше, чем целевых, ну и оплата за конверсии привела к подобной ситуации. Поэтому будьте осторожны, когда работаете одновременно и с оплатой за конверсии, и при этом передаёте офлайн-конверсии в ту кампанию, где у вас используется эта модель оплаты.

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

Леонтий Васьковский: Да, давай. Извините, плохой интернет. Что касается атрибуции данных из CRM, как получить максимальный процент атрибуции? Использовать ClientID. Когда у вас происходят какие-то заявки на нашем сайте, желательно вместе с формой скрытым полем отправлять в Метрику ClientiD. Если к вашей CRM-системе подключен кол-трекинг, убедитесь, что отдельным полем при создании заявки по звонку кол-трекинг передаёт ClientID. Если у вас там какие-то виджеты типа JivoSite, к примеру, которые тоже могут инициализировать создание заявки в вашей CRM-системе, убедитесь, что эти виджеты передают ClientID Метрике. То есть задача максимальной атрибуции — связать ваши данные с метричными визитами, а метричные визиты — это чаще всего ClientID. В первую очередь ClientID. Отправка данных только по имейлам и телефонам сработает хуже за счёт того, что Метрика не знает про все имейлы и телефоны. Какой-то конкретный визит мы с какой-то долей вероятности узнаем, что это именно этот имейл или номер телефона. Если мы говорим про то, что нам нужно повысить процент атрибуции, — пожалуйста, ClientID.

Если у вас сайт на Tilda, у них есть нативная интеграция с amoCRM и Битриксом и они отдельным полем передают ClientID Метрике. Если у вас какой-нибудь сайт на 1С Битриксе, есть достаточно много гайдов, которые рассказывают, как добавить в форму Битрикса ClientID. Самое главное — обеспечить появление поля ClientID в вашей CRM-системе, что касается именно CRM-формата.

Андрей Дёмин: Ты как раз уже подсветил эту тему. Может, сможешь привести какие-то примеры наиболее запрашиваемых целей со стороны рекламодателей, пока не было этих кастомных целей? Как вообще можно использовать какие-то конкретные примеры? Какие ещё статусы можно передать?

Леонтий Васьковский: К примеру, раньше пользователи — по крайней мере, из тех запросов, которые я видел — складывали все покупки в одну цель «Заказ оплачен» и как раз хотели бы видеть разницу по разным категориям того, что пользователи у них покупают и какие услуги заказывают. Если мы берём какой-нибудь медцентр, у них есть куча услуг: и анализы, и какие-нибудь операции. На тот момент не существовало этой возможности, но если сейчас об этом говорить, на каждый статус, на каждый заказ в CRM, я могу отправить свою джаваскриптовую цель, и у меня, к примеру, будут банально две цели: «Оплаченные анализы» и «Оплаченные операции». Пожалуйста, я уже могу сегментироваться по этим двум целям, смотреть разные воронки продаж и анализировать, кто у меня чаще что заказывает.

Леонтий Васьковский: Интересный вопрос. Наверное, специалист по рекламе должен выделить в бизнесе клиента именно те статусы или целевые действия, которые приносили бы пользователю максимальный профит. О чём я говорю? Если, например, у него на сайте происходит только заполнение каких-то форм, а в итоге продажа состоится только после того, как клиент свяжется, они заключат договор, потом, может, договор заключается на разное время... Короче, целевое, наверное, — всё-таки увидеть деньги. Специалист по рекламе всё-таки должен выбрать в бизнес-модели тот момент, когда его клиент получает деньги, определить финальный этап продажи, на который оптимизировать рекламу. И опять же, определить, хватает ли данных по реальным продажам для того, чтобы оптимизироваться. Может, оптимизироваться лучше стоит на шаг ниже — например, на хорошие лиды. Если какой-то пользователь проводит классификацию на плохие-хорошие, спам-заявки и заявки, которые в итоге могут переродиться в реальную продажу, в зависимости от их количества специалист по рекламе определяет саму цель оптимизации.

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

Андрей Дёмин: Смотри, допустим, мы говорим про карту компетенций, и нам нужно понять, какими конкретно компетенциями должен обладать каждый участник этой цепочки. По сути, чтобы получить какие-то офлайн-конверсии в Метрике, понятное дело, что должна быть настроена реклама специалистом по рекламе, должен быть какой-то трафик и какие-то заявки, отправки формы. Но дальше, например, в дело вступают менеджеры по продажам. Они должны проставить на стороне CRM какие-то определённые статусы. Правильно? То есть это делают сотрудники рекламодателя. Вот они проставили какие-то статусы. Должен быть какой-то человек, который скажет: так, теперь мы забираем из CRM такие-то данные. Кто принимает решение на этом моменте? Окей, давай так: стратегически понятно. Это принимает решение специалист по рекламе, что мы хотим оптимизироваться по таким-то действиям, по таким-то статусам. Но кто может технически это реализовать? Как вообще можно описать того человека, кому нужно ставить ТЗ, и какое оно должно быть, чтобы мы, как специалисты по рекламе, в конечном счёте увидели те самые деньги, о которых ты говоришь? Увидели офлайн-конверсии, какую-то стату в Метрике. Вот здесь чуть-чуть поточнее, если можно, прорисовать зону ответственности каждого участника?

Леонтий Васьковский: Естественно, зона ответственности будет разниться от клиента к клиенту. Некоторые перекладывают эту обязанность на своих специалистов по контекстной рекламе. Говорят, что вот, пожалуйста, у тебя есть такая-то задача, настрой мне. Какими средствами это будет сделано — уже другой вопрос. Но если у пользователя, у клиента, существует возможность внутри что-то доразработать, то часть, которая как раз таки касается проброса каких-то наших метричных ID в CRM-систему, — это, как мне кажется, ложится на сторону разработки. Cам специалист по контекстной рекламе должен понимать, что оптимизироваться на офлайн-конверсии в принципе должно быть выгоднее как для него самого, — потому что KPI клиента выполняются, он реально видит какие-то продажи — так и для клиента, потому что, опять же, если мы говорим про оптимизацию, например, обычное заполнение форм — это не то, что сейчас хочет рынок, потому что не все формы хороши. Есть спам-заявки, есть ещё какие-то люди, которые в итоге ничего никогда не купят. Это видение того, что нужно использовать офлайн-конверсии, мне кажется, идёт на стороне специалиста. А реализация, как именно это сделать — 50 на 50, в зависимости от компетенции специалистов по контекстной рекламе, либо наличия у клиента возможности сделать какую-то доработку.

Андрей Дёмин: То есть ты бы рекомендовал специалистам всё-таки расширять свои компетенции, кругозор и в том числе немножечко уходить в сторону…

Леонтий Васьковский: Мне очень хотелось бы верить, что специалисты по контекстной рекламе в итоге обратят внимание на то, что нам нужно получать для пользователя какую-то корректную аналитику, более глубокую, чем то, что у них произошло на сайте, а именно продолжение воронки продаж, которая есть у пользователя. Я думаю, что со временем либо появится намного больше инструментов и готовых интеграций уже даже со стороны СMS-систем, как пример от Tilda, которая сделала проброс ClientID отдельным полем после заполнения форм, либо появятся какие-то готовые решения со стороны пользователей.

Андрей Дёмин: Как, например, с отказами, когда говорят, что если у вас больше 20% отказов и что-нибудь такое…

Леонтий Васьковский: Мне кажется, что нет. Это очень индивидуально. Объясню почему. Тот же самый формат данных из CRM. У нас есть провязка по ClientID, которая работает очень хорошо — 99%+, что вы провяжете. Но опять же, для того чтобы провязать, надо отправить корректное время визита. Пример из головы: если в вашей CRM-системе время плюс ноль, а в Метрике — плюс шесть часов, какой-нибудь, условно Екатеринбург, могут возникнуть проблемы. У вас время, которое будет браться из CRM, не будет соответствовать времени визита пользователя, потому что визит пользователя произошёл позже. Возникает коллизия из-за того, что разное время провязки, на которое мы смотрим. Опять же, в отправленных данных может быть разный контент. Имейлы и телефоны привязываем хуже, чем информацию по ClientID. Если у вас большинство данных идёт с имейлами и телефонами, мы привяжем эту инфу хуже, чем у пользователя, который отправляют нам только информацию с ClientID. Это всё очень сильно разнится.

Андрей Дёмин: И если таких причин несколько, то какие их них более распространённые?

Леонтий Васьковский: Во-первых, на странице заказа может не быть Метрики, что странно, но окей. Во-вторых, в каких-то случаях блокировщик рекламы может заблокировать Метрику, такое тоже возможно. Ещё ClientID может… Если вы используете метод Get ClientID, с ним всё должно быть окей. Если вы используете какие-то свои кастомные методы для того, чтобы забирать с кук этот наш параметр, ClientID Метрики, здесь тоже могут быть какие-то проблемы. Мы не знаем, как могут работать кастомные методы. Тоже достаточно много причин.

Андрей Дёмин: Ты как раз упомянул блокировщик рекламы. Следующий вопрос связан именно с ним.

Леонтий Васьковский: Если мы говорим про блокировщик рекламы, тогда, скорее всего, самого визита пользователя на сайт не будет, если этот блокировщик внезапно заблокировал Метрику. Опять же, оговорюсь, что блокировщиков, которые блокируют именно аналитические трекеры, не так много, это не такая большая часть, но вероятность блокировки Метрики существуют. В таком случае, наверное, если мы говорим про Директ, из всех параметров останется возможным для использования только Yclid, потому что Yclid будет в URL. Yclid как раз таки можно будет запомнить и использовать, но опять же, визита пользователя сейчас с этим Yclid нет. Я не могу спойлерить, но в ближайшее время у нас появится инструмент, который может решить в том числе этот кейс, когда, например, каким-то сторонним трекером, блокировщиком рекламы, была осуществлена блокировка Метрики. Можно будет это обойти, можно будет всё равно получить какие-то данные по визиту. Рекомендую, наверное, ждать анонса.

Андрей Дёмин: Но пока главная проблема здесь даже не в том, будут предаваться айдишники или нет, а в том, что не будет визита, к которому…

Леонтий Васьковский: Не будет визита, к которому привязать эту информацию. Например, сам Yclid будет, но визита не будет. Как я сказал, в ближайшее время у нас будет анонс. Думаю, многих он порадует.

Леонтий Васьковский: Это мы сейчас говорим про какие-то екомы, да? Самый, наверное, очевидный вариант — во время инициализации покупки, когда у вас в data layer идёт отправка покупки, вместе с информацией про вашу покупку запоминать метричный ClientID, как минимум. Или UserID, который вы также можете назначить после покупки. Если, например, у вас там покупка подразумевает какой-то обязательный залогин, вы же можете давать пользователям UserID и потом по этому UserID делать отправку данных. Или, опять же, мы добавили возможность использовать PurchaseID. Пожалуйста, если у вас там есть какие-то еком-покупки, которые нормально трекаются у вас на сайте, вы можете без проблем отправить по номерам этих покупок дополнительную цель. Если у вас номер заказа скорректировался, если он вообще не был в итоге выкуплен, но еком-покупка на сайте почему-то была, вы можете, к примеру, не отправлять эту цель и ориентироваться на неё в итоге как финальный этап аналитики.

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

Объясню, почему рекомендую. У нас и там и там 21 день на первичную провязку конверсий и заказов, но заказ я могу изменить в течение 90 дней. Если мой заказ меняется, у меня всего 111 дней для того, чтобы дополнить его какой-то информацией. Если у меня, например, длинный цикл сделки, а не просто покупка на сайте, которая сразу же была оформлена, если я продаю что-то крупное и это не укладывается в месяц, у меня нет другой альтернативы, — по крайней мере, сейчас — кроме как использовать данные из CRM. В этот заказ будут добавляться новые цели, и потом, смотря на аналитику, я могу применять это для того, чтобы видеть какую-то воронку продаж. Одно это уже должно способствовать тому, что я больше склоняюсь к рекомендации данных из CRM, особенно учитывая то, что эти заказы могут быть привязаны к клиентам, а у нас в Метрике есть возможность сегментации на тех, кто больше всего покупает, кто меньше покупает, из учёта каких-то корректировок. Короче, больше возможностей сегментации сейчас есть в данных из CRM.

Леонтий Васьковский: Данные из Метрики сейчас удалить невозможно. Всё единожды отправленное, если привязано, останется там. Сами офлайн-конверсии, как я рассказывал, в данных из CRM можно в качестве статуса отправить в джавасткриптовую цель. Вот, пожалуйста, по сути, использование офлайн-конверсий. Вы можете отправлять какие-то конверсии, которые будут привязаны к этому заказу, но только с тем преимуществом, что эти данные имеют срок изменения 111 дней, имеют дополнительные сегменты, имеют клиентов, на которых можно сегментироваться. В общем, много всего хорошего.

Андрей Дёмин: Ты сказал, что невозможно удалить сейчас. Нам стоит здесь чего-то ждать?

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

Андрей Дёмин: Сергей в чате скинул скриншот с добавлением цели.

Леонтий Васьковский: Регулярное выражение — нет. Для отправки и офлайн-конверсии, и данных о кастомных джаваскриптовых целях используются цели типа джаваскрипт-события, которые идут с оператором соответствие «Совпадает». То есть то, что совпадает, можно использовать. Я бы рекомендовал не использовать регулярку. Я бы рекомендовал, если есть какая-то задача выделить… Лучше всего выделять разные статусы заявок в разные цели.

Леонтий Васьковский: Как я рассказывал, если у вас есть какая-то цель, которая выполняется на старом теге, и этот звонок был нам передан, то мы запишем эту цель, и когда тег звонка поменяется, та записанная конверсия не уйдёт. То есть будет записана новая. Если, например, есть цель на какой-то новый тег, она будет добавлена в этот визит, но на данный момент нет такого, что мы отдельно для каких-то целей убираем их из визитов и меняем на какую-то новую цель, приходящую к нам. Стоит учитывать при изменении тегов: если у вас есть какие-то цели, эти цели не удалятся из ваших визитов. Если вы не хотите, чтобы ваша аналитика шумела, можно убрать какие-то промежуточные цели и оставить только финальные теги, на которые вы оптимизируетесь или учитываете их в аналитике.

Андрей Дёмин: Вопросы по сегодняшней теме встречи закончились. Я пока разберу прочие вопросы.

Андрей Дёмин: Во-первых, если проблема именно в размере стоимости клика, то здесь нужно посмотреть на то, какие настройки у вас используются в вашей стратегии, какую стоимость конверсии вы используете. Если у вас, допустим, конверсионная стратегия, есть ли достаточно большие бюджеты, при которых стратегия может выставлять ставки без ограничений.

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

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

Андрей Дёмин: Я бы сейчас использовал в Директе единую перфоманс-кампанию. Там сейчас в рамках беты вы можете разместить рекламу через Карты и в карточках организаций в Поиске. Когда человек ищет какую-то стоматологию, он может увидеть эту самую стоматологию в этих карточках. Я думаю, имеет смысл размещаться и в обычном поиске тоже, то есть обычные текстовые объявления, которые размещаются в основной выдаче. Стратегии здесь, наверное, как и в случае с любыми другими нишами, в первую очередь, конверсионные, если есть возможность передавать данные по конверсиям. Опять же, как раз в тему сегодняшней встречи, офлайн-конверсии здесь были бы, наверное, более приоритетны. То есть брать только те заявки, которые действительно завершились хотя бы визитами клиентов в клиники или каким-то иным статусом, нежели просто бросили контакты — смотришь на номер, а там одни девятки или что-то в этом духе.

Но это если верхнеуровнево, потому что вопрос, наверно, не предполагает какого-то глубокого погружения. Единственное, что есть уточнение, работает ли радиус в настройках. Сложно сказать. У кого-то срабатывает, у кого-то нет. Можно как минимум попробовать настроить радиус, настроить какие-то полигоны, использовать их в качестве корректировок, но здесь уже, конечно, нужно будет обращаться к Яндекс Аудиториям, потому что именно там у вас будет возможность более гибко это всё настроить. Тем не менее попробовать стоит.

Ну и Карты, да. Стоматология — это зачастую именно Карты. Я вот, например, большинство всех врачей, всякие медуслуги предпочитаю искать… Если это какие-то распространенные услуги, а не что-то супер… Мне сложно сейчас представить, какая это должна быть за суперпроцедура, которую мне важно, чтобы провёл кто-то конкретно. Большинство услуг, того же стоматолога, я бы поискал где-нибудь поблизости. Я бы вряд ли ехал через весь город на другой конец Москвы за подобными услугами. Поэтому всё, что касается Карт, всё, что касается радиуса, вполне актуально.

Андрей Дёмин: В данном случае не совсем ставка, в данном случае цена конверсии. Учитывая то, что это у вас оплата за конверсии, я бы попробовал поменять модель оплаты на оплату за клики. Посмотрел бы, что будет в данном случае. Здесь точно нужно кардинально менять настройки. Обычно у стратегии с оплатой за конверсии довольно жёсткие алгоритмы, они не всегда могут разогнать обучение стратегий. Здесь лучше уходить от оплаты за конверсии в сторону оплаты за клики, пробовать такую модель оплаты.

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

Поэтому здесь, наверное, на будущее я бы рекомендовал не менять так резко стоимость конверсии. Лучше делать это постепенно, поэтапно, давая стратегии адаптироваться к новым настройкам. Меняйте как бюджет, так и целевую стоимость конверсии не больше, чем на 10% и не чаще, чем раз в неделю, если уж вам необходимо как-то усиливать работу вашей кампании. Пока что попробуйте оплату за клики и дальше, если накопятся данные, можно будет уже перейти обратно на оплату за конверсии. Но тут тоже нужно понимать, что оплату за конверсию лучше использовать тогда, когда у вас в неделю набирается даже не десять конверсий. Я бы рекомендовал, чтобы стабильно было двадцать конверсий в неделю. Тогда это даст большую вероятность того, что стратегия не загнётся в случае каких-то резких изменений, подобных тому, которое произошло.

Предлагаю на этом моменте завершать. Ребят, спасибо вам огромное за то, что вы задавали нам сегодня кучу вопросов. Напоминаю, что каждую среду в 12:00 по московскому времени мы проводим Q&A-сессии. Бывают тематические, как сегодня, когда мы делаем упор на разбор вопросов, связанных с этой темой, бывают Q&A-сессии, когда у нас темы открытые. Приносите нам любые вопросы, мы стараемся на них отвечать. У нас каждый раз новые гости. Ждём вас на следующих Q&A-сессиях. Лео, отдельное спасибо тебе за то, что сегодня настолько подробно, просто и понятно раскрыл данную тему. На этом всё. Всем до новых встреч.