Pull уведомления что это
Push-уведомления: что это такое, как они работают и какому бизнесу нужны
Блочный редактор писем, готовые шаблоны email, формы подписки и автоматизация. Запускайте email-рассылки, чтобы быть на связи со своими клиентами.
Push-уведомления или пуши — всплывающие сообщения на экране компьютера или телефона. Такие оповещения отправляют пользователям, чтобы рассказать об услугах, акциях, новостях и обновлениях. Пуши бывают разных форматов: оповещения в соцсетях и приложениях, рекламные пуши, системные уведомления.
В этой статье я расскажу о рекламных пуш-уведомлениях в браузере, для чего они нужны, как работают, в чем плюсы и минусы их использования.
Виды push-уведомлений
Системные пуши. Автоматические сообщения от операционной системы, мобильных, десктопных программ и приложений об изменениях или обновлениях.
Пуши в мобильных приложениях. Пользователи получают короткие уведомления от приложений, если включают в настройках разрешение на их показ. В таких сообщениях бывают инструкции, напоминания, призыв к конкретному действию. Мобильные пуши побуждают пользователя открывать приложение чаще.
Web-пуши. Пользователи должны разрешить сайтам присылать web-уведомления. Запрос на показ пушей появляется на сайте в виде всплывающего окна в браузере и предлагает варианты: «Разрешить» и «Блокировать».
После разрешения на показ уведомлений пользователь становится подписчиком web-пушей от сайта. Сами пуши отображаются в правом нижнем углу рабочего стола, а их частоту появления определяет владелец сайта. Отказаться от подписки на уведомления можно в настройках браузера.
Web пуш-уведомление состоит из заголовка, картинки/лого компании, основного текста, ссылки или кнопки.
Для чего бизнесу нужны push-уведомления
Цель пуш-уведомлений — рассказывать подписчикам о полезном контенте, новостях, услугах, продуктах, акциях. Пуши помогают установить контакт с новыми подписчиками и поддерживать интерес действующих. Так например, подключение сервиса по настройке пуш-уведомлений Gravitec повысило посещаемость сайта онлайн-медиа Prensa Libre на 300 000 пользователей в месяц.
Интернет-издания и блоги используют пуши, чтобы рассказать о срочных новостях и новых материалах. Пользователи получают уведомления даже если сайт закрыт на устройстве.
Магазины и торговые сети рассылают оповещения о начале распродажи, акции или поступлении товара. Обычно в таких уведомлениях есть кнопка с призывом к действию.
Некоторые интернет-магазины настраивают уведомления о брошенной корзине — напоминание о том, что пользователь добавил товары в корзину, но не оформил покупку. У сервиса по настройке и рассылке пушей PushEngage есть кейс о том, как австралийский маркетплейс MyDeal увеличил выручку на 20% и повысил конверсию на 4% с помощью оповещений о брошенной корзине.
Некоторые сайты присылают приветственные пуши сразу после подписки и дают ссылки на полезную информацию для подписчиков.
Можно привлекать внимание подписчиков конкретными материалами в блоге.
Как настроить push-уведомления в мобильных приложениях
В начале пользователь разрешает приложениям отправлять уведомления в настройках.
Отправитель использует сервисы пуш-уведомлений в зависимости от операционной системы телефона получателя: Firebase Cloud Messaging (FCM), Apple Push Notification Service (APNS), HUAWEI Push Kit.
С помощью сервисов отправитель настраивает сбор мобильных токенов (идентификаторы устройств пользователей) — на этом этапе потребуется помощь разработчиков приложения. Затем сервер приложения использует токен, чтобы отправить пуш на устройство пользователя.
Как настроить web-пуши
Настроить и запустить push-уведомления для браузера относительно легко — для этого есть специальные сервисы. Схема работы push-уведомлений выглядит так:
Как работают сервисы по настройке пушей разберем на примере двух русскоязычных платформ.
Gravitec.net
Настраивайте работу пушей пошагово сразу после регистрации: добавьте адрес сайта, выберите внешний вид формы подписки и подключите ее.
Что можно сделать в сервисе:
Цена. Есть бесплатный тариф без ограничений по количеству рассылок, но с ограничением до 10 000 подписчиков. Тариф Business стоит от 280 руб./месяц, цена зависит от количества подписчиков.
Язык. Русский, украинский, английский, испанский, польский, португальский.
Push4Site
Подробная пошаговая настройка работы пуш-уведомлений в три этапа: добавление сайта, настройка запроса на подписку, получение кода для вставки на сайт.
Что можно сделать в сервисе:
Цена. 30 дней бесплатный тестовый период. Далее — от 990 руб./месяц (зависит от количества подписчиков).
Язык. Русский, английский, нидерландский.
На что обратить внимание при настройке рассылки web-пушей
Частота. Выбирайте умеренный график рассылки пушей — от частых уведомлений пользователи быстро устают и отписываются, а редкие могут пропустить. Частота зависит от особенностей бизнеса и контента сайта. Проанализируйте целевую аудиторию, протестируйте варианты и определите оптимальный график рассылки пушей. Например, оповещения о новых статьях в блоге присылайте по факту выхода материалов, а интернет-магазинам можно напоминать о себе раз в 2-3 дня. Регулярно отслеживайте статистику переходов и отписок, чтобы вовремя изменить частоту рассылки.
Содержание и польза. Пуши — короткий формат, в котором важно донести полезное сообщение клиенту и уложиться в количество знаков. Количество символов для заголовка и основного текста может отличаться в разных сервисах. Из текста пуша подписчик должен понять, почему ему нужно открыть уведомление, в чем для него польза — срочная новость, ссылка на новую статью по интересующей теме, нужный товар или акция.
Способы взаимодействия сервисов друг с другом. Пулинг/пуш. Достоинства/недостатки. Выбор
Курьер доставил заказ. По смене статуса заказа надо уведомить заинтересованные стороны об этих событиях.
Клиент отправляет сообщение в чат поддержки. Нужно уведомить сервисы поддержки о поступивших данных от клиента.
Построение отчёта завершено. Ожидающий отчёт пользователь может его загрузить. Надо его уведомить об этом.
Знакомые/типовые ситуации. Одному сервису надо уведомить другой (другие) о происшедших событиях.
Давайте немного усложним:
Какие способы уведомления есть?
Активность со стороны сервера
Это, в общем-то, типовое решение. Сервер держит список заинтересованных сторон. По мере появления событий выполняет HTTP-запросы к клиентам.
Подвариант этого решения: Websocket. Сервер отправляет события в сокеты всем подписанным сторонам.
Повторы, обработка ошибок
Рано или поздно любой TCP/HTTP-канал сталкивается с недоступностью другой стороны. Что делать после возникновения ошибки? Повторять запросы? Что делать с вновь поступающими запросами? Ждать, пока успешно выполнятся предыдущие?
Рассмотрим виды ошибок:
Получив неустранимую ошибку, клиент может только записать её в лог. То есть, если полная остановка доставки сообщений не приемлема, то, получив неустранимую ошибку, типовым решением будет считать, что «уведомление доставлено», и переходить к доставке следующих уведомлений. Вероятно, это единственный нормальный путь.
Идя по этому пути, надо постоянно и внимательно следить за мониторами таких ошибок. Анализировать трафик на тему «почему возникла неустранимая ошибка?» и «можно ли жить дальше с этой ошибкой».
Но это не самая большая проблема.
Более интересными являются проблемы:
500-е ошибки
Мы выполняем запрос-передачу данных для сервера X. Происходит 500-я ошибка. Что это?
Возможны два варианта:
Сервис-приёмник данных по какой-то причине именно сейчас не работает (перегружается, переключается БД итп). В этом случае повтор запроса в дальнейшем приведёт нас к успеху.
В сервисе допущена ошибка, приводящая к 500. В этом случае, сколько бы повторов мы ни сделали, до исправления кода в приёмнике ситуация не изменится.
То есть, по повторяемости запросов ошибки у нас делятся на три вида:
Те, которым повтор поможет (сетевые, устранимые 500-ки).
Те, которым повтор не поможет, но выглядят как те, которым поможет (неустранимые 500-ки).
Те, которым повтор не поможет (например 40x-ки).
Разрабатывая политику повторов, помимо указанной проблемы, имеем ещё множество других проблем:
Как часто повторять запросы?
Не будем ли мы «укладывать» внешний сервис, повторяя запросы?
Не будем ли сами «укладываться», если одна из внешних систем по какой-то причине имеет некорректный TCP-стек ( iptables DROP )?
Если посмотреть на систему повторов запросов, то обнаружится, что практически в каждом случае она выбирается индивидуально.
Если сервис, генерирующий событие, и занимается доставкой его до заинтересованных сторон, то имеем
минимальный лаг доставки
минимальная нагрузка на хранилище сообщений;
необходимость повторов в случае неуспеха доставок
необходимость ведения реестра, кому что доставлено и кому что нужно доставить
двусмысленность некоторых ошибок: непонятно, можно (нужно) ли повторять, или нет
система повторов может быть причиной DDoS для клиентских сервисов.
Также есть некоторое количество организационных минусов:
После того, как клиент прекратил де-факто работу (тут два варианта: сервера выключены, сервера не выключены), система продолжает доставлять ему уведомления.
Вебсокет в режиме клиент-сервер
Часть описанных проблем решает постоянное соединение, инициируемое клиентом. Однако именно часть.
Пулинг
Достоинства пулинга
Максимально быстрое восстановление работоспособности после факапов.
Недостатки пулинга
минимальный лаг доставки сообщений равен интервалу пулинга, который обычно выбирается ненулевым
множество сервисов пулящих один создают существенно бОльшую нагрузку, нежели случай с активным сервисом. Сервисы, для которых нет сейчас никаких сообщений, всё равно создают нагрузку на подсистему доставки сообщений.
Ещё один неочевидный, организационный недостаток пулинга: часто способ получения новой порции данных связан со структурой хранения данных.
отсутствие двусмысленности, описанной выше
наиболее быстрое восстановление работоспособности после сбоя
максимальная независимость от сетевого стека TCP на клиенте
нет необходимости хранить/майнтенить список клиентов.
Лаг доставки
Как правило, запросы для пулинга формулируются как «есть ли данные для меня; если есть, то какие?». Такие запросы (в случае, если они некорректно спроектированы) зачастую имеют следующие проблемы:
при перегрузках количество данных в ответе может расти, или время выполнения запроса ухудшаться.
В случае, если получение очередной порции данных сопровождается простой выборкой из BTREE индекса, то и ответ на вопрос «есть ли данные?», как правило, сравнительно бесплатен. Об индексах поговорим ниже.
А сейчас давайте рассмотрим алгоритм работы традиционного пулера.
Обрабатываем полученные данные
Пауза соответствующая интервалу
Если рассматривать этот алгоритм, то видим, что переменная index и есть то, что связывает нас со структурой хранения данных.
Такой алгоритм, как правило, используют новички и. приводят себя к трудноустранимой проблеме: запросы с большими значениями index сделать индексируемыми крайне сложно. Почти невозможно.
Почему разработчик попадает в такую ситуацию? Потому что проектирует БД и API отдельно друг от друга. А нужно посмотреть на все компоненты в целом и на влияние их друг на друга.
Проблема состоит в том, что в БД, как правило, данные хранятся в виде плоских таблиц. Когда мы получаем очередную порцию данных с одними и теми же условиями фильтрации, то приходится делать что-то вроде следующего:
Как сделать план независящим от положения смещения? Использовать вместо смещения выборку из индекса:
Первичная инициализация. index := 0
Выполняем запрос limit данных, передавая в запрос index
Пауза, соответствующая интервалу
В системе с такой архитектурой, как правило, уже нет существенных препятствий к снижению интервала до минимальных значений (вплоть до нуля).
Но давайте ещё порефлексируем над архитектурой. Что плохого в ней?
Алгоритм привязан к структуре данных
Выполняется практически полностью на стороне клиента
Вследствие предыдущей проблемы сложно, например, централизованно модифицировать его на иную работу после факапов/проблем.
Пользователь может сам подставлять в index произвольные значения. Иногда это может быть нежелательно или приводить к багам, которые разработчику сервера сложно понять.
Давайте ещё раз модифицируем алгоритм. Заменим index на state и управлять им будем с сервера:
Выполняем запрос limit данных, передавая в запрос значение state
Что мы получили? Гибкость.
Переменная state определяется только сервером и не обязана быть привязанной к числу смещения. При желании в этой переменной можем хранить JSON со многими полями.
Если в переменной state хранится не только позиция окна, а, например, и значения фильтров и криптоподпись, то эту переменную имеет смысл называть курсором. Переименуем переменную ещё раз и избавимся от постоянных задержек:
Если данные были, перейти к шагу 2
Таким образом, получаем алгоритм, минимизирующий число запросов, если данных для клиента нет, и запрашивающий данные с максимальной производительностью, если таковые имеются.
Рекомендации по работе с курсорами:
Поскольку хранением курсора между запросами озадачен клиент, то имеет смысл хранить в курсоре и версию ПО сервера. В этом случае можно написать дополнительный код, обеспечивающий обратную совместимость (конвертацию форматов курсоров).
Во избежание трудных багов весь набор фильтров, полученных в первом запросе, хорошо хранить в курсоре и в последующих запросах игнорировать параметры фильтрации не из курсора. Перфекционисты могут даже выделить инициализацию курсора в отдельный запрос.
Во избежание введения в соблазн пользователей использовать в своём коде какие-то данные из курсора, лучше не использовать человекочитаемую строку в значении курсора. JSON, пропущенный через base64-кодирование (и криптоподписанный) подходит идеально.
Пример. Изменение алгоритма после сбоя.
Любая система гарантированной доставки сообщений из точки А в точку B в случае факапов будет накапливать пул недоставленных сообщений. После восстановления работоспособности будет период времени, когда приёмник данных сильно отстаёт от источника.
В случае, если порядок доставки сообщений возможно нарушать, то обработчик запроса с курсором может (продетектировав значительное отставание) начать возвращать два потока данных: тот, на который подписан клиент, и тот же, но с более актуальными данными.
Таким образом, пользователи, запросившие отчёт прямо во время факапа, продолжат его ждать (и дождутся). А пользователи, запросившие отчёт после факапа, получат его с небольшой задержкой.
Пример алгоритма серверной стороны, включающего второй поток в случае сильного отставания, приведён на рисунке.
Пофантазировав, схему можно дополнить не одним, а несколькими фолбеками.
Курсорная репликация
Описанные курсоры можно использовать для репликации данных с сервиса на сервис.
Часто один сервис должен иметь у себя кеш/реплику части данных другого сервиса. При этом требований синхронности к этой реплике нет. Поменялись данные в сервисе A. Они должны максимально быстро поменяться и в сервисе B.
Например, мы хотим реплицировать табицу пользователей с сервиса на сервис.
Для такой репликации можно использовать что-то готовое из инструментария баз данных, а можно сделать небольшой «велосипед». Предположим, что пользователи хранятся в БД PostgreSQL. Тогда делаем следующее:
модифицируем изменяющие пользователей запросы, чтобы на каждое изменение записи пользователя значение lsn устанавливалось бы из растущей последовательности
строим по полю lsn (уникальный) BTREE индекс.
В этом случае обновление записи пользователя будет выглядеть примерно так:
А запрос для работы курсора будет выглядеть как-то так:
Итоги
Почти во всех случаях, когда применяется активная система уведомлений зависимых сервисов, её можно заменить описанной курсорной подпиской.
При этом проблемы доступности клиентов, настроек, работоспособности TCP-стека останутся у клиентов
Максимально быстрое и простое восстановление после простоя/сбоев. Отсутствие двусмысленностей в кодах ошибок.
Pull уведомления что это
Помощь и документация: десятая эвристика юзабилити
Аудио перевод статьи
Существует две формы помощи в интерфейсе: проактивная и реактивная. Проактивная помощь нацелена на то, чтобы познакомить пользователя с интерфейсом, в то время как реактивная помощь предназначена для решения проблем и повышения квалификации системы.
Несмотря на тот факт, что использование системы без документации является приоритетным вариантом, иногда может возникнуть необходимость в ее наличии. Информация, используемая в документации, должна быть:
Веб-сайты и приложения могут предложить два типа помощи: проактивную и реактивную.
Проактивная помощь предоставляется до того, как пользователь столкнулся с проблемой. Она помогает предотвратить возможные сложности, которые могут возникнуть в процессе работ и содержит:
Реактивная помощь, напротив, предоставляется в том случае, когда пользователь уже столкнулся с проблемой и ищет пути ее решения. Она включает в себя следующие элементы:
Несмотря на то, что эти материалы могут использоваться проактивно, пользователи редко делают это.
1. Проактивная помощь
Цель проактивной помощи — познакомить пользователей с интерфейсом. Проактивная помощь часто возникает в следующих трех сценариях:
Проактивная помощь может быть реализована посредством:
Push- и pull-уведомления: два типа проактивной помощи
Проактивная помощь бывает двух видов: push- и pull-уведомления. Чтобы понять разницу между ними, следует ответить на следующие вопросы:
Push-уведомления — это сообщения, появляющиеся в том случае, когда интерфейс предоставляет помощь или вспомогательный контент, не имеющий отношения к целям пользователей.
Push-уведомления часто игнорируются пользователями, поскольку мешают им: люди хотят использовать интерфейс, а не читать о нем. У этого типа помощи также отсутствует контекст, трудно запомнить выдаваемую информацию, когда она не связана с вашими ближайшими целями.
Pull-уведомления — это сообщения, показывающие контекстные подсказки, относящиеся к задаче пользователя. Они могут появляться в следующих случаях:
Pull-уведомления могут быть реализованы при помощи следующих средств:
Данный вид проактивной помощи будет проигнорирован с меньшей вероятностью, поскольку предоставляет своевременную информацию, помогающую пользователям выполнить конкретную задачу.
Руководство по предоставлению проактивной помощи
Сделайте проактивную помощь краткой и по существу. Проактивная помощь отвлекает пользователей от основной задачи, поэтому важно, чтобы она была:
Контент, представленный в сообщениях проактивной помощи, должен быть написан с точки зрения пользователя, а также с использованием глагольных фраз.
Предпочтите pull-уведомления push-уведомлениям. Сделайте справочный контент доступным, но не навязывайте его пользователям. Используйте push-уведомления для информации, которая может потребоваться независимо от текущей задачи пользователя, а pull-уведомления для своевременного предоставления справочного контента, который имеет отношение к выполняемой задаче.
Должна быть возможность игнорировать push-уведомления без приложения сверхусилий (например, закрывать их). Push-сообщения мешают пользователям получить доступ к основному интерфейсу. Кроме того, они могут расстроить пользователей, которые уже знакомы с интерфейсом или не считают, что им нужна помощь. Каждый раз, когда вы предоставляете контент таким образом, убедитесь, что пользователи могут его закрыть.
Содержание проактивной помощи должно быть доступным где-то еще. После самостоятельного изучения и исследования интерфейса, некоторые пользователи могут вспомнить, что где-то им уже встречалось push-уведомление, которое было полезным, но на тот момент они его проигнорировали. Ситуация привычна для сложных приложений. Позвольте таким пользователям получать доступ к содержанию проактивной помощи, включив ссылку на нее в пользовательском интерфейсе приложения или сайта.
2. Реактивная помощь
Реактивная помощь предоставляется в ответ на столкновение пользователя с проблемой. Цели реактивной помощи:
Реактивная помощь предоставляется в следующем виде:
Руководство по предоставлению реактивной помощи
Убедитесь, что документация, предоставляемая в качестве реактивной помощи, является исчерпывающей и подробной. Не включайте туда лишь очевидную информацию. Если пользователи просматривают ваши часто задаваемые вопросы, учебные руководства, системную документацию или что-то схожее, они делают это не ради веселья. Им нужна помощь в чем-то и они, вероятно, хотят получить подробные инструкции. Такая документация не должна содержать только лишь общие обзоры, хотя подобный контент и может быть размещен в верхней части страницы.
Обеспечьте возможность “сканирования” материала взглядом, используя правила написания текстов для веба:
Рассмотрите возможность использования графики и видео как вторичного источника информации. В случае сложных взаимодействий визуальные методы могут помочь пользователям лучше понимать и повторять инструкции. Но это не значит, что стоит отказываться от помощи в текстовой форме, поскольку люди не всегда могут (или хотят) смотреть видео.
Оптимизируйте для поиска. Когда пользователям требуется немедленная помощь по решению конкретной проблемы, им необходимы инструменты для ее быстрого получения. Убедитесь, что возможности поиска на сайте полностью функциональны и дают релевантные (соответствующие запросу) результаты.
Сгруппируйте справочную информацию по соответствующим категориям. Пользователи могут обратиться к вашей документации в поисках определенных типов помощи, связанных с уровнем опыта или конкретными темами. Помогите пользователям определить, какой контент соответствует их потребностям, классифицировав его.
Выделяйте наиболее часто просматриваемый контент. Если у вас много справочного контента, помогите пользователям найти ту информацию, которая им необходима, выделяя соответствующие части. Например, вы можете выделить популярные статьи или учебные модули, используя социальное доказательство (обозначить их как крайне рекомендуемые или наиболее просматриваемые).
Заключение
Помощь и документация — важные аспекты хорошего пользовательского опыта. Они часто необходимы, но редко доставляют удовольствие. Как правило, пользователи не любят читать, а особенно инструкции. Но любые проблемы, связанные со взаимодействием являются возможностью обучения для пользователя и, следовательно, возможностью для дизайнера воздействовать на информацию и таким образом развивать ментальную модель (интуитивное понимание принципов работы сайта, основанное на прошлом опыте взаимодействия) пользователя, что было бы невозможно без возникновения соответствующей проблемы.
Действуйте по следующему алгоритму:
Помните, что содержание справки должно быть кратким, конкретным и удобным для просмотра.