6.2. Проведення моніторингу ринку

Більшість читачів відвідує Web-сторінку в робочий час, знаходячись на роботі або на навчанні. Web-сервер The Gale зберігає доменні імена читачів, тому маркетологи електронної газети знають, які групи населення читають їх видання. Маркетологи знають також, скільки користувачів відвідало їх з комерційного домена .com, скільки з учбового .edu. Частіше за все цю сторінку відвідують представники різних компаній: дві третини всіх відвідувачів з домена «.com».

Звіти про потік відвідувачів

Кожний раз, коли відвідувач запитує файл з вашого Web-сервера (пам'ятайте, що файл може бути сторінкою, графікою, повідомленням про помилку і взагалі всім, чим бажано, з того, що постачає ваш Web-сервер), програмне забезпечення додає рядок у ваші файли реєстрації.

Реєстрація доступу

Для аналізу потоку відвідувачів Web використовуються дані реєстрації доступу. У самому простому форматі реєстрації дані ці мають вигляд:

hostname identd authuser [date] „request" status lenght

Hostname назва Web-вузла, з якої запитується ваш файл. Web-вузол це не те ж саме, що настільний комп'ютер окремого відвідувача; звичайно вузол це великий комп'ютер, за допомогою якого до мережі підключається декілька комп'ютерів поменше. Коли Web-вузол запитує файл на вашому Web-сервері, він може повідомити вашому серверу своє ім'я, хоч і не зобов'язаний цього робити. Якщо Web-вузол не повідомляє свого імені, у ваш файл реєстрації записується IP-адреса цього вузла, рядок цифр і точок, яка повідомляє про місце знаходження вузла в Internet.

Identd це ідентифікуючі дані відвідувача. Але ви їх отримуєте тільки в тому випадку, якщо комп'ютер відвідувача встановлений на повідомлення цих даних і якщо ваш Web-сервер запитує їх. Це називається видаленою ідентифікацією користувача. Процедура ідентифікації вельми істотно сповільнює діяльність Web-сервера, тому мало хто користується нею.

Authuser дає ім'я, яке користувач надає для входу на ваш сервер, якщо для входу на сервер потрібний пароль.

Date це дата і час отримання запиту, записуються в квадратних дужках.

Request повідомляє, що саме запитує відвідувач, записується в лапки. Складається з назви операції, що записується великими буквами, за якою слідує ім'я файла і версія протоколу, що використовується HTTP. Назва операції звичайно або GET (ПОЛУЧИТЬ), або POST (ПЕРЕДАТЬ), коли відвідувач запитує сценарій CGI.

Status Тут міститься інформація про те, що зробив ваш Web-сервер у відповідь на запит відвідувача.

Lenght повідомляє, скільки даних (в байтах) ваш Web-сервер відправив у відповідь на цей запит. Якщо ніякій інформації відправлено не було, замість цифр ставиться риска.

Ось чотири приклади поширених форматів реєстрації.

mis.fedex.com -- [10/Jun/l997:20:06:22 -0800]

„POST/cgi-bin/stscript.pl HTTP/1.1" 200 9872 127.0.0.1 -- [10/Jun/1997:20:06:37 -0800]

„СЕТ /index.htm HTTP/1.1 * 304 -greenjungle.com prefer- [10/Jun/1997:20:06:52 -0800]

„GET /oops.htm HTTP/1.1" 404 - usf.edu unknown - [10/Jun/1997:20:07:19 -0800] '

„GET/oops.htm HTTP/1.1" 404 -

Перший приклад повідомляє про запит, що поступив з MIS (відділу інформаційної управлінської системи) компанії Federal Express (mis.fedex.com). Оскільки ваш сервер не користується видаленою ідентифікацією користувача і не запитує пароль, то ви не отримуєте ніяких даних в пунктах identd і authuser. Замість цих даних ви бачите дві риски. Далі вказане слово POST, взяте в лапки (запит на сценарій CGI), за яким слідує cgi-bin (каталог на вашому комп'ютері, в якому знаходиться файл, що запитується ) і stscript.pl (ім'я файла). Вказане в пункті status число 200 показує, що файл був успішно доставлений користувачеві, а заключне число 9872 повідомляє, що розмір файла рівний 9 872 байт. (Якщо при цьому ви точно знаєте, що розмір вашого файла stscript.pl насправді становить 10 282 байт, таке свідчення об'єму файла повинне вас насторожити. Можливо, це говорить про відмову тобто відвідувач запитав на вашому Web-сервері файл, але на браузер відвідувача цей файл був переданий не повністю. Таке звичайно відбувається, коли відвідувач по час передачі файла клацає на кнопці Stop, щоб перервати процес завантаження. Деякі називають цю дію скасуванням. При цьому не забувайте, що неповна передача файла могла статися і по інших причинах, наприклад через помилки в роботі програмного або апаратного забезпечення.)

У другому прикладі відсутня назва Web-вузла відвідувача. Замість нього зареєстрована IP-адреса 172.0.0.1. Запит, вказаний в лапки, повідомляє, що відвідувач хотів отримати (GET) вашу Web-сторінку index.htm, але в пункті status ви бачите число 304, а тире за ним вказує, що жодного байта відправлено не було. Що ж сталося? 304 означає "Not Modified" ( "He змінювалася"). Мова йде про те, що ваш відвідувач хотів тільки дізнатися, чи змінювалася ваша сторінка з часу його останнього візиту. Сторінка не змінювалася, так що більше нічого не сталося.

Третій приклад показує, що відбувається, якщо підключити видалену ідентифікацію користувача. Другим пунктом слідує peter, ім'я відвідувача. Він запитує вашу Web-сторінку oops.htm і отримує повідомлення про помилку 404, оскільки у вас немає Web-сторінки з такою назвою.

У четвертому прикладі показано, що відбувається, якщо ви підключили віддалену ідентифікацію користувача, а відвідувач не підтримує її. Замість імені ви отримаєте слово unknown (невідомий). Цьому відвідувачеві також потрібна сторінка oops.htm.

На основі цих даних з вашого журналу реєстрації в свій звіт про потік відвідувачів на Web-сервері ви можете включити наступну інформацію.

1. Щоденна кількість відвідувачів.

2. Почасовий об'єм потоку відвідувачів (більшість Web-серверів дуже активно відвідується б робочі години, але так буває далеко не завжди. Web-сервер компанії Chemical Abstracts залучає таку кількість європейських користувачів, що більше усього звертань реєструється на ньому в 4 часи ранку).

3. Процент активності по доменних іменах верхнього рівня. (Звертайте увагу не тільки на. com,. edu і. gov, але і на доменні імена, відповідні назвам країн наприклад,. uk (Великобританія) або. fr (Франція). Завдяки цим доменам Chemical Abstracts дізнається, що її ранні відвідувачі проживають в Європі.)

4. Процент активності по доменах. (Домени містять назви компаній (.citibank), університетів (.ucsf), урядових установ і провайдерів доступу до Internet.)

5. Сторінки, на які поступає більше усього запитів, і сторінки, до яких звертаються рідше усього. (Дуже корисна інформація. Вказує, які області сервера потрібно розширювати. Попереджає про можливі проблеми. Файл з нулями може повідомити про гіперзв’язок, що не діє).

6. Кількість повідомлень про помилки і неякісно передані файли. Дозволяє дізнатися, які файли були передані успішно, а які - ні.

Всі ці цифри дуже корисно і добре, але журнал доступу не в стані відстежувати індивідуальних відвідувачів. Як показують приклади, ви можете дізнатися, звідки даний відвідувач, але не можете визначити, хто він. Якщо у вас п'ять запитів від mis.fedex.com, ви не можете визначити, чи було це п'ять окремих відвідувачів з компанії Federal Express або один і той же, що звернувся до вас п'ять разів. Те ж саме можна віднести до вашого відвідувача з usf.edu або з 127.0.0.1, ким би він там ні був.

Сам по собі ваш журнал доступу не відповість на ключові питання, а саме: скільки індивідуальних користувачів відвідало ваш Web-сервер? Скільки часу проводить у вас один середній користувач?

Ця основна інформація з журналу реєстрації, безумовно, досить цінна. Вона надає корисні відомості про кожний файл, запит на який був зроблений на вашому Web-сервері. Але по-справжньому корисної ця інформація стає тоді, коли ви об'єднуєте її з іншими важливими відомостями.