Вы не совсем правы. В справке Яндекса написано "Шаги должны быть выполнены в рамках одного визита посетителя". Не события, а шаги!
При этом в рамках одного шага, вы можете задать до 10 условий, которые будут объедены логическим оператором "ИЛИ, то есть цель считается достигнутой, если выполнено хотя бы одно из заданных условий". https://yandex.ru/support/metrica/general/goal-steps.html
Т.е. в составную цель, можно объединить до 10 любых целей. И составная цель будет срабатывать, если сработала хотя бы одна из них)
Вот вам лайфхак, и не надо писать для этого отдельный сервис)
Да, вы правы, но не совсем. Видимо вы не совсем поняли мои задачи в данном проекте. Наверное надо было остановиться на них подробнее в материале. Сейчас попробую объяснить.
Составной целью вы решаете вопрос с обычными JavaScript событиями или посещением url. Тут все хорошо. Они справятся с задачей, если не нужно выбрать из всех эвентов уникальные. Мне вот не хотелось, чтобы повторные сессии учитывались и средства за них списывались.
Второй нюанс: цель типа «Звонок», которая сама по себе не имеет идентификатора цели или url посещения, она находится вообще в данных стороннего сервиса и может быть передана в метрику как оффлайн-конверсия, а может быть вообще не передана, так как есть проблемы с настройкой доступа.
Или ещё например цели «электронной коммерции» у интернет-магазинов, их тоже нельзя напрямую выбрать в качестве варианта шага в составной цели — в ней ведь только url или JavaScript-событие.
Понимаю, и ту и другую цель можно задать через JavaScript-события: клик по номеру телефона или клик по кнопке подтверждения покупки. Вот только данные собранные таким образом, на самом деле, плохо коррелируют с количеством настоящих звонков (я проверял, можете и вы проверить).
Плюс в моем случае была задача фильтровать повторные вызовы пользователей, фильтровать заявки с фейковых номеров в формах, мы даже наловчились отсеивать пользователей, если они приходили с разных устройств: когда пользователь заказал обратный звонок со смартфона, недождался, потом пришёл с десктопа и позвонил по номеру на сайте сам.
Механика составной цели не справится с моей задачей. С более простыми задачами может справится, но с моей нет.
Вы не совсем правы. В справке Яндекса написано "Шаги должны быть выполнены в рамках одного визита посетителя". Не события, а шаги!
При этом в рамках одного шага, вы можете задать до 10 условий, которые будут объедены логическим оператором "ИЛИ, то есть цель считается достигнутой, если выполнено хотя бы одно из заданных условий".
https://yandex.ru/support/metrica/general/goal-steps.html
Т.е. в составную цель, можно объединить до 10 любых целей. И составная цель будет срабатывать, если сработала хотя бы одна из них)
Вот вам лайфхак, и не надо писать для этого отдельный сервис)
Да, вы правы, но не совсем. Видимо вы не совсем поняли мои задачи в данном проекте. Наверное надо было остановиться на них подробнее в материале. Сейчас попробую объяснить.
Составной целью вы решаете вопрос с обычными JavaScript событиями или посещением url. Тут все хорошо. Они справятся с задачей, если не нужно выбрать из всех эвентов уникальные. Мне вот не хотелось, чтобы повторные сессии учитывались и средства за них списывались.
Второй нюанс: цель типа «Звонок», которая сама по себе не имеет идентификатора цели или url посещения, она находится вообще в данных стороннего сервиса и может быть передана в метрику как оффлайн-конверсия, а может быть вообще не передана, так как есть проблемы с настройкой доступа.
Или ещё например цели «электронной коммерции» у интернет-магазинов, их тоже нельзя напрямую выбрать в качестве варианта шага в составной цели — в ней ведь только url или JavaScript-событие.
Понимаю, и ту и другую цель можно задать через JavaScript-события: клик по номеру телефона или клик по кнопке подтверждения покупки. Вот только данные собранные таким образом, на самом деле, плохо коррелируют с количеством настоящих звонков (я проверял, можете и вы проверить).
Плюс в моем случае была задача фильтровать повторные вызовы пользователей, фильтровать заявки с фейковых номеров в формах, мы даже наловчились отсеивать пользователей, если они приходили с разных устройств: когда пользователь заказал обратный звонок со смартфона, недождался, потом пришёл с десктопа и позвонил по номеру на сайте сам.
Механика составной цели не справится с моей задачей. С более простыми задачами может справится, но с моей нет.
Сейчас получилось объяснить?