대부분의 팀은 어떤 캠페인이 실제로 매출을 만들어내는지 알고 싶어 합니다. 하지만 이를 가로막는 것은 어트리뷰션입니다. 결제 데이터는 시스템마다 다른 형식으로 흩어져 있어서, 어떤 메시지가 그 구매를 이끌어냈는지 연결하는 일 자체가 별도의 프로젝트가 되어 버립니다. 그래서 팀들은 결국 오픈율과 클릭률로 돌아갑니다. 그 숫자는 이미 대시보드에 있으니까요.
해결책은 매출 데이터를 마케팅 플랫폼이 실제로 활용할 수 있는 형태로 가져오는 것입니다. Pushwoosh에서는 이렇게 진행합니다.
매출 데이터가 마케팅 플랫폼에 도달하지 못하는 이유 💰
원인은 형식에 있습니다. 매출 데이터는 결코 1가지 형태로만 들어오지 않습니다.
예를 들어, SDK는 사용자가 게임 재화를 구매할 때 인앱 구매 이벤트를 발생시킵니다. 백엔드는 자체 OrderPlaced 이벤트를 보냅니다. Stripe와 Shopify는 구독과 주문에 대해 각자의 웹훅 이벤트를 전송합니다. 필드명도, 구조도, “금액”의 정의도 모두 다릅니다.
이 모든 것을 아울러 매출을 집계하려면 소스마다 별도의 로직을 작성하고 계속 동기화해야 합니다. 대부분의 팀은 분기 결산 리뷰 전까지는 이 작업의 우선순위를 낮게 두는데, 막상 그 시점이 오면 데이터가 없습니다. 그렇게 매출 추적은 계속 뒤로 밀리고, 팀은 이미 연동되어 있는 오픈율만 보고합니다.
다행히 빠르게 해결할 수 있는 문제입니다. 핵심은 매출을 1가지 일관된 형식으로 통합하는 것입니다.
모든 매출을 담는 이벤트 1개
Pushwoosh는 내장 이벤트 1개로 형식 문제를 해결합니다: PW_Conversion. 원본 소스가 무엇이든, 매출은 고정된 필드 세트를 가진 정규화된 레코드 1개로 저장됩니다:
- value — 거래 금액
- currency — 예: KRW, USD, EUR
- transaction_id, product_id — 선택적 식별자
이게 전부입니다. 구독 갱신, 인앱 구매, Shopify 주문까지 모두 동일한 종류의 이벤트가 됩니다. 매출이 PW_Conversion으로 들어오는 순간, 이후의 모든 기능이 같은 데이터를 읽습니다: RFM 세분화, Customer Journey, 대시보드, ManyMoney AI까지 전부요.
시작하는 2가지 방법
전환 이벤트는 애플리케이션별로 설정하며, 2가지 경로 중 기존 결제 데이터 흐름에 맞는 것을 선택하면 됩니다.
- 기존 이벤트 매핑 — 코드 작업 불필요. 결제 데이터가 이미 다른 이벤트를 통해 Pushwoosh로 들어오고 있다면, Pushwoosh가 그 이벤트를 가리키도록 설정하면 됩니다. 소스 이벤트를 선택하고 필드를 매핑하세요: 어떤 속성이 가격이고 어떤 속성이 통화인지. 이후 해당 이벤트가 발생할 때마다 Pushwoosh가 자동으로 PW_Conversion 레코드를 생성합니다. 앱 코드는 한 줄도 바꾸지 않아도 됩니다. 여러 소스를 동시에 매핑할 수도 있습니다 — 자체 purchase_completed 이벤트와 Stripe나 Shopify 웹훅을 함께요.
- 코드에서 PW_Conversion을 직접 전송. 매출을 명시적으로 보내고 싶다면, 앱이나 백엔드에서 구매가 완료되는 지점에 postEvent 호출을 추가하세요. 이 방법은 개발팀의 도움이 필요하지만, 한 번만 진행하면 되는 작은 규모의 연동입니다.
매출로 전환할 수 있는 이벤트 (그리고 할 수 없는 이벤트)
매핑 방식은 금액 정보를 담고 있는 모든 이벤트에 적용됩니다:
- 커스텀 이벤트 — 자체적으로 정의한 purchase_completed, subscription_renewed, order_placed.
- 기본 이벤트 — 유료 행동을 나타내는 경우.
- 인바운드 웹훅 이벤트 — Stripe, Shopify 등 연동된 결제 소스.
매핑할 수 없는 것은 읽어올 금액이 없는 이벤트입니다. App_open, screen_view, push_opened는 사용자가 무엇을 했는지만 기록할 뿐, 금액이 없어서 전환할 대상 자체가 없습니다.
매출이 들어오면 측정할 수 있는 것들
여기서부터가 진짜입니다. 매출이 정규화되면, 이전에는 별도 개발이 필요했던 3가지가 기본 기능이 됩니다:
- 소비 규모로 세그먼트 나누기. RFM 세분화이 PW_Conversion을 직접 읽어, 최고 소비자가 자동으로 Champions 세그먼트에 들어갑니다. 바로 로열티 혜택을 타겟팅할 준비가 끝난 상태입니다.
- 어떤 Journey가 실제 구매를 이끄는지 증명하기. 원하는 Customer Journey에서 PW_Conversion을 Conversion Goal로 지정하세요. 실행이 끝나면 목표 통계가 단순히 몇 명이 열어봤는지가 아니라 실제로 몇 명이 구매했는지를 보여줍니다. “이 플로우가 정말 효과가 있었나?”라는 질문에 캔버스 위에서 바로 답을 얻을 수 있습니다.
- 다른 중요한 앱 성과 지표와 함께 대시보드에서 매출을 리포팅하세요. 구매 이벤트마다 별도 로직을 만들 필요가 없습니다.
우리 앱에 맞는 케이스 찾기
같은 설정이 앱이 실제로 매출을 만드는 방식에 맞춰 적용됩니다. 우리 앱과 가장 비슷한 행을 찾아보세요:
| 앱 유형 | 매핑하거나 전송할 이벤트 | 최종적으로 확인할 수 있는 것 |
|---|---|---|
| 이커머스 (카카오톡 채널 연동 포함) | order_placed 매핑 + Shopify 또는 Stripe 웹훅 | 어떤 장바구니 회수 플로우가 실제 주문을 만드는지, 재구매 고객을 찾는 소비 기반 RFM |
| 게임 | 코드에서 iap_completed, battle_pass_bought 전송 | 레벨 이후 오퍼가 단순히 열리는 게 아니라 실제로 전환되는지, 고과금 유저를 위한 소비 기반 세그먼트 |
| 구독 (미디어, 스트리밍) | subscription_renewed, plan_upgraded 매핑 (Stripe, App Store) | 윈백 Journey가 실제 재구독을 만드는지, 갱신 최근성 기준 RFM |
| 핀테크 | premium_subscribed, first_trade 또는 결제 웹훅 매핑 | 어떤 온보딩 넛지가 실제 입금 계좌로 이어지는지, 거래 규모별 세그먼트 |
| 배달/O2O | 백엔드에서 order_placed 매핑 | 어떤 재참여 푸시가 재주문으로 이어지는지, 최근 주문 시점 기준 RFM |
| 여행/예약 | booking_confirmed + seat_upgraded 같은 부가 서비스 매핑 | 어떤 가격 하락 알림이 실제 예약으로 전환되는지, 여행 가치 기준 세그먼트 |
order_placed 매핑 + Shopify 또는 Stripe 웹훅iap_completed, battle_pass_bought 전송subscription_renewed, plan_upgraded 매핑 (Stripe, App Store)premium_subscribed, first_trade 또는 결제 웹훅 매핑order_placed 매핑booking_confirmed + seat_upgraded 같은 부가 서비스 매핑마케터가 이미 일하는 곳에서 매출 확인하기
전환 이벤트는 Pushwoosh가 지향하는 더 큰 방향의 1가지 요소입니다: 마케터가 별도로 리포트를 가져와야만 확인할 수 있는 것이 아니라, 이미 일하고 있는 화면에서 매출이 보이도록 만드는 것입니다.
여러분은 이미 무엇을, 누구에게, 얼마나 자주 보낼지 결정하고 있습니다. 지금은 그 결정이 오픈율과 클릭률을 기준으로 이루어지고 있죠, 저희가 돌려드릴 수 있는 지표가 그것뿐이었으니까요. PW_Conversion을 보내주시면 같은 결정을 매출을 기준으로 내릴 수 있습니다: 어떤 캠페인을 유지할지, 어떤 캠페인을 중단할지, 어떤 세그먼트가 더 많은 발송을 받을 자격이 있는지 — 그리고 어떤 세그먼트가 아무런 대가 없이 구독 해지만 늘리고 있는지 말이죠.
매출 데이터가 흐르기 시작하면 추가적인 효과도 생깁니다:
Pushwoosh에서 매출 추적 시작하기
가장 부담이 적은 방법부터 시작하세요: 이미 보내고 있는 이벤트를 매핑하거나, 개발팀에 postEvent 예시를 전달하세요. 다음 Journey에서 PW_Conversion을 Conversion Goal로 설정하고, 오픈율과 클릭률 옆에 매출이 나타나는 것을 확인해 보세요.
