네이티브 앱의 데이터 추적
당시에는 HTML5라는 웹 기술이 완성도를 갖추기 직전이라 웹소켓, CSS3, CANVAS 등의 HTML 기술들이 살짝 부족한 시기였고 디바이스의 성능 또한 앞서나가는 기술들을 뒷받침하지 못하고 있던 시기였다.
기존 웹 기반 서비스에서는 데이터 트래킹을 위한 작업이 별도로 필요하지 않았는데, 모바일 서비스가 필수이다 보니 네이티브 앱으로 출시를 했다. 개발 과정에서 네이티브 앱에서는 데이터 추적을 위해서는 버튼이나 화면에 이벤트를 각각 심어줘야하는 아주 번거로운 녀석이라는 것을 알게 됐다.
우선 먼저 어떤 데이터가 필요한지 지표를 작성하고, 작성된 지표의 로그를 확인할 수 있도록 UX 설계서를 바탕으로 모든 화면을 뒤져가며 이벤트 적용이 필요 각각의 화면이나 버튼에 이벤트와 속성값들을 작성했다. 각각의 이벤트 수는 600~700 개 정도 됐었던거 같은데 정말 밤새며 작성했었던 기억이 난다.
어쨌든 힘들게 고생해서 필요한 데이터를 수집할 수 있게 되었다.
서비스 런칭 그것을 통해서 사용자 퍼널, UX 개선, A/B테스트 , 비즈니스 성과 모델 등을 만들 수 있었는데 생각보다 빠진 곳이 많아 사용하기 부적절한 분석 결과가 도출됐다.
다시 필요한 곳을 설계하고 개발파트에 요청 > 구현 > 마켓에 배포, 또 빈구석이 발견되서 요청,구현, 배포…
특히 이용자는 앱 업데이트가 잦아 VOC 인입되고 있었다.
아무리 트래킹 코드 설계를 꼼꼼하게 한다고 했어도 문제가 발견됐다. 데이터를 분석할 때 빠지는 부분 때문에 데이터 활용도나 신뢰도가 떨어졌다. 반복하다 보니 앱버전이 엄청나게 많았다.
지금이야 docker나 쿠버네티스 등으로 데브옵스에서 관리를 도맡아 하기 때문에 체계적이지만 이때만 해도 그런 개념이 없어서 빌드, 배포 등의 관리하기도 힘들었다.
당시에는 네이티브 앱 개발을 앵귤러와 이클립스를 사용하고 있었는데, 웹 프레임워크를 활용해서 풍부한 데이터 분석과 크로스플랫폼 배포 등 유연한 개발 운영을 위해 개선을 요청했다.
지금은 하이브리드앱이란 용어 자체를 쓰지 않지만 많은 장점을 가지고 있었으나 네이티브 앱은 크로스플랫폼이나 앱 업데이트 등이 좋지 못했지만 퍼포먼스는 좋았고 당시 폰의 성능도 그리 좋지 못한 시절이라 네이티브 앱으로 주로 출시하고 있었는데 변경이 필요했던 것이다.
개발 툴 같은 경우에도 이클립스 기반의 툴과 안드로이드 SDK를 활용하여 앱 개발했었지만 안드로이드 스튜디오로 전환하고 있던 시기였다.
개발자의 눈치가 보였지만 요청을 했다!!
개발팀에서는 “안됩니다. 어렵습니다!!” 로 대응했지만, 속으로는 필요성을 느끼고 있었던것 같다. 정말 오랜시간 논의 끝에 개선하기로 하고 개발파트에서 주도적으로 리서치하고 검토하여 다양한 프레임워크를 논의하게 되었다.
목적
데이터 분석 등 활용이 쉬워야 한다.
개발 편의성
개발 미래 트렌드
업데이트 시 마켓 배포의 횟수를 최소한으로 가능해야 한다.
크로스플랫폼이 가능해야 한다
폰갭, 플러터, 리엑트 네이티브 등을 검토하며 최종적으로는 크로스플랫폼 등과 개발자 커뮤니티 등의 활성도 등을 검토하여 리엑트 네이티브로 결정하고 진행!!
거기에
지금은 BI 툴도 너무 좋고, 서비스 데이터 분석 툴도 믹스패인, 앰플리튜트 등 여러 툴이 많지만 그당시에는 GA밖에 몰랐고, 웹 말고 네이티브로 데이터 트래킹하는 것은 너무나 힘든 과정이었다.
당시 위의 그림만 보더라도 GA의 코호트는 가입한 날짜를 기준으로 재유입되는 정보를 제공하고 있다. 하지만 실제 서비스에서는 가입자 뿐만이 아니라 이벤트를 통해서 유입된 그룹, 특정의 행동을 한 그룹등을 코호트로 분류하여 그들의 특징적인 행동을 분석할 수 있어야 한다.
GA 쓰임새도 낮아 믹스패널을 적용해서 A/B테스트나 비즈니스 활용에 필요한 데이터 등을 볼 수 있게 되었다.
이제 데이터 활용만 잘하면 되겠구나!!
어찌됐든 개발 방식과 제공 방법의 변화로 MAU 성장률(CC)을 2% 상승 시킬 수 있었고, UT 측정을 통해 사용성 5%를 상승 시킬 수 있었다.