본문으로 건너뛰기

푸시 알림은 앱이 아니라 사용자에게 보내야 한다

Your push notifications are probably about your app, not your user

medium.com

핵심 요약

  1. 알림은 사용자가 받아들일 이유가 있을 때만 보내야 한다. 첫 가치 경험 뒤에 권한을 요청하고, 메시지·시간·빈도를 사용자별 상황에 맞춘다.
  2. 야간 점수 계산과 시간별 발송 작업으로 이탈 가능성이 있는 사용자만 선별한다. 구체적인 알림 이유가 없거나 적절한 시간이 아니면 발송하지 않는다.
  3. 주간 예산, 플랫폼별 권한·채널·토큰 관리, 발송 후 옵트아웃 측정으로 알림의 비용을 통제하고 사용자 신뢰를 지킨다.

도입

푸시 알림은 앱의 일정이나 캠페인 목표가 아니라, 사용자가 지금 알림을 반길 이유를 기준으로 보내야 한다. 글은 첫 실행 직후 권한을 묻지 않고 앱에서 가치를 경험한 뒤 구체적 용도를 설명해 요청하는 방법을 제안한다. 또한 사용자별 활동과 현지 시간, 발송 이력을 활용해 불필요한 알림을 줄이는 운영 방식을 제시한다.

상세 요약

권한은 첫 가치 경험 뒤에 요청한다

첫 실행 때 시스템 권한을 묻는 대신, 저장·주문 완료·메시지 수신처럼 사용자가 앱의 가치를 경험한 순간을 기다린다. 시스템 창 전에 앱 자체 설명 화면을 보여주고, “알림 활성화”가 아니라 “주문이 발송되면 알려드리기”처럼 구체적 이유를 말한다. iOS에서는 정보성 알림에 provisional authorization을 사용하면 시스템 권한 요청 없이 Notification Center에 조용히 전달할 수 있다.

사용자에게 해당하는 이유만 보낸다

누구에게나 보낼 수 있는 문구는 알림으로 보내지 않는다. 미완성 초안, 사용자가 저장한 상품의 가격 변화, 연속 기록처럼 특정 사용자가 관심을 보인 정보가 기준이다. 첫 문장에 구체적인 내용을 두고, 알림 하나에는 한 가지 정보만 담는다. 탭하면 예고한 화면으로 바로 이동해야 하며, 허위 긴급성이나 실제로 발생하지 않은 활동을 꾸며내지 않는다. 발송 사유·제목·본문·딥 링크를 미리 정리한 표를 유지한다.

이탈 가능성과 적절한 시간을 함께 계산한다

매일 밤 사용자별 복귀 가능성을 점수화한다. 마지막 실행 이후 날짜, 첫 주 세션 수, 핵심 행동 완료 여부, 과거 푸시 탭 여부 등을 입력으로 삼으며, 글은 설명하기 어려운 모델보다 직접 조정할 수 있는 가중 합계를 권한다. 매시간 발송 작업은 점수가 기준선 아래인 사용자 중, 앱을 열었던 현지 시간대에 있고 이번 주에 아직 알림을 받지 않은 사람을 고른다. 사용자에게 맞는 이유가 없으면 보내지 않는다.

앱 실행 시 현지 시간과 Wi-Fi 여부를 기록하면 사용자의 활동 시간대를 파악할 수 있다. 집에서 주로 사용하는 네트워크는 요청 IP를 해시해 묶는 방식으로 추정할 수 있으며, SSID 조회에는 위치 권한이 필요하므로 사용하지 않는 방식을 제안한다. Android에서는 비계량 네트워크 조건의 백그라운드 작업으로 기기에서 처리할 수 있고, iOS에서는 서버가 네트워크 패턴을 추론해 일반 푸시를 보낸다. 이 신호는 습관 알림에만 쓰고, 광고나 공지 발송 조건으로 사용하지 않는다.

사용자별 알림 예산을 둔다

  • 일반적인 리마인더는 주 1회, 최대 2회로 제한하고, 알림 사이에는 최소 24시간을 둔다.
  • 현지 시간 기준 22시부터 8시까지는 보내지 않는다. 알림을 무시하면 다음 발송까지 2주를 기다리고, 두 번 연속 무시하면 거래성 알림만 남긴다.
  • 거래성 알림은 사용자가 시작한 작업의 완료나 메시지 수신을 알리는 경우다. 리마인더처럼 앱이 먼저 제안하는 알림과 구분해 예산을 적용한다.

전달 설정과 권한 복구도 관리한다

Android 8 이상에서는 알림 종류마다 사용자가 이해할 수 있는 채널을 만들고 중요도를 알림 성격에 맞춘다. 이미지 푸시는 이미지 자체가 내용일 때 사용하고, 100KB 이하의 이미지와 텍스트 대체 내용을 준비한다. iOS에서 이미지를 첨부하려면 Notification Service Extension이 필요하며, 이미지를 가져오는 시간은 30초로 제한된다.

FCM의 unregistered(HTTP 404), APNs의 BadDeviceToken 또는 Unregistered 응답을 받으면 해당 토큰을 삭제한다. 앱을 실행할 때마다 토큰을 다시 등록한다. 딥 링크는 앱이 종료된 상태에서 알림을 눌러도 정확한 화면을 열어야 한다. 알림 배지는 사용자가 해당 내용을 확인하면 지운다.

권한을 거절한 사용자에게는 시스템 권한 창을 반복해서 띄우지 않는다. 앱 안에서 작업 완료 알림이나 저장한 항목의 재입고 알림처럼 현재 화면에 맞는 이유를 한 번에 하나씩 제시하고, 앱 설정으로 바로 연결한다. 안내는 주 1회를 넘지 않으며 세 번 닫으면 한 달간 중단한다.

열람률보다 옵트아웃을 본다

발송 후 7일 내 옵트아웃 비율, 핵심 행동으로 이어진 열람 비율, 현지 시간대별 열람, 권한 요청 시점의 동의율, 앱 내 재요청 전환율, 잘못된 토큰 비율을 추적한다. 글은 각각의 기준값으로 발송당 옵트아웃 0.5% 미만, 열람 후 핵심 행동 30% 초과, 사전 안내 화면의 동의율 60% 초과, 재요청 전환율 10% 초과, 잘못된 토큰 비율 2% 미만을 제시한다. 발송 사유와 시간, 이후 48시간의 결과를 함께 기록하면 문제가 있는 알림을 빠르게 식별할 수 있다.

결론

알림 운영의 기준은 발송량이나 열람률이 아니라, 사용자가 알림을 끄지 않고 핵심 행동으로 이어지는지다. 사용자별 발송 예산과 무시 횟수에 따른 중단 규칙을 두고, 발송 이유·시간·이후 48시간의 결과를 기록해야 한다. 권한 복구 안내도 맥락에 맞게 제한하며, 플랫폼별 전달 조건과 토큰 상태를 함께 관리한다.