# 데이터 이해하기
### **하위 5%는 왜 중요하게 봐야 하나요?**
하위 5%는 성능이 좋지 못한 하위 5% 데이터의 평균값입니다. 성능이 좋지 못하다는 건 화면 로딩시간이나 응답시간이 느린 순, CPU와 메모리 사용량이 많은 순을 의미합니다.
예를들어, 화면 로딩시간 데이터가 1000건이 있다면 로딩시간이 느린 순으로 정렬했을 때 하위 5% 즉, 50건의 데이터의 평균값이 하위 5%가 되는 것입니다.
위 그래프에서 화면 로딩시간과 응답시간의 11:23\~11:24구간을 확인해 보겠습니다. 화면 로딩시간의 경우 하위 5%와 평균의 차이가 적음을 알 수 있습니다죠. 이렇게 하위 5%와 전체 평균의 차이가 적으면 대부분의 사용자들이 경험하는 속도는 비슷하다고 판단할 수 있습니다. 반면 응답시간의 경우 하위 5%와 평균의 차이가 크다는 것을 확인할 수 있습니다. 이렇게 하위 5%와 전체 평균의 차이가 크면 일부 사용자들이 평균보다 긴 응답시간을 경험했다고 판단할 수 있습니다.
### **성능 문제 발생률이 무엇인가요?**
현재 위치한 앱 버전과 다음 우선순위 앱 버전의 최근 30분 동안의 크래시, 메모리, CPU, 응답시간, 화면 로딩시간의 5가지 성능 지표의 문제 발생률을 그래프로 표시합니다.
* [성능 대시보드 > 성능 문제 발생률](https://docs.imqa.io/imqa-guide/user-guide/mpm/dashboard#issue-rate)
* [A/B 대시보드 > 성능 문제 발생률 (유료 플랜 only)](https://docs.imqa.io/imqa-guide/user-guide/mpm/abdashboard#issue-rate)
### 성능 문제 발생률 / 평균 문제 발생률, 다른 건가요?
성능 문제 발생률이란 전체 데이터에서 기준치 이상 데이터의 비율을 의미하며, 평균 문제 발생률은 성능 문제 발생률의 평균을 의미합니다.
* 성능 문제 발생률: 각 성능 지표별 (기준치 이상 데이터 / 전체 데이터)\*100
* 평균 문제 발생률: (기준치 이상 데이터 / 전체 데이터)\*100의 평균\
(성능 문제 발생률의 평균)
예를 들어,
* 크래시: 전체 앱 실행 수가 100건이고 크래시 발생 수가 30건일 경우 크래시의 문제 발생률은 30%로 표시하게 됩니다.
* 화면 로딩시간: 전체 데이터 수가 1000건이고 기준치 300ms 넘는 데이터 수가 100건일 경우 화면 로딩시간의 문제 발생률은 10%로 표시하게 됩니다.
### 최근 5분 성능 지표는 어떻게 해석해야 할까요?
'최근 5분 성능 지표'는 A/B 대시보드에서 확인할 수 있으며 A, B프로젝트의 최근 5분 동안의 화면 로딩시간, 응답시간, 자원 사용량(CPU/메모리)의 성능 변동을 실시간으로 확인할 수 있습니다. (1분마다 갱신)
이를 통해 5분 동안의 **성능 분포 상태를 한눈에 파악**할 수 있고, A,B데이터의 성능을 **비교**하기에 유용합니다.
그래프의 위치에 따라 아래와 같이 해석할 수 있습니다.
**1. 50% 기준치에 분포한 경우(가장 이상적인 현상)**
**2. 95% 기준치에 분포한 경우 (관리가 필요한 현상)**
**3. 데이터가 넓게 분산되어 있는 경우(앱 성능이 고르지 못한 현상)**
각 예시 데이터에 대한 자세한 설명은 블로그에서 상세히 확인하실 수 있습니다.
* [쉽게 읽는 데이터Ⅱ - 최근 5분 성능 지표(히스토그램)](https://blog.imqa.io/performance-indicators-for-the-last-5minutes/?utm_source=docs\&utm_medium=click\&utm_campaign=faq5min)
* [A/B 대시보드 > 최근 5분 성능 지표 ](https://docs.imqa.io/imqa-guide/user-guide/mpm/abdashboard#last-5minutes)
### 최근 5분 메모리에서 둘 중 하나는 항상 100%인데, 성능이 안 좋은 건가요?
메모리는 수치가 높은 프로젝트 막대를 100%로 표시하고, 나머지는 상대 비율로 표시합니다. 따라서 메모리의 막대그래프 중 하나는 항상 100%로 표시됩니다. 메모리의 경우 최대 사용량을 정할 수 없기 때문에 수치가 높은 프로젝트의 막대를 100%로, 나머지를 상대 비율로 표기합니다.
막대그래프의 수치가 100%로 표시되어 있어도 성능이 좋지 않은 것은 아니니 그래프 아래의 CPU 사용량을 확인해 주세요.
* [A/B 대시보드 > 최근 5분 성능 지표 > 최근 5분 CPU/메모리 ](https://docs.imqa.io/imqa-guide/user-guide/mpm/abdashboard#cpu-memory)
### 히트맵 > CPU/메모리에서 OS, APP은 왜 구분하나요?
* OS: 운영체제 전체적인 자원 사용량
* APP: 해당 앱이 할당하고 있는 자원 사용량
OS 사용량과 APP 사용량을 구분하여 우리 앱이 디바이스 자원을 얼마나 사용하는지 알 수 있습니다.
### 버블 차트 데이터는 어떻게 해석해야 하나요?
가로축은 문제 발생률 / 세로축은 성능 수치(화면 로딩시간, 응답시간, CPU, 메모리)로 표현하였고, 이는 '0'에 가까울수록 좋은 성능이라는 것을 의미합니다. 버블은 사용자가 방문한 화면으로 크기는 방문자 수를 나타냅니다.
**문제 발생률, 성능 수치, 버블, 버블의 크기**를 통해 A, B프로젝트의 상호 관계를 파악할 수 있고, 버블을 통해 **평균적인 성능**과 **눈에 띄는 성능 저하 화면**을 직관적으로 확인할 수 있답니다. 화면 버블을 클릭하면 '화면 성능 분석'을 통해 성능 저하 원인을 상세하게 분석할 수 있습니다.
버블 차트는 기본적으로 버블의 위치에 따라(4사분면) 아래와 같이 해석할 수 있습니다.
예시 데이터를 통한 버블 차트에 대한 설명은 블로그에서 상세히 확인하실 수 있습니다.
* [쉽게 읽는 데이터Ⅰ - 화면별 성능 현황(버블 차트)](https://blog.imqa.io/screen-performance-analysis_bubble-chart/?utm_source=docs\&utm_medium=click\&utm_campaign=faq-databubble)
### 구간 분석에서 데이터 확인하는 방법이 궁금해요. / 구간 분석에서는 어떤 정보를 볼 수 있나요?
구간 분석은 전체 데이터 분포를 파악하거나 시간 별로 비교할 수 있으며, 특정 성능 저하 구간을 상세하게 확인할 수 있어 성능 저하 관리에 유용합니다. 날짜, 시간(30분 단위)별 성능 정보와 자원 사용량을 확인할 수 있으며, 성능 분포 그래프는 50%, 95% 기준선으로 3개의 구간으로 구분이 됩니다.
❶ 3개의 구간 중 상세 확인이 필요한 구간을 선택하여 확인 가능합니다.\
❷ 사용자 정보에서는 화면, OS 버전, 디바이스, 위치/통신사, 프로세스, GPS 등 선택한 구간의 사용자가 어떤 환경에 있었는지 확인할 수 있습니다.\
❸ 해당 구간의 성능 히트맵과 리소스 히트맵을 확인할 수 있습니다.
* **성능 히트맵(성능 현황)**: 화면 로딩시간, 응답시간, 프래그먼트 렌더링, 이벤트, 크래시의 히트맵 확인 가능
* **리소스 히트맵(자원 사용량)**: CPU/메모리 사용량, 네트워크I/O 히트맵 확인 가능
### 구간 분석에서 3개로 나눠진 구간은 무슨 차이가 있는 건가요?
기본적으로 50% 기준선에 데이터가 분포되어 있다면 평균적으로 앱 성능이 고른 상태, 95% 기준선에 데이터가 분포되어 있다면 평균에서 벗어난 관리가 필요한 상태라고 이해할 수 있습니다.
**1. 구간 1 (성능 최적화 구간)**
구간 1은 전체 데이터 분포의 0 \~ 50% 미만에 해당되는 구간입니다. 데이터는 ‘0’에 가까울수록 좋은 성능이며, ‘0’에 가까운 데이터가 많을수록 50% 기준선도 ‘0’에 가까이 위치합니다. **이 구간은 평균 기준선 미만의 데이터로 성능 최적화 구간이라고 할 수 있습니다.**
**2. 구간 2 (성능 주의 구간)**
구간 2는 전체 데이터 분포의 50% 이상 \~ 95% 미만에 해당되는 구간입니다. 평균 기준선에 분포한 데이터와 95% 기준선에 분포한 데이터가 공존하는 구간으로 성능을 주의해야 할 구간입니다. **평균 기준선에 분포한 사용자는 좋은 성능을, 95% 기준선에 분포한 사용자는 좋지 못한 성능을 경험했다고 판단할 수 있습니다.**
**3. 구간 3 (성능 위험 구간)**
구간 3은 전체 데이터 분포의 95% 이상에 해당되는 구간으로, 성능이 가장 좋지 못한 하위 5%를 의미합니다. **성능 저하 문제를 관리하기 위해선 성능이 좋지 못한 데이터, 즉 성능 저하 구간인 구간 3을 집중 관리해야 합니다.**
위의 각 예시 데이터에 대한 상세 데이터 분석에 대한 내용은 블로그에서 확인하실 수 있습니다.
* [쉽게 읽는 데이터 Ⅲ - 통계(구간 분석)](https://blog.imqa.io/statistics-distribution-analysis/?utm_source=docs\&utm_medium=click\&utm_campaign=faqstatistics)
* [통계 > 구간 분석](https://docs.imqa.io/imqa-guide/user-guide/mpm/statistics#distribution-analysis)
### 성능 / 병목 현상 리포트는 어떻게 해석해야 할까요?
**성능 리포트**는 각 성능 지표를 9구간으로 분할하여 표기하며, 컬러로 성능 안정/위험 구간을 구분합니다.
* 회색 구간: 성능 안정 구간
* 회색 이외의 구간: 성능 위험 구간
분할된 구간 내 비율을 보고 사용자 분포도를 확인할 수 있는데요. 기준치 구간(성능 안정 구간)에 대부분의 사용자가 분포되어 있다면 앱 사용이 원활하다고 판단할 수 있으며, 넓게 분포되어 있다면 앱이 다양한 사용자 환경에 최적화되어 있지 않음을 의미합니다.
성능 리포트는 성능 지표별 사용자 분포를 통해 몇 %의 사용자가 어느 정도의 성능 문제를 겪는지 알 수 있는데요. 이를 통해 하루 동안의 전체 성능 현황을 파악하는데 유용합니다.
{% hint style="info" %}
위의 성능 리포트에서 네이티브 화면 로딩 시간을 해석해 본다면
* 전체 데이터 34, 523건\
\- 화면 로딩시간 100ms 이하(성능 안정 구간): 99.684%\
\- 화면 로딩시간 101ms 이상(성능 위험 구간): 0.316%
대부분의 사용자가(99% 이상) 짧은 로딩시간을 경험, 즉 불편함 없이 앱을 사용했다고 판단할 수 있으며 그 외 일부 사용자는(0.316%) 40초의 긴 로딩시간을 경험, 즉 성능 저하로 인해 불편함을 겪었음을 알 수 있습니다.
{% endhint %}
**병목 현상 리포트**는 성능 지표별 하위 5%와 응답 시간 / 웹뷰 화면 로딩시간 하위 20으로 나누어져 있습니다.
* 성능 지표별 하위 5%: 네이티브 화면 로딩시간, CPU 사용량, 메모리 사용량 하위 5%의 화면과 사용자 환경(OS 버전, 디바이스, 위치/통신사) 확인
* 응답 시간 / 웹뷰 화면 로딩시간 하위 20: 일일 사용자 데이터 중 가장 응답시간이 길었던 하위 20 / 가장 화면 로딩시간이 길었던 웹페이지 20개 확인
성능 지표별 하위 5%를 통해 성능이 저하된 주된 화면, 성능 저하를 경험한 사용자의 환경과 비율을 확인할 수 있고, 응답 시간 / 웹뷰 화면 로딩시간 하위20을 통해 성능 저하가 있었던 항목, 성능 저하를 경험한 사용자 환경을 확인할 수 있습니다.
병목 현상 리포트는 성능 저하 원인을 자세히 파악할 수 있어 오류 보고서로도 사용할 수 있고, 성능 개선 지표로 활용할 수 있습니다.
* [보고서 - 성능 리포트](https://docs.imqa.io/imqa-guide/user-guide/mpm/report#performance)
* [보고서 - 병목 현상 리포트](https://docs.imqa.io/imqa-guide/user-guide/mpm/report#bottleneck)