Внутренние переходы в «Яндекс.Метрике»: что это значит

Среди многочисленных отчетов «Яндекс.Метрики» отдельного упоминания заслуживают внутренние переходы. «Яндекс» определяет их как заходы со страницы на страницы одного и того же сайта, а также с зеркал, которые полностью или частично копируют основной ресурс.

Можно отключить все остальные источники трафика, оставив данные только по внутренним переходам

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

Из-за чего появляются внутренние переходы

Можно выделить 4 основные причины.

Слишком длинные сессии

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

Он снова садится за компьютер и начинает серфить по другим страницам. В итоге «Метрика» промаркирует его переходы как внутренние, потому что с ее точки зрения это новый визит.

Читайте также:

Что такое сессия на сайте: описание термина, использование, различия у «Яндекса» и Google

Работающий редирект внутри сайта

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

Чтобы понять, установлен ли он на сайте, нужно открыть страницу, которая помечена как источник внутренних переходов, и убедиться, что есть редирект. Не лишним будет и обратиться к браузерной строке. Иногда бывает, что вы остались на прежней странице (например, https://site/pirozhok), а адрес при этом изменился: в нем появились дополнительные параметры (https://site/pirozhok?display_collection2021)/). Они вполне вполне могут использоваться в целях аналитики, акценте на каких-либо элементах страницы и т. д.

Читайте также:

Как сделать редирект — подробное руководство по настройке и использованию

Страницы без установленного счетчика

Вполне может быть, что счетчик «Метрики» был установлен не для всего сайта. Переход со страниц без счетчика на страницы с ним система промаркирует как внутренний.

Читайте также:

Как установить счетчик Яндекс.Метрики

Активированная защита от DDoS-атак

Большинство сайтов записано на серверах компаний-хостеров. Если представители хостинга отмечают хакерские атаки на ресурс, они могут включить их блокировку. В результате еще до открытия страниц ресурса сработают редиректы, и «Метрика» все переходы засчитает как внутренние.

Как избавиться от внутренних переходов

Увеличиваем тайм-аут сессии

Первое, что надо сделать — увеличить тайм-аут сессии с получаса до часа. Нужно значение задается в дополнительных настройках счетчика «Метрики».

Тайм-аут задается в минутах и только целым числом

Учтите, что подобные меры не всегда спасают ситуацию. Например, есть страница товара, которую пользователь закрепил во вкладке с мыслью вернуться к ней через неделю-другую, когда снизится цена.

Выявляем страницы без кода счетчика

1. 
   
   В «Метрике» перейдите по пути «Отчеты» → «Источники» → «Источники, сводка»
   


В обновленном интерфейсе «Метрики» отчет открывается в два клика вместо трех





2. 
   
   Теперь перейдите в отчет «Содержание» и загляните в подраздел «Страницы входа».
   

Всего два клика, и мы попадаем в отчет «Страницы входа»

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

На первом уровне вложенности — страницы, куда переходили пользователи, на втором — источники прямых переходов

Как раз во вложенных страницах и стоит искать веб-страницы без счетчика. Но учтите, что сервис не показывает те страницы, где 100 % не установлен его код. Лучше всего проверить каждую страницу на наличие счетчика и поставить его там, где он отсутствовал. Оптимально сразу ставить счетчик на все страницы сайта.

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

Комплексная веб-аналитика

• Позволяет видеть каждый источник трафика, его качество — процент конверсии по каждой кампании, группе объявлений, объявлению, ключевому слову.
• Даст понимание насколько качественный трафик дает каждый канал, стоит ли в него вкладываться или стоит ограничить.

Что такое внутренние переходы в Яндекс.Метрике

Отчеты по источникам трафика в Яндекс.Метрике дают ответ на вопрос: «Откуда посетители/пользователи — потенциальные и действующие клиенты — приходят на сайт?» А также помогают оценить эффективность каждого канала, составить стратегию продвижения и контент-план, правильно распределить маркетинговый бюджет и так далее. Поисковые и рекомендательные системы, реклама, социальные сети, ссылки на других сайтах, прямые заходы — с этим все понятно. Но что такое внутренние переходы? Давайте разберемся.

Фрагмент отчета по источникам трафика в Яндекс.Метрике, в котором есть данные по внутренним переходам.

А разобраться с другими вопросами веб-аналитики, SEO, SMM, таргетированной рекламы и остальных направлений интернет-маркетинга вам поможет обучающий центр CyberMarketing. У нас есть самые разные образовательные форматы: статьи, вебинары, видеокурсы. Преподают эксперты «Сидорин Лаб», Click.ru, Promopult и др.

Для начала вспомним, как работают базовые показатели (метрики)

Есть просмотры (в GA называются хиты) — они засчитываются, когда посетитель загружает страницу. Есть события — определенные действия пользователя на сайте: загрузки файлов, клики по кнопкам, отправки формы и др. А есть визиты (или сессии) — это совокупная активность посетителя, последовательность тех самых просмотров/событий.

Визит начинается, когда пользователь приходит на сайт и загружает страницу, то есть совершает просмотр. Тогда Яндекс.Метрика «смотрит» на дополнительные параметры: метки и рефереры. Они как раз сообщают, откуда пришел посетитель: с почтовой рассылки, поисковой системы, рекламного объявления или др. В визите может быть несколько просмотров (и событий), но источник трафика определяется по информации, полученной во время первого просмотра.

Допустим, клиент переходит на сайт из Google и читает статью в течение 10 минут. Затем закрывает страницу, то есть покидает сайт, но через 5 минут снова возвращается на ту же статью, только уже напрямую — вставляет ссылку в адресную строку браузера. Источник визита в данном случае все равно поисковая система, а не прямой заход.

Визит заканчивается, когда нет активности, то есть посетитель длительное время (по умолчанию — 30 минут) не совершает никаких действий на сайте. Не переходит на другие страницы, не кликает по кнопкам, не скроллит и так далее. А еще предыдущий визит закончится — и начнется новый — когда пользователь перейдет по ссылке с UTM-метками.

Между прочим, если стандартные 30 минут не устраивают, лимит можно поменять в дополнительных настройках счетчика Яндекс.Метрики.

Когда же источником визита становится внутренний переход

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

Как это может произойти:

1. Посетитель перешел на условную страницу site.ru/page1, затем полчаса бездействовал, снова вернулся к вкладке и перешел уже на site.ru/page2. Тогда источником site.ru/page2 будет именно внутренний переход, так как новый визит начался со страницы того же site.ru.
2. У посетителя не было тайм-аута в 30 минут (или иного, если изменены стандартные настройки), и он переходил от одной странице к другой довольно быстро, просто у site.ru/page1 не оказалось счетчика Яндекс.Метрики. Из-за этого при переходе на site.ru/page2 начался новый визит, а источником стала страница того же сайта — site.ru/page1. Именно поэтому в качестве источника засчитался внутренний переход.

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

2 % внутренних переходов бывают и у коммерческих сайтов, например, нишевых интернет-магазинов.

Если внутренних переходов довольно много, и есть подозрение, что на каких-то страницах действительно отсутствует счетчик, можно сделать так:

1. Открыть кастомный отчет (или стандартный отчет по источникам трафика).
2. Оставить в фильтрах («Визиты, в которых») или сегментах только «Внутренние переходы».
3. Как группировку выбрать «Страницы входа». Потом добавить еще одну группировку — «Реферер», чтобы, помимо страницы, с которой начался визит, узнать источник внутреннего перехода.
4. Для удобства можно поменять их местами: сначала расположить «Реферер», затем «Страница входа».

В данном случае все нормально: за три года — при общем трафике в десятки тысяч визитов — было всего 136 внутренних переходов, значит, со счетчиком на главной странице точно все хорошо.

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

1. Открыть новую вкладку браузера Google Chrome, ввести в адресную строку нужный URL, а в конце добавить специальный параметр ?_ym_debug=1. Например, так: site.ru/page1/?_ym_debug=1
2. Открыть главное меню браузера и перейти на «Дополнительные инструменты → Инструменты разработчика». Или сделать это с помощью сочетания клавиш Ctrl + Shift + J.
3. В консоли должна быть информация о номере счетчика и различных событиях на странице, например, Pageview, который сообщает о факте просмотра. Если все это есть, значит, счетчик работает корректно.

Здесь сразу видно, что счетчик работает, просмотры засчитываются

Читайте также: 20+ ресурсов для обучения веб-аналитике: блоги, курсы, каналы, сообщества, рассылки

Почему внутренние переходы в отчете «Контент» сильно отличаются

Потому что внутренние переходы в контентных отчетах ≠ внутренние переходы в стандартных.

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

Допустим, посетитель приходит из Google на статью site. ru/page1, а затем переходит к чтению site.ru/page2. В обычных отчетах источником трафика для обеих страниц будет поиск, а в контентных отчетах так:

• Источник переходов для site.ru/page1 — поисковая система.
• Источник переходов для site.ru/page2 — уже внутренний переход, так как к просмотру этой страницы привела другая страница этого же сайта — site.ru/page1.

Получается, большое количество внутренних переходов в стандартных отчетах может свидетельствовать о проблемах с кодом счетчика на сайте. А когда много внутренних переходов в отчетах группы «Контент» — все хорошо, значит, посетители активно переходят от одной страницы к другой, положительно влияют на поведенческие факторы. Меньше отказов, больше глубины просмотра, рециркуляции и т. д.

Кстати, с другими похожими метриками — просмотрами (в стандартных отчетах) и просмотрами материалов (в контентных отчетах) — тоже может возникнуть путаница. Дело в том, что обычные просмотры засчитываются при каждой загрузке страницы, это можно увидеть с помощью вышеупомянутого параметра ?_ym_debug=1. А просмотры материалов — более качественные: срабатывают, когда было достаточно долгое нахождение на странице, и она попала в область видимости в рамках браузера пользователя. То есть, если заголовок и обложка занимают много места, пользователю нужно как минимум проскроллить ниже, чтобы просмотр материала был засчитан.

На практике просмотров материалов может быть даже на 30–40 % меньше, чем обычных просмотров

Автоматизация изменения статуса на доске Яндекс Трекера с помощью Яндекс-трекера-действие от Evrone

Яндекс-трекер-действие

Яндекс Трекер похож на сервис Jira тем, что используется для совместной работы над проектами и управления процессами внутри компании. Компании используют Яндекс Трекер для структурирования и реализации проектов, таких как разработка приложений, запуск рекламных кампаний, обработка запросов пользователей, утверждение договоров и многое другое. Яндекс Трекер позволяет менеджерам распределять работу между членами команды и отслеживать их прогресс, а также помогает сотрудникам следить за своими задачами, сроками и приоритетами.

На данный момент Яндекс Трекер не может автоматически перемещать задачи по доске, поэтому приходится перемещать задачи самостоятельно, что не всегда удобно. Например, разработчик может отправить коммит и открыть пулл-реквест, но тогда ему нужно зайти в Яндекс Трекер и вручную изменить статус этой задачи, например, на «На проверку».

У Evrone есть команда, работающая над внутренним проектом ERP, и они начали задаваться вопросом, можно ли автоматизировать этот процесс. Первой идеей, которая пришла в голову для решения этой проблемы, было написать экшен в пайплайне Github, так как, на данный момент, альтернатив этому экшену Github нет. В Яндекс Трекере есть API, к которому можно отправлять запросы, например, «Перевести задачу в другое состояние».

Так вот что делает Яндекс-трекер-действие . Никакой магии — он просто общается с API Яндекса под капотом и перемещает задачу. Теперь, когда мы открываем запрос на вытягивание, у нас выполняется действие, которое перемещает задачу. Когда мы закрываем пул-реквест и объединяем его, задача также переходит в статус «Объединено».

Как работает Яндекс-трекер-действие?

По умолчанию анализирует коммиты вида « [RI-1] реализовать что-то » и принимает номер задачи, который в данном случае равен РИ-1 . Вы также можете ставить задачи прямо в действии, например, указав вывод из предыдущего задания.

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

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

Основное использование

По умолчанию сообщения фиксации, такие как « [RI-1] awesome-feature «, будут проанализированы, где « RI-1 » будет ключом функции. Вы можете указать конкретный ключ задачи, а также можете использовать логику из предыдущего шага задания.

 название: YC Tracker
на:
  pull_request:
    типы:
      - открыт
      - вновь открыт
      - синхронизировать
      - закрыто
вакансии:
 транзитные задачи:
    запуски: ubuntu-последняя
    шаги:
      - название: Касса
        использует: action/checkout@v3
        с:
          ссылка: ${{github.event.pull_request.head.sha}}
      - название: Переместить задачу при открытии PR
        если: github.event.action != 'закрыто'
        использует: evrone-erp/yandex-tracker-action@v1
        с:
          токен: ${{secrets.GITHUB_TOKEN}}
          yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
          yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
          task_url: правда
          игнорировать: ERP-31,ERP-32
      - название: Переместить задачу при слиянии PR
        если: github.event.pull_request.merged == true
        использует: evrone-erp/yandex-tracker-action@v1
        с:
          токен: ${{secrets. GITHUB_TOKEN}}
          yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
          yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
          task_url: правда
          игнорировать: ERP-31,ERP-32 

Добавить специальный ключ задачи

Вы можете указать номера задач, разделенные запятыми.

 - использует: evrone-erp/yandex-tracker-action@v1
  с:
    токен: ${{secrets.GITHUB_TOKEN}}
    yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
    yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
    задачи: RI-218 # или RI-218,RI-11 

Добавить задачи игнорирования

Возможно, вам придется игнорировать некоторые задачи с длительным жизненным циклом. Если у вас есть длительные задачи, которые вы не хотите автоматически перемещать, то можете их игнорировать. Несколько задач должны быть разделены запятыми.

 - использует: evrone-erp/yandex-tracker-action@v1
  с:
    токен: ${{secrets.GITHUB_TOKEN}}
    yandex_org_id: ${{ секреты. YANDEX_ORG_ID }}
    yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
    игнорировать: RI-1 # или RI-1,DI-8 

Комментарий PR с адресом задачи

Если true — будет установлен комментарий к текущему PR с адресом задачи формы в описании PR.

 - использует: evrone-erp/yandex-tracker-action@v1
  с:
    токен: ${{secrets.GITHUB_TOKEN}}
    yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
    yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
    task_url: правда 

Получить все доступные переходы

По умолчанию, если PR открыт, задача перейдет в состояние in_review . Если PR объединены, состояние будет , разрешение . Вы можете указать удобочитаемое имя или имя конечной точки.

Получить все доступные состояния:

 curl -H "Авторизация: OAuth " -H "X-Org-ID: " -H "Content-Type: application/json" https: //api. tracker.yandex.net/v2/issues//transitions | jq ".[].id" 

Посмотреть вывод действия и найти состояния:

 - использует: evrone-erp/yandex-tracker-action@v1
  с:
    токен: ${{secrets.GITHUB_TOKEN}}
    yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
    yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
    to: 'На ревью' # или 'in_review' 

Один ход, если PR открыт, и один ход, если он объединен

Вы можете перемещать задачу при открытии PR и при объединении PR в разные переходы. См. имена состояний по умолчанию выше.

 - имя: Переместить задачу при открытии PR
  если: github.event.action != 'закрыто'
  использует: evrone-erp/yandex-tracker-action@v1
  с:
    токен: ${{secrets.GITHUB_TOKEN}}
    yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
    yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
    в: 'in_review'
- название: Переместить задачу при слиянии PR
  если: github.event.pull_request.merged == true
  использует: evrone-erp/yandex-tracker-action@v1
  с:
    токен: ${{secrets. GITHUB_TOKEN}}
    yandex_org_id: ${{ секреты.YANDEX_ORG_ID }}
    yandex_oauth3_token: ${{ секреты.YANDEX_OAUTh3_TOKEN }}
    в: "объединить" 

Планы на будущее

Разработка Яндекс-трекера-акции началась совсем недавно и продолжается до сих пор, но в конечном итоге мы хотели бы включить дополнительные опции, которые могут понадобиться другим компаниям. Поэтому в ближайшее время мы планируем выпустить новую реализацию и использовать Яндекс-трекер-действие на клиентских проектах.

У каждой компании свои бизнес-процессы, и действия должны быть адаптированы к желаемым статусам каждого бизнеса. Например, когда мы открываем пулл-реквест, мы переводим задачу в состояние «На проверку», но, возможно, в другой компании этот процесс построен по-другому, и они переносят задачу в другое поле.

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

Если вы ищете инструмент для автоматизации ваших бизнес-процессов, мы можем помочь вам разработать полезное решение — в Яндексе или в другом продукте или услуге. Просто отправьте нам сообщение, используя форму ниже, и мы свяжемся с вами, чтобы обсудить детали и посмотреть, как мы можем сотрудничать с вами для совместной разработки полезного проекта.

Нам было интересно поработать с этим действием и лучше понять, как все работает в Яндекс Трекере. В конечном итоге мы поняли, что таким образом можно создавать любые функции, и надеемся использовать полученные знания для разработки более полезных функций в будущем.

Когда Яндекс ведет себя странно — Обнаружение роботов-пауков с помощью Striim

Ф. Кларк, аналитик SOC, Striim

Домо аригато, г-н Робото,
Mata ah-oo hima de
Domo arigato, Mr. Roboto,
Himitsu wo shiri tai

Время от времени аналитику приходится смотреть на уникальные вещи, которые вызывают интерес и чтобы день прошел быстрее. (В другие дни есть кофе.) Когда администратор веб-сервера подошел к моему столу, я как раз собирался поставить еще один кофейник. Я решил воздержаться.

Наш админ пришел ко мне с небольшой загадкой. Хотя ежедневно на нашем веб-сайте просматривается множество известных роботов, один из них ему не понравился. Он назывался Яндекс, российская поисковая система. Учитывая количество вредоносного ПО и других нежелательных вещей, исходящих из российских сетей, администратор был обеспокоен доступом этого индексатора к нашему сайту. С широкой улыбкой я отложил кофе и потянулся за своим зеленым чаем с медом и сердечно ответил: «Я готов».

ПЕРВЫЕ ШАГИ

Первое, что мне нужно было сделать, это перенести наши веб-журналы в место, где я мог бы использовать Striim для их анализа. По моей просьбе администраторы внедрили SYSLOG-NG и использовали центральный репозиторий для всех наших журналов, что значительно упростило доступ к ним с помощью Striim. Наши основной и резервный веб-серверы в рабочей среде находились в каталогах /var/log/www-prod-1 и /var/log/www-prod-2 в центральной системе ведения журналов. Оттуда все, что мне нужно было сделать, это ввести их в Striim, и мы могли начать веселиться. Из пользовательского интерфейса я сделал пару текстовых ридеров и настроил их для получения данных из журналов доступа с обоих производственных серверов.

Следующим шагом был анализ файлов журналов, чтобы информация из файлов журналов была организована в поля, которые можно было обрабатывать. Небольшой взмах палочки REGEX, и мы проанализировали оба журнала и объединили их в единый поток для анализа Striim.

Затем я создал панель инструментов, чтобы показать мне только информацию, связанную с веб-запросами от Яндекса. Это дало бы мне четкое и актуальное представление данных, которые мне нужны, в режиме реального времени. Быстрый TQL-запрос в сочетании с таблицей, и я уже в пути!

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

Как сказала бы Дороти Паркер: «Что это за новый ад?» Паук делал GET-запрос к поисковой системе нашего сайта! Это ненормальное поведение для паука, если все, что он делает, это индексирует наш сайт. Небольшая магия аналитика, примененная к этому запросу, показала, что он использовал нашу собственную функцию поиска по сайту для поиска «Fun HB Slot Machine» и домена qpyl18.com. Быстрая проверка этого домена показала, что он [защищен Cloufflare (Привет, Отто!)], но на исходном сервере возникли проблемы. Быстрая проверка задействованных IP-адресов, и мои паучьи аналитические чувства затрепетали.

Следующим животрепещущим вопросом было, как часто это происходило и с какой громкостью? Вернуться к приборной панели я пошел! Я изменил свой запрос, чтобы показать запросы, которые выполняли внутренний поиск, и был быстро вознагражден информацией, которую я искал:

Это не только случалось, но случалось часто.

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

Как и любой хороший аналитик, я собирал данные в течение 60 дней, а затем представил их веб-администратору, и мы оба решили, что это не то, что нам нужно в нашей сети. Несколько настроек веб-сервера, брандмауэра и IDS, и мы отправились на праздничный обед.

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

This entry was posted in Популярное