Первая партия августовских обновлений пришла со стороны аналитики: Pushwoosh теперь принимает выручку как отдельное событие, а аналитика контрольной группы показывает, какую часть этой выручки на самом деле принесли ваши рассылки. Также вышли native in-app сообщения.
Что изменилось 👇
Отслеживайте выручку в Pushwoosh с помощью конверсионного события 🤑
Теперь Pushwoosh собирает выручку как отдельный тип события. Каждая покупка, продление подписки или платёж фиксируется как PW_Conversion — одно чистое число, на которое можно опираться.
Настройка простая: отправляйте событие из своего кода после покупки, либо смаппите уже существующее событие — включая вебхуки Stripe и Shopify — вообще без кода. Суть не в настройке, а в том, что можно делать, когда выручка уже поступает.
Как это работает на практике:
- Сегментируйте по реальным тратам. Стройте RFM-сегмент high-value покупателей на основе реальных сумм и давности покупок — без кастомной логики выручки под каждое событие. Ваш VIP-флоу таргетирует тех, кто тратит, а не тех, кто просто открывает.
- Смотрите, какие journey приносят деньги. Атрибутируйте выручку к Customer Journey или кампании, и ваш флоу брошенной корзины перестаёт отчитываться только по кликам — теперь он показывает выручку, которую реально вернул.
- Единое число выручки из всех источников. Объединяйте in-app покупки и платежи через вебхуки Stripe или Shopify в один датасет, вместо того чтобы сшивать источники вручную.
Вы уже решаете, что отправлять, кому и как часто. Но эти решения вы принимаете на основе открытий и кликов — потому что только их мы вам и показываем. Отправьте
PW_Conversion, и те же решения будут приниматься на основе денег: какие кампании оставить, какие отключить, какие сегменты приносят больше — и какие обходятся вам отписками просто так.
Несколько примеров, как команды это используют:
- E-commerce. Смаппьте вебхук оформления заказа Shopify на
PW_Conversion— и ваш флоу брошенной корзины перестаёт отчитываться в открытиях: вы видите выручку, которую он реально возвращает, и стоят ли отправки затраченных усилий. - Приложения с подпиской. Направьте его на событие продления Stripe, чтобы увидеть, какие journey возврата и напоминаний о продлении реально возвращают ушедших подписчиков к оплате — вместо того чтобы гадать по клик-рейту.
- Игры и приложения с in-app покупками. Передавайте in-app покупки и стройте RFM-сегменты, которые выявляют топовых покупателей — а затем отправляйте им предложения, которые никогда не отправили бы всей базе.
Измеряйте реальное влияние ваших рассылок 📊
Поступающая выручка — это только половина истории. Вторая половина — доказать, что именно ваши рассылки её принесли, и теперь на этот вопрос отвечает аналитика контрольной группы.
Глобальная контрольная группа исключает фиксированную долю пользователей из всех маркетинговых рассылок, продолжая при этом доставлять им транзакционные сообщения. Новая аналитика сравнивает эту удержанную группу со всеми, кто получал ваши кампании, — так вы видите прирост, который на самом деле обеспечили рассылки.
Почему это важно: это чёткий ответ на вопрос — какая часть этой выручки на самом деле обеспечена маркетингом? Чем больше ваша аудитория, тем ценнее это сравнение с удержанной группой.
В паре с конверсионными событиями из предыдущего раздела цикл замыкается: сначала вы отслеживаете выручку, затем измеряете, какая её часть реально на счету ваших кампаний.
Создавайте native in-app сообщения 📱
В Pushwoosh теперь доступны native in-app сообщения — in-app контент, который отображается как часть интерфейса вашего приложения, а не как веб-оверлей. Они открываются быстрее, анимируются плавнее, а собрать их можно без участия дизайнеров и разработчиков.
Доступны 3 типа отображения:
- Modal — центрированная карточка, опционально на затемнённом фоне. Подходит для одного предложения или запроса.
- Fullscreen — изображение на весь экран с заголовком, текстом и кнопками сверху.
- Stories — последовательность полноэкранных слайдов с индикаторами прогресса, в привычном пользователям формате историй из соцсетей.
Сценарии использования: native in-app сообщения естественно вписываются в онбординг-подсказки, напоминания о функциях или короткий опрос в рамках сессии.
Email-редактор становится умнее ✏️
Пакет улучшений, которые снимают часть работы с ваших плеч в drag-and-drop редакторе:
- Условный контент — условия отображения блока теперь принимают любое Liquid-выражение, а не только тег из списка. Можно выстраивать цепочку IF / ELSE IF / ELSE и показывать разным группам получателей разные варианты, а не просто скрывать или показывать один блок. Подробнее →
- Каталог товаров в письмах — блоки Product теперь подтягивают данные напрямую из подключённого фида (Google Merchant XML или JSON), так что список товаров остаётся актуальным без ручных правок. Подробнее →
- Подгонка изображения — задавайте размер и обрезку изображения внутри блоков Card и Column прямо в редакторе, без правок кода. Подробнее →
- Синхронизация копий — отредактируйте повторно используемый блок один раз, и изменение применится везде, включая уже запланированные к отправке письма. Подробнее →
- Brand book — сохраните цвета, шрифты и логотип бренда один раз и используйте их во всех письмах для единообразного вида. Подробнее →
Больше доработок для in-app и веб-попапов 🔧
3 небольших обновления, которые часто нужны в повседневной работе:
- Предпросмотр in-app сообщений перед отправкой. Проверьте, как шаблон выглядит и ведёт себя на устройстве прямо в Control Panel, до отправки. Подробнее →
- Радиус скругления кнопки закрытия in-app. Слайдер от 0 до 16px переводит кнопку закрытия от полностью круглой до квадратной — под ваш дизайн. Подробнее →
- Формы подписки в веб-попапах. Показывайте существующую форму подписки внутри веб-попапа вместо баннера — найдите форму по имени и добавьте её. Подробнее →
Попробуйте обновления сами
Все описанные выше функции уже доступны в вашем аккаунте. Впереди ещё августовские обновления — а пока войдите в аккаунт и начните применять эти новинки.
Полный список изменений — в наших release notes.
Похожие статьи
Показать все
