모바일 앱 로그분석, 어떻게 시작해야 할까?

https://brunch.co.kr/@leoyang99/15

모바일 앱 로그분석, 어떻게 시작해야 할까?

이 글은 마이리얼트립의 양승화님이 브런치에 게시한 글을 읽고 정리한 글입니다.
자세한 내용은 원문을 참고하심이 좋습니다.

--

서비스를 이용하는 사용자들이 남기는 로그

• 서비스 로그 (예시 : 가입완료, 예약완료, 결제완료 등)
• 행동 로그 (예시 : 가입하기 버튼 클릭, 배너 스와이프, 검색 실행 등)

서비스 로그는 기본적인 서비스 운영을 위해 필수적이지만, 행동 로그는 데이터 양도 훨씬 많고,
설계하는 과정에서의 자유도도 높아서 수집이나 활용이 상대적으로 까다롭다. 때문에 분석하고자 하는 방향에
맞게 꼼꼼히 설계해야 한다.

행동 로그 설계하기

• Event Property (예시 : 도시, 화면명, 상품명, 가격 등)
• User Property (예시 : 가입일, 누적예약건수, 쿠폰보유여부 등)

위의 property를 어떻게 구성하였는지에 따라 수집할 수 있는 정보의 수준은 천차만별이다.

출처 : 원문에서 발췌

BigQuery에 적재하기

BigQuery에 쌓인 이벤트 로그는 다음의 스키마를 갖습니다.

• event_date
• event_timestamp
• event_name
• event_params.key
• event_params.value.string_value
• event_params.value.int_value

event에 딸린 key가 있고, 해당 key에 매핑된 value가 있습니다.
아래의 그림을 참고하시면 이해가 빠를 것입니다.

출처 : 원문에서 발췌

위 그림에서 하나의 이벤트 로그에 복수 개의 property가 존재하는 것을 볼 수 있습니다.
BigQuery에서는 이런 유형의 컬럼을 Record type으로 분류합니다. (원문에 의하면 일명 nested 구조)
Record type의 데이터를 조회할 때에는 항상 unnest한 다음에 쿼리를 작성해야 합니다.

BigQuery에서 로그 조회하기

이번 문단부터는 원문에서 참고한 Medium에 게시된 Todd Kerpelman 님의 아티클을 함께 참고하여 작성하였습니다.
unnest를 활용하여 기본적인 쿼리를 작성하는 방법은 다음과 같습니다.
from 문 뒤에 unnest를 이용해 cross join으로 새로운 컬럼을 만들어 정보를 조회합니다.

SELECT * 
FROM `spaceships`,
UNNEST(crew) as crew_member

출처 : 원문에서 발췌

 

위 쿼리를 이용하여 아래의 nested 형태의 BigQuery 데이터를 unnest하여 event_name이 'level_complete_quickplay' 이면서, event_params.key의 'value'를 조회하는 경우, 다음과 같이 작성할 수 있습니다.

 

출처 : 원문에서 발췌

SELECT event_name, param
FROM `firebase-public-project.analytics_153293282.events_20180915`,
UNNEST(event_params) AS param
WHERE event_name = "level_complete_quickplay"
AND param.key = "value"

 

하지만, 위와 같이 매번 nested 되어 쌓이는 DB구조 때문에 복잡한 조건이 포함된 쿼리를 작성하는 것은 어려울 뿐더러,
다음과 같은 문제사항이 생겨 많은 시행착오를 겪게 됩니다.

• unnest가 항상 필요하다.
• unnest 과정에서 불필요하게 많이 생성되는 row 때문에 쿼리 스캔 비용 발생
• event, parameter.key, parameter.value가 매번 헷갈린다.
• value의 타입이 string, integer, float, double 중 어느 것인지 쿼리할 때 마다 지정해줘야 한다.
• parameter.value를 꺼내 쓰기 위해 subquery 등 복잡한 문법이 필요하다. 

이러한 시행착오는 쿼리 작성에 시간이 많이 들기 때문에, 로그를 소극적으로 보게 된다는 문제가 발생합니다.
다음은 이러한 문제점을 해결하기 위해 마이리얼 그로스팀의 안성환님이 로그 테이블 전처리를 한 사례를 소개합니다.

분석이 편한 로그 테이블 만들기 

 

출처 : 원문에서 발췌

 

위와 같은 nested 테이블을 아래의 보기 좋은 테이블 형태로 flatten한 결과입니다.
+ 개인적으로 Pandas의 unstack()이 생각나는 작업이었습니다!
(저작권 문제로 원문의 코드를 가져올 수 없습니다. 전처리 코드가 궁금하신 분은 원문을 참고하세요!)

 

출처 : 원문에서 발췌

 

마침내, 이렇게 테이블을 전처리함으로써 SQL의 기초문법을 갓 배우신 분도 unnest 없이
쿼리를 쉽게 작성하여 데이터에 접근할 수 있게 되었습니다.
이제 보니 <그로스해킹, 양승화 저>의 '데이터 접근성 높이기' 대목에 맞는 작업이었습니다!

--

실제로 스타트업이나 작은 규모의 데이터 조직이 있는 회사에서 데이터 분석 직무를 맡게 된다면,
위와 비슷한 작업을 하게 되는 경우가 생길 수 있습니다.
이번 기회에 한번 정리를 해둔 덕분에 크게 당황하지 않을 것 같습니다.