앰플리튜드 Guides를 통해 푸시 팝업 매끄럽게 유도하기

⏱️째깍악어🐊 선생님 앱에서 푸시 알림 대상자를 확보하기 위해 DB와 앰플리튜드로 현황을 분석하고 Amplitude Guides & Surveysamplitude.com (amplitude.com, 새 창)를 통해 앱 배포 없이 팝업을 운영해보았습니다. 이 글에서는 의사결정 단계에서부터 맥락별 UX 라이팅, 이벤트·사용자 속성 및 트리거 구성까지 하나의 기능이 프로덕트에 담기기까지 전 단계에서 고민한 흔적들을 정리해 보았습니다. 데이터 기반으로 푸시 유도를 고민하시는 프로덕트 엔지니어분들께 도움이 되기를 바랍니다.

⏱️째깍악어🐊 선생님 앱에서 푸시 알림은 주변 공고 추천, 채팅, 지원 결과 알림 등 서비스의 핵심 기능을 전달하는 통로입니다. 다만 최근 DB와 앰플리튜드 로그를 확인해보니 푸시 설정을 끄고 있는 선생님이 생각보다 많더라구요. 푸시 허용한 사용자 수치가 점점 하향 곡선을 그리고 있는 상황이었는데요. 물론 근본적으로는 저희가 제공하는 푸시의 설득력이 약하기 때문이라고도 해석할 수 있겠지만(예: 지나치게 잦거나 원치 않는 주변 공고 추천으로 짜증난 사용자가 푸시를 끄는 상황) 지속적으로 유입되는 CS를 확인하면 꼭 그렇지도 않은 상황처럼 보였습니다.

CS 중 🗣️​ "공고를 너무 늦게 봐서 놓쳤어요." 🗣️​ "부모님 채팅을 못 봐서 돌봄 장소가 바뀐지 몰랐어요." 🗣️​ "...(지원 결과 확인 안해 노쇼)"

게다가 ⏱️째깍악어🐊는 단일 푸시 허용 방식이 아닌 개별 푸시 항목에 대해서 허용 여부를 설정할 수 있기 때문에 시스템 푸시는 허용한 채로 개별 푸시를 끄는 방식으로 서비스를 사용할 수도 있는 상황이었는데요. 아래처럼요.

그럼에도 대다수의 선생님들이 시스템 알림 설정조차도 끈 상태로 두고 있다는 것은 우리의 푸시가 어떤 기능을 하는지, 또 어떻게 푸시를 켜야 하는지 인지조차 하지 못한 상태라는 것을 방증하는 지표처럼 보였습니다.

결과적으로 핵심 이벤트의 푸시 수신에 대한 필요성과 이를 저지하는 문제 상황은 충분히 확인된 바, 우리 플랫폼 그룹은 우선 선생님들의 푸시 허용률 상승을 목표로 여러 작업들을 수행해보기로 했습니다. 그 중에서 저는 푸시 허용 팝업을 통해 선생님들의 시스템 알림과 서비스 푸시 허용을 동시에 유도하는 작업에 착수해 보았습니다.

푸시 허용 실태를 조금 더 들여다 보니

작업 착수에 앞서 조금 더 데이터를 들여다 보았었는데요, 푸시 허용 관련해서 다소 특이한 양상을 확인할 수 있었습니다. 바로 활동량이 많은 선생님들과 이제 막 활동을 시작하는 선생님들 사이에서 푸시 허용 비율 간극이 꽤나 컸다는 점이었는데요, 활동량이 많은 슈퍼악어 선생님들은 푸시 알림을 허용(푸시 중 하나라도 허용)한 비율은 80%에 육박한 반면, 이제 막 활동을 시작한 선생님들은 약 30% 정도만이 푸시 알림을 허용하고 계신 상황이었습니다.

다만 푸시 유형별로 쪼개보니 [공고 알림 동의] 푸시에서는 그 간극이 조금 좁혀져 있는 상황이긴 했는데요, 이는 우리의 추천 공고 알림이 선생님들에게 적절하지 않게 전달되고 있음을 시사하기도 해서 추후의 과제로 남겨둔 상황입니다.

다시 푸시 허용으로 돌아와서, 푸시 허용과 활동량에 대한 인과를 확인할 수는 없지만 최소한의 상관 관계는 확인된 바, 푸시 유인은 주로 신규 사용자 층에서 발생할 것으로 해석할 수 있었습니다. 다시 말하면 아직 깊게 일하지 않았거나 알림 가치를 모르는 선생님들에게는 여전히 푸시 유인이 확실히 있는 상황인 것이죠. 푸시 허용을 유도해서 우리의 매끄러운 공고 지원 프로세스를 경험할 수 있다면 슈퍼 악어로까지 우리 서비스에 깊게 인볼브하게 만들 수 있다(물론 인과는 증명되지 않았습니다!)는 생각에 서비스의 리텐션 측면에서도 푸시 유도는 그 의미가 있어 보였습니다.

유의미한 푸시 채널

그렇다면 알림을 켠 사용자에게 푸시 채널은 실제로 작동하고 있었을까요? 이는 푸시 도달율(푸시를 실제로 클릭하여 앱 진입) 지표를 통해 확인할 수 있었습니다. 실제로 푸시를 통해 서비스에 진입한 사용자가 많다면(=도달율이 높다면), 푸시 채널 자체는 충분히 의미가 있다고 확언할 수 있는 것이죠. 이를 위해 utm을 활용했습니다(미리 utm_source로 push를 심어뒀던 스스로를 칭찬했습니다 👏).

utm_source=push, utm_content=offer-recommendation으로 필터링한 추천 공고 푸시 클릭 후 Page Viewed 추이를 보면, 일별 1,000~2,300건 수준의 유입이 꾸준히 발생하고 있었습니다. 주 1회 정도 눈에 띄는 피크도 보였는데요, 추천 공고 푸시가 단순히 발송만 되는 것이 아니라 실제로 앱 진입으로 이어지고 있다는 뜻이기도 했습니다.

이처럼 푸시는 우리의 핵심 기능을 보여주는, 실제로 유의미한 통로​임이 확인되었음에도 아직 일부 선생님들에게는 이러한 푸시의 가치를 충분히 경험되지 못하는 상황이었는데요. 결국 남은 문제는 어떤 사용자에게, 언제, 어떻게 푸시 설정을 안내할 것인가​에 대한 문제였습니다. 앱(웹)을 다시 배포하지 않고도 이 문제를 빠르게 검증하고 운영할 수 있는 방법으로 저는 Amplitude Guides를 선택했습니다.

👉 앰플리튜드 Guides 확인하기amplitude.com (amplitude.com, 새 창)

Guides를 통해 빠르게 띄운 팝업

시스템 OS 알림을 허용하면 사용자들은 무엇을 얻을 수 있을까요? 앞서 말했듯이 ⏱️째깍악어🐊 선생님 앱에서의 푸시 알림은 주변 공고 추천, 채팅, 지원 결과 알림 등 실시간 결과가 핵심인 다양한 기능들을 지원하고 있습니다. 이러한 사용자 니즈가 명확하게 수면 위로 떠오르는 시점에 유도 팝업을 띄운다면 그 효과가 분명할 것이라는 생각에 서로 다른 두 가지 맥락에서 두 가지 팝업을 설정했습니다.

두 가지 맥락, 두 가지 팝업 (1): 홈 진입

홈은 서비스 사용자라면 무조건 방문하게 되는, 탐색과 발견의 공간입니다. 사용자는 아직 특정 행동을 완료하지 않은 상태이고 놓칠 수 있는 혜택·맞춤 공고라는 프레임 자체가 이 맥락과 자연스럽게 연결됩니다. 때문에 파괴력이 강한 홈 화면에 팝업을 배치함으로써 최대한 많은 사용자가 푸시 허용에 대한 이득을 자연스럽게 인지할 수 있도록 했습니다.

잠재적인 손해 상황을 암시하는 "놓치지 마세요" 문구와 함께 하단의 서브 문구로 잠재적인 이득 상황을 동시에 제시함으로써 사용자의 손실 회피 심리와 보상 욕구를 자극하는 전략을 취했습니다. 이때 팝업에서는 기존의 푸시 설정 스위치 디자인과 유사한 디자인을 미리 노출함으로써 사용자가 길을 잃지 않고 이후 플로우에서 유사한 스위치로 시선이 옮겨갈 수 있도록 했습니다.

다만 강력한 힘은 강력한 부작용을 초래하는 법, 홈에서의 팝업은 사용자를 피로하게 만들 가능성이 높기 때문에 적확한 노출 조건이 필요했습니다.

1. 시스템 OS 푸시를 허용하지 않은 사용자를 대상으로만 팝업을 띄웠습니다. 해당 사용자는 앱이 실행되는 시점 플러터 브릿지를 통해 네이티브에서 판단, 앰플리튜드에 전달되므로 식별이 가능합니다.
2. 동일한 사용자에게 하루 최대 1회만 팝업이 띄워지게끔 설정했으며, 팝업과 마주한 사용자가 닫기 버튼을 클릭하면 3일 동안은 팝업이 띄워지지 않도록 빈도를 조정해 두었습니다.

놀랍게도 앰플리튜드에서는 이러한 기능들을 간편하게 제공하고 있어 약간의 코드 수정만으로도 목적을 쉽게 달성할 수 있는 상황이었습니다! (감사해요 앰플리튜드 👏)

--

두 가지 맥락, 두 가지 팝업 (2): 공고 지원 완료

홈 진입 팝업과는 달리 지원 완료 팝업은 공고 지원이라는 행동이 막 끝난 직후, 아직 시스템 알림이 꺼져 있는 사용자에게 노출됩니다. 모두 시스템 알림이 꺼져 있는 사용자이지만 이 지점에서의 사용자는 홈 진입 시점의 사용자와는 조금 다른 상황에 처해져 있습니다. 때문에 UX 라이팅을 조금 다르게 가져가 보았습니다.

우선 해당 지점의 사용자는 이미 공고 지원이라는 핵심 동작을 진행했습니다. 공고 지원이라는 행위는 기본적으로 스트레스를 유발하기 마련입니다. 공고를 탐색하고 자기 소개를 작성하는 과정을 통과하며 사용자는 에너지를 많이 소모하기 때문입니다. 더구나 공고 지원 직후는 결과가 아직 나오지 않은 불확실한 상태입니다. 탈락이나 대기처럼 불확실성 자체가 불안감을 야기할 수 있는 순간이기도 하죠.

이때 "놓치면 손해"라는 손실 회피 프레임을 사용하는 것은 오히려 압박과 불안을 증폭시킬 가능성이 있습니다. 그래서 지원 완료 팝업에서는 손실 회피를 의도적으로 배제하고, 사용자에게 통제감을 부여하는 방향으로 라이팅을 풀어내 보았습니다: 알려드릴까요 같은 질문형 구조를 사용해서 선택권 자체를 사용자에게 넘겼고, 지원 결과를 바로 받아보세요 라는 문장으로 정보에 대한 수신을 사용자가 능동적으로 선택할 수 있음을 전달했습니다.

정리하면 두 팝업 모두 알림을 켜달라는 동일한 목표를 가지고 있지만 팝업이 노출되는 지점과 해당 지점에서의 사용자 특성에 따라 UX 라이팅을 다르게 가져감으로써 팝업의 효과를 극대화시켜 본 것입니다. 맥락에 따라 다른 설득 프레임을 사용한 것이죠.

측정 가능하게 만든 이벤트와 사용자 속성

Guides 팝업을 운영하려면 트리거 조건과 결과 측정이 모두 가능해야 합니다. 이를 위해 이벤트 로그와 사용자 속성을 심어 지속적으로 측정이 가능하도록 해두었습니다.

이벤트 로그

system_notification_permission은 앱 진입 시 최초 1회 판단되어 앰플리튜드에 이벤트 형태로 전달됩니다. 물론 사용자 속성을 통해 푸시 허용 사용자를 발라낼 수도 있지만 퍼널 등을 활용하기에는 능동적으로 이벤트 자체를 수신 하는 것이 유리하여 추가한 것입니다. set_notification은 알림 설정 페이지(하단 이미지 참고)에서 스위치를 통해 ON/OFF가 변경될 때 유형과 상태를 포착합니다. 시스템 푸시를 허용하지 않은 사용자에 한하여서는 아래와 같은 안내 섹션을 별도로 띄워 기기의 알림 설정 페이지로 사용자를 이동시키며 전후의 푸시 상태를 측정해 이벤트를 쏘아냅니다.

사용자 속성

기존에 추적하고 있던 채팅과 공고 푸시 허용 여부에 더해 시스템 알림 허용이라는 신규 사용자 속성을 추가했습니다. 다만 시스템 알림 허용 여부는 네이티브단에서 비동기적으로 포착이 가능한 속성이기에 앰플리튜드를 처음으로 로드(amplitude.identify)하는 시점에서는 이 값이 누락될 가능성이 있습니다. 때문에 별도의 플러그인으로 처리하여 최초 로드 이후 사용자 상태를 업데이트하는 방식으로 구현하였습니다.

function AmplitudeNotificationPermissionPlugin({
  children,
}: PropsWithChildren<AmplitudeNotificationPermissionPluginProps>) {
  const sendNotificationPermission = (isGranted: boolean) => {
    if (!isApp()) return;

    /*
     * Tracker 인터페이스를 통해 사용자 속성 업데이트 처리합니다.
     * 이 지점은 사용자 속성이 특정된 이후의 시점입니다.
     */
    Tracker.update("system_notification_allowed", isGranted);
  };

  useEffect(() => {
    const handleVisibilityChange = async () => {
      // 해당 플러그인을 심어둔 지점에서 시스템 푸시 여부를 포착합니다.
      const result = await FlutterBridge.callHandler<
        "handleCheckNotificationPermission",
        BridgeResponse<{
          isGranted: boolean;
        }>
      >("handleCheckNotificationPermission", {});

      sendNotificationPermission(result?.data?.isGranted ?? false);
    };

    /* *** */
  }, []);
}

결과 지속적으로 추적하기

우리의 궁극적인 목적인 시스템 알림 허용자 증대라는 목적을 추적하기 위해 차트를 만들고, 앰플리튜드 대시보드 형태로 추적하는 방향을 선택했습니다. 알림 허용 부산물로 채팅/공고 알림 허용자 수도 증가할 것임을 기대하면서 관련 지표에 대해서도 측정할 수 있도록 해두었습니다.

1. 시스템 알림 허용: system_notification_allowed = true 사용자 수(비율) 증가

• 교차 검증을 위해 system_notification_permission 유니크 이벤트 수도 동시에 추적

2. 채팅/공고 알림 허용: set_notification where notification_type: chat/offer & enabled: true 유니크 이벤트 수, chat_allowed·recommend_allowed 변화

추가적으로 Guides에서 기본적으로 제공하는 [인사이트] 기능을 이용하여 두 팝업이 얼마나 노출되었고, 사용자에게 얼마만큼의 반응을 이끌어 냈는지 지속적으로 확인하였습니다.

해당 데이터를 기반으로 지속적으로 추이를 확인했고, 푸시 허용 팝업 관련 인사이트를 정리해 팀에 공유드렸습니다. 3명 중 1명이 시스템 알림을 허용해 놓은 최초 시점에 반해 푸시 유도 팝업 시행 이후 절반 정도의 사용자가 시스템 알림을 허용, 사용자 알림 허용 분포가 조금씩 변경되는 ✨꽤나 긍정적인 결과✨를 낳고 있습니다. 다만 추천 공고 푸시를 비허용하는 사용자가 꾸준히 증가하고 있어, 후속 작업으로 사용자 맞춤 추천 공고 로직을 변경하는 작업에 착수하려 합니다.

마무리하며

이번 작업을 돌아보면 초기 인사이트 → 분석 → Guides 운영 -> 결과 측정 -> 후속 작업 결정이라는 흐름이 꽤 매끄럽게 이어졌다고 느낍니다. 여러 지점에서 이미지 생성 에이전트, 앰플리튜드 같은 툴들을 잘 활용했기 때문인 것 같습니다.

개인적으로 가장 인상 깊었던 지점은 같은 목표(알림 허용)라도 맥락별로 UX 라이팅을 달리한 지점이었습니다. 처음 메시지를 기획-디자인 팀에 공유드렸을 때 부정적인 의견도 있었는데요, 홈에서는 손실 회피가 자연스럽지만 공고 지원 직후에는 오히려 통제감을 주는 것이 맞다는 제 판단을 기반으로 설득했죠. 그리고 맥락을 나눈 가설과 사용자 반응이 같은 방향이었기에 더 값지게 느껴집니다(물론 라이팅에 따라 다른 A/B 테스트를 진행한 것은 아닙니다만 두 맥락에서 사용자 반응성에 차이가 있다는 것이 이를 방증한다고 보고 있습니다).

이벤트와 사용자 속성을 먼저 정비해 둔 덕분에 Guides뿐 아니라 향후 다른 채널의 실험에도 같은 데이터를 재사용할 수 있을 것 같습니다. 조직이 개편되면서 조금 더 빠른 속도로 협업하며 기능을 개발할 수 있었는데요, 좋은 서비스는 혼자 만드는 것이 아니라는 점을 또다시 확인하는 작업이었습니다 ☺️. 긴 글 읽어주셔서 감사합니다.