Любая компания или отдел, которые ценят данные, не будут игнорировать роль интерфейсной отчетности по данным.
Интуитивно понятно, что такого сложного в плане предварительной отчетности? Разве это не просто сбор данных о поведении пользователей?
Чтобы ответить из реального опыта разработки: на самом деле это не так просто. Чтобы иметь возможность, наконец, отображать и анализировать собранные пользовательские данные для получения значимых данных, требуется больше деталей, чем предполагалось.
В этой статье мы рассмотрим процесс представления данных о скрытых точках с двух аспектов: сбор данных и представление данных.
сбор информации
В процессе сбора данных мы не будем проводить различие между методами представления данных (такими как отчеты об общих скрытых точках и отчеты об отсутствии скрытых точек) и сосредоточимся на технических моментах, которые являются общими независимо от того, какой метод отчетности используется. Сосредоточьтесь на следующих основных данных: UV, PV и общее время просмотра приложений.
UV
У UV есть два статистических параметра: зарегистрированные пользователи и незарегистрированные пользователи.
Зарегистрированный пользователь — это хорошо, вам нужен только уникальный идентификатор зарегистрированного пользователя в приложении.
Для незарегистрированных пользователей, как определить, что это пользователь? В таком случае возникает вопрос: как идентифицировать устройство?
Как идентифицировать устройство?
Проще всего придумать, как воспользоваться возможностями хранения браузера: куки, localStorage и т. д. Конкретный метод заключается в том, чтобы поместить UUID (например, случайно сгенерированную строку) в хранилище, когда пользователь загружает страницу в первый раз.Это решение является самым простым, среди которых:
Файлы cookie имеют ограничение по времени жизни и размеру.
localStorage сохраняется навсегда и намного больше, чем файлы cookie с точки зрения емкости.
Таким образом, использование localStorage будет более эффективным, чем файлы cookie. Однако решение, основанное на функции хранения браузера, имеет врожденный недостаток:Пользователи могут выбрать активное удаление хранилища.
В этот момент разработчики задаются вопросом: возможно ли иметь действительно уникальный идентификатор, связанный с устройством?
Так что естьТехнология отслеживания отпечатков пальцев в браузере: Подобно внешнему виду и отпечаткам пальцев людей, веб-клиент (в данном случае в основном браузер) также имеет различную информацию о «внешнем виде» и «отпечатках пальцев». После всестороннего анализа и расчета этой информации клиент может быть однозначно идентифицирован и затем заблокирован. , отслеживайте и анализируйте поведение и данные о конфиденциальности пользователей сети.
В WA другая внутренняя библиотека отслеживания на основе отпечатков пальцев браузера упоминается как уникальный идентификатор для идентификации доступа к тому же браузеру. После консультации с разработчиком библиотеки установлено, что технология браузерного отпечатка плохо работает в практических приложениях (очень высока вероятность нераспознания):
前提一： 只针对浏览器，换了浏览器即使同设备，id也不一样。
前提二： 用ip区分用户，不同ip认为是不一样的用户。
统计结果： 18年我们在生产环境做了测试，ios 7800个用户中，有22%的用户id未发生重复id。安卓15000个用户中，有39%未发生重复id。
原因分析： 因为浏览器拿不到设备底层数据，只能通过一些浏览器的配置参数去生成id。如果用户手机系统 型号 浏览器版本和相关配置一样，那生成的就一样。
В заключение
После всестороннего рассмотрения мы отказались от технологии отслеживания отпечатков пальцев в браузере. В разработанной нами схеме скрытых точек метод UV-статистики незарегистрированных пользователей использует схему имплантации UUID в localStorage.
PV
Когда страница меняется, мы увеличиваем количество PV на 1. Для этого мы хотим спросить: Откуда вы знаете, что страница изменилась?
Этот вопрос можно разделить на два подвопроса:
- Может ли сам браузер полностью знать, что страница изменилась?
- Может ли сам разработчик знать, что страница изменилась?
Второй вопрос, ответ - да. Разработчик, конечно, знает, когда страница изменилась. Но первый вопрос, при рассмотрении того, может ли браузер знать, что страница изменилась, возникает интересный момент:
Является ли изменение страницы, которое браузер считает нужным изменением страницы?
Для многостраничных приложений вы можете прослушивать события window.onLoad и window.onunload или прослушивать изменение URL-адреса onhashchange. Изменение страницы, которое браузер считает нужным изменением страницы.
Как насчет одностраничных приложений? Это не обязательно так.
Поскольку это одностраничное приложение, будет запущено только одно событие загрузки страницы. То есть этого нельзя добиться прослушиванием событий window.onLoad и window.onunload.
Итак, можно ли прослушивать изменения URL? Если в приложении есть несколько вложенных маршрутов, изменение URL-адреса не обязательно означает, что страница изменилась.
Что нам делать в это время? Давайте посмотрим, что делают крупные производители:
Для статистики PV в одностраничных приложениях в основном предусмотрены следующие методы:
1.информация о конфигурации: включить ли автоматический сбор страниц на основе изменений URL.
2.Ручная эскалация: Предоставляет интерфейс для активного сообщения об изменениях страницы.
Поэтому в нашей реализации он тоже основан на этой схеме.
Общее время просмотра приложения
В статистической фазе времени просмотра приложений ключевым моментом является то, как точно понять, что приложение закрыто. Давайте посмотрим на нормальное и ненормальное.
обычный: при обычном завершении работы приложения мы можем прослушивать событие window.onunload.
необычный: А как насчет нештатных ситуаций? Например эти:
-
Сбой браузера
-
Когда пользователь долго не работает (например, смотрит видео), браузер внезапно падает.
-
Клиентская часть страницы/апплета H5 аварийно завершает работу/убивается
Как быть в этих нештатных ситуациях?
Рекомендуемое решение:WebSocket. Интерфейсный SDK устанавливает постоянное соединение через веб-сокет с серверной частью. Обнаружение сердцебиения в соединениях через веб-сокеты — обязательная опция для борьбы с нестабильностью сети. Когда приложение закрывается, сервер может знать событие закрытия. Недостатки: схема WebSocket имеет определенные проблемы с совместимостью.
(ps: более подробные принципы webSocket лично не реализованы)
В нашем приложении данные сообщаются на основе WA. Он не обеспечивает такого постоянного подключения к веб-сокету. Что мы можем сделать по этому поводу?
В настоящее время делает это:
Мысль: в случае, если клиент убит или аварийно завершает работу, на самой веб-странице нет подходящих событий для точного отслеживания.
Затем приблизительная идея для подхода: в существующей схеме, путем установки регулярного отчетного события подходящей продолжительности (Отчет о времени сердцебиения), Получив последнее время отчетов, это сеанс, пользователь может быть понятен, чтобы быть приблизительным близким (максимальная ошибка интервала отчетов о сердцебиении).
Для реализации этой схемы необходимостатистика данныхСотрудничество: при расчете общей продолжительности приложения необходимо учитывать фактор пульса.
отчетность данных
Для решения со скрытыми точками в отчетах о данных необходимо учитывать два момента:
- Выполните специальную обработку для междоменного доступа.
- После того, как страница будет уничтожена, как можно успешно сообщить о незагруженных данных скрытых точек?
Традиционный способ отправки запросов данных XHR бессилен в отношении двух упомянутых выше моментов. В процессе представления данных обычно используются два метода:
- Динамически создавать теги img и отправлять запросы, объединяя URL-адреса в img.src.
- Вызовите интерфейс sendBeacon для отправки данных
Тег изображения
использоватьimgпомеченsrcСпособ отправки запроса к атрибуту, конкретная схема реализации выглядит следующим образом:
let _img = new Image();
_img.src = `${url}?${util.spliceParam(params)}`;
_img.onload = _img.onerror = function() {}
Это очень подходит для сценария приложения для создания отчетов о скрытых точках:
① Только сообщаемые данные не требуют ответа;
② Атрибут src в img, естественно, не имеет междоменных проблем.
Есть и недостатки такого использования. Во-первых, в src есть ограничение на размер содержимого URL, и он не подходит для большого объема данных. я вижу в деталяхздесь. Во-вторых, когда страница выгружается, если возникает ситуация, когда данные не отправляются, сначала будут отправлены соответствующие данные, а затем страница будет выгружена. В этом случае это принесет пользователю неудобства в работе.
В настоящее время метод SendBeacon предназначен для устранения упомянутых выше дефектов.
sendBeacon
Метод sendBeacon — это асинхронный неблокирующий метод передачи данных. Конкретное использование заключается в следующем:
window.navigator.sendBeacon && window.navigator.sendBeacon(url, params)
Его уникальные особенности:
- Запросы маяка — это методы Post.
- Запросы маяка имеют приоритет, чтобы избежать конкуренции с критическими операциями и сетевыми запросами с более высоким приоритетом.
- Запросы маяков можно эффективно комбинировать для оптимизации энергопотребления на мобильных устройствах.
- Маяк гарантирует, что запрос маяка инициируется до того, как страница будет выгружена, и может выполняться до завершения без блокировки запроса или блокировки задач, обрабатывающих события взаимодействия с пользователем.
- Возвращаемое значение: метод sendBeacon возвращает логическое значение после его выполнения.
trueОт имени пользовательского агента успешно ставит в очередь запрос маяка, в противном случае возвращаетfalse.
Для метода sendBeacon существуют следующие ограничения:
- Он не может быть междоменным и требует настроек на стороне сервера.
- Новый функциональный интерфейс, существуют проблемы с совместимостью.
Поэтому в реальном процессе приложения необходимо комбинировать тег Img с методом sendBeacon в соответствии с реальной ситуацией.
Суммировать
В этой статье мы отдельно обсудим два аспекта этапа отчетности: сбор данных и отчетность по данным. Среди них мы проанализировали некоторые заслуживающие внимания ситуации в процессе сбора данных. В то же время вам доступны два общих метода представления данных. Я надеюсь полезно для вас!