Однажды при общении с коллегами из 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% потери рекламного бюджета в силу различных причин). Перед запуском рекламном кампании (или подключения нового канала привлечения пользователей) необходимости провести аудит всех шагов загрузки сайта и убедиться в отсутствии значительных проблем.
