Действия пользователей¶
- Explanation
- 12-min read
Действие пользователя -- это взаимодействие с интерфейсом конечного пользователя, которое включает вызов веб-сервера с возможными множественными вложенными вызовами. Это переход от одного представления к другому, инициированный пользовательским вводом, например загрузка страницы, клик или касание.
Типы действий пользователей для веб-приложений¶
Веб-приложения
Следующие типы действий пользователей доступны в Dynatrace для веб-приложений:
Ключевое различие между этими типами действий заключается в способе расчёта продолжительности действия и списке доступных метрик.
Действия загрузки¶
Действие загрузки определяется как фактическая загрузка страницы в вашем браузере. Если вы вводите URL в браузере и нажимаете Enter, происходит действие загрузки. Во время этого типа действия загружается множество ресурсов, включая изображения, HTML и CSS.
Продолжительность действия загрузки¶
Продолжительность действия -- это время, необходимое для полного действия загрузки. Более конкретно, время начала действия пользователя равно времени W3C navigationStart. Если этот атрибут недоступен, время начала равно времени инициализации RUM JavaScript в браузере. Время окончания -- это момент завершения работы последнего обработчика onload. Обработчик onload -- это обработчик событий в JavaScript, который вызывает выполнение JavaScript после полной загрузки страницы, фрейма или изображения. Если обработчик onload инициирует какие-либо XMLHttpRequests, действие пользователя завершается, когда XMLHttpRequest будет выполнен.

Тайминги действия загрузки¶
Следующие показатели используются для отображения продолжительности отдельных этапов процесса действия загрузки.
XHR-действия¶
Dynatrace непрерывно отслеживает взаимодействия пользователей с каждой страницей. Если взаимодействие пользователя приводит к вызовам XmlHttpRequests или fetch(), создаётся XHR-действие. Dynatrace также определяет, есть ли дополнительные XHR, инициированные в обратном вызове начального XHR, и так далее. В этом случае Dynatrace ожидает завершения всех запросов. Мониторя DOM, Dynatrace также может определить ресурсы, добавленные в обратных вызовах. Затем Dynatrace ожидает завершения загрузки этих ресурсов, прежде чем завершить действие.
XHR-действие начинается с клика пользователя на элемент управления на веб-странице. Все метрики рассчитываются относительно этого момента времени и основаны на начальном XHR, который инициирует действие пользователя.
По умолчанию RUM захватывает определённые типы взаимодействий. Вы можете настроить RUM для обнаружения ещё большего количества типов взаимодействий. Подробнее см. Захват дополнительных типов взаимодействий для веб-приложений.
XmlHttpRequest¶
Большинство современных приложений, включая одностраничные приложения, полагаются на одно действие загрузки, которое загружает фреймворк и инициализирует страницу. После этого DOM страницы изменяется через JavaScript, и вся коммуникация с веб-сервером осуществляется через XmlHttpRequest.

Fetch API¶
Fetch API предоставляет интерфейс для получения ресурсов, включая ресурсы по сети. Он аналогичен XMLHttpRequest, но API предоставляет более гибкий набор функций. Общие определения Request, Response и других объектов сетевых запросов в Fetch позволяют использовать их в любое время, будь то для service workers, Cache API или чего-либо ещё, что обрабатывает или модифицирует запросы и ответы. Fetch также поддерживает Cross Origin Resource Sharing (CORS).
Действия пользователей, основанные на Fetch API, отображаются в Dynatrace как XHR-действия. Вы можете настроить RUM для автоматического обнаружения и захвата информации о запросах Fetch API.
Пользовательские действия¶
Вместо того чтобы полагаться на автоматическую генерацию действий пользователей, вы можете захотеть более тонко настроить Real User Monitoring, добавив дополнительные действия пользователей непосредственно в HTML вашего приложения. Это может быть полезно, если наша автоматическая генерация действий пользователей не улавливает определённые действия или вы хотите ввести определённые точные тайминги в мониторинг вашего приложения. Например, вы можете измерить, сколько времени занимает открытие раскрывающегося меню на JavaScript, или измерить продолжительность выполнения некоторого JavaScript-кода. Для определения пользовательских действий используйте RUM JavaScript API.
Продолжительность действия пользователя¶
Ниже вы найдёте информацию о максимальной продолжительности действия пользователя в Dynatrace и составляющих действия пользователя для веб-приложений.
Максимальная продолжительность действия пользователя¶
Максимальная продолжительность действия пользователя зависит от типа приложения.
Веб-приложение
Мобильное приложение
Пользовательское приложение
Максимальная продолжительность веб-действия пользователя составляет 3 минуты. Если действие пользователя занимает больше времени, Dynatrace сообщает о таком действии как о 3-минутном действии.
Максимальная продолжительность мобильного действия пользователя зависит от типа действия.
- Автоматически генерируемые действия
По умолчанию максимальная продолжительность мобильного автоматически генерируемого действия пользователя составляет 1 минуту. Вы можете увеличить этот лимит до 9 минут, хотя мы не рекомендуем этого делать. Для Android см. Настройка мониторинга действий пользователей; для iOS используйте ключ конфигурации DTXAutoActionMaxDurationMilliseconds.
Если автоматически генерируемое действие пользователя занимает больше настроенной максимальной продолжительности, такое действие закрывается и передаётся в Dynatrace с продолжительностью, немного превышающей настроенный максимум. * Пользовательские действия
Максимальная продолжительность мобильного пользовательского действия составляет 9 минут.
Если пользовательское действие занимает более 9 минут и не закрыто, такое действие отбрасывается и не передаётся в Dynatrace.
Максимальная продолжительность действия пользователя в пользовательских приложениях составляет 10 минут. Если действие пользователя занимает больше времени, такое действие отбрасывается и не передаётся в Dynatrace.
Составляющие действия пользователя для веб-приложений¶
Продолжительность действия пользователя может быть разбита на три компонента:
- Время сервера: время, затраченное на серверную обработку страницы
- Время сети: время, затраченное на запрос и получение ресурсов (включая время DNS-поиска, перенаправления и TCP-соединения)
- Время фронтенда: время, затраченное браузером на отрисовку страницы
Эти компоненты составляют общую продолжительность действия пользователя.
Продолжительность действия пользователя рассчитывается следующим образом.
Продолжительность действия пользователя = (loadEventEnd или endTimeOfLastXHR) - actionStart
В этом расчёте
actionStart
: navigationStart для загрузок страниц или "время клика" для XHR-действий и пользовательских навигаций, таких как клик по кнопке или ссылке
endTimeOfLastXHR
: Когда XHR-вызовы инициируются в процессе и не завершены до loadEventEnd, вместо времени loadEventEnd используется время окончания последнего XHR-вызова.
Составляющие действия пользователя рассчитываются следующим образом.
Время сервера = responseStart - requestStart
Время сети = (requestStart - actionStart) + (responseEnd - responseStart)
Время фронтенда = Продолжительность действия пользователя - Время сервера - Время сети
Смотрите примеры составляющих действия пользователя ниже.
Составляющие действия пользователя для отдельного экземпляра действия пользователя в рамках пользовательской сессии

Составляющие действия пользователя, агрегированные для одного действия пользователя, то есть по всем экземплярам действия пользователя

Составляющие действия пользователя, агрегированные для всего приложения

Правила именования действий пользователей¶
Многие приложения позволяют пользователям достигать одной и той же цели с помощью различных элементов UI и следуя различным путям. При мониторинге таких приложений бывает сложно отличить действия, которые имеют одинаковый результат и цель, но выполняются с помощью разных частей UI приложения. Точно так же, если приложение переведено на несколько языков, одна и та же функция приложения или элемент UI может отображаться под разными именами. С помощью правил именования действий пользователей Dynatrace может обнаруживать такие тонкие различия и интеллектуально группировать действия пользователей, достигающие одной цели, в логические группы для мониторинга.
Dynatrace автоматически удаляет определённые распространённые токены sessionid из имён действий пользователей, например jsessionid для Java-контейнеров, стандартный sessionid для PHP и CFID и CFTOKEN для ColdFusion. Тем не менее существуют многочисленные варианты идентификаторов сессий, которые могут присутствовать в вашей среде. Если Dynatrace автоматически не распознаёт и не удаляет идентификаторы сессий из определённых имён действий пользователей, вам потребуется настроить пользовательские правила именования для ваших веб-, мобильных и пользовательских приложений.
При настройке пользовательских правил именования для ваших веб-, мобильных и пользовательских приложений помните, что ввод в разделах Add placeholder и Add naming rule чувствителен к регистру. Только уже настроенное имя действия пользователя может быть установлено как нечувствительное к регистру.
Дочерние действия¶
Дочерние действия -- это действия, присоединённые к основному, или родительскому, действию пользователя. Вы можете создавать дочерние действия для веб-, мобильных и пользовательских приложений.
Для веб-приложений вы можете создавать дочерние действия с помощью RUM JavaScript API, а именно метода enterXhrAction.
Для мобильных и пользовательских приложений Dynatrace предлагает API-метод для создания дочернего действия.
Android SDK iOS SDK Xamarin .NET MAUI Flutter React Native OpenKit
Возможная вложенность дочерних действий зависит от типа приложения и используемой технологии.
Веб-приложения
Нет ограничений на количество дочерних действий, присоединённых к родительскому действию, и нет ограничений на количество уровней вложенности.
Однако обратите внимание, что дочерние действия не отображаются на странице деталей пользовательской сессии, и вложенность дочерних действий не сохраняется на странице каскадного анализа для родительского действия, к которому эти дочерние действия присоединены.
Android, iOS
Нет ограничений на количество дочерних действий, присоединённых к родительскому действию. Однако обратите внимание, что вы можете иметь только девять уровней дочерних действий -- вы можете создать одно родительское действие и девять уровней дочерних действий (когда дочернее действие A добавляется к родительскому действию, дочернее действие B добавляется к дочернему действию A, дочернее действие C добавляется к дочернему действию B и т.д.). Также см. Структура пользовательской сессии для отдельного пользователя.
Дочерние действия не отображаются на странице деталей пользовательской сессии, но вы можете просмотреть их на странице каскадного анализа для родительского действия, к которому эти дочерние действия присоединены. Несмотря на то что вложенность дочерних действий не полностью сохраняется в представлении каскадного анализа и все дочерние действия отображаются как дочерние действия уровня 1, вы всё равно можете понять вложенность действий по таймингам.
Flutter, React Native, Xamarin, .NET MAUI, OpenKit
Нет ограничений на количество дочерних действий, присоединённых к пользовательскому действию. Однако обратите внимание, что вы можете иметь только один уровень дочерних действий -- вы не можете создать дочернее действие для другого дочернего действия (дочерние действия не могут иметь собственных дочерних действий). Также см. Структура пользовательской сессии для отдельного пользователя.
Дочерние действия не отображаются на странице деталей пользовательской сессии, но вы можете просмотреть их на странице каскадного анализа для пользовательского действия, к которому эти дочерние действия присоединены.
Ключевые действия пользователей¶
Большинство приложений содержат действия пользователей, которые особенно важны для успеха вашего цифрового бизнеса. Примерами таких действий являются регистрация, оформление заказа и поиск продуктов. Такие ключевые действия пользователей могут выполняться дольше других, или к ним может предъявляться требование более короткой, чем средняя, продолжительности.
Например, предположим, что вы установили глобальный порог Apdex в 3 секунды. Хотя этот порог может быть приемлемым для большинства действий пользователей, он может быть неприемлемым для действия регистрации. Или может существовать действие поиска, которое довольно сложное и требует больше времени, чем отведённые 3 секунды.
Вы можете отметить действие пользователя как ключевое и настроить рейтинг Apdex для ключевых действий пользователей в настройках вашего веб-, мобильного и пользовательского приложения.
Связанные темы¶
- Создание пользовательских имён действий для веб-приложений
- Создание пользовательских имён действий для мобильных приложений
- Создание пользовательских имён действий для пользовательских приложений
- Настройка ключевых действий пользователей для веб-приложений
- Настройка ключевых действий пользователей для мобильных приложений
- Настройка ключевых действий пользователей для пользовательских приложений