FunnelFlux имеет три основных навигационных действия, которые происходят:
- Загрузка входной ссылки:
/fts/ - Загрузка ссылки действия:
/action/x - Отслеживание просмотра страницы с помощью JS: POST запрос на
/js/funnel
Входные ссылки довольно строгие и содержат все необходимые данные для перенаправления в пункт назначения (так как вы бы сгенерировали их в нашем пользовательском интерфейсе), и если они работают, они пойдут точно туда, где указано, игнорируя любую другую контекстную историю, поскольку входная ссылка является автономным, новым входом в воронку.
В последних двух случаях, FunnelFlux Pro edge использует доступную информацию для определения на какой ноде/странице находится пользователь и, в случае действий, по какому соединению двигаться.
Это может быть подвержено проблемам, если не настроено правильно, поэтому в этом разделе будет обобщено, как JavaScript и ссылки действий определяют текущую страницу и исходную страницу/ноду, соответственно.
Логика ссылок действий
Ссылки действий всегда выполняют пронумерованное действие, исходящее из ноды, на которой, как они думают, находится посетитель.
При тестировании воронки и навигации полезно рассмотреть диаграмму воронки и то, как каждое действие приводит к переходу от одной ноды к следующей, отслеживая, на какой ноде вы находитесь (т.е. на какой, по мнению трекера, вы находитесь).
Рассмотрим ситуацию, когда вы переходите на страницу > нажимаете ссылку действия > она открывается в новой вкладке. Вы возвращаетесь на исходную вкладку и снова нажимаете ссылку. Теперь вы инициируете действие с предыдущей ноды, которая находится перед текущей известной позицией ноды.
Рассмотрим второй сценарий, но где ссылка действия не открывается в новой вкладке. Затем вы нажимаете кнопку "назад" в вашем браузере, загружая предыдущую страницу. Если на этой странице нет JS для отслеживания просмотров, трекер не знает, что вы вернулись на нее. Если вы сейчас нажмете ссылку действия, вы снова инициируете действие с предыдущей ноды.
В обоих случаях трекеру нужен какой-то механизм для определения этих повторных кликов, путем определения исходной ноды клика.
Обработка реферера
При загрузке ссылки действия наш edge проверяет реферер.
Если этот реферер содержит VID, edge теперь осведомлен о сессии посетителя (без необходимости в куках).
Если этот реферер содержит полный URL страницы, трекер теперь может сопоставить этот URL с известными нодами/страницами в воронке, а также с ранее посещенными страницами, чтобы определить, что клик пришел со страницы, которая уже была посещена (необходимое событие для существования клика).
Если реферер содержит параметр n=NODE_ID в URL, трекер теперь может точно определить исходную ноду, не полагаясь на сопоставление URL страницы. Это более специфично, так как одна и та же страница может использоваться несколько раз в одной воронке (с разными ID нод), или страница может быть встроена в iFrame, где родительский URL и, следовательно, реферер не представляют загруженную страницу.
Вот почему наш JavaScript имеет две вспомогательные функции:
Одна, которая проверяет тег <meta name="referrer"> на странице и, если он присутствует, обновляет его значение на no-referrer-when-downgrade, а если его нет, создает его.
Вторая функция, которая переписывает текущее местоположение страницы, чтобы включить ID посетителя и ID текущей ноды в URL, делая полное значение реферера очень информативным для обработчика ссылок действий.
Учитывая это, следует избегать добавления атрибутов rel="noreferrer" к ссылкам. Это бессмысленно -- скрывать информацию от собственной системы отслеживания!
Нюанс со страницами, размещенными на корневом домене
Интересный нюанс может возникнуть, когда полный реферер не передается.
Рассмотрим воронку, которая имеет начальную целевую страницу A на https://domain.com (т.е. корневой домен/домашняя страница), которая соединяется со второй страницей B с URL https://domain.com/some-page/
В браузере пользователь загрузит страницу A и успешно перейдет на страницу B.
Однако на странице B, если полный реферер не передается, следующий клик по действию может передать усеченный реферер (только имя хоста). Наш edge тогда видит клик, явно возникший с "domain.com".
Уникально, поскольку пользователь использовал свой корневой домен как страницу, этот реферер является известным URL/путем предыдущего лендинга, поэтому трекер правомерно определит, с учетом предоставленной информации, что это фактически повторный клик со страницы A.
Это приводит к циклу перенаправлений страница A > клик > страница B > клик > страница B > клик страница B
Прямая инъекция параметров URL
Еще одна из наших вспомогательных функций JS будет обнаруживать элементы <a> на странице, где href содержит /action, затем внедрять:
...&vid=VISITOR_ID&rn=CURRENT_NODE_ID
Если это происходит, информация о реферере не используется, так как прямо указанные параметры URL имеют приоритет.
Можно утверждать, что функции реферера и перезаписи URL могут быть полезны -- но это не так.
Есть много ситуаций, когда пользователи могут добавлять JS-код на страницу, но не используют простые элементы <a> для перенаправления на следующую страницу. У них могут быть элементы <a>, но которые напрямую ссылаются на другие страницы, где они не могут вставлять параметры в эти URL. Перенаправления на URL действий также могут управляться JavaScript, где пользователь имеет мало входных данных или динамического контроля.
В любом случае, параметр "rn" явно указывает нашему edge, что клик исходит с определенной ноды для соответствующего посетителя. Это наиболее надежный способ гарантировать надежное отслеживание.
В продвинутых случаях, когда перенаправление на ссылки действий не включает простые элементы <a>, а манипуляции JavaScript, мы бы рекомендовали использовать функцию onDone() в нашем JS для отслеживания просмотров.
Вы можете использовать это для получения текущего ID ноды и ID посетителя, затем вставить их в любые функции, которые управляют перенаправлением > вручную добавить ранее упомянутые параметры URL к URL действия, предоставляя ту же выгоду.
Параметры действий по умолчанию
Их можно включить при использовании пункта контекстного меню "получить ссылку действия" в конструкторе воронок.
Они доступны только здесь, так как должны быть специфичны для воронки и ноды.
Этот переключатель предназначен только для генерации, он не применяет никакого конкретного эффекта к самой воронке/ноде.
Эти URL объявляют ID воронки и ноды по умолчанию, например:
https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number
Важно отметить, что эти значения НЕ являются переопределениями, они будут использоваться только для запроса ссылки действия, где значение VID неизвестно, т.е. для нового или неизвестного посетителя.
Таким образом, они будут работать в инкогнито-окне, тогда как общие/универсальные ссылки действий без контекста не будут.
В 99% случаев эти резервные параметры не используются -- но есть несколько сценариев, где они полезны, если не критически важны:
- При отправке форм, которые перенаправляют через какую-то третью сторону перед возвращением на URL перенаправления, установленный в этой третьей стороне. Здесь, из-за случайных переходов, которые вы не контролируете, если вы использовали общую ссылку действия, она, вероятно, загрузится и не будет иметь полезной информации о реферере (только информацию от случайной сторонней системы). Edge сможет использовать только куки для определения VID (ненадежно!), поэтому параметры по умолчанию будут важны, чтобы хотя бы довести пользователя до ожидаемого места назначения, даже если его сессия потеряна и он отключен от своего оригинального входа в воронку. Если третья сторона могла бы принимать и передавать параметры URL дальше, отлично! Но во многих случаях это недоступно...
- Когда вы отправляете пользователей на какую-то страницу, где им нужно кликнуть на ссылку действия, но по какой-то причине невозможно контролировать код страницы, чтобы внедрить наш JS, который помог бы передаче реферера/данных
- Когда пользователи могут перейти с известной, отслеживаемой страницы на какие-то другие страницы, а затем вернуться на известную страницу -- например, через поток вебинара, где вы, вероятно, потеряете отслеживание сессии, но все еще хотите отслеживать некоторые финальные действия/клики и обеспечить, чтобы посетители все еще перенаправлялись в предполагаемое место назначения
Другими словами, эти ссылки действий полезны во всех раздражающих ситуациях, когда у вас нет контроля над тем, чтобы сделать отслеживание надежным, и вы можете ожидать нулевую надежность передачи реферера/кук/данных, но все еще хотите, чтобы люди загружали ссылку, которую вы контролируете в какой-то более поздний момент.
Логика отслеживания просмотра страницы JavaScript
Событие отслеживания просмотра страницы через наш JS имеет только два источника данных - текущий URL (и его строку запроса) и встроенные атрибуты.
Параметры URL всегда имеют приоритет. Таким образом, страница может встраивать JS с выбранными ID по умолчанию, но входные ссылки, сгенерированные в нашем пользовательском интерфейсе, всегда будут отслеживаться как ожидается, переопределяя эти значения.
В случае прямых ссылок, параметры строки запроса URL переопределяют значения JS по умолчанию.
В случае ссылок перенаправления, результирующая страница загружается без таких параметров, но с внедренным значением vid=VISITOR_ID.
Этот VID передается в POST-запросе JS и, таким образом, возвращает уже известный ID ноды, на которую переходит пользователь, который затем переопределяет значения JS по умолчанию.
Вот некоторые другие сценарии и результирующее поведение:
- Ссылка перенаправления загружает страницу, которая имеет JS, но без встроенных значений по умолчанию. Здесь VID будет присутствовать в URL и будет использован, а URL страницы будет использован для определения текущей страницы. Это, вероятно, будет соответствовать месту назначения, куда перешло перенаправление, в результате чего не будет создано дополнительного просмотра страницы (дедупликация)
- Страница загружается без параметров URL и JS без установленных встроенных параметров. Отслеживание просмотра не удастся, так как ID воронки всегда должен быть передан -- оно будет работать только если присутствует VID для определения сессии, которая будет содержать текущий ID воронки.
- Ссылка перенаправления загружает страницу, которая содержит JS с встроенными параметрами, которые не соответствуют текущей сессии/воронке. В этом случае VID будет известен и будет иметь приоритет, так что воронка не изменится. Просмотр ожидаемой страницы уже был создан перенаправлением, и событие просмотра JS автоматически отследится с соответствием URL. Если JS указывает ID страницы, который не соответствует странице, которую обслужило перенаправление, это может вызвать отдельный аномальный просмотр, если объявленный ID страницы существует в текущей воронке (иначе это вызовет ошибку)
- Параметры URL отсутствуют. Используются встроенные параметры, но с указанным ID страницы, который не существует в текущей воронке. Просмотр не будет отслежен.
- Параметры URL отсутствуют. Встроенные параметры используют ID ноды, который не существует в объявленном ID воронки. Просмотр не будет отслежен.
- Параметры URL отсутствуют. Присутствует ID страницы, но текущий URL не соответствует этому ID страницы. Edge будет учитывать ID страницы, игнорируя соответствие URL. Это позволяет iframing/встраиванию функционировать как ожидается.