Skip to content

푸시 모범 사례

푸시 알림은 앱 사용자와 소통할 수 있는 강력한 도구이지만, 적시에 관련성 있는 메시지를 전달할 수 있도록 신중하게 사용해야 합니다. 푸시 메시지를 보내기 전에 다음 모범 사례를 참조하여 알아야 할 사항과 확인해야 할 사항을 점검하세요.

푸시 메시지 작성

모범 사례로, Braze는 모바일 푸시 알림에서 선택적 제목과 메시지 본문의 각 텍스트 줄을 약 30~40자로 유지하는 것을 권장합니다. 작성기의 문자 카운터는 Liquid 문자를 계산하지 않는다는 점에 유의하세요. 즉, 메시지의 최종 글자 수는 각 사용자에 대해 Liquid가 렌더링하는 방식에 따라 달라집니다. 확실하지 않은 경우 짧고 간결하게 작성하세요.

푸시 알림 페이로드 크기 줄이기

최대 페이로드 크기는 플랫폼에 따라 다릅니다.

푸시가 최대 페이로드 크기를 초과하면 메시지가 전송되지 않을 수 있습니다. 모범 사례로, 페이로드를 수백 바이트 이내로 유지하세요.

푸시 페이로드란 무엇인가요?

푸시 서비스 제공업체는 전체 푸시 페이로드의 바이트 크기를 확인하여 사용자에게 푸시 알림을 표시할 수 있는지 여부를 판단합니다. 페이로드는 다음을 포함한 대부분의 푸시 서비스에서 4KB(4,096바이트)로 제한됩니다:

  • Apple 푸시 알림 서비스(APN)
  • Android의 Firebase Cloud Messaging(FCM)
  • 웹 푸시
  • Huawei 푸시

이러한 푸시 서비스는 이 한도를 초과하는 모든 알림을 거부합니다.

Braze는 통합 및 분석 목적으로 푸시 페이로드의 일부를 사용합니다. 이를 감안하여 최대 페이로드 크기는 3,807바이트입니다. 푸시가 이 크기를 초과하면 메시지가 전송되지 않을 수 있습니다. 모범 사례로, 페이로드를 수백 바이트 이내로 유지하세요.

푸시에서 다음 요소가 푸시 페이로드를 구성합니다:

  • 제목 및 메시지 본문과 같은 텍스트
  • Liquid 개인화의 최종 렌더링
  • 이미지의 URL(이미지 자체의 크기는 제외)
  • 클릭 타겟의 URL
  • 버튼 이름
  • 키-값 페어

페이로드 크기를 줄이기 위한 팁

페이로드 크기를 줄이려면 다음을 참고하세요:

  • 메시지를 간결하게 작성하세요. 일반적인 가이드라인은 40자 이내로 실행 가능하고 유익한 내용을 작성하는 것입니다.
  • 텍스트에서 공백과 줄 바꿈을 생략하세요.
  • Liquid가 전송 시 렌더링되는 방식을 고려하세요. Liquid 개인화의 최종 렌더링은 사용자마다 다르므로, Braze는 Liquid가 포함된 경우 푸시 페이로드가 크기 제한을 초과할지 여부를 판단할 수 없습니다. Liquid가 짧은 메시지를 렌더링하면 문제가 없을 수 있습니다. 그러나 Liquid로 인해 메시지가 길어지면 푸시가 페이로드 크기 제한을 초과할 수 있습니다. 사용자에게 푸시 메시지를 보내기 전에 항상 실제 기기에서 테스트하세요.
  • URL 단축기를 사용하여 URL을 줄이는 것을 고려하세요.

타겟팅 최적화

관련 사용자 데이터 수집

푸시 알림은 적시에 관련성 있는 알림으로 사용자를 타겟팅할 수 있도록 신중하게 다뤄야 합니다. Braze는 관련 세그먼트를 타겟팅하는 데 사용할 수 있는 유용한 기기 및 사용 정보를 수집합니다. 이 정보는 앱에 특화된 커스텀 이벤트 및 속성으로 보완해야 합니다. 이 데이터를 활용하면 메시지를 신중하게 타겟팅하여 열람률을 높이고 사용자가 푸시를 비활성화하는 사례를 줄일 수 있습니다.

알림 설정 페이지 만들기

앱에서 설정 페이지를 만들어 사용자가 수신할 알림을 직접 지정할 수 있도록 할 수 있습니다. 일반적인 접근 방식은 앱 설정 상태에 해당하는 부울 커스텀 속성을 Braze에 생성하는 것입니다. 예를 들어 뉴스 앱에는 속보, 스포츠 뉴스 또는 정치에 대한 구독 설정이 있을 수 있습니다.

뉴스 앱에서 정치에 관심 있는 사용자만 타겟팅하는 캠페인을 만들고자 하는 경우 세그먼트에 Subscribes to Politics 속성 필터를 추가합니다. true로 설정하면 알림을 구독한 사용자만 알림을 받게 됩니다.

커스텀 속성 설정에 대한 자세한 내용은 iOS, Android 또는 REST API에 대한 다음 문서를 참조하세요.

옵트인 및 관련성 향상

사용자 권한 얻기

푸시 활성화에 대한 일반적인 통계는 사용자가 운영체제에서 알림을 승인했는지 여부와 관련이 있습니다. 사용자가 iOS에서 알림을 끄면 Apple에서 푸시 토큰 전송을 허용하지 않으므로 시스템에서 자동으로 제거됩니다.

Android 13 이상에서는 푸시 알림을 표시하기 전에 먼저 권한을 얻어야 합니다. 이전 버전의 Android에서는 기본적으로 사용자가 알림을 구독하도록 설정됩니다.

푸시를 위한 사용자 사전 안내

사용자에게 푸시 권한을 요청할 수 있는 기회는 단 한 번뿐이며, 사용자가 이를 거부하면 기기 설정에서 푸시를 다시 활성화하도록 설득하기가 매우 어렵습니다. 따라서 시스템 프롬프트를 표시하기 전에 인앱 메시지를 사용하여 사용자에게 푸시를 사전 안내해야 합니다. 옵트인을 높이는 방법에 대해 자세히 알아보려면 푸시 프라이머 인앱 메시지를 참조하세요.

푸시 구독 제어 추가

사용자가 기기 수준에서 알림을 끄면 포그라운드 푸시 토큰이 완전히 제거되므로, 이를 방지하려면 사용자가 앱 내에서 직접 푸시 구독을 제어할 수 있도록 하세요. 자세한 내용은 푸시 구독 상태 업데이트를 참조하세요.

푸시 구독 상태 이해하기

푸시 구독 상태는 푸시 전송을 보장하지 않으며, 알림을 받으려면 사용자의 푸시가 활성화되어 있어야 합니다. 이는 고객 프로필에 포그라운드 푸시 권한이 서로 다른 여러 기기가 있을 수 있지만 푸시 구독 상태는 하나만 존재하기 때문입니다.

사용자가 앱에 유효한 포그라운드 푸시 토큰이 없는 경우(즉, 설정을 통해 기기 수준에서 푸시 토큰을 끄고 알림을 받지 않기로 선택한 경우) 구독 상태는 여전히 푸시에 대해 subscribed로 간주될 수 있습니다. 그러나 이 사용자는 포그라운드 푸시 토큰이 유효하지 않으므로 Braze에서 Foreground Push Enabled for App이 아닙니다.

또한 고객 프로필에 다른 앱에 대해 유효하거나 등록된 푸시 토큰이 없는 경우 세분화의 Foreground Push Enabled 필터도 false가 됩니다.

응답이 없는 사용자에 대한 일몰 정책 구현

시의적절하고 관련성 있는 푸시 알림만 보내더라도 일부 사용자는 여전히 응답하지 않거나 스팸으로 느낄 수 있습니다. 사용자가 푸시 알림을 반복적으로 무시한 이력이 있다고 가정해 보겠습니다. 이 경우 앱의 커뮤니케이션에 짜증을 느끼거나 아예 앱을 삭제하기 전에 푸시 전송을 중단하는 것이 좋습니다.

이를 위해 오랫동안 직접 열기 또는 영향받은 열기가 없는 사용자에게 푸시 알림 전송을 점진적으로 중단하는 일몰 정책을 만드세요.

  1. 직접 열기 또는 영향받은 열기를 기반으로 응답하지 않는 사용자를 식별합니다.
  2. 해당 사용자에게 푸시 알림 전송을 점진적으로 중단합니다.
  3. 푸시 알림을 완전히 제거하기 전에 더 이상 푸시 알림을 받지 않게 되는 이유를 설명하는 마지막 알림을 한 번 전달하세요. 이렇게 하면 사용자가 해당 알림을 열어 지속적인 푸시 수신에 대한 관심을 표시할 수 있습니다.
  4. 일몰 정책이 적용된 후에는 인앱 메시지를 사용하여 더 이상 푸시를 받지 않지만 인앱 메시징 채널을 통해 흥미롭고 유용한 정보를 계속 전달받을 수 있음을 사용자에게 알려주세요.

원래 푸시를 옵트인한 사용자에게 푸시 전송을 중단하는 것이 꺼려질 수 있지만, 특히 이전에 푸시를 무시했던 사용자라면 다른 메시징 채널이 이러한 사용자에게 더 효과적으로 도달할 수 있다는 점을 기억하세요. 사용자가 이메일을 열어본다면 이메일 캠페인은 앱 외부에서 사용자에게 도달할 수 있는 좋은 방법입니다. 그렇지 않은 경우 인앱 메시지는 사용자가 앱을 삭제할 위험 없이 콘텐츠를 전달할 수 있는 가장 좋은 방법입니다.

앱 실행에 대한 전환 이벤트 설정

푸시 캠페인에 전환 이벤트를 할당하면 캠페인 수신 후 일정 기간 동안 앱 실행을 추적할 수 있습니다. 앱 실행에 대한 전환 이벤트를 설정하면 푸시 캠페인 후 일반적으로 받는 결과 통계와는 다른 인사이트를 얻을 수 있습니다.

모든 푸시 캠페인 결과는 메시지의 직접 열기와 열기(직접 열기 및 영향받은 열기 모두 포함)를 분류하지만, 전환 추적은 직접 열기든 영향받은 열기든 모든 유형의 열기를 추적합니다.

또한 전환 이벤트 “앱 열기”를 사용하면 해당 전환 마감일(예: 3일) 이전에 발생한 앱 열기를 추적할 수 있습니다. 이는 영향받은 열기와 다른데, 사용자가 영향받은 열기로 등록되기까지의 시간이 각 사용자의 과거 참여 동작에 따라 사람마다 다를 수 있기 때문입니다.

관련 문서

원하는 정보를 찾지 못하셨나요? 다음 추가 모범 사례 문서를 확인해 보세요:

New Stuff!