Sourcebuster js как настроить

Скрипт для анализа источников посещений сайта

Есть в нашем арсенале 2 модуля: Анализ источников заказов в магазине и Анализ конверсии форм. Рассказываем о том, что за винтики крутятся внутри.

Установка и настройка

bower install —save sourcebuster-js

Поскольку модуль написан на чистом JavaScript, не зависит от сторонних библиотек и фактического содержания DOM’а, вызываться он может когда вы посчитаете нужным. Чем выше вы он будет в страницы, тем раньше вы получите куки, данные из которых могут использоваться для манипуляций с объектами DOM’а.

Простая установка (для тех, кто не использует поддомены на сайте, и кого устраивают настройки по-умолчанию)

Вставляем в страницы:

— органическим трафиком считаются переходы из выдачи Яндекс, Google и ряда дополнительных источников:

Установка «для продвинутых пользователей ПК»

Всего 9 видов пользовательских настроек:

Продолжительность сессии пользователя в минутах

Этот показатель влияет на перезапись реферального источника.

При первом заходе пользователя на сайт, мы получаем данные об источнике перехода. Если этот пользователь вернётся на сайт с другого источника, мы можем перезаписать текущий источник, или этого не делать. Логика перезаписи полностью повторяет логику Google Analytics:

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

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

Эта настройка актуальна, только если вы используете на своём сайте поддомены.

Сценарий 1.
Предположим, есть сайт: site.com. На сайте есть блог: blog.site.com. И вы хотите, чтобы переходы с сайта на блог и обратно считались внутренним трафиком: то есть источник blog.site.com не фиксировался как referral и не перезаписывал другие источники при новой сессии.

Для этого на страницах сайта и блога нужно добавить строчку:

При такой настройке, если пользователь перешел с blog.site.com на site.com (а также с alex.blog.site.com на site.com), источник не перезапишется и такой переход будет равноценен переходу с site.com/about на site.com/contacts.

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

Есть основоной сайт (site.com) и есть блог (blog.site.com), на котором поддомены для юзеров (alex.blog.site.com). Нужно считать переходы между blog.site.com и alex.blog.site.com внутренним трафиком, а переходы между этими поддоменами и основным сайтом — реферальным.

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

В нашем примере при такой настройке все переходы между основным сайтом и блогами будут считаться реферальным трафиком. И если пользователь в первый раз перешёл на основной сайт, кликнув по ссылке из блога пользователя, то его источник будет: alex.blog.site.com (тип трафика: referral).

Итак, закрепим: когда использовать параметр false.

Домен страницы, на которой установлена настройка _setBaseHost с параметром false должен совпадать с хостом, указанным в этой настройке.

Указанный хост не имеет поддоменов, трафик с которых вы хотите считать не-реферальным.

Источник

Sourcebuster JS: скрипт определения
источников посетителей сайта

Скрипт определяет, откуда пришёл посетитель сайта: с рекламы, органического поиска или другого источника. Вот что можно дальше делать с этим данными:

Указывать источник в тексте заявок и заказов с сайта.

Модуль сохранит данные в cookies, технолог добавит их вывод в заявку.

Генерировать промокод, который можно выводить на сайте, отправлять в Google Analytics и др. системы.

Промокод также сохранится в cookies, технолог добавит его вывод на сайте.

Подменять номера телефонов в зависимости от источника перехода.

Подмена реализуется отдельным модулем SB Placer на основании данных Sourcebuster JS.

Подменять заголовки и другой контент в зависимости от источника перехода.

Реализуется аналогично подмене номеров телефонов через SB Placer.

Вот что определил модуль для вас

Первый визит

Текущий визит

Личные данные

Данные о текущей сессии

Тестовые ссылки

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

Органическая выдача

После клика на одну из ссылок вы попадете на страницу органической выдачи поисковой системы, где будет ссылка на тестовую страницу модуля: sbjs.rocks/

Переходите по ссылке из выдачи и смотрите что определил для вас модуль.

Реферальные переходы

Это переходы со сторонних сайтов. После клика на тестовую ссылку вы увидите, что модуль определил ваш визит как реферальный, который был совершен со страницы сайта .ru

Открывайте эту ссылку в режиме Incognito / Private, поскольку если у вас открыта текущая сессия, то источник не перезапишется.

Дистрибутив

Или скачать репозиторий с GitHub и использовать sourcebuster.min.js из папки /dist

Установка

После подключения библиотеки становится доступен объект sbjs. Он имеет 2 метода: init & get. Первый — запускает скрипт, второй — отдаёт данные.

Запускаем:
После инициализации:

• проставятся куки скрипта
• будут доступны данные через метод sbjs.get

Настройка

Параметры

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

Почему это работает именно так. Предположим сайт не имеет поддоменов и сейчас это не важно: шарит ли главный домен печеньки с поддоменами или нет. Но что будет, если однажды поддомены всплывут? Если куки были не расшарены, то поддменам они будут недоступны. Это означает, что переход с основного домена на поддомен (и наоборот) будет считаться реферальным трафиком.

Поэтому по умолчанию печеньки шарятся. Так или иначе, если вы не хотите делиться куками — используйте опцию isolate: true для того, чтобы изолировать их.

Давайте посмотрим на примеры.

Предположим у вас есть сайт: site.com. На вашем сайте есть блог: blog.site.com. И вы хотите, чтобы переходы с сайта на блог и обратно считались внутренним трафиком: то есть источник blog.site.com не фиксировался как referral и не перезаписывал другие источники при новой сессии. Для этого нужно на страницах сайта и блога добавить строчку:

При такой настройке, если пользователь перешел с blog.site.com на site.com (а также с alex.blog.site.com на site.com), источник не перезапишется и такой переход будет равноценен переходу с site.com/about на site.com/contacts.

Теперь рассмотрим противоположенный сценарий: когда вы хотите разделять трафик между поддоменами и считать его реферальным. Есть основной сайт (site.com) и есть блог (blog.site.com), на котором есть поддомены для юзеров (alex.blog.site.com). Вы хотите переходы между blog.site.com и alex.blog.site.com считать внутренним трафиком, а переходы между этими поддоменами и основным сайтом — реферальным. Для этого:

Обратите особое внимание на параметр isolate в параметрах для основного сайта. Он имеет значение true тогда и только тогда, трафик должен быть исключительно в рамках указанного домена. Весь остальной трафик, включая переходы с поддоменов в этом же домене, будет считаться реферальным.

В нашем примере при такой настройке все переходы между основным сайтом и блогами будут считаться реферальным трафиком. И если пользователь в первый раз перешёл на основной сайт, кликнув по ссылке из блога пользователя, то его источник будет: alex.blog.site.com (тип трафика: referral).

Не изменяйте значение параметра isolate после выкатки скрипта на боевой сервер. Иначе посетители получат дублирующиеся куки и начнут происходить странные вещи.

Опция, которая позволит принудительно обновлять домен у печенек при смене настроек, в списке работ, но пока она не реализована.

Проверьте ещё раз, что вы правильно поняли, когда использовать этот параметр.

Домен страницы, на которой установлена настройка isolate с параметром true должен совпадать с хостом, указанным в этой настройке:

Указанный хост не имеет поддоменов, трафик с которых вы хотите считать :

Добавляем источник реферального трафика. Вообще, если вас устраивает, что utm_medium при переходе например с facebook.com будет иметь значение referral, то ничего настраивать не надо. Но если вы хотите присваивать таким переходам кастомный канал (например, utm_medium=social), то вы можете добавить такую настройку через referrals. Первый параметр host — это хост , второй — medium — желаемое значение utm_medium.

Кроме того у некоторых ресурсов реферер отличается от основного домена (например, у Twitter хост реферера — t.co). В таких случаях вы можете присваивать алиас источникам через опциональный параметр display. Через него же вы можете группировать несколько сайтов с разными реферерами в один виртуальный источник.

Скрипт по умолчанию распознает переходы из Twitter и Google+:

Вы всё ещё можете переопределить эти переходы через свою настройку (например если хотите изменить отображаемые названия источника или сменить канал на social).

В скрипте уже есть ряд предустановленных органических источников:

Source	Alias
google.all	google
yandex.all	yandex
bing.com	bing
yahoo.com	yahoo
about.com	about
aol.com	aol
ask.com	ask
globososo.com	globo
go.mail.ru	go.mail.ru
rambler.ru	rambler
tut.by	tut.by

Допустим вы хотите, чтобы система считала переходы с поиска bing.com — органическим трафиком. И алиас для этого источника должен быть my_bing_alias. Для этого вам нужно добавить параметр host: ‘bing.com’, и параметр ключевого слова param: ‘q’. Оба параметра обязательны. Для переопределения алиаса укажите опциональный третий параметр display: ‘my_bing_alias’.

Для получения параметра ключевого слова, нужно зайти на bing.com и вбить в поисковую строку запрос (например, «apple»). После этого вы попадёте на страницу выдачи с адресом вида: http://www.bing.com/search? q=apple &go=&qs=n&form=QBLH&pq=apple&sc=&sp=-1&sk=&cvid=718ad07527244c319ecebf44aa261f64

Параметр ключевого слова — ‘q’ — это символ между «?» (или «&» если параметр идёт не первым после знака вопроса) и «=apple» в урле страницы поисковой выдачи.

Устанавливаем пользовательские значения source и medium для typein трафика. По умолчанию значения этих параметров — (direct) & (none). Вы можете переопределить их с помощью параметра typein_attributes.

Устанавливаем часовой пояс. По умолчанию используется часовой пояс пользователя.

Пример. Посетитель из Лондона (UTC +00:00) зашел на сайт в 03:00 AM (местное время посетителя). Если предустановки нет, то в куку сохранится 03:00 AM. Другой посетитель в то же самое время заходит из Берлина (UTC +01:00). Его местное время 04:00 AM. Время в его куке будет 04:00 AM.

Если вы хотите нормировать время всех посетителей (например по Москве UTC +03:00), нужно выставить настройку timezone_offset: 3. Тогда время в куках обоих посетителей будет 06:00 AM.

Устанавливаем , значение которого будет сохранено в качестве utm_campaign (если в запросе нет оригинального параметра utm_campaign). Эта настройка была добавлена в основном Google AdWords gclid.

Пример использования
Если у вас есть трафик с Google AdWords, и вы используете метку gclid, вы можете сократить урлы, убрав . Sourcebuster всё равно определит, с Google AdWords.

Если в урле присутствует только метка gclid: http://site.com//? gclid=sMtH

Это даст следующий результат:

• Traffic type: utm
• utm_source: google
• utm_medium: cpc
• utm_campaign: google_cpc
• utm_content: (none)
• utm_term: (none)

Вы можете изменить значение utm_campaign через campaign_param: http://site.com//? gclid=sMtH&custom_campaign=test_custom

Тогда результат будет такой:

• Traffic type: utm
• utm_source: google
• utm_medium: cpc
• utm_campaign: test_custom
• utm_content: (none)
• utm_term: (none)

ВАЖНО

• Если в урле присутствуют оригинальные ( utm_source , utm_medium , utm_campaign ), то метка gclid и параметр, заданный через campaign_param, будут проигнорированы.
• Если в урле присутствует только параметр, заданный через campaign_param, Sourcebuster будет считать этот переход .

По умолчанию скрипт не сохраняет посетителя (потому что JS не умеет его определять). Если вы хотите сохранять его в пользовательской куке, можете добавить его через параметр user_ip, получив на бэке. В примере показано, как это сделать на Ruby.

Устанавливаем промокод. Он сохраняется в cookies и действует всё время их жизни (устанавливается параметром lifetime).

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

Нижняя и верхняя границы диапазона значений промокода задаются через параметры min & max параметры. Они, кстати, необязательные. Если их не указать, то будут генерироваться промокоды в диапазоне от 100 000 до 999 999.

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

Callback. Передайте параметру имя функции, и скрипт исполнит её сразу после того, как куки будут проставлены. В качестве аргумента функция получит объект с результирующими данными:

Использование данных

Данные доступны через метод sbjs.get (отдается объект).

Ниже список того, что вы можете получить.

Текущий источник посетителя

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

Дополнительные данные о текущем источнике

Дополнительная информация о визите, при котором был зафиксирован текущий источник:

Первый источник посетителя

Объекты: sbjs.get.first & sbjs.get.first_add

Всё то же самое, что и sbjs.get.current & sbjs.get.current_add, но относится к самому первому визиту посетителя. Фиксируется один раз, никогда не перезаписывается.

Активная сессия

Информация о текущей открытой сессии посетителя:

Информация о пользователе

Дополнительная информация о пользователе: , ip и браузер:

Промокод

Ограничения

По стандарту при переходе с протокола https на http в реквесте нет реферера, и такие переходы будут определяться модулем как typein (то есть прямые заходы).

Источник

Sourcebuster.js — скрипт определения источников посетителей сайта

С этим скриптом я познакомился несколько лет назад, хотя ему уже более 6 лет. О нем до сих пор знает не такое большое количество человек, а использует в работе еще меньшее количество интернет-маркетологов. Будем восстанавливать эту несправедливость и учиться применять Sourcebuster.js на практике.

Sourcebuster.js — это скрипт определения источников посетителей сайта. Он позволяет отследить, откуда пришел пользователь (с рекламы, органического поиска, социальной сети или другого источника), чтобы впоследствии эту информацию можно было использовать в различных целях. Например, для:

• передачи источника трафика пользователя вместе с его заявкой;
• генерации промокода, который можно выводить на сайте;
• отправки данных по источникам в CRM-систему или другие инструменты аналитики;
• подмены телефонного номера в зависимости от источника трафика;
• подмены заголовков или контента.

Для последних двух у маркетингового агентства it-agency есть отдельный модуль SB-Placer, который подменяет телефонные номера, заголовки и контент в зависимости от источника или тематики рекламной кампании по заданным критериям. И это далеко не все, что данный скрипт умеет!

Alex Fedoseev, автор решения Sourcebuster.js, опубликовал исходный код в открытом доступе у себя на Github. Подробное описание также доступно на сайте it-agency.ru. Там есть много технического описания и различных примеров кода для веб-разработчиков. В этом материале я постараюсь максимально упростить использование данного скрипта и продемонстрировать настройку и примеры того, как я (интернет-маркетолог) использую его в работе.

Но перед тем, как это сделать, я рекомендую прочитать вам несколько материалов, которые позволят упростить понимание и усвоение текущей темы:

Итак, что даст вам скрипт Sourcebuster JS? В качестве примера я хочу продемонстрировать отрывок из моего вебинара по передаче заявок с сайта в Telegram с помощью Google Tag Manager.

Здесь я использую Sourcebuster вместе с GTM для определения источника трафика, а именно 5 переменных UTM, чтобы передавать дополнительную информацию вместе с заявкой в Telegram. Это самый простой прием использования данного скрипта, но он и самый наглядный. Аналогично можно передавать содержимое utm_меток в Google Таблицы, на почту или в любое другое место. Например, Максим Гапчук (автор блога Analytics Tips) в публикации для Ringostat описывает процесс настройки сквозной аналитики с помощью Sourcebuster, Google Таблиц и нескольких JS-кодов без привлечения веб-разработчиков

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

Работа с Sourcebuster.js

Первым делом необходимо скачать сам скрипт по ссылке.

Я даю прямую ссылку на чуть измененный, адаптированный код для GTM, чтобы вам проще было провести все необходимые настройки. Оригинальный код можно скачать на Github по ссылке. Отличие состоит в теге

Источник