Как живут баннеры в 2019 году
Есть популярное мнение, что баннерная реклама уже не работает. О баннерной слепоте написано много статей и исследований. Это правда, но не вся.
Действительно, мы обращаем меньше внимания на рекламу, которая пытается отвлечь нас от основного содержания страницы. Но сейчас технологии позволяют экспериментировать с механиками отображения контента и взаимодействием пользователей.
Например, мы делали баннер, у которого была нестандартная механика: пользователь делал селфи, а оно затем отправлялось на наш сервер и публиковалось в соцсетях. Именно из-за этой механики — когда файлы по внешнему запросу уходили на сторонний сервер — Google тестировала наш Мasthead-баннер для YouTube вручную.
Несколько дней нам приходили фотографии их тестировщиков, офиса. Судя по всему, офис располагался в Индии, хотя геометок мы, конечно, не получали. Было интересно.
Проще всего сравнить баннеры с небольшими страницами на HTML5, CSS и JavaScript. Они могут быть частью других сайтов или выступать в качестве самостоятельной мини-страницы. Код помогает реализовать в баннерах любую анимацию и интересные игровые механики. Например, такие:
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
Баннеры могут представлять собой мини-игры или, к примеру, содержать интерактив с использованием веб-камеры
Сложность в том, что у площадок, на которых размещаются баннеры, есть жёсткие технические ограничения. Эти ограничения — головная боль при разработке баннеров. В этой статье расскажем про то, как мы с ней боремся.
Какие ограничения есть у баннеров
Чтобы загрузить баннер на рекламную площадку или сеть, он должен соответствовать техническим требованиям (ТТ). На данный момент мы выделили 25 характеристик, большую часть которых мы проверяем в автоматическом режиме при сборке баннера. Для простоты мы делим все требования на пять категорий:
1. К коду баннера: поведение при нажатии на баннер, метатеги. Полностью автоматизируемые.
2. К наличию изображений-заглушек. Их создание мы автоматизируем собственным инструментом.
3. К кроссбраузерности и нагрузке на процессор. Это довольно сложно автоматизировать, поэтому пока фича в планах.
4. К дизайну. Автоматизировать невозможно, можно только отслеживать часть требований, например запрет на использование кислотных цветов в баннере.
5. Субъективные критерии, такие как частота анимации, которые сложно оценивать. По ним принимают решение люди на площадке, поэтому мы можем только учитывать эти моменты на основе опыта.
Какие требования площадок можно автоматизировать
1. Вес баннера
Вес — ключевое требование у всех площадок. Мы называем его проблемой 150 Кб — именно такое ограничение ставит большинство площадок. Чтобы не проверять это вручную после сборки баннера, у нас выводится отчёт, который показывает размер каждого файла и предупреждает о превышении размера.
В последней колонке указывается относительный размер файла в архиве по сравнению с исходным файлом
Площадки принимают как отдельные файлы, так и в архиве. По отчету видно, что архив даёт больше свободы разработчикам. Например, файл JavaScript стал меньше на 66%. В итоге мы можем упаковать в архив не 150 Кб, а в два-три раза больше. Значит, можем добавить более проработанные анимации и качественные изображения.
При превышении лимита чаще всего мы сжимаем изображения. Если качество получается неудовлетворительным, то тогда мы обсуждаем изменение креатива. Например, убираем какие-то кадры из анимации. Но это вопрос управления проектом и согласований, а не технических инструментов оптимизации.
В будущем мы хотим сделать проверку на ограничение веса каждого файла в баннере с предложениями по способам уменьшения веса.
2. Изменения в коде, необходимые для площадки
У каждой крупной рекламной сети — например Google, Adfox, Adriver, Яндекса — есть собственные инструменты по загрузке материалов. Чтобы баннеры правильно работали на площадке, нужно заранее подготавливать код под технические требования.
Возьмём, к примеру, переход по ссылке из баннера на сайт заказчика. Для Яндекса он должен выглядеть так:
В код автоматически вставляются ссылки, методы и теги для работы с конкретной площадкой. В этом случае — с Яндексом
Кроме правильно прописанных ссылок, нужно вставлять в код мета-теги — служебную информацию, такую как размер баннеров, для площадок. У каждой — свои требования. Когда площадок больше десяти и у всех разные требования к коду, есть риск запутаться и что-то забыть. Поэтому работу с кодом для каждой площадки мы автоматизировали полностью.
3. Предупреждение о необходимости заглушки
Заглушка — это изображение, чаще всего анимированное, которое показывается пользователям устаревших версий браузеров. Если площадка требует заглушку, у нас в отчёте выводится предупреждение. А дальше мы создаём её с помощью собственного инструмента — для этого достаточно нажать одну клавишу.
В планах: автоматизировать работу с самой программой, чтобы не приходилось нажимать эту кнопку. А также проверять вес заглушки и выводить рекомендации по уменьшению веса изображения.
Даже если не получается полностью автоматизировать процесс, важно выводить отчёты с предупреждениями после каждой сборки баннера. В этом случае отчёт выполняет роль чеклиста, который помогает ничего не забыть перед отправкой баннера заказчику.
4. Инлайнинг
Инлайнинг применяется, чтобы в одном файле собрать несколько других. Каждый файл в баннере — это дополнительный запрос к серверу; чем их больше, тем дольше общее время загрузки баннера. Поэтому площадки требуют, чтобы файлов было не больше десяти, например.
Base64 — это бинарный код в текстовом формате, который напрямую обрабатывается браузером. Так можно закодировать не только изображения, но и вложения к электронной почте, например
Причём в один файл можно собрать не только код, но и изображения. У нас это происходит автоматически с помощью кодировки Base64. Принцип работы чем-то похож на формат SVG: у вас есть изображение, которое экспортируется в код и рендерится браузером. Только SVG генерирует код, понятный человеку, а Base64 — просто шифр.
Что автоматизировать сложно
У площадок есть субъективные критерии или требования, которые сложно автоматизировать.
Пример субъективного критерия — это частота мелькания анимации. Такие критерии часто проверяют люди на площадке. Один человек может сказать, что баннер слишком часто мерцает, а другой — что всё в порядке. В этом случае присутствует человеческий фактор, который сложно предугадать.
Есть объективные требования, которые сложно автоматизировать — к ним относятся кроссбраузерность, нагрузка на процессор, лимит на время анимации. Если с первыми двумя понятно, то последнее требование нужно объяснить.
Допустим, у нас есть такой баннер:
Каждая анимация двигается со своей скоростью, поэтому не получится написать условно «стоп» в коде и остановить их все одновременно
Через тридцать секунд он должен остановиться не на последнем кадре (с лого), а за кадр до этого. Все анимации тоже должны замереть: неба, гор, солнца, покачивания автомобиля, отражения на лобовом стекле, колёс, смены текстов. У каждой свой таймер, поэтому нет общего действия, после которого можно считать, что анимация точно остановилась.
Единственное надёжное решение для автоматизации — когда программа смотрит как бы человеческими глазами и сравнивает предыдущий кадр с текущим. Только так мы можем проверить остановку программным способом во всех случаях.
Почему не остановиться на варианте, когда человек отслеживает остановку анимации? Это долго, а всё что долго — дорого. Баннеров может быть 10, 100 или 500, и тогда 30 секунд на проигрывание баннера превращаются в 15 000 секунд чистого рабочего времени (более 4 часов).
На самом деле времени может уходить и больше, если учитывать изменения в баннерах после согласований и делать проверку. Человек устаёт, поэтому растет шанс упустить деталь. С компьютером такой проблемы нет. Вдобавок можно программно увеличить скорость проигрывания и тестировать баннер за секунду, а не за тридцать.
Для проверки кроссбраузерности, нагрузки на процессор и лимита на время анимации нужно разрабатывать отдельные решения. Полноценные программы, на которые уйдёт много ресурсов. Пока мы обходимся меньшими усилиями и оптимизируем эти процессы с помощью чеклистов, гайдлайнов и внутреннего тестирования.
Что даёт нам автоматизация
Даже если баннер собирается за десять секунд, работы по подготовке баннеров по техническим требованиям по-прежнему будет много. Рутина никуда не уйдёт. Требования будут меняться, некоторые будут субъективными или сложнопроверяемыми. Но сэкономив время на рутине, мы можем уделять больше внимания качеству других работ на проекте.
Благодаря автоматизации мы берём на 30% больше проектов, не увеличивая штат разработчиков и не меняя часовую ставку. А значит — сокращаем время разработки и стоимость каждого проекта.
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.
Источник: