Файл: Разработка системы сбора и анализа данных о пользовательском поведении.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.10.2023
Просмотров: 173
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Глава 1. Теоретическое обоснование и актуальность проблематики
Анализ современных систем метрик активности
Глава 2. Исследование проблемы
2.1. Анализ современных систем отслеживания активности пользователя
2.2. Анализ возможных решений для улучшения отслеживания активности пользователей
2.3. Обоснование выбранного решения путем анкетирования
3.1. Общее описание архитектуры системы
3.3. Диаграммы сценариев и последовательностей
3.5. Последовательность интеграции модуля в клиентскую часть пользовательского приложения
3.6. Последовательность интеграции серверной части системы
Система должна иметь следующие компоненты:
JS-модуль, который будет вставляться в веб-проекты и способен отслеживать действия пользователей и информацию об устройствах.
Веб-сервис на C#, который принимает POST-запросы от модуля активности пользователя и сохраняет данные.
Отчеты для анализа данных:
-
Анализ действий: подсчитывать количество раз, когда произошло каждое отдельное действие -
Анализ категорий событий: подсчет количества событий в каждой отдельной категории -
Анализ активности пользователей: показывает метку времени, действие и категорию каждого события, инициированного каждым пользователем. -
Анализ переходов пользователей: возможность отслеживать путь пользователя по веб-сайту, показывая последовательность действий и категорий, связанных с каждым посещенным URL -
Анализ использования устройств: возможность подсчитывать количество пользователей для каждой комбинации операционной системы, браузера и типа устройства.
Данный анализ выражается в следующих отчетах React компонентах: EventAction, EventCategory, UserActivity, UserJourney и DeviceUsage.
Система должна обрабатывать возникающие ошибки во время операции получения данных, такие как проблемы с сетью или ошибки сервера, и записывать эти ошибки для отладки.
Система должна иметь функциональный js-модуль, готовый для развертывания в любом web-приложении.
Полностью функциональный веб-сервис на C# с безопасными API-точками доступа.
Необходимо всегда соблюдать правила безопасности и конфиденциальности данных. Система также должна быть разработана с учетом масштабируемости и обслуживаемости, чтобы адаптироваться к изменениям в поведении пользователей и увеличению нагрузки.
3.3. Диаграммы сценариев и последовательностей
На основе технического задания разработаем сценарии и изобразим диаграммы последовательностей, которые мы определили несколько ключевых сценариев. Каждый сценарий использования представляет определенную последовательность действий, которые пользователь или система выполняют для достижения конкретной цели.
Рис. 19. Сценарий создания объекта
Рис. 20. Диаграмма последовательности создание объекта
Сценарий создания объекта с данными о пользовательском поведении:
-
Система инициирует процесс сбора данных о пользовательском поведении -
Система отправляет запросы, создавая объект, в систему хранения данных -
Компоненты отвечают на запросы, предоставляя необходимую валидацию -
Система сохраняет полученные данные в хранилище для последующего анализа
Рис. 21. Диаграмма сценария создания отчета
Рис. 22. Диаграмма последовательности создания отчета
Сценарий: анализ данных о пользовательском поведении:
-
Система получает данные о пользовательском поведении из хранилища -
Система выполняет определенные аналитические операции для выявления паттернов и тенденций -
Система предоставляет результаты анализа пользователю или другим компонентам системы
Диаграммы сценариев последовательностей помогли лучше понять нужные взаимодействия между компонентами системы, а также последовательность выполнения операций в различных сценариях использования.
3.4. Диаграммы классов
Для разработки диаграмм классов мы провели анализ функциональности системы и выделили ключевые классы
, которые должны быть в системе. Каждый класс представляет определенную сущность.
Объекты модуля сбора данных о пользовательской активности полностью соответствуют модели в серверной части. Код модуля предоставлен в приложении А.
EventData — это основной класс модели, представляющий отдельное событие пользователя в системе. Он содержит информацию о конкретном действии или взаимодействии, выполненном пользователем. Вот свойства класса EventData:
-
EventAction: Строка, описывающая действие пользователя (например, "клик", "прокрутка", "вход в систему") -
EventCategory: Строка, категоризирующая событие (например, "навигация", "отправка формы", "аутентификация пользователя") -
EventLabel: Строка, предоставляющая дополнительные детали о событии (например, идентификатор нажатой кнопки) -
EventTimeStamp: Объект DateTime, записывающий точную дату и время события -
EventUrl: Строка, представляющая URL страницы, на которой произошло событие -
EventUserName: Строка, идентифицирующая пользователя, выполнившего событие -
EventValue: Строка, которая может содержать любое дополнительное значение, связанное со событием -
UserInformation: Объект класса UserInfo, содержащий конкретную информацию о устройстве и окружении пользователя
UserInfo – класс, который предоставляет подробную информацию о устройстве и окружении пользователя. Вот свойства класса UserInfo:
-
UserAgent: Строка, идентифицирующая браузер и операционную систему устройства пользователя -
ViewportWidth: Целое число, представляющее ширину видового экрана пользователя в пикселях -
ViewportHeight: Целое число, представляющее высоту видового экрана пользователя в пикселях -
IsMobile: Булево значение, указывающее, находится ли пользователь на мобильном устройстве -
IsDesktop: Булево значение, указывающее, находится ли пользователь на настольном устройстве -
IsiOS: Булево значение, указывающее, работает ли устройство пользователя на iOS -
IsAndroid: Булево значение, указывающее, работает ли устройство пользователя на Android -
Browser: Строка, идентифицирующая браузер пользователя (например, "Chrome", "Firefox") -
OS: Строка, идентифицирующая операционную систему пользователя (например, "Windows", "Mac OS", "Linux")
Рис. 23. Диаграмма классов модели
Ядром любого приложения является модель. На рис.24 и рис.25 предоставлен исходный код классов модели системы.
Рис. 24. Исходный код класса модели события пользовательской активности
Рис. 25. Исходный код класса модели информации о пользователе, совершившем активность
Серверная часть приложения имеет сервис, работающий с файловой системой для сохранения данных, а также сервис загрузки, для отправки с помощью DTO классов JSON файлы в конкретный отчет.
Рис. 26. Диаграмма классов сервисов обработки пользовательской активности
DTO классы предназначены конкретно для отправки JSON объектов в React компоненты для последующего отображения в графиках. DTO классы отправляют контроллеры, в соответствии с MVC.
Рис. 27. Диаграмма DTO классов для отчетов
Рис. 28. Диаграмма контроллеров
Часть системы, которая отображает данные о пользовательской активности в виде диаграмм, представлена на рис.29. В ней каждый js файл соответствует функциональному компоненту.
Рис. 29. Файлы содержащие компоненты пользовательской активности
Функциональные React компоненты подключаются в index.html как на рис. 30.
Рис. 30. Подключение функционального React компонента
Чтобы функциональный компонент стал доступен внутри главного модуля, в index.html файле, надо его экспортировать через общую области видимости window, как на рис. 31. Экспортировать таким способом не рекомендуется, однако часть системы, предназначенная для отчетности слишком маленькая. Данный способ является проблемой лишь для больших приложений.
Рис. 31. Экспорт функционального React компонента без использования сборщика модулей
Для эффективной отрисовки данных, внутри функционального компонента используется библиотека d3. Способ отображения представлен на рис.32.
Рис. 32. Экспорт функционального React компонента без использования сборщика модулей
Исходные файлы C# серверной части приложения показаны на рис.33.
Рис. 33. Файлы серверной части приложения