ну, а задача то какая, год к году сравнить? тогда signals в сравнение не берите, его же не было в прошлом году. В тотале по каналам увидите совокупный рост (если он есть).
Если хотите вернуть “как было” – посмотрите конверсии по каналам за прошлый и текущие года до декабря, если они не отличаются – просто перемножьте трафик на конверсию и получите как “должно было быть”.
PS: Не совсем понятно, чего вы добиться хотите этим сравнением, если отчеты руководству, то ситуацию можно объяснить изменением алгоритмов атрибуции и показать что – тут упало, а тут выросло, а в тотале – вот что! Если цели сравнения другие, то и подход к сравнению нужно менять
Трафик особо то и не растет, а регистрации падают- факт. Direct – это прямой трафик, not set- нераспознанный.
Я бы попробовал поискать корреляцию в регистрациях в других каналах – возможно она где-то начала расти. Если в тотале по всем каналам с момента падения в Direct просадки нет – значит часть регистраций присвоил себе другой канал.
Нет, проблема всё-таки есть) вы не ту задачу решаете. Не важно как генерировать user_id, важна логика, как вы будете смачивать сессии по этому id.
Опишите формально эту логику и поймёте тонкие места. В вашем случае, пока пользователь с нового устройства не заявит о себе (снова оставит тот же контакт) вы о нем будете думать и собирать статистику как о новом. Как только он себя засветит, вы его сматчите в текущий user_id, но предыдущие действия так и останутся нераспознанными. В итоге: garbage in – garbage out.
vitbash
Ну а поставить триггер на видимость рекламного блока внизу страницы не вариант?
Опишите формально свою задачу, еще лучше с примерами)
vitbash
В Гугле полно кейсов на эту тему, вот например:
https://www.ru.advertisercommunity.com/t5/Stati/Otslezhivanie-vidimosti-elementov-na-sayte-s-pomoshchyu-Google-Tag/ba-p/354008
vitbash
ну, а задача то какая, год к году сравнить? тогда signals в сравнение не берите, его же не было в прошлом году. В тотале по каналам увидите совокупный рост (если он есть).
Если хотите вернуть “как было” – посмотрите конверсии по каналам за прошлый и текущие года до декабря, если они не отличаются – просто перемножьте трафик на конверсию и получите как “должно было быть”.
PS: Не совсем понятно, чего вы добиться хотите этим сравнением, если отчеты руководству, то ситуацию можно объяснить изменением алгоритмов атрибуции и показать что – тут упало, а тут выросло, а в тотале – вот что! Если цели сравнения другие, то и подход к сравнению нужно менять
vitbash
Потому что в отчётах по дефолту атрибуция последний не прямой. Поэтому трафик может остаться за direct, а конверсия нет.
Да вероятно это signals, Гугл научился вычислять часть вашей аудитории с разных устройств.
vitbash
Трафик особо то и не растет, а регистрации падают- факт. Direct – это прямой трафик, not set- нераспознанный.
Я бы попробовал поискать корреляцию в регистрациях в других каналах – возможно она где-то начала расти. Если в тотале по всем каналам с момента падения в Direct просадки нет – значит часть регистраций присвоил себе другой канал.
vitbash
eventCategory и eventAction – это не события, а параметры события VirtualPageview.
Вы можете настроить триггер на “пользовательское событие” – VirtualPageview. Тогда он будет срабатывать всякий раз, когда будет вызвано это событие.
vitbash
Почему бы просто не ловить факт успешной отправки через событие js?
vitbash
Все ответы есть в Яндекс хелпе, очень легко гуглится.
vitbash
Нет, проблема всё-таки есть) вы не ту задачу решаете. Не важно как генерировать user_id, важна логика, как вы будете смачивать сессии по этому id.
Опишите формально эту логику и поймёте тонкие места. В вашем случае, пока пользователь с нового устройства не заявит о себе (снова оставит тот же контакт) вы о нем будете думать и собирать статистику как о новом. Как только он себя засветит, вы его сматчите в текущий user_id, но предыдущие действия так и останутся нераспознанными. В итоге: garbage in – garbage out.
vitbash
У вас нет никакой проблемы. Стройте аналитику на основе client_id. Для оценки эффективности рекламы этого достаточно.