Comments 13
Отличный пост! Сам занимаюсь веб-разработкой на Ruby on Rails и интернет-маркетингом, ваша статья — просто находка!
По переходам в песочницу с хабра — в chrome на ПК гем честно показал referral переход с хабра, а вот в chrome на андроиде показывает typein. Не знаю, возможно это проблемы андроида, либо хрома на андроиде.
Еще несколько сложно было понять суть правил перезаписи — вы упомянули, что они такие же, как в GA, т.е. в статье предполагается, что читатель уже хорошо знаком с GA. Может быть, сможете порекомендовать статьи или документацию по этой теме? Что конкретно сохраняется в куках, как перезаписывается и как это можно использовать. Заранее спасибо.
По переходам в песочницу с хабра — в chrome на ПК гем честно показал referral переход с хабра, а вот в chrome на андроиде показывает typein. Не знаю, возможно это проблемы андроида, либо хрома на андроиде.
Еще несколько сложно было понять суть правил перезаписи — вы упомянули, что они такие же, как в GA, т.е. в статье предполагается, что читатель уже хорошо знаком с GA. Может быть, сможете порекомендовать статьи или документацию по этой теме? Что конкретно сохраняется в куках, как перезаписывается и как это можно использовать. Заранее спасибо.
Спасибо)
Я тестировал в Safari и Chrome на iOS, там всё честно. Скорее всего что-то режет рефререр на андроиде, посмотреть сейчас, к сожалению, возможности нет.
По поводу перезаписи источников: всё довольно просто.
Переходы с utm-метками — перезаписывают любой источник независимо от сессии.
Переходы с органики — перезаписывают любой источник независимо от сессии.
Реферальные переходы — не перезаписывают источник, если переход был совершён в рамках текущей сессии.
Если реферальный переход начал новую сессиию, то источник перезаписывается.
Прямой переход (typein) не перезаписывает ничего.
Я тестировал в Safari и Chrome на iOS, там всё честно. Скорее всего что-то режет рефререр на андроиде, посмотреть сейчас, к сожалению, возможности нет.
По поводу перезаписи источников: всё довольно просто.
Переходы с utm-метками — перезаписывают любой источник независимо от сессии.
Переходы с органики — перезаписывают любой источник независимо от сессии.
Реферальные переходы — не перезаписывают источник, если переход был совершён в рамках текущей сессии.
Если реферальный переход начал новую сессиию, то источник перезаписывается.
Прямой переход (typein) не перезаписывает ничего.
По поводу того, что сохраняется и как использовать.
Как я написал в посте, прежде всего сохраняеются все utm данные:
И кроме этого ряд дополнительных параметров: точка входа, дата первого посещения и т.д.
Оно полезно при аналитике. Например, можно анализировать сколько времени прошло с момента первого перехода до момента совершения конверсии.
Как использовать эти данные.
Прежде всего это приписки к заявкам. Данные об источнике, с которого пришел целевой пользователь, улетают вместе с заявкой в «систему» (бд / crm / почта и т.д.), после чего используются при построении отчетов по эффективности.
Также их можно использовать для подмены контента: заголовков, номеров телефонов и т.д.
Например, у вас есть сайт в сегменте кредитов. Ваши рекламные кампании разбиты по формулировкам запроса: кредиты, ссуды, займы и т.д.
В зависимости от значения utm_campaign в куке (или utm_term, если все запросы в одной РК), вы можете на странице приземления подменять формулировку: кредит, ссуда и т.д.
И соответственно если у вас РК имеют отдельные телефонные номера, то в зависимости от utm_campaign на сайте происходит подмена телефонного номера.
Как я написал в посте, прежде всего сохраняеются все utm данные:
- utm_source — источник (например, yandex)
- utm_medium — канал (например, cpc или organic)
- utm_campaign — название рекламной кампании
- utm_content — версия баннера / объявления
- utm_term — ключевое слово (пока не тянется из органики, и я не уверен, что это надо добавлять, т.к. гугл уже всё спрятал, а яндекс увернно к этом движется)
И кроме этого ряд дополнительных параметров: точка входа, дата первого посещения и т.д.
Оно полезно при аналитике. Например, можно анализировать сколько времени прошло с момента первого перехода до момента совершения конверсии.
Как использовать эти данные.
Прежде всего это приписки к заявкам. Данные об источнике, с которого пришел целевой пользователь, улетают вместе с заявкой в «систему» (бд / crm / почта и т.д.), после чего используются при построении отчетов по эффективности.
Также их можно использовать для подмены контента: заголовков, номеров телефонов и т.д.
Например, у вас есть сайт в сегменте кредитов. Ваши рекламные кампании разбиты по формулировкам запроса: кредиты, ссуды, займы и т.д.
В зависимости от значения utm_campaign в куке (или utm_term, если все запросы в одной РК), вы можете на странице приземления подменять формулировку: кредит, ссуда и т.д.
И соответственно если у вас РК имеют отдельные телефонные номера, то в зависимости от utm_campaign на сайте происходит подмена телефонного номера.
Вот насчет подмены контента интересно. Просто сейчас я работаю по такой схеме:
— В рельсах создаются маршруты, на странице для подмены используются параметры
— В кампанию в Директе (AdWords и тому подобное) вместо ссылки на основной сайт вставляется ссылка узкоцелевая, например так: hairmaster-lux.ru/podolsk/services/extension/hot/slavic/cheap
А с утм-метками не совсем ясно. Получается, при переходе с того же директа, можно автоматически парсить параметры source (direct) campaign и content (вот в них что будет?) и по ним уже контент подменять?
— В рельсах создаются маршруты, на странице для подмены используются параметры
— В кампанию в Директе (AdWords и тому подобное) вместо ссылки на основной сайт вставляется ссылка узкоцелевая, например так: hairmaster-lux.ru/podolsk/services/extension/hot/slavic/cheap
А с утм-метками не совсем ясно. Получается, при переходе с того же директа, можно автоматически парсить параметры source (direct) campaign и content (вот в них что будет?) и по ним уже контент подменять?
Flow такой.
Все рекламные кампании размечены и на объявлении висит ссылка вида:
www.site.com/some/page?utm_source=yandex&utm_medium=cpc&utm_campaign=campaign_name
Также в ссылке могут быть utm_content =banner_1(если проводите сплит-тест обявлений) и utm_term=keyword (если метите до ключа).
Значения этих параметров складываются в куку и вытаскиваются методом модуля.
И в зависимости от значений, отдаваемых модулем, происходит подмена. Удобный настраиваемый модуль подмены надо писать, но смысл ясен: в зависимости от значения рекламной метки выводится соответствующий контент.
Все рекламные кампании размечены и на объявлении висит ссылка вида:
www.site.com/some/page?utm_source=yandex&utm_medium=cpc&utm_campaign=campaign_name
Также в ссылке могут быть utm_content =banner_1(если проводите сплит-тест обявлений) и utm_term=keyword (если метите до ключа).
Значения этих параметров складываются в куку и вытаскиваются методом модуля.
И в зависимости от значений, отдаваемых модулем, происходит подмена. Удобный настраиваемый модуль подмены надо писать, но смысл ясен: в зависимости от значения рекламной метки выводится соответствующий контент.
По поводу проблемы с андроидом: там точно не было прямого перехода сначала?
Если был, то оно не перезапишет источник, потому что сессия та же.
Если был, то оно не перезапишет источник, потому что сессия та же.
В чем смысл создавать такую же печеньку, как в GA, если из самого GA она скоро исчезнет? Для тех, кто раньше парсил эту печеньку? Получается костыль на костыле.
И зачем вообще в Rails использовать печеньки, если там есть сессии? Лучше положить всю эту информацию в сессии в готовом для использования виде.
И зачем вообще в Rails использовать печеньки, если там есть сессии? Лучше положить всю эту информацию в сессии в готовом для использования виде.
В чем смысл создавать такую же печеньку, как в GA, если из самого GA она скоро исчезнет? Для тех, кто раньше парсил эту печеньку? Получается костыль на костыле.
«Такая же» — это условно. Просто я переложил информацию из чужой печеньки в свою, автономную, данные в которой не зависят от чего-то «third party». GA убил 4 печеньки из 5 для того, чтобы уменьшить трафик и производить все вычисления на стороне своих серверов. В моём случае всё и так на моем сервере.
И зачем вообще в Rails использовать печеньки, если там есть сессии? Лучше положить всю эту информацию в сессии в готовом для использования виде.
Можно и в сессию складывать. Я выбрал печеньки, т.к. данные можно и через js достать, и визуально на любом из сайтов можно быстро проверить что в куках. Это полезно, когда есть менеджер, который знает как посмотреть в куку при тестировании страницы приземления, но понятия не имеет что такое Rails сессия. Если есть какие-то веские основания этого не делать — расскажите. С удовольствием проникнусь.
Интересно. Чутка подрихтовал. Будет время, пропишу документацию.
Sign up to leave a comment.
Модуль определения источников посетителей сайта для Ruby on Rails