Файли відвідувань міфи та реальність - Статистика - Розкрутка та реклама - Статті
Часто при спілкуванні з іншими вебмайстрами розмова заходить про відвідування серверів. Задавши питання про середню кількість відвідувачів в день або про ефективність поставленого на якомусь сервері посилання, іноді дивуєшся почутій відповіді: "Ну, я точно не знаю - по Рамблеру близько 300 чоловік на день, але ж він не точний". Або ще гірше: "А як це дізнатися?". Дивно, але зустрічаються професійні вебмайстри, які нічого не чули або просто не замислювалися про файли відвідувань (лог-файли). З іншого боку, навіть ті, хто їх аналізує і витягує велику кількість інформації, не підозрюють, що інформації в них набагато більше, ніж вони передбачали. Тому я вирішив розповісти вам про те, що можна і чого не можна з них отримати, як можна використовувати отримані дані, які інструменти можна використовувати для цього.
Що таке ці загадкові лог-файли? Це прості текстові файли, в які порядково записується інформація про кожен запит файлу у Веб-сервера. Відразу хочу пояснити тим, хто не знає подробиць роботи протоколу HTTP - для кожного окремого файлу браузер повинен згенерувати окремий запит. Припустимо, що ми просимо HTML сторінку, яка містить п'ять графічних елементів. У цьому випадку браузер згенерує шість запитів до сервера, і в лог-файлі з'явиться шість нових рядків. Крім цього, сервер поміщає в лог-файл інформацію і про всі невдалі запити, наприклад, до неіснуючих документів. Тобто, строго кажучи, в лог-файл міститься інформація про всі коректні запити, отримані сервером. Задля справедливості зазначу, що некоректні запити теж реєструються, але в іншому файлі - файлі реєстрації помилок. Цікавий технічний аспект: запит реєструється не в момент його приходу, а тільки післяйого повна обробка.
У загальному випадку лог-файли можуть мати будь-який формат, він залежить не тільки від сервера, що використовується, але і від налаштувань, вироблених вебмайстром. Але найбільшого поширення набули два формати - " звичайний " , використовуваний найпершим Веб-сервером, і " комбінований " , званий також " комбінований NCSA формат " , т.к. він уперше з'явився у сервера NCSA - прабатька всесвітньо відомого Apache.
Рядок лог-файлу звичайного формату виглядає так:
Всі поля запису поділяються пробілами (якщо значення укладено в подвійні лапки, або у випадку з датою в квадратні дужки, воно сприймається як одне поле), якщо значення у поля відсутнє, то ставиться дефіс.
В даний час більшість веб-серверів використовують саме цей формат, т.к. він надає набагато більше інформації про запит, ніж звичайний. Причому саме два останні поля найбільш важливі при аналізі ефективності дій з популяризації (розкрутки) вузла, що вживаються вебмайстром, і при плануванні його розвитку в плані впровадження нових технологій і послуг.
Настав час проаналізувати кожне поле докладніше і з'ясувати, яку корисну інформацію можна витягти з нього.
Адреса джерела запиту
Аналізуючи поле джерела запиту, можна побудувати три досить інформативні залежності:
На основі цього поля будуються погодинні, подобові, понеділкові та помісячні графіки активності на вузлі. Якщо аналіз кількості хостів дозволяє визначити популярність сервера, ці залежності вказують на моменти пікового навантаження на сервер, моменти найменшої активності, швидкість збільшення активності у міру розвитку вузла. Аналізуючи ці залежності можна визначити найбільш підходящі періоди для внесення виправлень у вузол,оновлень або перегенерації сторінок, що генеруються.
Поле запиту є основним під час аналізу відвідуваності вузла. Як я вже згадував, сервер реєструє всі запити до сервера (хіти). Навряд чи вам потрібно мати інформацію про запити до елементів оформлення документів (картинок, звуків, таблиць стилів, файлів із зовнішніми сценаріями тощо), тому при побудові більшості звітів "зайві" записи треба ігнорувати. Тому багато аналізаторів запроваджують таке поняття, як покази сторінок. Вебмайстер сам зазначає, які саме файли вважати сторінками. У найпростішому випадку це *.html та *.htm. Далі під хітами ми маємо на увазі саме покази сторінок. Перерахуємо найбільш інформативні залежності, що будуються на основі цього поля:
Код відповіді
Як правило, код відповіді використовується для визначення необхідності використання цього запису в аналізі, але й сам по собі він використовується у кількох звітах:
Кількість переданих байт
Сама по собі інформація про обсяг переданих даних є скоріше ознайомчою, але спільно з іншими даними вона дозволяє виявляти корисні факти:
- Звіт про найбільш активні з точки зору обсягу завантажених даних хості дозволяє виявити підозрілих відвідувачів, особливо, якщо на вашому вузлі розташовується цінна або продається вами за гроші інформація. Свого часу саме завдяки цьому звіту я виявив факт крадіжки програми телепередач із мого вузла (www.telesputnik.ru). Мало того, що ця інформація була дуже цінною, т.к. вимагала значних зусиль з підготовки, тож ще порушник скачував (очевидно, скриптом) програму передач майже кожну секунду, що збільшило трафік майже вдвічі.
- При суміщенні даних про кількість переданих байт для кожного файлу зінформацією про фактичному розмірі файлу можна виявити, яких файлів найчастіше переривається передача. Це може означати, що розмір цих файлів занадто великий, і треба спробувати зменшити його - розбити файл на два, якщо це документ або запакувати в архів, якщо це якийсь інший файл. Збільшення загальної кількості таких файлів може означати, що ваш сервер або канал перевантажений, і відвідувачі просто не чекають на закінчення і натискають "Cancel".
Документ, що посилається
По-друге, для всіх об'єктів (графічних файлів, аплетів тощо), вказаних на запитаній сторінці, документом, що посилається, буде ця сторінка, а не той документ, який посилався на запитану сторінку.
При аналізі цього поля цікавими будуть наступні залежності:
Ідентифікатор програми-клієнта
За коректність інформації у цьому полі відповідальність також несе браузер. Тому, як і в попередньому випадку, в ньому можуть з'являтися дивні, іноді дуже веселі записи. Пов'язано це з тим, що значення цього поля часто може змінювати власник програми-клієнта - ваш відвідувач. Аналіз цього поля дозволяє здійснювати технічний розвиток вашого вузла у правильному напрямку: