첫 캠페인의 데이터 조건

CRM 화면에는 고객도 있고 구매 이벤트도 보입니다. 그런데 “구매한 지 한 달쯤 된 고객에게 재구매 안내를 보내자”고 하면 대상 추출부터 막힙니다. 구매자를 어떤 회원과 연결해야 하는지, 취소된 주문도 구매에 포함되는지, 지금 메시지를 받아도 되는 사람인지가 분명하지 않기 때문입니다.

이럴 때는 수집 항목을 늘리기보다 캠페인 하나의 조건을 적고, 그 조건을 판정할 데이터가 같은 고객에게 연결되는지 확인하는 것부터 시작하는 편이 낫습니다. 이벤트, 현재 고객 속성, 사용자 식별자, 기기·구독 식별자, 수신 상태를 나누면 어디가 비어 있는지 드러납니다. OneSignal도 사용자를 나타내는 User와 채널별 접점을 나타내는 Subscription을 구분합니다.[1][2]

데이터가 준비됐는데도 실행할 수 없다면 기능 제공 여부나 설정 권한을 확인해야 합니다. 아래에서는 먼저 데이터 준비도를 진단하고 마지막에 OneSignal의 실제 제공 조건을 따로 살펴봅니다. 필드명과 재구매 시나리오는 별도 표시가 없는 한 설명을 위한 설계 예시입니다.

이름이 비슷해도 데이터의 역할은 다릅니다

설계할 때는 다음 질문을 서로 다른 칸에 놓습니다. customer_id 같은 이름을 모든 도구의 공통 표준으로 가정하지 않습니다.

구분답해야 할 질문설계 예시혼동하면 생기는 문제
이벤트무엇이 언제 일어났는가?구매 확정, 주문 취소구매 화면을 본 행동을 실제 구매로 취급한다.
현재 고객 속성지금 어떤 상태인가?계정 활성 상태, 최근 유효 구매 시각예전 회원 등급이나 구매 시각으로 대상을 고른다.
사용자 식별자우리 서비스의 어느 계정인가?내부 회원 키 customer_id같은 사람을 여러 고객으로 세거나 다른 고객을 합친다.
기기·구독 식별자어느 접점에 보낼 것인가?브라우저별 푸시 구독 ID한 고객의 여러 접점을 같은 구독으로 취급한다.
기술적 수신 상태이 채널로 받을 수 있는 상태인가?푸시 구독 상태, 토큰 유효 상태고객이 존재한다는 이유만으로 발송 가능한 대상으로 본다.
목적·채널별 발송 허용 근거이 안내를 이 고객에게 보내도 되는가?마케팅 수신 동의 상태·변경 이력운영체제의 알림 허용을 마케팅 동의로 대체한다.

OneSignal에서 Tags는 사용자에게 붙는 키·값 속성이고 Custom Events는 시점이 있는 행동을 전달하는 수단입니다. Tags의 값은 문자열이며 중첩 객체나 배열을 그대로 넣는 저장소가 아닙니다. 주문 이력은 원천 시스템에 두고, 캠페인에 필요한 현재 값을 어떤 규칙으로 계산해 갱신할지 정하는 편이 명확합니다.[3][4]

푸시를 받을 수 있다는 사실과 광고성 안내를 보낼 근거가 있다는 사실도 분리해야 합니다. OneSignal의 Subscription Status는 채널의 수신 가능 상태를 표현하며 모바일 푸시와 웹 푸시의 상태 해석도 다릅니다. 이것만으로 한국의 법적 마케팅 동의 요건 충족 여부를 판정하지 않습니다. 캠페인 설계에서는 목적·채널별 허용 기준, 철회 상태, 확인 시각을 별도로 관리하도록 합니다.[1][2]

서비스 작동 방식

캠페인에 필요한 데이터부터 연결 — 캠페인에서 역산한 이벤트와 속성을 정의하고 식별자와 전송 시점, 측정 도구의 역할을 맞춥니다.

로그인 전후에 ‘같은 고객’이라는 근거가 있는가

식별 연결은 가입 시 한 번 확인하고 끝낼 일이 아닙니다. 아래는 웹 서비스의 설계 예시입니다. 모바일 앱은 사용하는 SDK의 로그인·로그아웃 동작을 따로 확인해야 합니다.

익명 방문. 아직 누군지 모르는 브라우저를 특정 회원에게 연결하지 않습니다. OneSignal의 자동 식별자를 사용하더라도 모든 익명 방문자에게 공통 External ID를 주지는 않습니다. 인증된 계정이 확인된 뒤에만 우리 회원 키를 연결하는 경계를 둡니다. 내부 회원 키, OneSignal의 User 식별자, Subscription ID는 서로 다른 값이므로 매핑 관계로 관리합니다.[1][2]

회원 로그인. OneSignal Web SDK의 login(external_id)는 현재 브라우저의 웹 푸시 구독을 해당 사용자에게 연결합니다. 다만 이미 존재하는 External ID로 전환할 때는 로그인 전 익명 데이터가 병합되지 않습니다. 처음 연결하는 External ID일 때와 동작이 다르므로, “로그인하면 과거 행동이 전부 회원 이력으로 붙는다”고 전제해서는 안 됩니다.[5]

여러 기기 사용. 같은 계정임이 확인된 접점은 같은 내부 회원 키에 연결하되 구독 ID는 각각 보존합니다. OneSignal의 Custom Alias는 다른 시스템의 식별자를 함께 참조하는 용도입니다. Alias만 같다고 여러 Subscription이 연결되지는 않으며, External ID가 필요합니다. 계정 키는 불필요한 이메일·전화번호 노출을 피할 수 있는 값으로 설계합니다.[6]

로그아웃과 공용 기기. Web SDK의 logout()은 현재 웹 푸시 구독을 기존 사용자에게서 분리하고 익명 사용자 문맥으로 바꿉니다. 다른 기기의 연결까지 끊는 작업은 아닙니다. 따라서 A가 로그아웃한 브라우저에서 B가 로그인했을 때 A의 구매 정보가 계속 붙는지, 기존 구독 ID로 예약한 개인화 메시지가 남는지를 별도로 검사해야 합니다. 로그아웃, 푸시 수신 중지, 계정 삭제를 하나의 처리로 묶어 이해하지 않습니다.[5]

계정 탈퇴. OneSignal의 User 삭제와 Subscription 하나의 삭제는 범위가 다릅니다. 삭제 뒤에도 앱·웹의 재등록이나 이메일·SMS 재추가로 레코드가 다시 생길 수 있습니다. 탈퇴 시 원천 회원 상태를 먼저 확인하고 대기 중인 이벤트·재시도·재등록 경로가 탈퇴 계정을 되살리지 않도록 막는 절차가 필요합니다. 완료 여부는 삭제 요청의 응답뿐 아니라 후속 동기화 뒤에도 확인하는 방식으로 설계합니다.[7]

첫 캠페인 데이터 준비도 진단표: 재구매 안내

다음은 가상의 소모품 재구매 캠페인입니다. 실제 고객 사례나 특정 제품의 기본 기능을 뜻하지 않습니다.

매일 오전 9시, Asia/Seoul 기준으로 대상을 검토합니다. 선정 시각을 T라 할 때, 같은 상품군의 최근 유효 구매 이후 경과 시간이 30일 이상 37일 미만인 활성 회원이 후보입니다. 여기서 하루는 24시간입니다. 취소·환불로 무효가 된 구매는 기준 구매에서 제외합니다. 웹 푸시 수신 가능 상태와 해당 목적의 발송 허용 근거를 확인하고 같은 기준 주문에 대한 이 캠페인의 중복 발송을 막습니다. 이 예시에서는 고객별로 확인된 웹 구독 하나만 선택합니다. 사용자 한 명의 중복 처리를 막는 것과 그 사람의 여러 접점에 동시에 보내지 않는 것은 별개의 규칙입니다.

먼저 캠페인 담당자가 이 사업 규칙을 확정합니다. 그다음 각 조건의 원천과 책임자, 전송 시점, 검증 증거를 아래처럼 연결합니다. 허용 지연은 이 예시 팀이 정한 운영 목표이지 OneSignal의 SLA나 일반 권장 수치가 아닙니다.

필요한 데이터사용 목적원천·담당자식별 연결허용 지연·전송 시점검증 방법누락 시 조치
구매 확정 이벤트·취소/환불 상태기준이 될 유효 구매 선택주문 원장·주문 백엔드 담당주문 ID → 회원 키변경 후 15분 내 반영 목표. 선정 때 원천 최신 상태와 대조동일 주문의 금액·상품군·상태 및 이벤트 수신 결과 비교유효 구매 여부가 불명확한 고객 제외
최근 유효 구매 시각·상품군30일 이상 37일 미만 판정주문 원장의 계산 결과·데이터 담당회원 키 + 상품군후보 추출 전 계산 완료, 계산 기준 시각 기록이벤트 일부가 아니라 원장의 최근 구매와 일치하는지 비교재계산 전 해당 고객 보류
회원 키와 구독의 연결다른 사람에게 보내지 않기인증 시스템·웹 개발 담당회원 키 → External ID → 해당 웹 구독로그인·계정 전환 결과를 확인한 뒤 사용두 테스트 계정과 두 브라우저로 연결·분리 확인충돌은 보류. 임의 추정으로 합치지 않음
발생·수집 시각과 전송 범위지연·누락을 비구매로 오해하지 않기이벤트 발행·수집 로그·연동 담당원천 + 이벤트 ID15분 처리 목표와 별개로 원천 대조를 마친 시각 표시시간대·누락 건·재시도 건 및 원장 대비 반영 범위 확인범위를 모르면 전체 후보를 확정하지 않음
계정 활성·탈퇴 상태비활성·탈퇴 계정 제외회원 원장·회원 백엔드 담당회원 키대상 확정 전 최신 원천 상태 확인상태 변경과 동기화 후 재등록 여부 점검최신 상태 확인 전 제외
웹 푸시 구독 상태사용 가능한 발송 접점 선택구독 상태·채널 연동 담당웹 구독 ID → 현재 사용자대상 확정 때 최신 확인값 사용, 변경 이벤트 반영테스트 환경의 허용·거부·연결 해제 상태 대조상태가 불명확한 접점 제외
목적·채널별 동의와 철회 상태이 안내의 발송 허용 근거 확인동의 관리 원장·개인정보/CRM 담당회원 키 + 목적 + 채널대상 확정 전 확인. 철회가 확인되면 동기화 완료를 기다리며 발송하지 않음현재 상태·변경 시각·취득 경로를 원천과 대조근거가 없거나 충돌하면 발송 금지
캠페인 처리·발송 이력동일 기준 주문의 중복 실행 방지캠페인 실행 원장·CRM 운영 담당캠페인 ID + 회원 키 + 기준 주문 ID작업 재시도·재실행 전 조회 및 중복 방지 처리같은 후보를 다시 처리하는 테스트의 결과 확인처리 여부가 불명확하면 재발송하지 않고 수동 확인

이 표에서 주문 데이터의 ‘15분’은 처리를 감시하기 위한 목표입니다. 15분 전 상태만으로 지금 발송해도 된다는 뜻이 아닙니다. 후보를 확정할 시점의 원천 상태를 확인할 수 없다면 확정을 미루거나, 확인 가능한 대상만 남깁니다. 발송 직전에 다시 바뀐 구매·철회 상태와 여정 예외는 별도의 실행 통제로 다뤄야 합니다.

준비도를 평균 점수로 합산하지 않는 것도 중요합니다. 여덟 항목 중 일곱 항목을 통과해도 남은 항목이 회원 연결이나 발송 허용 근거라면 그대로 실행할 수 없습니다. 진단 결과는 “연동률이 높다”가 아니라 어느 조건을 믿고, 무엇이 불명확해 누구를 제외했는가로 남깁니다.

데이터가 없다는 것과 구매하지 않았다는 것은 다릅니다

재구매 캠페인은 과거 구매뿐 아니라 그 뒤에 더 최근 구매가 없다는 사실까지 확인해야 합니다. 전송이 끊긴 기간이 있는데 이벤트가 없다는 이유로 ‘미구매’를 판정하면, 데이터 장애를 고객 행동으로 오해하게 됩니다.

다음 점검은 특정 제품 기능이 아니라 이 캠페인의 설계에 적용합니다. 발생 시각은 사업 사건이 일어난 때, 수집 시각은 수집 계층이 받은 때로 나눕니다. 예를 들어 2026-09-26T09:00:00+09:00와 2026-09-26T00:00:00Z는 같은 시각입니다. 이를 00:07:00Z에 수집했다면 두 기록 사이 지연은 420초입니다. 시간대가 포함된 표현에는 RFC 3339를 적용합니다. 다만 원천 시계가 틀렸다면 이 차이에도 오차가 있으므로 시계 이상을 별도로 점검합니다.[8]

내부 명세의 occurred_at, received_at 같은 이름은 설명용입니다. 이를 전송 대상의 실제 필드와 매핑해야 합니다. OneSignal Custom Event에는 timestamp와 idempotency_key 등이 있으며, 내부 필드명을 그대로 추가한다고 같은 의미로 처리되는 것은 아닙니다.[9]

중복 검사는 사건의 ID를 기준으로 합니다. 하나의 구매 사건을 재전송할 때는 같은 ID를 유지하지만 그 주문의 취소는 다른 사건입니다. CloudEvents도 원천과 ID의 조합으로 사건을 구별하도록 정의합니다. 주문 ID 하나를 구매·취소·환불 전체의 중복 제거 키로 쓰는 설계는 피해야 합니다.[10]

수신 순서가 바뀌는 경우에는 늦게 도착한 과거 이벤트가 현재 상태를 되돌리는지 확인합니다. 상태를 단순히 ‘마지막으로 도착한 값’으로 덮기보다 원천의 버전이나 최신 조회 결과를 기준으로 판정하도록 정합니다. 누락은 원장의 해당 기간 주문과 대조하고 지연된 이벤트를 다시 넣을 때도 이미 처리한 사건인지 확인합니다.

스키마 변경 역시 이름만 관리해서는 부족합니다. ‘구매 완료’가 결제 승인 시점을 뜻하다가 배송 완료 시점으로 바뀌면 같은 이벤트 이름이어도 캠페인의 30일 계산은 달라집니다. 의미·자료형·허용 값·발행 시점의 변경을 승인할 담당자와 적용 버전을 남기고, 구버전과 신버전이 함께 들어올 때의 처리 규칙을 정합니다.

서비스 작동 방식

채널 연결에서 첫 캠페인과 인계까지 — SDK와 채널을 설정하고 핵심 캠페인을 검증한 뒤 내부 담당자가 이어갈 수 있도록 인계합니다.

OneSignal에서 전송·저장·대상화를 따로 확인하세요

OneSignal을 쓰는 경우, 데이터 준비도 확인에 제품 조건을 더해야 합니다. 2026년 9월 26일 확인한 공식 문서에 따르면 Custom Event 수집에는 유료 플랜이 필요합니다. 이벤트를 수신해 Journeys 등에 사용하는 것과, 이벤트를 저장해 과거 행동 기반 Segment나 사용자 이력을 조회하는 것은 구분됩니다. 저장 기능은 순차 제공 중이므로 해당 앱에서 사용할 수 있는지도 확인해야 합니다.[11]

저장은 활성화한 시점부터 시작되며 보존 기간을 늘린다고 활성화 전 기록이 저절로 복원되지 않습니다. 공식 문서의 보존 상한은 90일이고 저장량 제한도 있습니다. 따라서 위 캠페인에서는 필요한 구매 기간을 실제로 조회할 수 있는지를 확인해야 합니다. CRM에 그 이력이 없더라도 원천 주문 시스템에서 대상을 산출해 기존 연동 경로로 전달하는 방법도 있습니다. 과거 이벤트를 새로 보내는 작업은 여정을 다시 시작시킬 수 있으므로 단순한 이력 복원으로 취급하지 않습니다.[11][12]

API 응답도 확인해야 합니다. Create Custom Events API는 HTTP 202와 함께 개별 이벤트의 errors를 반환할 수 있습니다. 사용자 식별에 실패한 이벤트가 섞였는데 상태 코드만 기록하면 누락을 놓칩니다. 같은 idempotency_key의 중복 억제는 공식 문서상 4시간 범위의 best-effort 처리이므로, 이를 전체 보존 기간의 완전한 중복 제거 보장으로 확대하지 않습니다.[9]

SDK가 설치됐다는 사실은 주문 확정의 사업 의미나 서버의 환불 상태까지 자동으로 연결됐다는 증거도 아닙니다. Custom Events를 SDK·API·연동 도구 중 어디서 보내는지 정하고 동일 사건을 여러 경로에서 보내는 경우에는 중복 책임을 합의해야 합니다.[12]

분석 도구에 있는 이벤트는 어디까지 다시 쓸 수 있을까

GA4의 구매 이벤트를 재활용한다고 가정해 봅시다. GA4의 User-ID는 서비스가 직접 일관된 값을 설정해야 하며 purchase의 transaction_id는 사용자가 아니라 거래를 식별합니다. 이벤트 이름이 같거나 숫자가 일치한다는 이유만으로 CRM의 회원과 연결됐다고 볼 수 없습니다.[13][14]

재사용 검토에서는 “어떤 계정의 어떤 주문이 어느 시각에 확정됐는가”를 원천까지 따라가 봅니다. 기존 계측의 의미가 맞으면 유지하되, CRM으로 보내는 경로와 식별자 매핑은 별도로 확인합니다. 분석 화면의 총구매 건수 비교만으로는 충분하지 않습니다. 취소, 익명 방문, 계정 전환이 포함된 테스트 기록도 같은 고객에게 올바르게 연결되는지 확인할 수 있어야 합니다.

준비가 덜 됐다면 보류·대상 축소·수동 검증 중에서 고릅니다

모든 데이터를 연결할 때까지 아무것도 못 하는 것은 아닙니다. 다만 편의를 위해 식별 충돌이나 수신 거부를 우회해서는 안 됩니다. 다음 조건으로 실행 여부를 판단합니다.

선택적용할 조건다음 행동
캠페인 보류고객 연결 충돌, 발송 허용 근거 불명확, 탈퇴·철회 미반영, 원천 데이터의 반영 범위를 알 수 없음원인과 책임자를 지정하고 확인 가능한 상태가 될 때까지 발송하지 않는다.
대상 축소특정 접점·집단만 데이터가 불완전하며 나머지 고객은 모든 필수 조건을 독립적으로 검증할 수 있음검증된 고객·채널만 남긴다. 개인화용 부가 속성이 없으면 해당 표현을 제거할 수 있지만 필수 조건은 생략하지 않는다.
수동 검증 후 제한 실행규모가 작고 원천이 정확하며 담당자가 실제 발송 대상 전체의 조건과 최신 상태를 확인할 수 있음추출 기준·확인 시각·승인자·중복 확인 결과를 기록한다. 일부 표본만 보고 전체 고객을 승인하지 않는다.

이 재구매 안내를 위해 이름·전화번호·전체 주문 원문까지 CRM에 복제할 필요는 없습니다. 판정에 필요한 회원 키, 상품군, 구매 기준 시각, 상태와 근거 참조부터 정하고 사용 목적이 없는 필드는 보내지 않는 방식으로 설계합니다. 동의 원문과 상세 이력은 책임 있는 원천에서 관리하고 CRM에는 필요한 판정값과 참조만 전달할 수 있습니다. 보관 기간과 조회 권한도 항목별로 정합니다.

원천 시스템과 책임자가 명확하고 첫 캠페인의 범위가 작다면, 기존 조회 기능과 통제된 대상 추출만으로 시작할 수도 있습니다. 별도의 고객 데이터 플랫폼이나 새로운 수집 도구를 먼저 추가할 필요는 없습니다. 반대로 여러 시스템이 같은 계정과 동의 상태를 다르게 해석한다면, 캠페인을 늘리기 전에 연결 규칙과 운영 책임부터 정리해야 합니다.

진단 결과를 구현용 명세로 옮길 때는 OneSignal 사용자 식별·이벤트 명세 키트를 참고합니다. 이 글의 표는 “지금 실행할 수 있는가”를 판단하고 명세 키트는 확정한 규칙을 개발·검수 항목으로 정리하는 데 사용합니다.

첫 캠페인의 준비 완료 기준은 데이터 항목 수가 아닙니다. 각 고객을 왜 포함했고 왜 제외했는지 설명할 수 있고, 그 판단의 원천·확인 시각·담당자를 찾을 수 있는 상태입니다. 그 한 캠페인에 필요한 데이터부터 연결하고 검증한 뒤 범위를 넓히면 됩니다.

시스템별 원천과 구현 책임을 함께 정리할 지원이 필요하다면, IXC의 고객 데이터 연동 설계에서 공개된 지원 범위를 설명합니다.