Вы создавали свой список подписчиков push-уведомлений, получая согласие за согласием, и каждое согласие стоило реальных денег на привлечение. Поэтому, когда приходит время сменить поставщика push-уведомлений, возникает специфический страх: расторгнуть старый договор, и список исчезнет вместе с ним. Ваш текущий поставщик может даже сказать вам именно это.
Это неправда, и это руководство покажет вам, почему на уровне браузера. Подписка на веб-push привязана к вашему домену, а не к вашему поставщику. Как только вы поймете механику, каждый переход сводится к одному из двух четких сценариев, короткому списку письменных вопросов к вашему текущему поставщику и однонедельному чек-листу, который ваша команда сможет выполнить без проблем.
Одно честное замечание сразу. Отдел продаж каждого поставщика, включая наш, скажет вам, что миграция — это легко. Большинство на этом останавливаются. Эта статья показывает вам механизм вместо этого, чтобы ваш разработчик мог проверить каждое утверждение, включая те, которые мы делаем в конце.
Что такое подписка на веб-push на самом деле
Когда посетитель нажимает «Разрешить» на вашем сайте, браузер создает подписку на веб-push, состоящую из трех частей:
- Ваш источник. Точный домен, на котором было предоставлено разрешение (
https://yoursite.com). Разрешение хранится в браузере, привязанное к источнику. Оно не упоминает никакого поставщика. - Сервис-воркер. Небольшой файл JavaScript, размещенный на вашем домене, который получает и отображает уведомления. Доставкой управляет зарегистрированный сервис-воркер.
- Ключ сервера приложений. Открытая половина пары ключей VAPID. Служба push-уведомлений браузера принимает только отправки, подписанные соответствующим закрытым ключом. Любой, кто владеет этим закрытым ключом, может отправлять сообщения по подписке. (Обзор push-уведомлений на web.dev охватывает полный протокол.)
Сам объект подписки состоит из трех строк: URL конечной точки плюс два коротких ключа, p256dh и auth. Это весь актив. Весь ваш список — это таблица этих записей.
Одно правило определяет все последующие действия: браузеры принимают отправки только от владельца соответствующего закрытого ключа VAPID. Это означает, что каждый переход поставщика сводится ровно к двум сценариям, в зависимости от того, где находятся эти ключи.
Сценарий A: ваши ключи VAPID переносятся, поэтому вы импортируете подписчиков push-уведомлений в первый день
Сценарий A применяется, когда ключи принадлежат вам: вы настроили собственные ключи VAPID или собственный проект Firebase при настройке, или ваш уходящий поставщик соглашается передать пару ключей. Некоторые команды настраивают это намеренно с первого дня; этот подход описан в нашем руководстве по реализации веб-push без привязки к поставщику.
Имея на руках закрытый ключ, ваш новый поставщик может напрямую импортировать подписчиков push-уведомлений: все конечные точки, записи p256dh и auth будут перенесены, и вы сможете отправлять сообщения всему вашему существующему списку с первого дня. Это включает спящих подписчиков, которые не посещали сайт месяцами. Никто не будет повторно подписываться. Никто ничего не заметит.
Один нюанс, который стоит четко прояснить. Даже в сценарии A, долгосрочная миграция все равно завершается через повторные посещения, потому что каждому подписчику в конечном итоге нужно перейти на новый сервис-воркер. Импортированные ключи обеспечивают вам охват с первого дня, пока этот переход незаметно происходит в фоновом режиме.
Сценарий B: ключи остаются у старого поставщика, и происходит бесшумная повторная подписка
Сценарий B — это стандартный вариант по умолчанию: поставщик сгенерировал ключи VAPID и сохраняет их. Без закрытого ключа экспортированные записи криптографически бесполезны. Охват с первого дня равен нулю, и предупреждение вашего старого поставщика будет звучать правдоподобно еще примерно один абзац.
Вот что происходит на самом деле. В следующий раз, когда каждый подписчик посетит ваш сайт, сервис-воркер нового поставщика возьмет на себя управление: он отменит регистрацию старой регистрации, отпишет от старой подписки и повторно подпишет посетителя под новыми ключами. Незаметно, за одно посещение, без второго запроса на разрешение.
Почему новому сервис-воркеру не нужен второй запрос
Разрешение на уведомления предоставляется вашему домену, а не поставщику. Браузер уже доверяет вашему домену. Замена сервис-воркера и ключей под уже предоставленным разрешением невидима для посетителя, потому что браузер рассматривает это как реорганизацию собственных внутренних механизмов вашего сайта. Что, собственно, и происходит.
Две ловушки, о которых должен знать ваш разработчик
Один домен, одна подписка. Браузер не может хранить две push-подписки для одного и того же домена. Попытка подписаться с другим ключом завершится неудачей, пока старая подписка не будет отменена. Поэтому «одновременная работа двух поставщиков» работает на уровне списка, но никогда внутри одного браузера: каждый подписчик либо у старого поставщика, либо у нового, и каждое повторное посещение переводит еще одного пользователя.
Подписки на поддомены поставщиков никогда не переносятся. Подписки, собранные на yoursite.vendor.com, принадлежат домену поставщика, и ни один поставщик не может их перенести. Эта база данных будет создаваться с нуля. Это самая большая ловушка при любой миграции push-уведомлений и самый веский аргумент в пользу привязки подписок к домену, который вы контролируете в этот раз. Если вы управляете несколькими брендами или региональными доменами, та же логика домена формирует всю вашу архитектуру; мы рассматриваем это в разделе push-уведомления для нескольких доменов.
Вот два сценария бок о бок:
| Сценарий A: ключи перемещаются | Сценарий B: ключи остаются у старого поставщика | |
|---|---|---|
| Когда это применимо | Собственные ключи VAPID / собственный проект Firebase или поставщик выпускает пару ключей | Поставщик сгенерировал и сохраняет ключи (стандартный вариант по умолчанию) |
| Охват с первого дня | Весь ваш список, включая спящих подписчиков | Ноль, пока посетители не вернутся |
| При каждом повторном посещении | Подписчик незаметно переходит на новые ключи | Бесшумная повторная подписка под новыми ключами, без второго запроса |
| Кого вы восстанавливаете | Всех | Всех, кто снова посетит сайт |
| Кого вы теряете | Никого | Подписчики, которые никогда не возвращаются (которые и так уже были недоступны для получения дохода) |
Почему аудитории, посещающие ежедневно, быстрее всего завершают миграцию push-уведомлений
В Сценарии B, время перехода — это частота возврата вашей аудитории. Ничего больше. Подписчик электронной коммерции может посещать ежемесячно, поэтому переход растягивается на месяцы. Игрок проверяет коэффициенты, линии и результаты ежедневно. Читатель новостей возвращается для каждого цикла новостей.
Именно такой ритм возврата является причиной того, что сайты ставок и новостные сайты являются лучшими вертикалями в Интернете для смены поставщиков push-уведомлений: та же частота посещений, которая делает push-уведомления для сайтов ставок механизмом удержания, также сжимает миграцию, которая занимает у других сайтов квартал, до недели или двух. Сайты ставок и игр на PushEngage отправили более 3,5 миллиардов уведомлений, поэтому эти механизмы перехода для нас — ежедневная рабочая реальность, а не теория.
| Паттерн возврата аудитории | Типичный переход активной базы |
|---|---|
| Ежедневные посетители (live-коэффициенты, срочные новости, ежедневные промо) | Дни до недели |
| Несколько посещений в неделю (игроки выходного дня, постоянные клиенты) | 1–2 недели |
| Еженедельно или реже (сезонные посетители, потерянные пользователи) | Недели, ускоренные отправками от старого поставщика и крупными событиями |
| Неактивные (без посещений в течение месяцев) | Восстанавливаются только в рамках Сценария A |
Это типичные паттерны для аудиторий с ежедневными посещениями, а не гарантии; ваша кривая зависит от ритма вашего трафика, и вы будете наблюдать ее в реальном времени на панели управления. Вы также можете изогнуть кривую: запланируйте переход за неделю до крупного матча, и трафик события возьмет переход на себя. Букмекерские конторы, планирующие последовательность push-уведомлений в день матча, уже знают, какие выходные дни это будут.
Push-уведомления приложений проще: ваши токены всегда были вашими
Если вы также отправляете push-уведомления приложений, сделайте перерыв. Эта часть структурно проста, потому что ни один поставщик не может держать ее в заложниках.
Сертификаты и ключи APNs выдаются вашей учетной записи Apple Developer. Ваш проект FCM находится в вашей консоли Google. Поставщик push-уведомлений — это уровень поверх учетных данных, которыми вы владеете, поэтому смена означает подключение нового уровня к тем же учетным данным. Токены устройств экспортируются и импортируются чисто, без переустановок и без повторного запроса разрешения.
Два практических замечания. Во-первых, фильтруйте экспорт токенов примерно до устройств, активных в течение 270 дней, перед импортом, потому что FCM рассматривает токены, неактивные более ~270 дней, как устаревшие. Дамп токенов за пять лет раздувает количество ваших подписчиков, и при ценообразовании, которое учитывает только активных подписчиков, это никому не выгодно. Во-вторых, полное покрытие SDK достигается со скоростью обновления пользователями вашего приложения, обычно одна-две недели для приложения ежедневного использования с автообновлением.
Если ваше iOS-приложение в настоящее время отправляет уведомления через Firebase, пошаговый процесс — это отдельная тема; см. наше руководство по миграции с Firebase Cloud Messaging на iOS, а не импровизируйте его из этой статьи.
Прежде чем сменить поставщика push-уведомлений, задайте эти шесть вопросов в письменной форме
Экспорт данных поставщика и политики ключей различаются и меняются. Вместо того чтобы доверять любой таблице вердиктов поставщиков (включая ту, которую мы могли бы опубликовать), получите собственные ответы вашего поставщика официально. Электронная почта подойдет; запрос в службу поддержки — лучше. Если вы одновременно оцениваете и другие платформы, те же вопросы послужат полезным фильтром при сравнении альтернатив OneSignal.
- Можете ли вы экспортировать полные записи моих веб-push подписок — URL конечной точки плюс ключи
p256dhиauthдля каждого подписчика — или только внутренние идентификаторы? Внутренние идентификаторы бессмысленны вне системы поставщика. - Вы опубликуете пару ключей VAPID, под которыми были созданы мои подписки? Этот единственный ответ определяет Сценарий А против Сценария Б.
- На каком FCM или Firebase проекте работает мой веб-push, на моем или на вашем? Если на вашем, ключи уже могут быть в вашей собственной консоли.
- Могу ли я экспортировать сегменты, теги, атрибуты подписчиков и списки блокировок отдельно? Они не передаются вместе с записями подписок автоматически.
- Могу ли я экспортировать токены устройств моих push-приложений и в каком формате?
- Что произойдет с моими данными, если я понижу уровень или отменю подписку — будет ли автоматическое удаление или период хранения? Некоторые поставщики удаляют неактивные данные подписчиков на более низких уровнях. Всегда сначала экспортируйте.
Чек-лист недели миграции
Распечатайте этот раздел. Восемь шагов по порядку.
- Экспортируйте все перед отменой или понижением уровня. Записи подписок, токены приложений, сегменты, теги, атрибуты, списки блокировок. Доступ к экспорту прекращается с окончанием вашего контракта.
- Получите ответ по ключам VAPID в письменной форме. Это определит ваш сценарий и то, сможете ли вы импортировать push-подписчиков в первый же день.
- Сначала переместите списки блокировок, а не в последнюю очередь. Для операторов ставок и азартных игр это не подлежит обсуждению: игроки, исключившие себя, должны быть заблокированы на новой платформе до возобновления какой-либо кампании, а не урегулированы после.
- Отфильтруйте токены приложений по активности за ~270 дней перед импортом.
- Установите новый SDK и service worker, и объедините с любым существующим service worker (оболочкой PWA, worker старого поставщика), а не перезаписывайте его.
- Не удаляйте файл service worker старого поставщика в первый день. Возвращающиеся посетители все еще несут регистрации, указывающие на него; переход плавно отменяет их регистрацию. Если вы удалите файл слишком рано, вы получите ошибки в консоли вместо миграции. Удалите его при окончательном демонтаже.
- Продолжайте использовать старого поставщика для отправки в параллельном режиме. Контринтуитивно, но критически важно: каждое уведомление, отправленное старым поставщиком, вызывает повторное посещение, и каждое повторное посещение завершает миграцию еще одного подписчика. Ваш уходящий поставщик становится вашим лучшим инструментом миграции.
- Ежедневно измеряйте переход и переключайтесь на плато. Отслеживайте новую активную базу по сравнению со старой активной базой. Когда кривая выравнивается, завершите демонтаж, отмените старый контракт и архивируйте экспорты.
Стоимость перехода, когда PushEngage делает это за вас
В PushEngage миграция — это услуга «белых перчаток», включенная бесплатно в платные тарифы. Вы получаете инженера по миграции, а не статью из справочного центра: они обрабатывают сопоставление экспорта, управление ключами, слияние service worker и план перехода. Это важно, потому что сбои бывают незаметными — простой импорт с несовпадающими форматами полезной нагрузки может привести к технически успешным, но пустым уведомлениям, что является именно тем классом тихих сбоев, которые специалист обнаруживает до того, как их увидят ваши подписчики.
Установочный звонок занимает около пятнадцати минут: количество подписчиков по каналам, текущий поставщик и вышеупомянутые ключевые вопросы. К концу разговора вы будете знать, относитесь ли вы к сценарию A или B, и у вас будет датированный план.
Если вы готовы сменить поставщика push-уведомлений, начните с шести письменных вопросов в этой статье и посмотрите, как ответит ваш текущий поставщик. Затем посмотрите, что платформа push-уведомлений, построенная на основе сегментации и атрибуции доходов, сделает со списком, которым вы уже владеете, и сравните цены PushEngage с вашим текущим счетом. Каждый платный тариф имеет 14-дневную гарантию возврата денег, поэтому сама миграция push-уведомлений является наименее рискованной частью решения.
