데이터 집계 환경 Zero to One 시도하기

들어가며

입사한 지 2년, 제품을 맡은 지 1년 반이 되도록 왜 데이터 집계 환경을 구축하지 못했을까요. 제 개인적인 의견으로는, 데이터가 급하지 않았기 때문이라고 생각합니다. '뭐? 데이터가 급하지않아? 데이터보다 더 중요한게 어딨어!' 라고 말할 수 있겠습니다. 주니어 PM으로써 가장 먼저 신경 썼던 것은, 약속한 개발 산출물을 약속한 시간 안에 오류없이 (거의 없이) 딜리버리하는 것입니다. 애초에 고객에게 우리 제품이 전달조차 되지 못하면 데이터가 무슨 소용일까요. 그 딜리버리를 배우는데 2년이 걸렸던 것 같습니다.(아직도 배우고 있긴 합니다.) 물론 딜리버리 안에는 수많은 스토리들이 숨어있지만, 오늘은 데이터 집계 환경을 만드는 게 메인이기 때문에 데이터 집계 환경에만 집중하도록 하겠습니다.

 

목적: 왜 데이터 집계를 하는 걸까요? 

1. 우리가 개발한 기능을 실제로 사용자가 어떻게 사용하는지 행동 데이터를 확인하고, 성과를 측정합니다.

그럼 왜 성과를 측정해야할까요? 우리가 만든 기능이 사용자의 문제를 정말 해결했는지, 사용자는 그걸 만족해하는지 우리는 알아야 다음에 개선을 할지 아니면 우리가 잡은 방향이 잘못된 것인지 알 수 있습니다.

 

2. 신규 기능을 개발 시 결정하기 힘든 내용이 있을 때, 데이터를 기반으로 소통하고 결정합니다.

그럼 왜 데이터 기반으로 소통해야 할까요? 실제 현업에서는 아주 작은 의사결정부터, 큰 의사결정까지 매우 다양하게 소통이 이뤄집니다. 저는 특히 '아주 작은 의사결정'에 집중했습니다. 결국 우리는 '팀'으로 일하는 조직이기 때문에 팀원 간의 신뢰가 너무 중요합니다. 그 신뢰를 더욱 안전하기 위해선 근거를 기반으로 하는 소통이 중요하다고 생각했습니다. 따라서 그 '근거'를 마련하기 위해 누구나 납득할 수 있는 사용자 행동 데이터를 집계하는 것입니다.

 

구현 목표

• 사용자가 어떤 버튼을 얼마나 눌러보는지 확인합니다.
• 사용자가 어떤 상황에서 각 버튼을 눌러보는지 확인합니다.

 

시작 시점

• 어떤 데이터를 보고 싶은지, 왜 그 데이터를 보고 싶은지 정의하였습니다.
  • 예시: 도움말 버튼을 사용자가 어떤 상황에서 자주 누르는지 파악하여, 도움말 버튼의 UI를 개선하거나 기능을 개선하는데 근거 자료로 사용한다.
  • 위 예시와 같은 항목을 20가지 넘게 생각나는데로 작성해보았습니다.
• 제품 싱크 회의에서 개발자 분들의 아이디어를 받았습니다.
• 주신 아이디어를 바탕으로 원하는 데이터와 어떤 목적으로 활용할 것인지 문서로 작성하였습니다.

 

구현 방향 결정

1. 정리한 항목 중, 지금 당장 집계할 수 있는 것과 집계하지 못하는 것을 나누었습니다.

• 특히, 서버에서 이미 API 호출을 할때 집계하는 로그 데이터들이 존재했는데, 주요한 사용자의 행동들은 DB에서 쿼리문을 통해 확인할 수 있었습니다.
• 이번에 중점적으로 집계 환경을 구축할 곳은 Client 쪽이었습니다.

2. 사내에서 집계 파이프라인 구조를 조사하였습니다.

• 기술적으로 복잡한 구조를 갖고 있었기 때문에, 기존에 집계 환경을 구축해둔 다른 솔루션과 서비스 담당자들을 한 분씩 찾아가 여쭤보았습니다. 감사하게도 너무 친절하게 설명해주셨고, 제가 이해한게 맞는지 확인까지 받을 수 있었습니다.

3. 집계할 수 없는 것 중 특히 행동 데이터들을 집계할 방법을 개발자분들과 논의하여 방안을 2개로 좁혔습니다.

(참고. 제가 맡은 제품은 B2B AI 학습 솔루션이며, 주로 사내 앱 서비스에 탑재되어 고객에게 전달됩니다.)

• 1안은 기존의 집계 파이프라인 구조를 동일하게 차용하는 것이었습니다.
  • 장점: 구조적인 고민없이, 우리 제품 개발자분들이 쉽게 인터페이스를 구축할 수 있음.
  • 단점: 우리는 솔루션이기 때문에, 우리 제품을 사용하는 서비스에 집계 권한이 종속됨.
• 2안은 서비스와 독립적으로 솔루션에서 집계하는 환경 구축하기 였습니다.
  • 장점: 서비스에 집계 권한이 종속되지 않고, 우리 제품팀에서 원하는대로 집계할 수 있음.
  • 단점: 새로운 구조에 대한 설계 필요, 시도하지 않은 방법이기 때문에 리스크가 비교적 큼.

4. 서버 개발자, 클라이언트 개발자와 논의 끝에, 현재는 실패를 최소화하여 Zero to One을 먼저 하는 것에 우선순위를 두고 1안으로 가는 것으로 합의하였습니다.

 

채택된 구축 방안 상세

• App, Web 모두
  • 솔루션 Client: 정의된 이벤트를 트래킹하는 인터페이스 개발
  • 서비스 Client: 솔루션에서 제공하는 이벤트 집계 인터페이스를 통해 각 서비스의 클라우드 저장소(App: Firebase, Web:GTM)에 데이터 전송하도록 개발
  • 솔루션 PM: 각 서비스의 데이터 분석 도구 (GA 등)를 통해 집계 여부 확인
• 장점
  • 현재 각 서비스에 구축된 집계 환경을 활용하여 빠르게 구축 및 확인 가능
• 단점
  • 집계하고 싶은 이벤트가 있을때마다 각 서비스에 이벤트 트래킹 인터페이스 배포 필요. (서비스 의존적)

하지만, 어떤 안을 선택하든 사용자가 결국 서비스에 있기 때문에, 우리가 뭔 짓을 해도 집계에 대한 결과 확인은 서비스에 의존적일 수 밖에 없었습니다. 우리가 기깔나는 인사이트를 얻을 수 있는 데이터 집계 인터페이스를 만들었다고 해도 고객이 없으면 집계가 되지 않으니 아무런 소용도 없으니까요.

실행

• 사내에 다른 솔루션에서 데이터 집계 환경 구축 당시의 구조를 그대로 차용하였습니다.
• 이벤트 정의 문서 작성 후 개발자 분들과 피드백 2회 진행 후 최종 업데이트하였고,
• 작업 일정을 산정하여 개발을 진행하였습니다.

테스트

• 문서에 정의한 이벤트명과 파라미터들이 잘 구현되었는지 각 서비스 GA4, GTM에서 확인.
  • Android, iOS: Firebase 연동 후 테스트 환경 GA4에서 확인
  • Web: GTM 연동 후, GTM 내의 미리보기 서비스에 Web Stage URL을 넣고 데이터영역 변수 확인

성과

• 사용자가 각 버튼을 얼마나 클릭 했는지 확인할 수 있습니다.
• 사용자가 Help 툴팁(또는 학습 보조자료 툴팁)을 보면서 녹음하는 횟수와 비율에 대한 정보를 알 수 있습니다.

테스트환경 GA4에서 의도한대로 집계됨을 확인

 

한계점

• 수정, 업데이트 요구사항 발생 시, 플랫폼 당 배포가 2군데에서 일어나야 합니다.
  • 솔루션 Client 배포 → 서비스 Client 배포
• 각 서비스의 분석도구에 세팅하고 유지보수하는 공수가 많이 듭니다.
  • e.g.
    • GA4에서 측정 기준을 테스트 환경과 상용 환경 모두 등록
    • GTM에서 변수, 트리거, 태그를 테스트환경과 상용 환경에 모두 등록
    • 수정이 필요하면 테스트환경과 상용환경에서 수정 필요
• 각 서비스에서 GA4 연동 권한을 제한하거나, 일정을 연기하면 LAURA 입장에서는 원하는 때에 사용자의 데이터를 확인할 수 없습니다.
• GA4에서는 이벤트 1건에 포함된 파라미터 묶음을 볼 수 없습니다.
  • e.g. 이 사용자가 어떤 학습 활동의 어떤 세션에서 몇 번째 메시지에서 도움말 버튼을 눌렀는가? 에 대한 정보는 알 수 없음.

개인 의견

• 이번에 처음으로 도입한 거라서 시행착오 비용이 꽤 들었으나, 최초 시도가 아니더라도 세팅하는데 공수가 많이 들어갈 것으로 보입니다. 따라서 이 방식은 유지보수의 난이도가 높고, 지속성이 높을 것 같지는 않습니다.
• 제가 생각한 바람직한 프로세스는 다음과 같습니다.
  • PM이 개발자에게 최소한의 요구사항을 정확하게 문서로 전달
  • 그 기능을 담당하는 각 플랫폼 개발자가 1번만 개발하고 1번만 배포
    • (모듈이 다른 서비스에 적용될 때는 추가 작업 또는 배포 불필요)
  • PM이 1개의 분석도구에서 각 이벤트별 1번의 세팅 (테스트용이 필요하다면 테스트용 1번, 상용 1번 총 2번)
  • PM은 분석도구 내에서 데이터를 조합하여 원하는 결과 확인

이후 고려사항

• 한 서비스 내에서 2개의 GA4 프로젝트를 띄울 수 있을지 확인 필요.
• 현재 구현된 상태에서 BigQuery를 도입하여 원하는 목표를 달성할 수 있는지 확인하기
• GA4 외에 다른 집계도구 조사해보기
  • Amplitude, Mixpanel ..

 

다음 포스팅은, 구체적으로 PM이 데이터를 추가하고 싶을 때 마다 해야할 행동들을 정리할 예정입니다.