notikit 은 유저 중심 푸시 플랫폼입니다. 토큰이 아니라 유저를 기준으로 발송하고, 클릭까지 추적해 통계를 냅니다.
| 개념 | 설명 |
|---|---|
| 프로젝트 | 발송 단위이자 격리 단위. 각 프로젝트는 자기 api-key 와 Firebase 자격증명을 가집니다. |
| 디바이스 | 푸시 토큰 하나 = 디바이스 한 대. 앱 삭제가 감지되면 비활성 처리됩니다. |
| 유저(user_id) | 고객사 서비스가 쓰는 회원 ID(회원번호·로그인 아이디 등). 디바이스를 유저에 바인딩하면 유저 단위 발송·통계가 가능해집니다. 예전 이름 external_id 도 모든 API 에서 똑같이 받습니다(둘 다 보내면 user_id 우선). |
| 토픽 | 이름 붙인 수신자 묶음. 명단을 채우는 방식이 두 가지입니다(아래). |
토픽 — 하나의 개념, 두 가지 채우기
| 방식 | 명단이 정해지는 시점 | 예 |
|---|---|---|
| 구독식 | 구독 API 를 부를 때 저장 | 유저가 앱에서 켜는 것 — "야구 소식" |
| 규칙식 | 발송할 때마다 다시 계산 | 회사가 아는 값 — 등급 grade = vip |
둘을 가르는 질문은 하나입니다. 유저 본인이 알고 있는 사실인가? 유저가 직접 켜고 끄는 수신 동의라면 구독식이고, 회사 시스템이 계산해 identify 로 넣어 주는 속성이라면 규칙식입니다. "최근 30일 미접속"처럼 유저가 구독할 수 없는 조건은 규칙식으로만 표현됩니다.
발송하는 쪽에서는 차이가 없습니다 — 둘 다 type: "topic" 에 이름만 줍니다. 자세한 내용은 발송을 보세요.
예전에는 규칙식을 세그먼트라는 별도 개념으로 뒀습니다. 지금은 토픽으로 합쳐졌고,
type: "segment"발송은 하위 호환으로 계속 동작합니다.
클릭의 유저 귀속은 서버가 디바이스 바인딩에서 해석합니다. 클라이언트가 보낸 user_id 를 믿지 않습니다 — 그랬다면 등록 시 막아둔 사칭이 클릭 경로로 다시 열립니다.