Если вы не пишите собственную бибилиотеку (jQuery плагин или что-то в этом духе), которая должна оборачиваться в UMD-обёртку с внешними зависимостями (которые не нужно включать в сборку), то беспокоиться не о чем.
Я вот как-то не чувствую острой необходимости в browsersync: прикрутил, попробовал и убрал. А http-server я просто ещё до вникания в автоматизацию сборки использовал и на `npm start` изначально его повесил. Есть какая-то разница откуда его запускать?
Я сначала тоже плевался и пока изучал — всё писал на чистом JS. Но как только переключился с коротких примеров на реальный апп, то очень быстро вернулся к JSX и сейчас у меня с ним в принципе harmony)
Я тоже не хочу уходить с Рельс. Но хороший фронт тоже очень хочется. Я недавно написал первый апп с React & Rails. В итоге в приложении вместо slim/erb теперь jsx. React просто стал V в MVC рельс. Правда сам React ещё довольно молод и некоторые вещи приходится заново изобретать. Но, судя по темпам, оно скоро исправится. И надеюсь серверный рендеринг в геме допилят до вменяемого состояния.
Выше правильно прокомментировали: запросы вы сможете получать только через utm-разметку.
И гугл, и яндекс шифруют 100% запросов в органических реферерах, и модуль даже не пытается их получать.
Максимум он сможет определить, что посетитель пришел с органики Яндекса или Гугла (по гуглу ещё см. ограничение, связанное с переходами https → http).
С терминологией спорить не буду, всё так и есть. Я хотел подчеркнуть, что валидация осуществляется средствами js ( + server-side), но без отправки формы с перезагрузкой страницы. Пользователь сразу получает информацию о правильности заполнения полей, как будто это делает чистый js, но без дублирования логики валидации.
Значения этих параметров складываются в куку и вытаскиваются методом модуля.
И в зависимости от значений, отдаваемых модулем, происходит подмена. Удобный настраиваемый модуль подмены надо писать, но смысл ясен: в зависимости от значения рекламной метки выводится соответствующий контент.
По поводу того, что сохраняется и как использовать.
Как я написал в посте, прежде всего сохраняеются все utm данные:
utm_source — источник (например, yandex)
utm_medium — канал (например, cpc или organic)
utm_campaign — название рекламной кампании
utm_content — версия баннера / объявления
utm_term — ключевое слово (пока не тянется из органики, и я не уверен, что это надо добавлять, т.к. гугл уже всё спрятал, а яндекс увернно к этом движется)
И кроме этого ряд дополнительных параметров: точка входа, дата первого посещения и т.д.
Оно полезно при аналитике. Например, можно анализировать сколько времени прошло с момента первого перехода до момента совершения конверсии.
Как использовать эти данные.
Прежде всего это приписки к заявкам. Данные об источнике, с которого пришел целевой пользователь, улетают вместе с заявкой в «систему» (бд / crm / почта и т.д.), после чего используются при построении отчетов по эффективности.
Также их можно использовать для подмены контента: заголовков, номеров телефонов и т.д.
Например, у вас есть сайт в сегменте кредитов. Ваши рекламные кампании разбиты по формулировкам запроса: кредиты, ссуды, займы и т.д.
В зависимости от значения utm_campaign в куке (или utm_term, если все запросы в одной РК), вы можете на странице приземления подменять формулировку: кредит, ссуда и т.д.
И соответственно если у вас РК имеют отдельные телефонные номера, то в зависимости от utm_campaign на сайте происходит подмена телефонного номера.
В чем смысл создавать такую же печеньку, как в GA, если из самого GA она скоро исчезнет? Для тех, кто раньше парсил эту печеньку? Получается костыль на костыле.
«Такая же» — это условно. Просто я переложил информацию из чужой печеньки в свою, автономную, данные в которой не зависят от чего-то «third party». GA убил 4 печеньки из 5 для того, чтобы уменьшить трафик и производить все вычисления на стороне своих серверов. В моём случае всё и так на моем сервере.
И зачем вообще в Rails использовать печеньки, если там есть сессии? Лучше положить всю эту информацию в сессии в готовом для использования виде.
Можно и в сессию складывать. Я выбрал печеньки, т.к. данные можно и через js достать, и визуально на любом из сайтов можно быстро проверить что в куках. Это полезно, когда есть менеджер, который знает как посмотреть в куку при тестировании страницы приземления, но понятия не имеет что такое Rails сессия. Если есть какие-то веские основания этого не делать — расскажите. С удовольствием проникнусь.
Спасибо)
Я тестировал в Safari и Chrome на iOS, там всё честно. Скорее всего что-то режет рефререр на андроиде, посмотреть сейчас, к сожалению, возможности нет.
По поводу перезаписи источников: всё довольно просто.
Переходы с utm-метками — перезаписывают любой источник независимо от сессии.
Переходы с органики — перезаписывают любой источник независимо от сессии.
Реферальные переходы — не перезаписывают источник, если переход был совершён в рамках текущей сессии.
Если реферальный переход начал новую сессиию, то источник перезаписывается.
Прямой переход (typein) не перезаписывает ничего.
В поле с ключевым словом в органических источниках будет стоять
(none).И гугл, и яндекс шифруют 100% запросов в органических реферерах, и модуль даже не пытается их получать.
Максимум он сможет определить, что посетитель пришел с органики Яндекса или Гугла (по гуглу ещё см. ограничение, связанное с переходами https → http).
Если был, то оно не перезапишет источник, потому что сессия та же.
Все рекламные кампании размечены и на объявлении висит ссылка вида:
www.site.com/some/page?utm_source=yandex&utm_medium=cpc&utm_campaign=campaign_name
Также в ссылке могут быть utm_content =banner_1(если проводите сплит-тест обявлений) и utm_term=keyword (если метите до ключа).
Значения этих параметров складываются в куку и вытаскиваются методом модуля.
И в зависимости от значений, отдаваемых модулем, происходит подмена. Удобный настраиваемый модуль подмены надо писать, но смысл ясен: в зависимости от значения рекламной метки выводится соответствующий контент.
Как я написал в посте, прежде всего сохраняеются все utm данные:
И кроме этого ряд дополнительных параметров: точка входа, дата первого посещения и т.д.
Оно полезно при аналитике. Например, можно анализировать сколько времени прошло с момента первого перехода до момента совершения конверсии.
Как использовать эти данные.
Прежде всего это приписки к заявкам. Данные об источнике, с которого пришел целевой пользователь, улетают вместе с заявкой в «систему» (бд / crm / почта и т.д.), после чего используются при построении отчетов по эффективности.
Также их можно использовать для подмены контента: заголовков, номеров телефонов и т.д.
Например, у вас есть сайт в сегменте кредитов. Ваши рекламные кампании разбиты по формулировкам запроса: кредиты, ссуды, займы и т.д.
В зависимости от значения utm_campaign в куке (или utm_term, если все запросы в одной РК), вы можете на странице приземления подменять формулировку: кредит, ссуда и т.д.
И соответственно если у вас РК имеют отдельные телефонные номера, то в зависимости от utm_campaign на сайте происходит подмена телефонного номера.
«Такая же» — это условно. Просто я переложил информацию из чужой печеньки в свою, автономную, данные в которой не зависят от чего-то «third party». GA убил 4 печеньки из 5 для того, чтобы уменьшить трафик и производить все вычисления на стороне своих серверов. В моём случае всё и так на моем сервере.
Можно и в сессию складывать. Я выбрал печеньки, т.к. данные можно и через js достать, и визуально на любом из сайтов можно быстро проверить что в куках. Это полезно, когда есть менеджер, который знает как посмотреть в куку при тестировании страницы приземления, но понятия не имеет что такое Rails сессия. Если есть какие-то веские основания этого не делать — расскажите. С удовольствием проникнусь.
Я тестировал в Safari и Chrome на iOS, там всё честно. Скорее всего что-то режет рефререр на андроиде, посмотреть сейчас, к сожалению, возможности нет.
По поводу перезаписи источников: всё довольно просто.
Переходы с utm-метками — перезаписывают любой источник независимо от сессии.
Переходы с органики — перезаписывают любой источник независимо от сессии.
Реферальные переходы — не перезаписывают источник, если переход был совершён в рамках текущей сессии.
Если реферальный переход начал новую сессиию, то источник перезаписывается.
Прямой переход (typein) не перезаписывает ничего.