home

Методы сбора статистики в электронных библиотеках

Существует совсем немного подходов подсчета статистики по книгам (или документам) в электронных библиотеках (ЭБ). Можно:

  1. Анализировать логи веб-сервера.
  2. Установить внутренние счетчики на скачивание страниц или файлов целиком (по некоторому URL, по которому доступен ресурс).
  3. Установить асинхронные счетчики в плеерах документов, которые будут отправлять информацию на сервер об чтении того или иного документа.

Рассмотрим достоинства и недостатки каждого из методов.

Методы сбора статистики[править]

Логи веб-сервера[править]

Каждое обращение на веб-сервер записывается в текстовый файл, в котором указывается обязательно URL, по которому было обращение и, часто, параметры обращения (ip-адрес пользователя, UserAgent и т.д.). Затем уже самостоятельно парсятся и из них составляется некоторая общая статистика.

Плюсы:

  • Легко прикручивается к любой библиотеке, даже если она сама не имеет никакого статистического функционала.
  • Все настройки ведутся на веб-сервере, соответственно, не трогается код электронной библиотеки.
  • Не создается нагрузка на библиотеку для хранения логов.

Минусы:

  • Логи надо уметь правильно фильтровать. Обычно в логи попадают все запросы на все ресурсы и если не отфильтровать результаты обращений, то можно получить 10-40 кратное завышение количества обращений из-за попадания в лог статических файлов.
    • В некоторых случаях полностью отфильтровать ненужное и оставить нужное невозможно, т.е. способ может не подходить для конкретных ЭБ.
  • Необходимо отфильтровать поисковых роботов, которые могут давать трафик превышаюший органический (запросы от людей).
  • Парсинг файлов может быть длительной процедурой, т.к. результаты извлекаются путем парсинга каждой строки.
  • Веб-сервера, обычно, проводят ротацию логов и надо позаботиться об их сохранности.
  • Такие логи ничего не знают про сессии, хотя могут записывать ip-адрес. Пользователи за NAT будут при таком подходе выглядить как один пользователь.

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

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

Внутренние счетчики[править]

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

elis_ebook_log.png

Плюсы:

  • Возможен очень подробный трекинг чтения книги конкретным пользователем (знание кто когда и какую страницу читал).
  • Не зависит от способа обращения к странице и не требуется интеграция в плееры (работает с любым плеером).
  • Позволяет вести надежный учет конкурентных лицензий.

Минусы:

  • Быстрое разрастание базы с логами и необходимого для нее места.
  • Из-за большого размера базы, построение годовых отчетов требует большого количества времени и рекомендуется предварительная агрегация.
  • Завышение статистики из-за предварительного кеширования на клиенте.
  • В некоторых реализациях может фиксировать показ обложки книги в каталоге или в результатах поиска как книговыдачу (т.е. завышать книговыдачу и, при этом, уменьшую среднее число просмотренных страниц на книговыдачу).
  • В некоторых реализациях возможно существенное завышение страницевыдачи из-за активности поисковых роботов.

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

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

Счетчик в книжном плеере[править]

Счетчик интегрируется непосредственно в плеер, по мере просмотра страниц в книжном плеере, на сервер отправляются данные о просмотренных страницах.

elis_play_log.png

Плюсы:

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

Минусы:

  • Зависит от плеера книги. Если есть мобильные приложения, они тоже должны использовать эту статистику.
  • В браузере не работает без JavaScript.
  • Учет конкурентных лицензий в некоторых случаях может обходиться (зависит от реализации защиты).
  • Имеет погрешность измерений из-за неотправленных данных в момент закрытия браузера.
  • Отправка данных дополнительными запросами увеличивает нагрузку на сервер.

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

При грамотной реализации следует ожидать небольшое (5-10%) занижение фактической страницевыдачи.

Подсчет числа сессий (сеансов) взаимодействия с сайтом[править]

Внешние системы аналитики устанавливают куки в браузер и по ним определяют сессию. Таким образом, они не чувствительны к искажением из-за использования NAT.

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

Соответственно, можно подсчитать число сессий как на основе счетчика логов, так и из системы внешней аналитики и сравнить результаты.

Достоверность статистических сведений облачных ЭБС[править]

Владельцы ЭБС мотивированы в хорошей посещаемости своих систем. Тем самым они мотивированы на завышение статистики, но не заинтересованы потерять доверие к своим отчетам. Для доступа к распространенным облачным ЭБС требуется авторизация, а статистика считается для каждой организации отдельно и пользователь должен быть ассоциирован с организацией. Поэтому отчеты облачных ЭБС не подвержены искажениям статистики из-за активности поисковых систем.

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

Выводы[править]

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

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

Полученная статистика должна рассматриваться критически и не должна существенно противоречить данным внешних аналитических систем (Google Analytics / Yandex Metrika).