IMQA CRASH 데이터 읽기

IMQA 공식 -

안녕하세요, IMQA입니다.

지난 IMQA MPM 데이터 읽기(LITE 플랜)에서는 그래프 위치에 따라 어떻게 해석하는지 자세히 알아보았습니다. 이어지는 이번 글에서는 IMQA CRASH 데이터를 해석하는 방법과 전시회나 영업을 나가면 가장 많이 질문해 주시는 타 크래시 솔루션과 차이점을 알아보겠습니다.

  1. IMQA MPM 데이터 읽기 (LITE 플랜)
  2. IMQA MPM 데이터 읽기 (유료 플랜)
  3. IMQA CRASH 데이터 읽기 (대시보드, 에러 상세)

대시보드

1.크래시 & ANR

주간 요약 정보

  • 최근 1주일 간 발생한 크래시, ANR 발생 수 및 이용자 수, 실행 수 확인
    - 마우스 오버 시 실제 데이터 확인 가능
  • 크래시와 ANR 발생 비율 확인
    - 평균적으로 주간 실행 수 대비 크래시 발생 수가 10%가 넘을 경우, 이상 현상으로 빠른 점검/개선 필요
    - 위의 경우 주간 실행 수: 78,521회 주간 크래시:583건 발생비율 약 0.74% 로 비교적 안정적인 앱이라고 판단
  • 크래시와 ANR의 구분은 안드로이드 프로젝트에서만 표기

일별 에러

  • 특정 일자에 에러 발생 수가 많다면?
    - 해당 앱 버전에 업데이트 등 변동 사항이 있었는지 확인
    - 이용자 수, 실행 수에 따라 데이터 수도 차이가 나기 때문에 이용자 수와 실행 수를 확인하고 발생 비율을 파악
타 솔루션 대비 크래시, ANR이 더 많이 나오는 이유는 무엇인가요?

데이터를 일부 수집하는 타 솔루션과 달리 IMQA는 데이터 샘플링 방식이 아닌 모든 데이터를 수집, 보관합니다. 따라서 모든 크래시, ANR 발생 현황을 확인할 수 있기 때문에 타 크래시 솔루션보다 더 많은 수치 확인이 가능합니다.

*IMQA: 모든 데이터를 수집, 보관
(보관 기간은 플랜, 계약 등에 따라 상이하며, IMQA LITE는 15일 기준)
*Firebase: 데이터 샘플링을 통해 일부 데이터만 수집
*Google Play Console: 수집 데이터 보관 과정 중 클라우드에 보관되어 있는 필요 없는 데이터를 삭제하기도 함

2. 에러 테이블

  • 가장 먼저 확인해야 할 것은?
    - 누적순으로 정렬하여 누적이 가장 많은 에러부터 확인
    - 5명의 사용자가 동일한 에러를 경험했더라도 에러 자체는 1개로 보고, 에러 테이블에 1개 에러/ 누적 5로 표기
    - 누적순이 많다는 것은 그만큼 많은 사용자가 해당 에러를 경험했다는 것을 의미하므로 빠른 해결이 필요!
  • 에러는 에러 명, 클래스 명, 코드 라인 번호로 표시하며 에러 클릭 시 해당 에러에 대한 상세 정보 확인이 가능

에러 상세

1.앱 버전별 에러 발생률

  • 선택한 에러의 상세 정보 확인
    - 해당 에러의 발생 추이 및 앱 버전별 발생 비율 확인
  • 해당 에러 처리 후 최신 버전에 재발생했는지 파악하기 용이
  • 특정 날짜에 에러 수가 급격하게 증가했다면?
    - 어떤 버전에서 발생했는지 확인
    - 특정 버전 에서 지속적으로 발생할 경우, 해당 버전 사용자에게 업데이트 권고할 수 있음
  • 현재 운영 중인 앱 버전에 따라 해당 에러 관리 여부를 판단
    - 현재 운영 중인 앱 버전이 2.0.71인 경우: 에러 발생률이 높기 때문에 빠른 개선 필요
    - 현재 운영 중인 앱 버전이 2.0.72인 경우: 해당 에러가 개선되었다고 판단
    - 2.0.72 버전이 테스트 중이거나 실 사용자의 데이터가 적어서 상대적으로 에러 발생이 적을 수 있으므로 이러한 환경도 함께 고려해야 함

2. 사용자 정보(환경별 에러 발생 파악)

  • 해당 에러가 어떤 사용자 환경에서 발생했는지 파악 가능
  • 분류가 많을수록 다양한 환경의 사용자가 해당 에러를 경험
    - 분류가 1종인 경우: 통신사/앱 버전/OS/디바이스/국가에서 1종만 뜬다면 특정 환경에서만 발생하는 문제라고 파악
    - 분류가 많은 경우: 각 기준별 데이터가 다양하다면 다양한 환경에서 해당 에러를 경험했다고 판단
  • Unknown Device는 디바이스 정보가 수집되지 않았음을 의미하며 맥과 같은 기기에서 시뮬레이터로 테스트한 경우 등이 해당

3. 인스턴스

  • 크래시가 발생한 사용자 정보 확인
    - 개별 사용자의 LogCat(로그켓, 로그 상세 정보)과 화면 이동 경로, 사용자 환경에 대한 상세 정보 확인
  • 해당 에러를 경험한 사용자가 많을 경우에는 전체 확인이 어려우므로, 앱 버전/디바이스 등을 기준으로 일부만 랜덤하게 확인
  • 로그켓 확인
    - 안드로이드 상세 로그 정보로, 스택 정보로 파악하지 못한 문제를 크래시 발생 시점 이전에 기록된 로그 정보 확인

4. 에러 관리

상태값 표기

  • 선택한 에러 처리 상태 변경
  • 상태 값은 설정 기준 (아래 기준은 참고용으로 내부 관리 기준에 따라 설정)
    - 신규: 새롭게 발생된 에러
    - 처리: 담당자 원인 파악 후 처리 중
    - 완료: 담당자 처리 완료
    - 마감: 관리자 확인 후 처리 완료 (더 이상 노출되지 않음)
  • 상태 변경한 에러는 동일 버전 및 하위 버전에서 동일한 에러가 발생한 경우 상태 변경이 되지 않음
    - 상위 버전에서 동일 에러 발생 시, 해당 에러와 구분이 필요하여 신규 에러로 생성

태그

  • 에러별 구분을 위해 해당 에러에 대한 태그 작성 가능
  • 등록한 태그는 ‘에러 검색’ 페이지에서 검색어로 활용
  • 앱의 타겟 사용자 환경으로 태그를 관리하거나 발생 상황, 높은 자원 사용량 기록 등으로 활용

지금까지 IMQA CRASH의 데이터 읽는 방법에 대해 알아보았습니다. IMQA CRASH는 대시보드 외 에러 상세, 통계 등 전면 개편을 진행하고 있답니다. 추후 업데이트 시 IMQA CRASH 튜토리얼로 다시 찾아뵙겠습니다. 많은 관심 부탁드립니다 😉