Push-реклама

Происхождение и история термина

Слово push обозначает передачу информации по инициативе отправителя: человек не должен каждый раз открывать сайт и проверять обновления. Отсюда название канала, который может обслуживать и полезные оповещения, и рекламу. ^[3]

Развитие такого общения видно по первичным документам. В марте 2009 года Apple представила бета-версию iPhone OS 3.0 с сервисом push-уведомлений, позволявшим приложениям привлекать внимание звуком, текстом или значком. ^[9] В апреле 2015 года команда Chromium описала переход аналогичной возможности в веб: Chrome 42 поддерживал подписку на уведомления сайтов на Android и настольных компьютерах. Среди ранних участников были названы eBay, Beyond the Rack и VICE News. ^[6]

Так развивался способ возвращать внимание пользователя к сервису без нового посещения сайта. Рекламный смысл появляется, когда через него передают коммерческое предложение; сегодня правила Apple отдельно регулируют именно продвижение и прямой маркетинг через push. ^[7] Эти вехи показывают развитие явления, но не устанавливают единственного изобретателя push-рекламы или дату её первого размещения.

Суть и механизм

Рассмотрим обычную веб-схему. Сайт получает разрешение на уведомления и создаёт подписку — технические данные, позволяющие адресовать сообщения конкретному браузеру. При отправке сервер сайта обращается к push service, то есть службе доставки. Та передаёт данные браузеру, который запускает Service Worker — фоновый обработчик сайта, способный принять сообщение без открытой страницы. Обработчик может вызвать показ уведомления. ^{[1, 3]}

Показом управляет Notifications API. API — программный интерфейс, набор доступных программе команд. Здесь он позволяет задать заголовок, текст и действия уведомления; отображение выполняется средствами устройства, обычно за пределами самой веб-страницы. ^{[2, 4]} Поэтому красивый прямоугольник внутри статьи ещё не означает, что сайт использовал системные уведомления.

Учебный пример: книжный магазин сообщает подписчику о начале распродажи. Сервер передал запрос службе доставки, но компьютер покупателя пока не подключён к сети. Данные могут ожидать доставки; отправитель также может ограничить время таких попыток. ^[3] Запись об отправке сама по себе не показывает, появилось ли предложение перед покупателем.

Описанная цепочка не единственная. Рабочий проект Push API от 5 октября 2026 года содержит declarative push: сообщение передаёт описание уведомления в формате данных JSON, которое понимает браузер. Этот подход не требует обязательного выполнения обработчика Service Worker для каждого показа. Наличие механизма в проекте спецификации не означает его поддержку всеми браузерами. ^{[1, 2]}

Виды и классификации

Для понимания рекламы полезно редакционное разграничение: уведомления сайта, уведомления установленного приложения и визуальные имитации внутри страницы. Первые два случая используют уведомления соответствующей среды; третий описывает оформление элемента страницы. Это не универсальная классификация рекламных сетей: при покупке размещения следует уточнить, что именно называют push. ^{[4, 7]}

Отдельная, техническая классификация есть в Notifications API. WHATWG различает уведомления без привязки к Service Worker и связанные с ним — non-persistent и persistent. MDN поясняет различие через время жизни: взаимодействие с первым связано с открытой страницей, второе может оставаться доступным после её закрытия. ^{[2, 4]} Слово persistent здесь не обещает, что сообщение останется на экране навсегда.

По содержанию важно отличать предложение купить товар от сообщения об обслуживании. Учебный пример: «Заказ передан курьеру» описывает исполнение покупки, а «Посмотрите новую коллекцию» предлагает новый выбор. Юридическая квалификация зависит от содержания и обстоятельств распространения, а не от одинакового вида карточек; российское определение рекламы дано в статье 3 закона о рекламе. ^[5]

Как применяется на практике

Международная практика показывает, что возможность отправить сообщение и право использовать её для продвижения — разные вопросы. Пункт 4.5.4 App Review Guidelines допускает рекламные push-сообщения при явном согласии пользователя, оформленном через текст в интерфейсе приложения, и наличии способа отказаться от них внутри приложения. Это правило Apple, а не общий закон для всех платформ. ^[7]

Учебный пример для российского магазина: посетитель согласился получать уведомления о наличии выбранной книги, а магазин хочет сообщить ему о платном курсе партнёра. Редакционный разбор начинается с вопроса, на какие сообщения человек согласился. Кнопка браузера подтверждает разрешение показывать уведомления от сайта; содержание рекламного согласия оценивают отдельно. ^{[4, 5]}

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

Как измерить или проверить

Сначала определяют, какие события система действительно фиксирует. Доставка данных и показ разделены технически; документация также описывает обработку нажатия на уведомление. ^{[1, 2]} Из этого следует практическое правило: отчёт должен объяснять каждый счётчик, а отсутствующий показатель нельзя восстанавливать простым переименованием соседнего.

CTR, или кликабельность, — отношение числа кликов к числу показов. Так показатель определяет справка Google Ads; для выражения в процентах отношение умножают на сто. ^[8]

Учебный пример: за сутки отправлены 10 000 сообщений, зарегистрированы 8 000 показов и 200 кликов. Предположим, что все счётчики относятся к одной рассылке и одному периоду, а правила регистрации событий согласованы. CTR составит 200 / 8 000 × 100% = 2,5%. Отношение кликов к отправкам равно 200 / 10 000 × 100% = 2%. Оба расчёта верны, но отвечают на разные вопросы. Если доступны только отправки и клики, второй результат нельзя выдавать за первый.

В этом же примере после переходов завершены 20 регистраций на урок. Для учебного разбора доля регистраций относительно кликов составляет 20 / 200 × 100% = 10%. Это выбранное отношение событий, а не доля всех подписчиков. Число регистраций помогает увидеть продолжение пути после нажатия, но само по себе не объясняет, почему человек записался.

При нулевом знаменателе отношение не определено. Если показов не зарегистрировано, нельзя сообщать нулевой CTR без уточнения: возможно, показов действительно не было, а возможно, система их не измеряет. Для сравнения двух рассылок также нужны одинаковые правила подсчёта повторных событий.

Ошибки, ограничения и спорные вопросы

Главная ошибка — считать уведомление гарантированным контактом. Подписка может быть деактивирована, после чего сообщения по ней не должны доставляться. ^[1] Даже техническое отображение не равнозначно прочтению: событие показа и действие пользователя описаны в стандарте раздельно. ^[2]

Другая ошибка — обещать одинаковую работу на всех устройствах. MDN указывает ограничения доступности Notifications API; формат и поведение уведомлений зависят от среды. ^[4] Поэтому перед кампанией разумно проверить фактическую цепочку на нужных устройствах: подписку, получение, внешний вид, переход и отказ. Это редакционная процедура проверки, а не гарантия охвата.

Правовой аспект

В России часть 1 статьи 18 закона № 38-ФЗ требует предварительного согласия адресата на рекламу по сетям электросвязи. Наличие согласия должен доказать рекламораспространитель; по требованию адресата распространение необходимо немедленно прекратить. Используется редакция закона от 04.08.2026, проверенная 30.10.2026. ^[5]

Для конкретной push-кампании юрист оценивает применимость нормы, текст согласия и доказательства его получения. Техническое разрешение не снимает этих вопросов. Правовой раздел объясняет общее требование к согласию и не заменяет проверку конкретного размещения.

Частые вопросы

Связанные термины

• email-marketing
• retargeting
• CTR (кликабельность)
• cpc
• posadochnaya-stranitsa
• push-uvedomleniya-smi