[디스이즈] 앱 로그 데이터 분석 프로젝트 [2]

이전 과정

[디스이즈] 앱 로그 데이터 분석 프로젝트 [1]

• 디스이즈 앱 UI 설명
• 정보구조도 작성
• 로그 설계의 목적 및 지표 설정

---

1. 1차 로그 설계

이전 글의 필요 로그에 이벤트 로그는 기능별 클릭 로그였습니다.따라서 앱의 각 기능 별로 클릭 로그를 설계했습니다.

그리고 필요 로그 중 유저 로그는 앱에 로그인 기능이 있었으므로 user_id 로그를 설계하여 접속한 유저가 누구인지 특정하기로 했습니다. 

1차적으로 저희가 설계한 로그의 예시는 아래와 같았습니다.

{“user_id” :” "5d468b47-6ec6-4eb3-8704-e3a96c8a504b"
, “property” :{“gender” : “male”,
“grade”:22
“department”:”management information department”}
,”events”:[{”screen name” : “홈(학교공지)”
“category”:”학사공지”
“action”: “click” }

• user_id : 특정 앱 내에서 내가 갖는 고유한 아이디
• property : 유저 아이디 내 추가 정보
• events : 앱을 실행할 때 사용한 앱 내 기능
• action : 사용자의 앱 내 행동

---

2. 추가 회의

위 1차 로그 설계를 바탕으로 추가 데이터팀 내부 회의, 개발팀과 회의를 거친 후 로그의 문제점을 발견했습니다.

 

팀 내 회의

• 사용자 접속 시간의 파악 불가능
• 만약 한 사람이 하루에 3번 접속했을 때, 액티브 유저의 파악

개발팀과 회의

• 디스이즈 앱은 학교 자체의 학적부를 가지고 와서 로그인하는 시스템이라 앱 내에서 개인정보를 저장하지 않음.

---

3. 문제 해결

위 문제점을 해결하기 위한 방법을 모색하였습니다. 

 

앱 접속 시각 파악

• date 로그 추가 설계
  • date 로그를 통해 "앱 접속 시각", "앱 접속 지속 시간" 등 추가적인 분석이 가능하므로 설계 추가가 적합함.

액티브 유저의 파악

• session_id 추가 설계

session(세션)이란?
사용자가 앱을 시작해서 종료할 때까지의 일련의 과정을 말함. 사용자가 앱에서 이탈하게 되면 1개의 세션으로 카운트가 됨. session_id란 한 번의 접속~종료에서 생성되는 임시 아이디.

session_id 가 없는 기존의 로그 설계는 A1이라는 유저가 비슷한 시간에 3번 접속했을 시, 접속 별 앱 경험 흐름을 제대로 구분하기 어렵습니다.  또한 실질 액티브 유저는 1이지만 하루 앱 접속 수가 3으로 카운트되는 문제점도 해결하였습니다.

 

USER db의 부재

• 디스이즈 앱의 로그인은 서비스 자체 로그인이 아닌 학교 홈페이지의 로그인 후 학적부를 가져오는 형식임.
• 학교 공식 어플이 아니므로 학생의 개인 정보를 저장하기에 어려움이 있음.
• 만약 저장한다 하더라도 보안 관련 문제가 발생할 시 대처가 불가능함. 

위와 같은 이유로 디스이즈는 유저 db를 가지고 있지 않았습니다.

유저 db의 부재는 user_id 로그 설계 불가를 의미합니다. user_id가 없으므로 그에 따른 property 값(성별, 학년, 학과)을 사용한 다양한 분석이 불가능했습니다. 그리고 active user 파악의 불가능을 뜻하기도 합니다. 이는 로그 분석에 치명적이었기에 문제점을 해결하기 위한 방법을 모색하였습니다.

• 앱 사용 시간 기반 액티브 유저(활성 사용자) 파악
  • ex) 앱 접속 시간이 3분 이상 일 경우 활성 사용자로 카운트
  • 추가 로그 설계 없이 로그 수집이 용이하나, 정확한 분석에 어려움이 있음.
• user_id를 device_id로 대체한 후  액티브 유저 파악
  • 기기별 반영구 아이디인 device_id를 사용자 동의 후 수집
  • property 로그로 기기의 OS 값 등을 추가할 수 있음.
  • 비교적 정확한 활성 사용자 수를 파악할 수 있음.

위 두 가지 우회 방법 중 개발팀의 동의를 얻어 device_id를 수집하는 방향으로 로그 설계를 결정하였습니다.

---

4. 최종 로그 설계

위 세 가지 과정을 통해 결정된 로그 예시는 다음과 같습니다.

• Active User 파악 → user_id(device_id) 로그를 통한 카운트
• 사용 앱 기능 파악 → 이벤트 로그의 클릭 로그 분석(앱 내 회원가입, 결제 등 클릭 이외의 트랜잭션이 없기 때문에 클릭만으로 충분하다고 판단함.)
• 추가 분석 → property, session, date와 event의 조합을 통한 분석

---

정리

이번 글에서는 실제 로그 설계 과정을 설명드렸습니다.

로그 설계가 처음 예상대로 되지 않았지만 계속해서 공부, 회의 한 뒤 해결책을 도출해 낼 수 있었습니다.

사실 위 문제 이외에도 개발팀과 첫 협업이기에 서로의 이해와 중요도가 다른 문제가 있었습니다. 

• 개발팀 → 로그 설계해서 카운팅 뷰 형식으로 보여주면 되는 거지?

• 데이터팀 → 아니..?? 로우 데이터가 필요해! 분석용 db로 넘겨줘!

• 데이터팀  → 분석을 다양하게 하기 위해 로그 추가추가!
• 개발팀 → 앱을 가볍게 하기 위해 로그 빼빼!

개발팀과 데이터팀이 서로의 지식을 더 많이 공유하는 회의를 만들어야겠다는 생각을 했습니다.

그리고 디스이즈 프로젝트(데이터 분석가의 로그 설계)와 유사한 공개 프로젝트가 없어, 자체 피드백이 불가능하다는 점도 문제점 중 하나입니다. 

데이터 분석 실무자께서 이 프로젝트를 보셨다면, 간단하게라도 댓글로 피드백 남겨주시면 정말 감사하겠습니다.  

---

제 블로그에는 프로젝트의 진행 상황과 진행할 때 배운 점을 정제하여 기재할 예정입니다.

상세한 진행 상황은 디스이즈 프로젝트 노션 페이지에서 확인하실 수 있습니다.

디스이즈 프로젝트

---

다음편 바로가기

2022.10.08 - [Specialist/Project] - [디스이즈] 앱 로그 데이터 분석 프로젝트 [3]

[디스이즈] 앱 로그 데이터 분석 프로젝트 [3]