Всего на оптимизацию влияют три группы факторов. 4 страница

Посмотреть, к какому региону относится нужный вам IP-адрес, можно на сайтах: ripe.net (европейский регион, включая Россию), afrinic.net (Африка), apnic.net (Азия), lacnic.net (Латинская Америка и Карибский регион), arin.net (Северная Америка). На рис. 7.2. показан результат запроса к базе Ripe.

Рис. 7.2. Результат запроса к базе данных Ripe. В результате запроса показан диапазон сети (в первой строке), которым владеет указанная ниже компания, а также адрес компании как место расположения устройств, имеющих адрес из этой сети. Для данного IP-адреса это город Соммерсет в Англии

• ДАТА И ВРЕМЯ, в которые сделан запрос. Указывается время, установленное на сервере, а не на компьютере пользователя, и они могут различаться. Однако даже если время на сервере установлено неверно, то оно неверно для всех пользователей одновременно.

• ЗАПРОШЕННЫЙ ЭЛЕМЕНТ, то есть что конкретно запросил пользователь на сервере. Это может быть HTML-документ (страница сайта), картинка, видеоролик, исполняемый скрипт, архив, множество других вещей, которые пользователь может захотеть получить. Каждая страница на сайте состоит из множества элементов, часть из которых мы явно видим, а другую – нет. При получении страницы сайта с сервера браузер считывает ее (разбирает язык разметки HTML) и определяет, какие еще элементы нужны для показа страницы: картинки, таблицы стилей и проч. Также еще до того, как «отдать» страницу пользователю, сервер может «собрать» страницу из множества различных модулей, хранящихся на сервере отдельно. Для каждого элемента, задействованного на странице, создается свой запрос и записывается строчка в отчет. • REFERRER, ИЛИ ССЫЛАЮЩИЙСЯ ДОКУМЕНТ, то есть адрес страницы, на которой была ссылка на запрашиваемый элемент. Refferer – это адрес страницы какого-либо сайта, откуда был совершен переход, в том числе это могут быть и страницы вашего сайта. Адрес ссылающегося документа содержит много информации, например, если это был переход из результатов поиска поисковой машины, то можно из адреса referrer определить поисковый запрос, а также – какая именно поисковая машина была задействована. Иногда это поле бывает пустым, тогда такой переход на сайт называют type-in-переходом.

Type-in-трафик

Поле referrer может быть пустым, если пользователь обращается к странице (или к какому-либо другому элементу):

• набрав ее адрес в строке браузера;

• перейдя из закладок;

• перейдя на «домашнюю страницу»;

• перейдя из почтовой программы или из любого приложения (например, из Word).

В этом случае сервер не может определить, откуда был сделан переход, и не указывает это в журнале записи событий. Все переходы на сайте без указания ссылки совокупно называются Type-in-трафиком.

Следует отметить, что ссылка может не записываться также при переходе из flash-ролика. Поэтому, если вы используете для рекламы Flash-баннеры, то переходов с них вы вообще не увидите. Кроме того, в некоторых случаях proxy-сервер, через который пользователи осуществляют доступ в Интернет, может отрезать referrer и не передавать его внешним серверам. Особенно это касается корпоративных сетей с высокой степенью защищенности.

• USER AGENT – кодовое обозначение операционной системы и браузера, используемых для доступа к сайту. Пример UA: «Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)» – это Windows XP с IE 6.0.

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

• РЕЗУЛЬТАТ – код результата запроса пользователей. Наиболее известный результат – это 404 «страница не найдена», однако самый часто встречающийся – 200 «данные переданы успешно». Нам для анализа результат нужен именно для того, чтобы определять случаи, когда пользователь по каким-либо причинам не получил нужную страницу.

Кроме параметров, перечисленных выше, фиксируется еще большое количество различных данных: размер переданного файла, промежуточные IP-адреса, тип запроса и другие. Маркетологов эти параметры не слишком интересуют, они нужны скорее системным администраторам для контроля работы серверов и программ.

Наконец, при помощи дополнительного программного обеспечения мы можем фиксировать такие параметры, как наличие java-script и его версии, наличие и версии flash-модуля, разрешение экрана и другие параметры, которые также могут быть интересны, однако не важны для анализа эффективности маркетинговых действий.

Идентификация посетителей

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

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

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

1. ПО IP-АДРЕСУ. Каждый компьютер в момент подключения к любой сети TCP/IP (к которым относится и Интернет) имеет уникальный и однозначный IP-адрес, который не изменяется в течение всего времени подключения к Интернету, а для постоянного подключения вообще не меняется. Следовательно, можно однозначно идентифицировать компьютер пользователя по IP-адресу.

Этот метод идентификации совсем не точен, поскольку несколько пользователей могут иметь один и тот же IP-адрес, если они находятся, например, за общим proxy-сервером. В этом случае они все будут иметь тот IP-адрес, который подставляет им proxy-сервер. Таких пользователей сегодня большинство – это все пользователи корпоративных сетей, большинство пользователей домашних сетей, пользователи в интернет-кафе, институтах и т. д. Но и это еще не все: в том случае, когда пользователь выходит в сеть через коммутируемое соединение, при каждом соединении он получает новый IP-адрес. Более того, dial-up-соединение может быть разорвано в процессе сессии, и оно будет восстановлено потом уже с новым уникальным IP-адресом. Все это, конечно, уменьшает точность идентификации.

Последние годы применяется идентификация одновременно по IP-адресу и какому-либо еще постоянному параметру, которым может выступать User Agent или разрешение экрана. То есть пользователь идентифицируется по сочетанию двух параметров. Однако и этот метод недостаточно точен, поскольку в корпоративных сетях последнее время техника в очень большой степени унифицирована, и если в домашних сетях действительно за общим IP-адресом скрывается «зоопарк» различных компьютеров, то в корпоративных сетях все компьютеры часто имеют одинаковую конфигурацию и одинаковый набор программного обеспечения. Расхождение числа реальных пользователей и числа пользователей, определенных по IP, тем больше, чем больше сайт. Хостов всегда меньше. Для посещаемости менее 500 человек разница несущественна.

Методика идентификации по IP-адресу весьма грубая, несмотря на все дополнения и уточнения. Эта методика никак не позволяет идентифицировать посетителя между сессиями – при повторном посещении – и не всегда дает возможность отличить друг от друга корпоративных пользователей или пользователей в одной домашней сети. Несомненное преимущество метода: он возможен всегда, поскольку у пользователя всегда есть IP-адрес.

2. ПО COOKIE. В отличие от IP-адреса, уникальные cookie записываются на каждый компьютер посетителей сайта, поэтому эта технология изначально намного точнее. В cookie-файлы может записываться все что угодно, но обычно это уникальный идентификатор, который сохраняется и после того, как пользователь уходит с сайта и вообще отключается от Интернета. При следующем посещении сайта даже через длительный промежуток времени пользователь может быть идентифицирован повторно, то есть «узнан» сайтом. Поэтому данная методика используется сегодня чаще других.

Но и она не лишена погрешностей. Пользователи могут отключать cookie – это делают немногие, всего около 4 % всех пользователей, cookie могут стираться пользователем в результате переустановки системы или после окончания каждого сеанса связи с Интернетом, если сделаны такие предустановки на компьютере. Однако самой большой погрешностью метода является то, что он определяет не пользователей, а браузеры, за которыми работают пользователи. Если за одним компьютером работает несколько пользователей, они пользуются общей учетной записью и одним и тем же браузером, поэтому они будут считаться одним пользователем. И наоборот, человек, по каким-то причинам использующий несколько браузеров на одном компьютере, будет считаться столько раз, сколько различных браузеров он использует.

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

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

3. ПО СЕССИОННЫМ ИДЕНТИФИКАТОРАМ. При помощи несложного программного модуля можно присвоить пользователю уникальный идентификатор, который будет передаваться в адресной строке при перемещении пользователя от страницы к странице. Это выглядит как добавление к адресной строке конструкции вида? sessid=65468765213249875419876, где набор цифр – это и есть уникальный идентификатор (он может состоять из букв или быть смешанным в зависимости от используемых для этого программ). В отличие от метода идентификации по cookie, сессионный идентификатор нельзя отключить, его нельзя запретить на proxy-сервере. Конечно, можно стереть идентификатор из адреса, но это почти исключительное событие: большинство пользователей не имеют для этого достаточных знаний. В то же время сессионные идентификаторы не сохраняются после разрыва сессии, хотя сама по себе сессия может иметь иногда неограниченную длину – до тех пор, пока не будет закрыт браузер.

Этот метод идентификации, очевидно, может быть использован только в рамках одной сессии, однако в течение сессии он точнее всех других. Основное применение сессионных идентификаторов – это сохранение параметров при переходе между страницами. Например, пользовательские запросы или настройки гораздо проще сохранить на сервере в базе данных и сопоставлять с идентификатором, чем передавать в строке, где они могут банально не поместиться.

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

4. АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЯ. Единственный совершенно надежный метод идентификации пользователя – это его авторизация (ввод логина и пароля). К сожалению, далеко не всегда можно применять авторизацию, так как пользователи не любят регистрироваться и оставлять о себе какие-то личные данные. Заставить их делать это без потерь аудитории можно лишь в редких случаях. Кроме того, даже в случае, если пользователь зарегистрировался, нередко возникает ситуация, когда он теряет логин и пароль и поэтому регистрируется заново.

Например, около трети покупателей интернет-магазина «Озон» (крупнейшего сегодня в России по числу покупателей) забывают свои регистрационные данные и при следующей покупке заново регистрируются. Даже введение пластиковых карточек с данными пользователя, которые бесплатно выдавались при первой покупке, хоть и улучшило ситуацию, но не решило ее полностью. Для магазина «Озон» это критическая проблема, потому что три четверти продаж совершается постоянными покупателями, и работа с постоянными покупателями – важнейшая составляющая маркетинга компании.

Наконец, пользователь может просто-напросто передать пароль (мы все это нередко делаем) своим друзьям или знакомым, чтобы они могли совершать какие-то действия от его имени.

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

Для анализа в интернет-маркетинге используется чаще всего метод идентификации по cookies. Остальные методы применяют только в тех случаях, когда cookies недоступны. Если на сайте осуществляется авторизация пользователей, например для интернет-сервисов или для интернет-магазинов, то можно использовать авторизационные данные для анализа продаж.

Производные данные

Я уже упомянул выше, что, зная IP-адреса, можно определить географическое расположение пользователя, а зная referrer – запрос, по которому пользователь нашел ссылку на наш сайт в поисковой системе. Это так называемые производные данные – они получены за счет интерпретации собираемых данных. К основным производным данным относятся: СЕССИЯ – весь процесс посещения пользователем сайта от первой просмотренной им страницы и до выхода из сайта. По определению IAB[2] сессия – это вся последовательность просмотра одним пользователем страниц сайта, при условии, что запрос каждой следующей страницы не отделяет от предыдущей более 30 мин. В случае, если интервал между запросами страниц одним пользователем превышает 30 мин., то сессия закрывается и открывается новая. Здесь есть свое разумное объяснение. Существует достаточно большое количество сайтов, на которые мы заходим несколько раз в день: почтовые серверы, поисковые системы, сайты новостей и другие, – и каждый раз это будут различные сессии. Именно поэтому IAB приняло за норму, что если человек не проявляет никакой активности на сайте в течение 30 мин, то его сессия считается законченной, а при следующем хите открывается новая сессия. Другими словами, если пользователь после перехода на очередную страницу сайта выключил браузер, то сервер, на котором расположен браузер, никак не узнает об этом, и тогда через 30 мин сессия будет закрыта;

• ПУТЬ ПО САЙТУ – последовательная цепь страниц, просмотренных пользователем на сайте за одну сессию в том порядке, в котором они посещались. Важно, что если в промежутке между просмотром пары страниц на сайте пользователь смотрел страницы на другом сайте, то у сервера об этом нет никакой информации и он считает путь непрерывным всегда, когда сессия не прерывалась;

• ВРЕМЯ НА САЙТЕ – время, проведенное пользователем на сайте в течение одной сессии. Время на сайте может быть измерено как промежуток времени от момента запроса первой страницы до момента запроса последней страницы сессии. Важно, что время, проведенное пользователем на странице, обычно не может быть измерено, если пользователь не перешел на следующую страницу, поскольку браузер после получения страницы не общается с сервером;

• ГЛУБИНА ПРОСМОТРА САЙТА – число страниц на сайте, просмотренных пользователем в течение одной сессии. Если человек в течение сессии несколько раз просматривал одну и ту же страницу, то она может быть посчитана несколько раз или один в зависимости от настроек анализирующей программы. Аналогичная ситуация и с путями по сайту: если пользователь в промежутке между просмотрами двух страниц на сайте смотрел страницы на другом сайте, то у сервера нет никакой информации об этом, и система анализа будет считать глубину просмотра сайта до тех пор, пока сессия будет оставаться непрерывной;

• ВОЗВРАТ НА САЙТ – повторное посещение сайта пользователем. Иначе говоря – вторая и любая последующая сессия на сайте. Возвраты на сайт могут быть определены только при использовании системы идентификации посетителей по cookie-файлам или через авторизацию. Некоторые системы статистики считают возвраты по IP – это неверно даже для мелких сайтов;

• ПОСТОЯННАЯ АУДИТОРИЯ – пользователи, которые заходят на сайт регулярно. Регулярность захода на сайт может быть определена произвольно – раз в неделю, раз в день, раз в месяц– и зависит от содержания сайта и преследуемых им целей. Как и возвраты на сайт, постоянные посетители могут быть определены только за счет использования системы идентификации посетителей по cookie-файлам или через авторизацию; НОВАЯ АУДИТОРИЯ – пользователи, пришедшие на сайт в первый раз. Как и возвраты на сайт, новые посетители могут быть определены только при использовании системы идентификации посетителей по cookie-файлам или через авторизацию (по отсутствию регистрационных данных или cookie-файлов). Важно помнить, что оба метода идентификации пользователей не идеальны, поэтому новым может считаться пользователь, который уже был на сайте (но стер cookie или зарегистрировался заново). Все эти перечисленные выше термины нередко встречаются в системах анализа. Многие из них вы будете использовать в своей работе.

Инструменты анализа

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

Рис. 7.3. Фрагмент лог-файла

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

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

Рассмотрим различные инструменты анализа статистики подробнее.

ЛОГ-АНАЛИЗАТОРЫ – «коробочные» программы, устанавливаемые на локальный компьютер или на сервер, которые анализируют журналы записи событий (лог-файлы), накапливаемые на серверах. Иначе говоря, это аналитические пакеты, которые совершают обработку текстового файла и строят множество статистических отчетов, набор которых зависит от настроек и возможностей лог-анализатора.

Лог-анализаторы – сложные программные продукты, обладающие огромными возможностями. Наиболее совершенные из них имеют специальные модули для анализа финансовой информации (например, для сайта электронного магазина), поиска скрытых закономерностей (drill down reports), построения собственных статистических отчетов и так далее.

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

Существует несколько тысяч различных лог-анализаторов – в базовом варианте они представляют собой несложный программный продукт, поэтому их понаделали немало. Часть из них коммерческие, но большинство – бесплатные, появившиеся как развлечение или побочный продукт совершенно других разработок. Наиболее известные на сегодняшний день продукты – WebTrends, NetTracker, Analog, WebAlyzer. Первые два – коммерческие продукты, последние – распространяются бесплатно. Бесплатность лог-анализаторов – обманчивая вещь. Для того чтобы бесплатная система лог-анализа правильно работала, исследователю необходима недюжинная квалификация, а часто потребуется еще и программист, чтобы дописать необходимые модули (благо, бесплатные лог-анализаторы чаще всего поставляются в исходных кодах). Таким образом, эксплуатация свободно распространяемого программного продукта может оказаться более затратной, нежели коммерческого.

Наиболее важное свойство лог-анализаторов – это возможность строить с их помощью произвольные статистические отчеты. Они могут называться «Пользовательские отчеты», или Custom Reports, или Filters, или еще как-либо, но смысл одинаков – возможность построить отчет по специфическим параметрам. Не исключено, что как раз на этом этапе вам потребуется программист, чтобы написать нужный модуль.

Примеры произвольных статистических отчетов:

• страницы, посещаемые пользователями из Новосибирска, которые приходят на сайт не в первый раз;

• время, в которое пользователи сайта чаще всего просматривают страницу контактов,

• доля тех пользователей, которые просматривают эту страницу ночью.

СЧЕТЧИКИ – серверные приложения, основывающиеся на статистике вызовов счетчика – небольшого куска кода, включаемого в страницу. При загрузке страницы пользователем браузер обнаруживает код счетчика, считывает его и вызывает с серверов счетчика небольшую картинку (рис. 7.4). В этот момент на сервере счетчика засчитывается посещение сайта. Таким образом, счетчик учитывает не запрос страницы, который отражается в лог-файле на сервере сайта, а запрос пользователем счетчика. То есть счетчик – это данные не прямых, как в случае с лог-файлом, а косвенных измерений.

Рис. 7.4. Счетчики на сайте Gismeteo.ru и фрагмент кода страницы, содержащий счетчики

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

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

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

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

Для того чтобы разбирать поисковые запросы новой поисковой машины, требуется указать, как в адресе результатов поиска шифруется поисковый запрос. Форма указания поискового запроса различается для каждой поисковой машины. Вот пример поискового запроса для Яндекса: yandex.ru/yandsearch? text=Search+querry

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

В настоящее время существует достаточно много счетчиков, в каждой стране насчитываются десятки вариантов локальных счетчиков, есть и международные системы. Системы могут быть коммерческие, могут быть бесплатные. Первые обычно детализированы, предлагают больше сервисов и имеют множество дополнительных возможностей. Наиболее известные сегодня в России сервисы – это Google Analytics, Livelnternet (бесплатные), SpyLOG (коммерческий счетчик), за рубежом – Omniture, HitBox и WebtrendsLive (коммерческие), а также беошатный Google Analytics.

Все указанные выше счетчики умеют строить дополнительные индивидуальные отчеты, однако их возможности в этой области гораздо меньше, чем у лог-анализаторов. У Livelnternet это называется «срезы», у SpyLOG’а и Google Analytics – сегменты. Также у счетчика Google Analytics есть возможность настройки «целей», то есть посещения целевых страниц. В этом случае система будет автоматически собирать отдельно статистику по всем посетителям, достигшим определенной целевой страницы (с какой рекламной площадки пришли, какие страницы посмотрели, сколько времени провели на сайте и проч.). Этих возможностей счетчиков в большинстве случаев достаточно для анализа эффективности интернет-маркетинга.

СТАТИСТИЧЕСКИЕ МОДУЛИ CMS (content management system) – система управления содержанием сайта, часто имеет собственный статистический модуль, перерабатывающий статистику сайта. Такая система выдает статистические отчеты точно так же, как счетчик или лог-анализатор. В основе статистики CMS могут лежать разные исходные данные, как лог-файлы, так и данные, полученные при помощи косвенных измерений, как это делает счетчик. У грамотно спроектированного модуля есть еще один важнейший источник данных – собственно данные CMS: регистрационные данные пользователей, стоимости товаров, названия страниц, использованные скидки, приведшие клиента аффиляты и т. д. – вся та информация, которая позволяет получить качественно новые знания о посетителе сайта.

Статистический модуль, встроенный в CMS, может сочетать бизнес-статистику сайта со статистикой поведения пользователя, то есть получить несравнимо больший объем статистики, причем статистики, непосредственно отражающей работу сайта как бизнеса. Важно также, что эта статистика более понятна и наглядна – она выражена непосредственно в деньгах и продажах.

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