앱 푸시

제품 밖으로 나간 사용자에게 말을 걸 방법은 오랫동안 메일뿐이었습니다. 이메일 마케팅은 값이 싸고 길게 쓸 수 있지만 받은편지함에서 순서가 밀립니다. 페이지덱이 주간 요약 메일을 보냈을 때 열어 본 사람이 열 명 중 한둘이었고, 그 한둘도 이틀 뒤에 열었습니다.

앱을 깔아 둔 사람에게도 사정이 같았습니다. 앱은 열어야 보이는데, 열 이유가 생겼다는 사실을 알릴 방법이 앱 안에만 있었습니다. 문서에 누가 의견을 달아도 다음에 앱을 열 때까지 아무도 모릅니다. 사흘 뒤에 열어서 확인한 의견은 이미 답할 시점을 지나 있습니다.

앱 푸시는 앱을 열지 않아도 화면에 뜹니다. 잠금화면에 한 줄이 올라오니 몇 초 안에 눈에 들어옵니다. 그런데 이 힘이 그대로 약점입니다. 눈에 들어오는 만큼 귀찮게 하면 사용자가 알림을 꺼 버리고, 한 번 꺼진 알림은 앱 안에서 되살릴 방법이 없습니다.

보내는 쪽과 받는 쪽 사이에 전달 서비스가 끼어 있습니다. 단계는 여섯입니다.

1. 권한을 받습니다. 운영체제가 알림을 띄워도 되는지 묻고, 허용해야 그 뒤가 진행됩니다. 이 물음을 앱을 깐 직후에 띄우면 왜 필요한지 모르는 상태에서 거절이 많이 나옵니다. 문서를 처음 공유하는 순간처럼 알림이 쓸모 있어지는 자리에서 묻습니다.
2. 기기를 식별할 값을 저장합니다. 앱이 설치될 때 기기마다 하나씩 받는 값이고, 서버는 사람이 아니라 이 값에 보냅니다. 앱을 지우면 무효가 되므로 실패한 값은 정리합니다.
3. 전달 서비스로 넘깁니다. 우리 서버는 기기에 직접 띄우지 못합니다. 운영체제를 만든 회사의 전달 서비스에 넘기면 그 서비스가 기기로 보냅니다.
4. 기기가 띄웁니다. 여기서 도착이 보장되지 않는다는 점이 중요합니다. 기기가 꺼져 있거나 절전 상태면 늦게 오거나 오지 않습니다.
5. 내용을 만듭니다. 제목과 본문 한 줄, 그리고 눌렀을 때 도착할 자리가 필요합니다. 도착할 자리를 정하지 않으면 앱 첫 화면에 떨어지고, 사용자는 방금 본 알림을 스스로 찾아야 합니다. 대부분은 그 자리에서 앱을 닫습니다.
6. 결과를 재고 조절합니다. 보낸 수, 실제로 띄워진 수, 눌린 비율, 알림을 끈 비율을 봅니다. 앞의 셋보다 마지막 숫자가 중요합니다. 눌린 비율이 낮으면 다음에 고칠 수 있지만, 알림을 끈 사람은 그 채널에서 영구히 사라집니다.

시점과 횟수도 설계에 들어갑니다. 밤에 보내지 않고 하루 상한을 정해 둡니다. 광고성 내용은 광고임을 표시하고 야간 발송에 별도 동의를 받아야 해서, 정보성과 광고성을 갈라 두지 않으면 규정 위반과 대량 해제가 같이 옵니다.

가장 잘 맞는 자리는 사용자의 행동에 붙은 알림입니다. 트리거 메시지처럼 정해 둔 일이 일어난 그 순간에 보내는 방식입니다. 내 문서에 의견이 달렸을 때, 나를 언급했을 때, 결제가 실패했을 때가 그렇습니다. 이런 알림은 받는 쪽에서 광고가 아니라 안내로 읽히고, 누를 이유가 알림 안에 이미 들어 있습니다.

두 번째는 돌아오지 않는 사용자를 부르는 자리입니다. 2주 동안 앱을 열지 않은 사람에게 그동안 쌓인 일을 알려 주는 식입니다. 다만 여기서는 보낼 이유를 사용자 쪽에서 찾아야 합니다. 새 기능이 나왔다는 소식은 회사 쪽 이유고, 초대받은 문서가 세 건 기다린다는 소식은 사용자 쪽 이유입니다. 뒤엣것만 보내는 팀과 앞엣것까지 보내는 팀의 해제율이 크게 갈립니다.

맞지 않는 자리도 분명합니다. 전원에게 같은 내용을 보내는 일괄 발송은 이 채널에서 가장 비싼 선택입니다. 메일에서 같은 발송은 지워지는 것으로 끝나지만 푸시에서는 알림이 꺼집니다. 한 번의 발송으로 그 사용자에게 보낼 수 있는 모든 알림을 함께 잃습니다.

무엇을 언제 알릴지 전체를 정하는 일은 알림 전략이 맡습니다. 채널마다 따로 정하면 같은 사실을 푸시로도 메일로도 받게 됩니다. 사용자 한 명이 하루에 받는 총량을 먼저 정하고 그 안에서 채널을 고릅니다.

"이번 건은 푸시로 갈까요, 메일로 갈까요?"

즉시 알려야 하는 일인지 나중에 읽어도 되는 일인지 가르는 질문입니다.

"푸시 해제율이 지난주에 1.8퍼센트예요. 발송 줄입시다."

알림을 끈 사람이 늘었으니 횟수부터 손대자는 말입니다.

"눌렀을 때 어디로 보낼지 안 정했어요. 지금은 첫 화면으로 떨어집니다."

알림을 눌러도 해당 내용으로 가지 않는다는 지적입니다.

페이지덱은 푸시를 두 종류로 나눠 둡니다. 내 문서에 무슨 일이 생겼다는 알림과, 제품 소식을 알리는 알림입니다. 설정에서 두 종류를 따로 끌 수 있게 만들었습니다.

현우가 처음 제안한 안은 하나로 묶는 것이었습니다. 설정이 단순해지고 소식 알림의 도달 범위도 넓어집니다. 지현이 반대한 이유는 하나로 묶으면 소식이 귀찮아진 사람이 문서 알림까지 끄게 된다는 것이었습니다. 나눠 두고 석 달을 보니 소식 알림을 끈 사람이 14퍼센트였고 문서 알림을 끈 사람은 2퍼센트였습니다. 묶어 두었다면 그 14퍼센트가 문서 알림에서도 사라졌을 것입니다.

열람이 잘 되니 많이 보낼수록 좋다고 여기는 경우가 많습니다. 메일보다 눈에 잘 들어오는 것이 사실이라 그렇게 읽힙니다. 하지만 이 채널의 비용은 발송비가 아니라 해제입니다. 메일은 한 통을 안 열어도 다음 통을 보낼 수 있고 옵트인으로 다시 동의를 받을 여지도 있지만, 알림을 끈 사람에게는 그 사실을 알릴 방법조차 없습니다. 하루 세 통을 두 달 보내 열람률을 지킨 팀이 반년 뒤에 보낼 대상 자체를 절반 잃는 식입니다.

보냈으면 전달된다고 보는 것도 흔합니다. 발송 기록에 성공이 찍히니 자연스러운 오해입니다. 실제로는 권한을 거절한 사람, 앱을 지운 사람, 기기가 절전인 사람에게 닿지 않습니다. 발송 성공은 전달 서비스가 받았다는 뜻이고 사용자가 봤다는 뜻이 아닙니다. 그래서 반드시 닿아야 하는 내용은 다른 채널을 함께 씁니다.