브레이즈를 통한 가설 검증 (1)
숙지해야 할 브레이즈의 주요 제약 사항
본 시리즈는 처음 브레이즈를 사용하는 이들이 마주하게 될 브레이즈의 주요 제약 사항들을 공유하고, 이를 극복하여 어떻게 유의미한 가설 검증을 해나아갔는지를 살펴보는 ‘브레이즈 사용기’ 이다. 첫 번째 편으로, 담당자들이 숙지해야 할 주요 제약 사항을 정리해보았다.
딜라이트룸에 입사하고 처음 만난 브레이즈에 대한 나의 첫 인상은 그로스에 목마른 여러 조직에 꼭 필요한 툴 ! 이었다. 물론 가격이 그렇게 비싼 줄 모르고 그런 생각을 한 것이었지만.. 연동만 잘 해놓으면 별도의 추가 클라이언트 로컬 개발 작업 없이, 독립적으로 여러 가설을 실험해볼 수 있는 도구이기 때문이다. 앱 내 유저들에게 푸쉬 메세지, 인앱 메세지를 여러 포맷으로 보낼 수 있고, 이메일 또한 사용할 수 있다. 메세지 내의 문구도 유저의 프로퍼티를 가져다가 커스텀하게 사용할 수도 있고, 무엇보다 메세지 발송 기준과 타겟 새그먼트를 상당히 뾰족하게 구성할 수 있다.
브레이즈 인앱 메세지 세팅 화면브레이즈에 대한 나의 두번째 인상은 조악하고 투박해서 더 매력적인 툴! 이었다. 물론 그 조악함이 운영상의 큰 비효율과 불편함을 초래할 줄은 몰랐지만.. 브레이즈 또한 스타트업의 제품으로서 계속해서 변화하고 성장하는 모습을 보이고 있다는 점이 퍽 매력적이었다. 출시하지 못했거나, 절반만 출시한 기능들도 그 방향을 놓고 보면 굉장히 임팩트가 큰 기획들이라 생각되었다. 앞으로가 더 기대되는 툴 이런 느낌이랄까.
그러나 그 설렘도 아주 잠깐이었다. 막상 여러 가설들을 준비하고 실제 브레이즈를 쓰기 위해 책상 앞에 앉아보니, 쉽지 않은 난관들이 나를 가로막았다. 기능상의 제약사항을 AtoZ 숙지한 상태에서 기획을 짠 것이 아니다보니, 세팅 과정에서 맞닥뜨리게 된 제약사항들에 따라 중간 중간 기획 방향을 수정하거나 아예 드랍해야 하기도 했다. 그 중 주요 몇 가지 제약 사항들을 실제 사례를 담아 아래와 같이 정리해보았다.
난관1 - 캔버스 사용 불가
브레이즈의 캔버스 예시 이미지가장 큰 놀라움(?)은 그들이 중점적으로 어필하고 강조하던 핵심 기능인 캔버스 기능을 사용할 수 없다는 점이었다. 캔버스는 한 유저의 인앱 메세징 여정 맵을 한번에 그려내어 복수 개의 캠페인을 효율적으로 세팅 및 관리할 수 있게 해주는 기능이다. “첫 메세지를 받은 유저가 이 행동을 하면 (CTA를 누르거나 닫으면) 각 행동에 따라 그 다음에는 이 메세지를 받게끔 하고, 후속 메세지에 대한 행동에 따라 그 다음 메세지를 또 차별화 한다...”
얼핏 들어도 매력적인 이 기능은 아이러니하게도 ‘인앱 메세지'에는 사용이 불가능했다. 브레이즈를 통해 사용할 수 있는 메세징 채널은 ‘푸쉬 메세지’, ‘인앱 메세지', ‘이메일' 3가지이다. 그 중 알라미는 ‘인앱 메세지’에서 주된 효용감을 얻고 있었는데, 인앱메세지는 캔버스로 설계할 수가 없다는 치명적인 제약 사항이 있었다.
또한 캔버스 상에서는 액션 기준의 트리거 사용이 제한되었다. 브레이즈는 특정 시간에 맞춰 메세지를 보내거나, 유저의 특정 행동(액션)을 트리거 삼아 메세지를 보낼 수 있다. 그 중 특히나 인앱 메세지의 경우 푸쉬 메세지나 이메일의 경우 보다는 액션 트리거가 효과적이다. (앱을 사용하는 도중에 특정 액션 이후 트리거 되어 자연스럽게 이어지는 화면인 것처럼 구성될 수 있으므로). 그런데 캔버스 상에서는 첫 순서에 해당되는 캠페인에서만 액션 기준의 트리거 사용이 가능하고, 그 이후의 플로우에서는 시간 기준의 트리거만 사용 가능하다. 가령 첫 순서의 푸쉬 메세지를 클릭해서 열어본 유저들을 대상으로, 그들이 알람을 해제하는 액션을 기준으로 두 번째 푸쉬 메세지를 발송할 수가 없다. 대략 그 다음 날 아침 9시쯤 메세지가 발송되게끔 시간을 기준으로 설정해야 한다. 원하는 만큼 충분히 뾰족하게, 임팩트 있게 메세지를 딜리버 할 수가 없는 상황인 셈이다.
그래서 캔버스 사용은 포기했다. 개별 캠페인 단위로 유저 여정을 한땀 한땀 만들어가는 수밖에.
난관2 - 서버 이벤트 값을 기준으로는 메세지 트리거 불가
브레이즈는 그들이 제공하는 이벤트 및 유저 프로퍼티가 있고, 고객사가 직접 커스텀하게 작업해서 활용하는 커스텀 이벤트 및 커스텀 유저 프로퍼티가 있다. 그 중 당연히 말그대로 커스텀 값들이 메세지 트리거 및 새그먼트 타겟팅에 더 유용하게 (뾰족하게) 커스텀되어 사용되기 좋다. 앱내 특정 버튼을 클릭한 유저에게 메세지를 쏘거나, 특정 화면에 방문한 적이 없는 유저에게 메세지를 쏘는 것들은 커스텀 값을 기준으로 삼아야 하니까.
그런데 수집하는 이벤트 중에 서버 이벤트 값으로는 메세지 트리거가 되지 않는다. 가령 구독을 해지하는 시점에 메시지를 쏘고 싶은데, 유저의 구독 상태값이 바뀌는 서버 이벤트로는 트리거가 되지 않았다. 트리거에 사용하려면, 서버 이벤트와 별개로 구독해지 버튼에 클라이언트 이벤트를 심어 그것을 트리거 삼아야 했다. 또는 서버 이벤트로 새그먼팅(타겟팅)은 할 수 있어서, 그 이벤트를 발생시킨 적 있는 유저를 타겟하는 것도 방법이다. 이벤트를 발생하는 시점에 쏠 수는 없는 것이지만, 그래서 메세징 시점이 뭉툭해지지만, 구독 해지를 1일 이내 해본 적 있는 사람으로 새그먼트를 만들어 그들이 앱을 실행하면 메세지를 받을 수 있게 해두었다.
- 서버 이벤트 값 기준으로 메세지 트리거 [불가능]
- 서버 이벤트 값 변화에 영향을 주는 클라이언트 이벤트 값 기준으로 메세지 트리거 [가능]
- 서버 이벤트 값 기준으로 유저 새그먼트 생성하여 그들이 앱을 열 때 메세지 트리거 [가능]
난관3 - 특정 이벤트 프로퍼티를 기준으로 유저 새그먼트 생성 불가
이번에는 유저 새그먼트(타겟팅)에서의 난관에 부딪혔다. 특정 화면에 방문해본 적 없는 유저들을 타겟팅하고 싶은데, 그게 안되었다. 유저 새그먼트 생성시에 이벤트 프로퍼티 사용이 불가능하기 때문이다.
만약 앱 내 화면이 4개가 있고 각각을 Pageview A, Pageview B ... Pageview D 라는 별개 이벤트 값으로 수집하고 있으면 해당 화면을 방문했는지 여부로 새그먼팅이 가능하다. Has Pageview A more than 0 times 등 으로 설정하면 된다.
하지만 앱 내 화면 4개의 Pageview 이벤트를 하나의 이벤트로 수집하고, 프로퍼티 값 page_type = A, B, C, D 으로 식별하게끔 설계가 되어 있다면 A 화면에 방문한 유저만 발라내는 새그먼팅이 불가능하다. Has Pageview more than 0 times 로 뭉툭하게 타겟팅이 된다.
유저 새그먼트 섹션 - 이벤트의 프로퍼티 설정 불가이벤트 설계상 어느 정도 뎁스 이상부터는 프로퍼티 값으로 이벤트를 식별하는게 일반적이라 이같은 제약사항은 크리티컬한 제약사항이라 생각되었다. 또한 꼭 뎁스가 깊지 않더라도 특정 이벤트 프로퍼티를 기준으로 유저를 타겟팅하고 싶을 수도 있다. 가령 구매하기 버튼 클릭 이벤트 값에는 그 때 선택한 상품이 무엇인지를 프로퍼티로 쌓고 있다. ‘연간 구독' 일 수도 있고, ‘월간 구독'일 수도 있다. ‘월간 구독'을 선택하여 구매하기를 누른 유저들만 타겟팅하고 싶어도 현재 브레이즈에서는 그렇게 할 수가 없다.
메세지 트리거 섹션 - 이벤트의 프로퍼티 설정 가능이 때 특정 이벤트의 프로퍼티를 사용하여 유저 새그먼트를 만들 수는 없지만, 메세지 트리거로는 설정할 수가 있다는 점을 발견하여 하는 수 없이 이상한 방법(?)으로 원하는 가설을 확인해볼 수 있게끔 구색을 갖춰볼 수는 있었다. ‘월간 구독'을 선택하여 구매하기를 누른 유저들만 타겟팅할 수는 없지만, ‘월간 구독'을 선택하여 구매하기를 누른 시점에 메세지를 발송할 수는 있다. 원래는 ‘월간 구독'을 선택하여 구매하기를 누른 유저들을 타겟하여 그들이 구매 화면에 다시 들어오는 액션을 기준으로 메세지를 발송하고 싶었지만, 그러한 타겟팅이 안되다보니 뾰족한 메세지 발송 시점을 희생하여 타겟팅을 보조해야 했다. ‘월간 구독'을 선택하여 구매하기를 누른 액션 기준으로 30초 뒤에 메세지가 발송되게끔 세팅하는 것으로 스스로 합의를 보았다.
- 월간 구독 구매하기를 클릭 해본 유저를 타겟하여, 특정 시점에 메세지 쏘기 [불가능]
- 월간 구독 구매하기를 클릭한 액션 이후 n초 뒤로 설정하여 메세지 발송 [가능]
난관4 - 유저 새그먼트 만들기 어려움
브레이즈가 제공하는 여러 종류의 타겟팅 규격타겟팅 섹션에서 흥미로웠던 것은, 다양한 틀의 유저 타겟팅을 제공해준다는 점이었다. 하지만 브레이즈가 제공해주는 규격 틀들을 활용하여 내가 원하는 타겟팅을 하려면, 이리저리 조합을 해보며 조각을 해야 했다.
가령 “무료 체험을 시작한지 n일 째”를 타겟팅할 수 있는 틀을 제공해주지 않는다. 하여 “무료 체험을 시작한지 n-1일이 넘음" and “무료체험을 시작한지 n일을 넘지 않음" 이라는 틀의 조합으로 구색을 맞춰야 했다.
이는 마치 ‘주어지는 문장들만으로 원하는 내용의 글을 완성하시오' 같은 느낌이랄까.
같은 '액션'을 기준으로 타겟팅을 할 때에도, 주어지는 틀 종류가 여러 가지이다.
- 특정 액션을 처음 해본지 얼마 되었는가
- 특정 액션을 몇 번 해보았는가
- 특정 액션을 최근 n일 이내에 해보았는가
훌륭한 서비스라는 전제하에, 브레이즈가 제공하는 틀들로 내가 원하는 모든 타겟군을 정의하고 표현할 수 있을지도 모른다. 그러나 이미 내가 발견한 부족한 점들 - 위 난관1~3로 미루어 짐작컨대 새그먼트의 틀들의 조합이 모든 유즈케이스를 커버할 수는 없을 것 같다는 생각이 강하게 든다. (난관 3부터 해결을 해주면 좋겠다. 난관4는 그럭저럭 workaround 를 찾아가고 있으니..)
이러한 난관과 딛고 드디어 몇 가지 가설들을 실험하기 시작하였다. 심지어 커스텀 이벤트와 유저 프로퍼티도 세세하게 심어져 있지 않던 때였다. 원하는 만큼 뾰족한 타겟팅과 트리거는 아니었지만, 시행착오를 겪으며 한 스텝 한 스텝 나아가자는 마인드로 첫 실험을 진행했다.
프리미엄 기능 화면들을 방문하지 않은 유저를 타겟팅하고 싶었는데 그것은 난관3으로 인해 안되었고, 특정 상품을 선택했던 유저를 타겟팅하고 싶었는데 그것도 난관 3으로 인해 안되었다. 유저 속성 값을 기준으로 메세지를 차별화하고 싶었는데 속성 값 수집을 브레이즈 내에 하지 않고 있었고, 특정 기능으로 랜딩을 보내고 싶었는데 딥링크 작업이 되어 있지 않은 때였다.
하여 첫 실험은 신규 유저들이 앱을 첫 실행한지 5분 뒤에 프리미엄 무료체험을 권하는 메세징 실험이 되었다. 많은 기획을 덜어내고 아주 단순하게, 모든 신규 유저에게 메세징을 쏴보는 실험부터 시작해본 셈이다.
[다음 편에 계속]
