Александр Поляков

Позвонил в МТС, спросил, как отказаться от передачи данных о звонках третьим лицам. Мне сказали, что МТС никому ничего никогда не передает.

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

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

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

Дело в том, что мы не можем знать ничего о том как происходил клик по рекламе, сколько раз пользователь увидел нашу рекламу до клика и т д.

А вот о переходе на сайт нам достаётся уже огромное количество информации: если переход из органической выдачи, мы можем получить реферер из сессии пользователя, если переход происходил по рекламе: то в дополнение к рефереру все ссылки содержат разметку utm_source, utm_medium, utm_campaiign и т д. В utm_content мы передаём широкий спектр параметров включая позицию показа (над или под поисковой выдачей и место на котором мы находились 1,2.... в момент клика), регион местонахождения и т д

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

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

PS: кроме переходов по рекламе у пользователей есть еще один вариант взаимодействия с ней, который будет бедным на атрибуты. Это звонок по телефону, который расположен возле рекламы.
Чаще всего мы знаем только то, что этот звонок был + мы присваимваем разные телефоны разным лендингам и разным рекламным системам, а значит можем знать по рекламе какого из сайтов был звонок и в какой поисковой системе. Это очень "бедные" данные. Гугл выдаёт детальный отчет для таких размещений (ведь у Google Ads работает свой коллтрекинг): можно посмотреть объявление которое видел пользователь, запрос, который он вводил и даже длительность разговора, а вот в Яндексе такие данные получить пока нельзя. Всё что мы можем знать — позвонили через номер телефона в объявлении. Ни текста объявления ни запроса пользователя посмотреть нельзя.

У меня получилось ответить?

Обращайтесь, конечно. Кстати в Зумкит есть Инструменты для проверки разметки

Ты знаешь где меня найти ;)

Зумкит — серверная штука. Его тоже можно было бы запустить на Амазоне, но не уверен, что экономика сошлась бы. За сервер сейчас я плачу около трёх тысяч в месяц. 

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

Список пользователей вам надо хранить самостоятельно. Таковы тонкости работы телеграм. 

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

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

У меня в базе такие поля: 

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

Если вы прийдете в бот и активируете его, он запустит функцию записи или обновления ваших данных в базе пользователей.

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

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

Но в телеграме можно сделать так, чтобы бот отправлял все обновления сам на сервер, по HTTP протоколу. Это называется webhook.  Метод документации — /setWebhook

Мы можем настроить HTTP шлюз прямо на Амазоне. То есть Телеграм  будет присылать все обновления прямо в Амазон. Этот запрос будет является тригером для запуска AWS Lambda функции обновления базы данных прользователей. Она берет сообщение, ищет в нём команду и интерпретирует ее. Например если отправить боту /start он включится, а если /stop, перестанет присылать уведомления.
Можно отправить /register и бот будет ждать авторизационного ключа.
Всё поведение бота является реакцией на определенный апдейт, который присылает сам Телеграм.

>8 пункту: используется по сути пароль без логина? решение показалось изящным, одна строка, а не две или три. Плюс в принципе все пользователи являются деанонимизированными — то есть в случае необходимости отключить пользователя можно можно прямо в DynamoDB, ключ авторизации поменять тоже можно там же.

Получилось ответить? 

Могу добавить, что лично пользуюсь сервисами Comagic уже более 4 лет. И работа поддержки — это то, за что я ценю комейджик. Могут случаться различные форс-мажоры от несвоевременной оплаты бухгалтерией счетов до сбоев на уровне настроек. Коллеги всегда максимально оперативно помогают решить любую проблему. Случалось, что даже в выходной. Большие молодцы.

Надо пробовать и одно и другое. Для автосалона из примера мы одновременно крутим и Фейсбук с Инстаграмом и Яндекс.Директ и Google Ads + множество других вариантов размещения. Фокусировка на каком-то одном канале приносит результат, но не даёт стабильности. 

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

Скорее всего, если вы посмотрите заявки по любому своему более или менее популярному проекту, то обнаружите большое количество  вот таких 111-11-11 или 999-99-99 номеров. Любой человек сразу поймёт, что это скорее всего тестовые заявки разработчиков, а вот компьютеру это не понятно. Раньше мы очень часто получали размытие статистики из-за таких пользователей: представляете, в одного пользователя с номером из единиц попадали все работники отдела разработки.

Чтобы исключить это мы стали оценивать качество взаимодействий с такими пользователями в системах сквозной аналитики и соответствие номеров определённым маскам. Благодаря этому мы исключили попадание в отчеты шума.

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

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

Второй нюанс: цель типа «Звонок», которая сама по себе не имеет идентификатора цели или url посещения, она находится вообще в данных стороннего сервиса и может быть передана в метрику как оффлайн-конверсия, а может быть вообще не передана, так как есть проблемы с настройкой доступа. 

Или ещё например цели «электронной коммерции» у интернет-магазинов, их тоже нельзя напрямую выбрать в качестве варианта шага в составной цели — в ней ведь только url или JavaScript-событие.

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

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

Механика составной цели не справится с моей задачей. С более простыми задачами может справится, но с моей нет. 

Сейчас получилось объяснить?

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

У составной цели есть важное свойство: события из неё должны быть выполнены ВСЕ в одном визите. Если выполнено только одно из них, составная цель не учитывается. 

И второе свойство: события должны быть выполнены именно в той последовательности, в которой вы их указали в настройке. То есть если мы настроили Шаг 1: звонок, а Шаг 2: отправка формы, а пользователь сначала отправил форму, а потом позвонил, то цель не учитывется.

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

У меня получилось объяснить? 

Конечно не факт, что не сыграла. Я с вами согласен. Но платить за цели, которые не факт что сыграли мы не хотим. Вы можете действовать иначе. Тут дело выбора. 

Не очень понял ваш комментарий поля платить придётся так или иначе, за клики или да конверсии. 

В текущей схеме мы платим только за конверсии. За переходы не платим. Расход нулевой. 

Верно. Но нам же важно платить за конверсии Яндексу только когда они действительно сработали.

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

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

Именно поэтому мы решили, что платить будем только в случае, если Яндекс.Директ является последним значимым переходом. Поэтому заменили модель по умолчанию на "Последний значимый переход" 

Вы не хотите видеть разницу между "Оптимизацией конверсий" и "Оплатой за конверсии" почему-то.

Вот посмотрите на скриншот, который я приложил.

Важен отмеченный на нём селектор. Когда вы его включаете, возможность выбрать "все цели" исчезает. Остаётся только выбор какой-то одной цели. А пока он выключен: да, можно выбрать  "Все цели".

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

Конкретно в данной статье мы использовали его для объединения конверсий из трёх источников.

Но CPA-модель оплаты контекста может хорошо работать и без него/других сервисов. Просто в нашем случае без них не получалось. 

А так да, это биддер с функцией проверки объявлений под разные параметры. Подробно о юзкейсах я писал тут  https://vc.ru/marketing/52378-kontekstnaya-reklama-dlya-internet-magazina-shin-10-rubley-za-klik-kontrol-assortimenta

Это если аукцион с "оптимизацией конверсий", а в аукционе с оплатой за конверсий такой опции нет. Прикладываю скриншот.

Так что вы правы, но не совсем.

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

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

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

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

В перспективе, конечно, есть мысли о расширении штата и введения абонентской платы, но в ближайшие месяцы я буду работать над функционалом управления корректировками ставок, а не над биллингом)