Содержание
Однажды при общении с коллегами из AdRiver выяснилось, что далеко не все клики по рекламным объявлениям становятся переходами на целевой сайт. Для меня было бы нормальным услышать, что теряется 5-10% посетителей (вполне естественные цифры в рамках общей погрешности измерений). Но, как оказалось, потери могут составить до 50%. И мы решили разобраться подробнее, где же происходят утечки, почему обычные, здоровые, адекватные клики не становятся переходами.
Препятствие 1: на этом берегу
Почти всегда перед переходом на сторонний сайт с сайта рекламодателя происходит незаметный для обычного пользователя заход на страницу учета клика. Страница эта ничего не делает, кроме того что просто фиксирует переход по рекламному объявлению и отправляет (редиректит) пользователя дальше. И даже не для всех рекламных сетей актуально такое поведение — только если идет учет кликов (CPC) или действий (CPA), когда нужно строго считать каждое пользовательское действие. Но иногда и реклама, продаваемая по CPM (фиксированная стоимость за тысячу показов), тоже учитывается подобным образом: между сайтом-рекламодателем (где объявление показывается и где происходит клик) и целевым сайтом (на который должен перейти пользователь) пользователь заходит на рекламный сервер, который нужен просто для учета самого факта захода (клика) и который в дальнейшем использует информацию о заходах пользователей для построения аналитических отчетов.
На потери кликов это препятствие никак не влияет: между фиксацией клика и переходом на целевой сайт нет никаких лишних действий со стороны пользователя. Но при определенных условиях данный шаг (особенно, если происходит не один редирект, а несколько) может занимать существенное (от 1 секунды и выше) время, что приводит к увеличению потерь на следующих шагах. Ведь пользователь при редиректах видит белый экран в браузере и не знает, покажется ли ему целевой сайт после N секунд ожидания или нет.
Что можно сделать: если есть возможность учитывать действия пользователя через JavaScript (отправка невидимых пикселов на сервер статистики для тех пользователей, которые это могут делать) — то так и нужно поступать. Дополнительно нужно сводить DNS-запрос для сервера статистики к 0 (обычно именно он занимает большую часть времени ожидания при редиректах), сделать это можно, вызывая прозрачный пиксел с этого домена при загрузке рекламного объявления (либо производить загрузку объявлений с того же домена, что и производит учет переходов): браузер сделает обычный запрос к сайту, закэширует DNS ответ и в течение ближайшего времени сможет его использовать. И, естественно, нужен круглосуточный мониторинг доступности и работоспособности как сервера учета статистики, так и серверов показа объявлений, в том числе для того чтобы время ответа не превышало минимальных (10-20 мс) значений.
Потери: до 1,5% кликов, почти всегда это нецелевые заходы. И эти потери, если и происходят, рекламной сетью никак не фиксируются (поскольку происходят еще до записи самого факта клика).
Препятствие 2: локальная недоступность
Наиболее известная проблема, на которую пытаются списать все беды и потери. Связана с тем, что соединение конкретного пользователя с конкретным сайтом происходит далеко не всегда, когда и сайт и пользователь есть в Интернете. Если и сайт, и пользователь в Москве, то ситуация более-менее стабильная, потери составляют обычно не более 0,001%. Но если сайт расположен где-нибудь в Европе (на популярных сейчас немецких площадках), а пользователи находятся за Уралом, то потери уже совсем не такие мизерные и могут составить до 3% кликов.
Сюда же стоит отнести не только проблемы сетевой доступности веб-ресурсов, но и проблемы большого времени ответа от сервера, которые эти проблемы могут усугублять (и для пользователей, по большому счету, нет никакой разницы, почему их браузер не смог открыть сайт: потерялись пакеты по дороге или браузер не дождался ответа от сервера). Нормальным считается время ответа сервера до 200 мс (с учетом всех сетевых задержек, поэтому если у вас пользователи находятся по всей России, то сервер должен стоять строго в Москве и отдавать страницы не более чем за 100 мс): в этом случае пользователи проблем с сервером замечать не будут. Даже для крупных ресурсов до 1% пользователей не успевают дождаться ответа от сервера (типичная ситуация, когда в пути у мобильных пользователя меняется базовая станция, и нужно отправлять запрос повторно, если ответ от сервера не пришел достаточно быстро).
И конечно, сам сайт может тоже быть физически недоступен из-за большой посещаемости или проблем на сервере (проблемы с отказоустойчивостью сайта проверяем через loadimpact.com). Но обычно доля таких проблем (для качественных и надежных сайтов) невелика, до 0,1%.
Что можно сделать: нужно диагностировать проблемы с подключением у целевых пользователей к сайту. Сделать это можно при помощи мониторинга доступности из нескольких точек (даже лучше использовать несколько сервисов мониторинга, чтобы максимально расширить диапазон). Далее нужно либо переносить сайт на другую хостинговую площадку (у которой будет существенно меньше проблем с доступностью), либо сразу списывать зафиксированное количество потерь из рекламного бюджета: эти пользователи до сайта не дойдут.
Потери: 1-10% кликов.
Препятствие 3: в пути
О следующей категории препятствий вы, наверняка, слышали, но никогда не думали о ней именно в таком ключе — воришке, который крадет деньги из вашего кармана. Речь идет о белом экране в браузере пользователей, которые зашли на ваш сайт. Это типичная проблема медленных сайтов, и она решается тоже вполне типичными методами: сжатие данных, объединение файлов стилей и их минимизация, перенос клиентской логики (JavaScript) в конец страницы или максимальное ее облегчение, если требуется загрузка в начале страницы. Согласно исследованию WEBO Software скорости интернет-магазинов, сейчас стадия белого экрана для популярных сайтов для большинства пользователей составляет не более 1,5 секунд. Это хорошее значение, и оно гарантирует посещение сайта для абсолютного большинства пользователей (клики перейдут в переходы), но если у пользователей есть проблемы с подключением (регионы, мобильный интернет), то время ожидания существенно возрастает.
Самое интересное, что, практически, все счетчики не фиксируют отказы пользователей на этой стадии загрузки сайта: они сами еще не загрузились, чтобы что-то считать.
Что можно сделать: применить максимум методов клиентской оптимизации (FEO) для ускорения сайта, чтобы свести время белого экрана (до события DOMready) к 1-1,5с на подключении 5 Мбит/с — можно использовать www.webpagetest.org для проверки результата.
Потери: 2-10% кликов. В большинстве случаев это нецелевые заходы: пользователи успевают закрыть браузер раньше, чем будет зафиксирован их переход на целевой сайт.
Препятствие 4: почти приплыли
Проблема здесь заключается в том, насколько далеко (по ходу загрузки страницы) стоит счетчик и как долго он отправляет данные. Если полная загрузка страницы может составлять несколько (десятков) секунд, то пользователь может просто не дождаться счетчика и закрыть страницу (или перейти по ссылке) раньше. Здесь и происходят потери. По большому счету, потери на данном этапе характеризуют тот самый показатель отказов, который все стараются уменьшить (но, как видно из статьи, это лишь верхушка айсберга реальных проблем с доступностью сайта). Естественно, при ускорении сайта показатель отказов, связанный только со скоростью (временем загрузки страниц сайта) уменьшается. Реальное уменьшение показателя отказов возможно на уровне 2-10% (когда сайт становится существенно быстрее, и пользователи уже склонны на нем остаться, т.е. скорость сайта перестает влиять на решение пользователей о посещении этого сайта).
В случае медленных сайтов (перегруженных графикой или интерактивными элементами) всегда будет значительное количество отказов, связанных со скоростью. Но при грамотном подходе до 80% таких отказов можно устранить.
Что можно сделать: применить все известные техники клиентской оптимизации — начиная от сжатия текстовой информации и оптимизации изображений и заканчивая отложенной загрузкой второстепенных информационных блоков (виджетов). В случае «тяжелых» сайтов имеет смысл разработать «легкую» версию (для региональных или мобильных пользователей), на которую можно будет переключать пользователей (например, даже динамически — на стадии белого экрана без дополнительных редиректов) и максимально снижать показатель отказов тем самым. Задача — максимально снизить значение времени полной загрузки страницы (onload). Это время как скорость сайта показывает Google Analytics и учитывает Google Webmasters, для замеров можно использовать указанный в предыдущем пункте сервис — www.webpagetest.org.
Потери: 3-20% кликов.
Препятствие 5: был ли суслик?
Еще одна известная проблема, которую также любят использовать при аргументации, почему происходят потери кликов: расхождение данных счетчиков. Даже при использовании одной системы статистики для учета и кликов, и переходов возможны незначительные отклонения (рассинхронизация собранных данных, погрешности учета). При использовании же различных систем для учета кликов и подсчета переходов на сайт расхождения могут быть еще значительнее. По нашему опыту, расхождение между данными разных счетчиков может составлять до 20%. Почему так происходит?
Счетчики используют разные гео-базы (разное соответствие IP адресов и городов/стран). Это приводит к тому, что пользователи из России учитываются как пользователи из других стран. Или наоборот: российские IP-адреса используются зарубежными пользователями. Особенно плачевно состояние гео-баз по городам России, точность составляет около 80%. Также счетчики используют разные схемы учета пользователей с множеством нюансов: как выставляются cookie (с того же домена через JavaScript или со стороннего — через HTTP-заголовки); как учитываются пользователи с одним IP (корпоративные пользователи) — по браузеру, по cookie; как пользовательские устройства (особенно, мобильные) воспринимают cookie (устанавливают, не устанавливают).
Что можно сделать: использовать единый счетчик (базу) для учета и кликов, и переходов. Это сведет к минимуму возможные расхождения показателей.
Потери: 1-10% кликов.
Заключение
Как мы видим, вроде бы незначительные и малозаметные проблемы в совокупности могут приводить к существенному снижению эффективности рекламных кампаний в Интернете (до 50% потери рекламного бюджета в силу различных причин). Перед запуском рекламном кампании (или подключения нового канала привлечения пользователей) необходимости провести аудит всех шагов загрузки сайта и убедиться в отсутствии значительных проблем.
