Большинство команд хотят понимать, какие кампании реально приносят деньги. Останавливает их атрибуция: данные о покупках лежат в разных системах, у каждой свой формат, и связать их с сообщением, которое привело к покупке, превращается в отдельный проект. Поэтому команды возвращаются к открытиям и кликам — эти цифры уже есть в дашборде.
Решение — завести доход в платформу для рассылок в формате, который она реально может использовать. Вот как это сделать в Pushwoosh.
Почему данные о доходе никогда не доходят до вашей платформы рассылок 💰
Причина в формате: доход никогда не приходит в 1 виде.
Например, ваш SDK триггерит событие покупки внутри приложения, когда кто-то покупает игровую валюту. Бэкенд отправляет собственный OrderPlaced. Stripe и Shopify шлют свои webhook-события для подписок и заказов в магазине. У каждого — свои названия полей, своя структура, свое понимание того, что такое “сумма”.
Чтобы отчитаться по доходу со всех этих источников сразу, кому-то нужно написать отдельную логику под каждый источник и постоянно поддерживать её в актуальном состоянии. Большинство команд этого не делает, потому что это редко бывает приоритетом — вплоть до итогов квартала. А к тому моменту данных просто нет. Отслеживание дохода откладывается, а команда продолжает отчитываться по открытиям, потому что эти стандартные метрики уже подключены.
И решается это быстро: всё сводится к тому, чтобы привести доход к 1 единому формату.
1 событие для всего вашего дохода
Pushwoosh решает проблему формата с помощью 1 встроенного события: PW_Conversion. Независимо от исходного источника, доход попадает в 1 нормализованную запись с фиксированным набором полей:
- value — сумма транзакции
- currency — например, USD или EUR
- transaction_id и product_id — опциональные идентификаторы
Это всё. Продление подписки, покупка внутри приложения, заказ в Shopify — всё становится событием одного типа. Как только доход попадает в PW_Conversion, всё, что идёт дальше, читает те же данные: RFM-сегментация, Customer Journeys, дашборды и ManyMoney AI.
2 способа начать отслеживание
Конверсионные события настраиваются для каждого приложения отдельно, и есть 2 пути. Выберите тот, что соответствует тому, как уже устроен поток данных о покупках.
- Замаппить существующее событие — без кода. Если данные о покупках уже поступают в Pushwoosh через другое событие, просто направьте Pushwoosh на него. Выберите исходное событие и замаппьте его поля: какой атрибут содержит цену, какой — валюту. После этого Pushwoosh будет автоматически генерировать запись PW_Conversion каждый раз, когда это событие срабатывает, не меняя ни строчки в вашем приложении. Можно маппить сразу несколько источников — например, кастомное событие purchase_completed вместе с webhook от Stripe или Shopify.
- Отправлять PW_Conversion напрямую из кода. Если вы предпочитаете отправлять доход явно, добавьте вызов postEvent в том месте приложения или бэкенда, где завершается покупка. Этот путь требует помощи от команды разработки, но это небольшая, разовая интеграция.
Полная настройка описана в документации по конверсионным событиям.
Какие события можно превратить в доход (а какие нет)
Способ маппинга работает с любым событием, которое несёт денежную сумму:
- Кастомные события — ваши собственные purchase_completed, subscription_renewed, order_placed.
- Стандартные события — если они представляют платное действие.
- Входящие webhook-события — Stripe, Shopify и другие подключённые платёжные источники.
Что нельзя замаппить — событие, из которого нечего прочитать в качестве суммы. App_open, screen_view или push_opened только фиксируют, что сделал пользователь. Без суммы конвертировать нечего.
Что можно измерить, когда доход уже поступает
Вот в чём настоящая выгода. Когда доход нормализован, 3 вещи, которые раньше требовали ручной работы, становятся встроенными:
- Сегментировать по тратам. RFM-сегментация читает PW_Conversion напрямую, поэтому самые платящие пользователи автоматически попадают в сегмент Champions, готовые к таргетингу с предложением на лояльность.
- Доказать, какие journey реально приводят к покупкам. Установите PW_Conversion как Conversion Goal в любом Customer Journey. После прогона статистика цели покажет, сколько пользователей реально купили, а не просто сколько открыли сообщение. На вопрос “окупился ли этот flow?” наконец есть ответ прямо на канвасе.
- Показывать доход в дашбордах рядом с другими важными метриками эффективности приложения, не выстраивая отдельную логику под каждое событие покупки.
Найдите своё приложение здесь
Одна и та же настройка адаптируется под то, как ваше приложение реально зарабатывает. Найдите строку, похожую на ваш случай:
| Тип приложения | События, которые нужно замаппить или отправить | Что вы в итоге увидите |
|---|---|---|
| E-commerce | Замаппить order_placed + webhook от Shopify или Stripe | Какие flow возврата брошенных корзин приводят к реальным заказам; RFM по тратам для поиска повторных покупателей |
| Gaming | Отправлять iap_completed, battle_pass_bought из кода | Конвертит ли оффер после уровня, а не просто открывается; сегменты по тратам для платящих игроков с высоким чеком |
| Подписка (медиа, стриминг) | Замаппить subscription_renewed, plan_upgraded (Stripe, App Store) | Приводят ли win-back journey к реальным повторным подпискам; RFM по давности продления |
| FinTech | Замаппить premium_subscribed, first_trade или платёжный webhook | Какие onboarding-подсказки приводят к пополненным счетам; сегменты по объёму транзакций |
| Доставка еды | Замаппить order_placed из бэкенда | Какие пуши на реактивацию приводят к повторным заказам; RFM по давности последнего заказа |
| Путешествия / бронирования | Замаппить booking_confirmed + допуслуги вроде seat_upgraded | Какие flow снижения цены конвертят в бронирования; сегменты по стоимости поездки |
order_placed + webhook от Shopify или Stripeiap_completed, battle_pass_bought из кодаsubscription_renewed, plan_upgraded (Stripe, App Store)premium_subscribed, first_trade или платёжный webhookorder_placed из бэкендаbooking_confirmed + допуслуги вроде seat_upgradedПоказывать доход там, где маркетологи уже работают
Конверсионные события — 1 часть более широкого направления Pushwoosh: сделать доход видимым там, где маркетологи уже работают, а не в отчёте, за которым нужно отдельно идти.
Вы уже решаете, что отправлять, кому и как часто. Сейчас эти решения строятся на открытиях и кликах, потому что это всё, что мы можем вам вернуть. Отправьте PW_Conversion — и те же решения будут строиться на деньгах: какие кампании оставить, какие убрать, какие сегменты заслуживают больше рассылок — а какие просто генерируют отписки, ничего не принося взамен.
Как только доход начинает поступать, появляется накопительный эффект:
AI-маркетинговый копайлот Pushwoosh, ManyMoney AI, тоже читает PW_Conversion — можно просто спросить его обычным языком, как идут продажи или какие кампании зарабатывают, и получить ответ напрямую из живых данных, не дожидаясь отчёта. Он же самостоятельно работает с тем же сигналом, масштабируя кампании, которые зарабатывают, и ставя на паузу те, что нет.
Запустить отслеживание дохода в Pushwoosh
Начните с пути, который требует меньше усилий: замаппьте событие, которое уже отправляете, либо передайте команде разработки пример postEvent. Установите PW_Conversion как Conversion Goal в следующем journey и наблюдайте, как доход появляется рядом с открытиями и кликами.
Одну вещь конверсионные события не расскажут: вызвали ли ваши кампании этот доход, или пользователи купили бы в любом случае. Это отдельное измерение под названием Global control group — естественный следующий шаг, как только доход уже отслеживается.
Похожие статьи
Показать все