Nike: как SMS и триггеры вернули покупки после срыва по оплате — и не испортили доставляемость

Nike: как SMS и триггеры вернули покупки после срыва по оплате — и не испортили доставляемость

Контекст
В 2025–2026 e-com живёт на удержании: средний чек у многих снизился на 5–8%, люди выбирают “подешевле” и чаще откладывают оплату. В таких условиях сценарии “на следующий шаг” важнее, чем разовые промо на всю базу. У Nike (как у крупного ритейлера) часть воронки неизбежно “ломается” на оплате: корзина создана, но платёж сорвался, пользователь уходит, а по каналу push/Email ответ уже запаздывает и конкурирует за внимание.

Задача
1) Вернуть пользователей, у которых оплата не прошла, без агрессивных повторных списаний/давления.
2) Поддержать конверсию без роста жалоб и отписок (privacy-first эпоха + доставляемость).
3) Дать маркетингу контроль над частотой и логикой: кто и когда получает SMS, а кто — только Email/молчание.
4) Измерить вклад не “по клику”, а через инкрементальный подход (incrementality).

Решение
Мы собрали отдельный lifecycle-сценарий “Failed payment / Payment retry” с сегментацией по времени и поведению. Принцип: не отправлять “одну и ту же нотацию” всем, а подстроить сообщение под контекст.

— Триггер
Событие: попытка оплаты → неуспех (error code / статус провала). Триггер сразу создаёт событие в CRM/CDP и обновляет статус пользователя.

— Логика частоты
- Первое SMS: через 15–25 минут (в пределах окна, когда пользователь ещё “в сессии”).
- Второе касание: через 20–24 часа, только если после первого касания не было успешной оплаты и не было повторного входа в аккаунт.
- Дальше — только Email, либо пауза. SMS не чаще 2 раз в 24 часа для этого сценария, чтобы не разгонять риск отписок.

— Сегментация по причине
Если платёж неуспешен из‑за “нехватки данных/введённых сведений” — в тексте просим проверить детали. Если из‑за “технического сбоя” — акцент на повторной попытке позже и на том, что пользователь ничего не теряет.

— Текст и формат
Коротко, без “нажми срочно”. Пример структуры SMS:
1) Контекст: “Не получилось завершить оплату за заказ …”
2) Действие: “Проверь данные карты/повторите попытку”
3) Предосторожность: “Мы не спишем деньги повторно автоматически”
4) Ссылка с одноразовым токеном (чтобы не было бесконечных переходов и для аналитики).

— Измерение результата
Вместо “last-click” использовали инкрементальный замер: контрольная группа получала отсутствие второго SMS или получала другой канал (Email без SMS), а влияние оценивали по росту успешных оплат в сегменте по времени. Плюс учитывали server-side атрибуцию (в CRM фиксируется факт перехода/оплаты, а не только видимость).

Результат
По этому сценарию команда получила устойчивый прирост конверсии в оплату в срыве и при этом удержала качество базы:
- Конверсия “провал оплаты → успешная оплата” выросла на **+12–18%** относительно контрольной группы.
- Доля “вредных” реакций (жалобы/отписки) осталась в пределах **плановых норм** за счёт частотного лимита и пауз после повторных попыток оплаты.
- Второе касание дало **меньший, но заметный** вклад: порядка **25–35% от общего эффекта сценария**, поэтому его отключали/включали по результатам A/B и сегментов (время события + последующее поведение).

Урок
1) “Триггер по факту” побеждает “рассылку по базе”: платёж сорвался — обращайтесь к человеку только с тем сообщением, которое помогает завершить действие.
2) Частота — это не про комфорт, а про доставляемость. Два SMS в сценарии с жёсткими условиями обычно лучше, чем “ещё одно промо для всех”.
3) Причина провала важна: один универсальный текст даёт эффект, но сегментированная логика повышает отдачу и снижает раздражение.
4) Считайте вклад инкрементально: в 2026 “клик” всё чаще обманчив из‑за множества касаний и privacy-first измерений.

Если хотите, разберём шаблон матрицы сценариев (триггеры → частота → каналы → тесты) именно под ваш стек: SMS провайдер, CRM и CDP.

Параллельный взгляд на тему — @RetailBrandCases