Performance Monitoring 문제 해결 및 FAQ

성능 이벤트의 로그 메시지를 확인하는 방법

1. 앱의 AndroidManifest.xml 파일에 다음과 같이 <meta-data> 요소를 추가하여 빌드 시 Performance Monitoring에 디버그 로깅을 사용 설정합니다.

   <application>
       <meta-data
         android:name="firebase_performance_logcat_enabled"
         android:value="true" />
   </application>
   

2. 로그 메시지에 오류 메시지가 있는지 확인합니다.

3. Performance Monitoring은 로그 메시지에 FirebasePerformance로 태그를 지정합니다. logcat 필터링을 사용하면 다음 명령어를 실행하여 기간 trace 및 HTTP/S 네트워크 요청 로깅을 구체적으로 확인할 수 있습니다.

   adb logcat -s FirebasePerformance

4. Performance Monitoring에서 성능 이벤트를 로깅 중임을 나타내는 다음 유형의 로그를 확인합니다.

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. URL을 클릭하여 Firebase Console에서 데이터를 확인합니다. 대시보드에서 데이터를 업데이트하는 데 몇 분 정도 걸릴 수 있습니다.

앱에서 성능 이벤트를 로깅하고 있지 않으면 문제 해결 팁을 검토하세요.

앱에 SDK를 추가했지만 Console에 SDK를 추가하라는 메시지가 계속 표시됨

Firebase는 앱에서 이벤트 정보(예: 앱 상호작용)를 수신하면 앱에 Performance Monitoring SDK가 성공적으로 추가된 것으로 간주합니다. 일반적으로 앱을 시작한 후 10분 이내에 Firebase Console의 성능 대시보드에 'SDK 감지됨' 메시지가 표시됩니다. 그런 다음 30분 이내에 대시보드에 초기 처리된 데이터가 표시됩니다.

앱에 최신 버전의 SDK를 추가하고 10분이 경과한 후에도 변경사항이 표시되지 않으면 로그 메시지를 확인하여 Performance Monitoring이 이벤트를 로깅하고 있는지 확인하세요. 아래의 설명대로 적절한 문제 해결 단계를 수행하여 SDK 감지 메시지 지연 문제를 해결하세요.

Console에 SDK 감지 메시지가 나타났지만 데이터가 표시되지 않음

Performance Monitoring은 성능 이벤트 데이터를 성능 대시보드에 표시하기 전에 먼저 처리합니다.

'SDK 감지됨' 메시지가 나타난 후 24시간이 경과했는데도 데이터가 표시되지 않으면 Firebase 상태 대시보드에서 알려진 중단이 있는지 확인하세요. 중단이 없으면 Firebase 지원팀에 문의하세요.

앱이 성능 이벤트를 로깅하지 않음

성능 이벤트의 로그 메시지가 표시되지 않으면 다음 문제 해결 단계를 시도해 보세요.

1. 다음과 같이 Performance Monitoring Gradle 플러그인 설정을 확인합니다.

   1. 플러그인을 올바르게 추가했는지 확인합니다. 특히 다음 사항을 확인하세요.

      • 모듈(앱 수준) build.gradle 파일에 플러그인(apply plugin: 'com.google.firebase.firebase-perf')을 추가했습니다.
      • 프로젝트 수준 build.gradle 파일에 플러그인(classpath 'com.google.firebase:perf-plugin:1.4.2')의 클래스 경로 종속 항목을 포함했습니다.

   2. 다음 플래그 중 하나를 사용하여 플러그인이 사용 중지되지 않았는지 확인합니다.

      • 모듈(앱 수준) build.gradle 파일의 instrumentationEnabled
      • gradle.properties 파일의 firebasePerformanceInstrumentationEnabled

2. AndroidManifest.xml 파일에서 다음 플래그 중 하나를 사용하여 Performance Monitoring SDK가 사용 중지되지 않았는지 확인합니다.

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. 런타임에 Performance Monitoring이 사용 중지되지 않았는지 확인합니다.

4. 앱에서 사용 중지된 항목을 찾을 수 없으면 Firebase 지원팀에 문의하세요.

성능 대시보드에 화면 trace 데이터가 없음

화면 렌더링 trace에 대한 데이터가 누락된 경우 다음 문제 해결 단계를 수행합니다.

1. Android SDK의 최신 버전(v21.0.2)을 사용 중인지 확인합니다. 화면 렌더링 trace는 v15.2.0 이상에서만 사용할 수 있습니다.

2. 화면의 하드웨어 가속 기능을 수동으로 사용 중지하지 않았는지 확인합니다.

3. DexGuard 또는 Jack을 사용하지 않도록 확인해야 합니다. Performance Monitoring은 이러한 도구 모음과 호환되지 않습니다.

   • DexGuard는 앱 시작, 포그라운드 앱, 백그라운드 앱 trace의 자동 수집을 사용 중지합니다. 그러나 앱에서 DexGuard를 사용하는 경우 모든 커스텀 코드 trace는 정상 작동합니다.

   • Jack은 지원 중단되었으므로 일반적으로 앱에서 사용해서는 안 됩니다.

성능 대시보드에 커스텀 trace 데이터가 없음

커스텀 코드 trace가 아닌 자동으로 수집되는 trace의 성능 데이터가 표시되면 다음 문제 해결 단계를 시도해 보세요.

1. Trace API를 통해 커스텀 코드 trace를 계측한 경우 trace 설정을 확인합니다. 특히 다음 사항을 확인하세요.

   • 커스텀 코드 trace와 커스텀 측정항목의 이름에는 선행 공백이나 후행 공백, 선행 밑줄(_)이 없어야 하며, 이름의 최대 길이는 32자(영문 기준)입니다.
   • 모든 trace를 시작하고 중지해야 합니다. 시작 또는 중지되지 않았거나 시작 전에 중지된 trace는 로깅되지 않습니다.

2. @AddTrace 표기법을 통해 커스텀 코드 trace를 계측한 경우 Performance Monitoring Gradle 플러그인 설정을 확인합니다.

   1. 플러그인을 올바르게 추가했는지 확인합니다. 특히 다음 사항을 확인하세요.

      • 모듈(앱 수준) build.gradle 파일에 플러그인(apply plugin: 'com.google.firebase.firebase-perf')을 추가했습니다.
      • 프로젝트 수준 build.gradle 파일에 플러그인(classpath 'com.google.firebase:perf-plugin:1.4.2')의 클래스 경로 종속 항목을 포함했습니다.

   2. 다음 플래그 중 하나를 사용하여 플러그인이 사용 중지되지 않았는지 확인합니다.

      • 모듈(앱 수준) build.gradle 파일의 instrumentationEnabled
      • gradle.properties 파일의 firebasePerformanceInstrumentationEnabled

3. 로그 메시지를 확인하여 Performance Monitoring에서 예상되는 커스텀 코드 trace를 로깅 중인지 확인합니다.

4. Performance Monitoring에서 이벤트를 로깅 중이지만 24시간 경과 후에도 데이터가 표시되지 않으면 Firebase 지원팀에 문의하세요.

성능 대시보드에 네트워크 요청 데이터가 없음

네트워크 요청 데이터가 누락된 경우 다음 문제 해결 단계를 시도해 보세요.

1. Android 앱에서 Performance Monitoring Gradle 플러그인은 자동 HTTP/S 네트워크 요청 모니터링을 제공하는 계측을 사용 설정합니다. 다음을 확인하세요.

   1. 플러그인을 올바르게 추가했는지 확인합니다. 특히 다음 사항을 확인하세요.

      • 모듈(앱 수준) build.gradle 파일에 플러그인(apply plugin: 'com.google.firebase.firebase-perf')을 추가했습니다.
      • 프로젝트 수준 build.gradle 파일에 플러그인(classpath 'com.google.firebase:perf-plugin:1.4.2')의 클래스 경로 종속 항목을 포함했습니다.

   2. 다음 플래그 중 하나를 사용하여 플러그인이 사용 중지되지 않았는지 확인합니다.

      • 모듈(앱 수준) build.gradle 파일의 instrumentationEnabled
      • gradle.properties 파일의 firebasePerformanceInstrumentationEnabled

2. 네트워크 라이브러리의 비호환성을 확인합니다. Performance Monitoring은 OkHttp 3.x.x, 자바의 URLConnection, Apache HttpClient 등의 네트워킹 라이브러리를 사용하는 네트워크 요청의 측정항목을 자동으로 수집합니다.

   네트워크 요청에 커스텀 모니터링을 추가할 수 있습니다.

3. 다음 사항에 유의하세요.

   • 코드 및 코드에 사용된 네트워킹 라이브러리의 동작에 따라 Performance Monitoring에서 완료된 네트워크 요청만 보고할 수도 있습니다. 즉, 열려 있는 HTTP/S 연결은 보고되지 않을 수 있습니다.

   • Performance Monitoring은 DexGuard 및 Jack과 호환되지 않습니다.

     • DexGuard는 HTTP/S 네트워크 요청의 모니터링을 사용 중지합니다.
     • Jack은 지원 중단되었으므로 일반적으로 앱에서 사용해서는 안 됩니다.

   • Performance Monitoring은 Content-Type 헤더가 잘못된 네트워크 요청을 보고하지 않습니다. 그러나 Content-Type 헤더가 없는 네트워크 요청은 계속 허용됩니다.

네트워크 요청 데이터가 예상하는 방식으로 집계되지 않음

URL 패턴에 따라 Performance Monitoring이 네트워크 요청 데이터를 집계하는 방법에 대해 자세히 알아보세요.

커스텀 URL 패턴을 사용해 볼 수도 있습니다.

Project 홈 성능 카드의 주요 문제는 어떻게 되었나요?

최근 알림 기능의 후속 조치로 주요 문제를 최근 알림으로 교체했으며, 설정한 기준을 초과하면 자동으로 알림을 받게 됩니다. 이제 문제가 지원 중단되고 알림으로 대체됩니다.

성능 카드 상단의 앱 선택기는 최근 알림에서 알림 항목을 필터링합니다. 선택한 앱의 가장 최근 알림 3개만 표시됩니다.

알림에 대해 자세히 알아보려면 성능 문제에 관한 알림 설정을 참조하세요.

Console에서 문제에 대한 기준을 설정하는 기능은 어떻게 되었나요?

Performance Monitoring은 정의된 기준을 초과하는 측정항목에 대한 알림을 지원합니다. 성능 측정항목에 구성 가능한 기준과 혼동을 피하기 위해 문제에 대한 기준을 구성하는 기능을 삭제했습니다.

Firebase Console의 세부정보 및 측정항목 정보는 어떻게 되었나요?

문제 해결 과정을 개선하기 위해 세부정보 및 측정항목 페이지를 중앙 집중식 사용자 인터페이스(UI)로 새롭게 디자인했습니다. 새 문제 해결 UI는 기존 세부정보 및 측정항목 페이지와 동일한 핵심 기능을 제공합니다. 문제 해결에 대한 자세한 내용은 특정 trace에 대한 추가 데이터 보기를 참조하세요.

샘플 수가 예상과 다른 이유는 무엇인가요?

Performance Monitoring은 앱의 사용자 기기에서 성능 데이터를 수집합니다. 애플리케이션에 사용자가 많거나 앱에서 대량의 성능 활동을 생성할 경우 Performance Monitoring은 데이터 수집을 기기의 하위 집합으로 제한하여 처리된 이벤트 수를 줄일 수 있습니다. 이러한 한도는 충분히 높아서 이벤트 수가 훨씬 적더라도 측정항목 값이 여전히 사용자의 앱 환경을 나타낼 수 있습니다.

수집하는 데이터 볼륨을 관리하기 위해 Performance Monitoring은 다음 샘플링 옵션을 사용합니다.

• 기기 내 비율 제한: 기기에서 갑작스러운 trace 버스트가 발생하는 것을 방지하기 위해 Google은 기기에서 전송되는 코드 및 네트워크 요청 trace의 수를 10분마다 이벤트 300개로 제한합니다. 이 방식은 대량의 성능 데이터를 전송할 수 있는 루프 계측으로부터 기기를 보호하고, 단일 기기가 성능 측정을 왜곡하지 않도록 합니다.

• 동적 샘플링: Performance Monitoring은 모든 앱 사용자의 앱당 일일 코드 trace의 경우 제한된 수, 네트워크 요청 trace의 경우 제한된 수를 수집합니다. Firebase Remote Config을 사용하여 동적 샘플링 레이트를 기기 내로 가져와 임의 기기에서 trace를 캡처하고 전송해야 하는지 결정합니다. 샘플링용으로 선택되지 않은 기기는 이벤트를 전송하지 않습니다. 동적 샘플링 레이트는 앱별로 적용되며 수집된 데이터의 전체 볼륨이 한도를 초과하지 않도록 조정됩니다.

  BigQuery 통합을 사용 설정한 프로젝트는 네트워크 요청 트레이스 수에 대한 한도가 더 높습니다.

  사용자 세션은 사용자 기기에서 추가 세부 데이터를 전송하므로 데이터를 캡처하고 전송하려면 더 많은 리소스가 필요합니다. 사용자 세션의 영향을 최소화하기 위해 Performance Monitoring은 세션 수를 제한할 수도 있습니다.

• 서버 측 비율 제한: 앱이 샘플링 한도를 초과하지 않도록 하기 위해 Performance Monitoring은 서버 측 샘플링을 사용하여 기기에서 수신된 일부 이벤트를 삭제할 수 있습니다. 이러한 유형의 제한은 측정항목의 효과를 변경하지는 않지만 다음과 같은 사소한 패턴 변화가 발생할 수 있습니다.

  • trace 수는 코드 실행 횟수와 다를 수 있습니다.
  • 코드에서 밀접하게 연결된 trace는 각각 다른 수의 샘플을 포함할 수 있습니다.

Console의 문제 탭은 어떻게 되었나요?

사용자가 설정한 기준을 초과하면 자동으로 알림을 전송하는 알림 기능으로 문제 탭을 대체했습니다. 더 이상 기준 상태를 확인하기 위해 Firebase Console을 직접 살펴볼 필요가 없습니다. 알림에 대해 자세히 알아보려면 성능 문제에 관한 알림 설정을 참조하세요.

Console의 기기별 및 네트워크 탭은 어떻게 되었나요? 해당 페이지에 있는 trace를 보려면 어떻게 해야 하나요?

대시보드 탭에 주요 측정항목과 모든 trace가 한 공간에 표시되도록 Firebase Console의 Performance Monitoring 섹션을 새롭게 디자인했습니다. 디자인 개편에 따라 기기별 및 네트워크 페이지가 삭제되었습니다.

기기별 및 네트워크 탭에 표시되었던 것과 동일한 모든 정보가 대시보드 탭 하단의 trace 테이블에 표시되며, 특정 측정항목의 변화율을 기준으로 trace를 정렬하는 기능을 비롯한 일부 기능이 추가되었습니다. 특정 trace의 모든 측정항목과 데이터를 보려면 trace 테이블에서 trace 이름을 클릭하세요.

trace 테이블의 다음 하위 탭에서 trace를 확인합니다.

• 네트워크 요청 trace(즉시 사용 가능 및 커스텀) — 네트워크 요청 하위 탭
• 커스텀 코드 trace — 커스텀 trace 하위 탭
• 앱 시작, 포그라운드 앱, 백그라운드 앱 trace - 커스텀 trace 하위 탭
• 화면 렌더링 trace — 화면 렌더링 하위 탭
• 페이지 로드 trace — 페이지 로드 하위 탭

trace 테이블과 측정항목 및 데이터 보기에 대한 자세한 내용은 Console 개요 페이지를 참조하세요(iOS+ | Android | 웹).

느린 프레임과 정지된 프레임 수가 예상과 다른 이유는 무엇인가요?

느린 렌더링 프레임과 정지된 프레임은 60Hz의 기기 새로고침 빈도로 가정하여 계산됩니다. 기기 새로고침 빈도가 60Hz보다 낮은 경우 초당 렌더링되는 프레임이 적기 때문에 각 프레임의 렌더링 시간이 느려집니다. 렌더링 시간이 느리면 더 많은 프레임이 더 느리게 렌더링되거나 정지되기 때문에 느린 프레임이나 정지된 프레임이 더 많이 보고될 수 있습니다. 그러나 기기 새로고침 빈도가 60Hz보다 높으면 각 프레임의 렌더링 시간이 더 빨라집니다. 이로 인해 느린 프레임이나 정지된 프레임이 더 적게 보고될 수 있습니다. 이는 Performance Monitoring SDK의 현재 제한사항입니다.

프래그먼트 trace를 볼 수 없는 이유는 무엇인가요?

앱 활동 외에도 프래그먼트의 성능을 확인하려면 앱에서 Performance Monitoring Android SDK 버전 20.1.0 이상을 사용하는지 확인합니다. 자세한 내용은 앱에 Performance Monitoring 추가를 참조하세요.

프래그먼트 및 활동과 관련된 trace가 어떤 것인지 어떻게 이해할 수 있나요?

각 프래그먼트 및 활동 trace는 애플리케이션에 정의된 클래스 이름을 기반으로 합니다. 각 화면 trace에는 클래스 이름 앞에 st 프리픽스를 포함합니다. Firebase Console에서 프리픽스는 삭제됩니다. 자세한 내용은 화면 렌더링 성능 데이터 알아보기(Apple 및 Android 앱)를 참고하세요.

프래그먼트 trace가 다른 trace보다 적은 이유는 무엇인가요?

Performance Monitoring은 기기에서 수집된 모든 이벤트에 대해 이벤트 샘플링을 수행합니다. 이 접근 방식을 사용하면 사용자 기기에서 성능 측정항목을 제공하는 데 필요한 최소한의 이벤트를 수집할 수 있습니다.

애플리케이션의 렌더링 성능에 문제가 있을 때 알림을 받으려면 어떻게 해야 하나요?

Performance Monitoring을 통해 중요하게 생각하는 측정항목에 대한 알림을 설정할 수 있습니다. 생성된 화면 렌더링 trace의 경우 알림을 설정하여 느린 프레임과 정지된 프레임 비율이 설정된 기준점을 초과하면 알림을 받을 수 있습니다.

Performance Monitoring Gradle 플러그인을 사용 설정한 후 빌드 시간이 증가했습니다. 이를 개선하려면 어떻게 해야 하나요?

Android용 Performance Monitoring은 바이트 코드 계측을 사용하여 HTTP/S 네트워크 요청 모니터링과 같이 즉시 사용 가능한 몇 가지 기능을 제공합니다. 컴파일 과정의 일부인 이 프로세스에서는 애플리케이션의 네트워크 요청 성능을 측정하는 데 필수적인 코드를 계측하기 위해 앱의 모든 클래스(종속 항목 포함)를 반복해야 합니다.

다음은 빌드 시간 증가를 유발하는 몇 가지 주요 요인입니다.

• 클래스 또는 파일 수
• 각 클래스의 크기(코드 줄)
• 머신 구성
• 초기 빌드와 후속 빌드(일반적으로 후속 빌드는 보통 초기 빌드보다 빠름)

빌드 시간을 최적화하려면 코드를 모듈화하는 방법을 고려하세요.

Google에서는 Performance Monitoring 플러그인 v1.3.3부터 라이브러리 입력의 증분 빌드 처리 및 캐싱을 상당히 개선하는 데 주력했습니다. 최근 빌드 시간 개선사항을 활용하려면 최신 버전의 플러그인(v1.4.2)을 사용해야 합니다.

긴 빌드 시간을 피하려면 로컬에서 디버그 빌드에 Performance Monitoring 플러그인을 사용 중지하면 됩니다. 그러나 이 방법은 앱에서 네트워크 요청에 대한 성능 측정을 놓치게 될 수 있으므로 프로덕션 빌드에는 권장되지 않습니다.

Performance Monitoring Gradle 플러그인과 호환되지 않는 라이브러리로 인해 빌드 오류가 발생하면 어떻게 해야 하나요?

Android용 Performance Monitoring은 바이트 코드 계측을 사용하여 HTTP/S 네트워크 요청 모니터링과 같이 즉시 사용 가능한 몇 가지 기능을 제공합니다. 컴파일 과정의 일부인 이 프로세스에서는 애플리케이션의 네트워크 요청 성능을 측정하는 데 필수적인 코드를 계측하기 위해 앱의 모든 클래스(종속 항목 포함)를 반복해야 합니다.

Performance Monitoring 플러그인과 통합한 후 JSR/RET are not supported with computeFrames option 또는 이와 유사한 오류가 발생하는 경우, Performance Monitoring Gradle 플러그인과 호환되지 않는 라이브러리에 대한 종속 항목이 있기 때문일 수 있습니다.

이 문제를 해결하기 위해 다음 단계에 따라 호환되지 않는 클래스 또는 라이브러리가 계측되지 않도록 제외할 수 있습니다.

1. Performance Monitoring Gradle 플러그인을 최신 버전(최소 v1.4.0)으로 업데이트합니다.
2. Android Gradle 플러그인을 v7.2.0 이상 버전으로 업데이트합니다.
3. 모듈(앱 수준) build.gradle 파일에 다음 플래그를 추가하여 호환되지 않는 클래스 또는 라이브러리가 계측되지 않도록 제외합니다.

   android {
     // ...
     androidComponents {
       onVariants(selector().all(), {
           instrumentation.excludes.add("example.incompatible.library")
       })
     }
   }
   

   Android Gradle 플러그인 Instrumentation API의 exclude 속성에 관한 자세한 내용은 계측을 참고하세요.

호환되지 않는 라이브러리로 인해 빌드 오류가 발생하면 Performance Monitoring 플러그인에서도 계측에서 제외될 수 있도록 GitHub 문제를 제출해 주세요.

Performance Monitoring 데이터를 BigQuery로 내보내는 데 예상보다 시간이 더 걸리고 있습니다. 실시간이 아닌가요?

Firebase Performance Monitoring용 BigQuery 통합을 사용 설정한 경우 하루가 끝나고(태평양 표준시 기준) 12시간에서 24시간 후에 데이터를 BigQuery로 내보냅니다.

예를 들어 4월 19일 데이터는 4월 20일 오후 12시부터 자정까지 BigQuery에서 사용할 수 있습니다(모든 날짜와 시간은 태평양 표준시 기준).

'실시간에 가까운' 성능 데이터란 무엇인가요?

Firebase Performance Monitoring은 수집된 성능 데이터를 들어오는 대로 처리하므로 Firebase Console에 데이터가 실시간에 가깝게 표시됩니다. 처리된 데이터는 수집 후 몇 분 내에 Console에 표시되므로 '실시간에 가까운'이라는 용어를 사용합니다.

실시간에 가까운 데이터 처리의 이점을 활용하려면 앱에서 실시간 호환 SDK 버전을 사용하는지 확인합니다.

앱의 실시간에 가까운 성능 데이터를 가져오려면 어떻게 해야 하나요?

실시간에 가까운 데이터 처리의 이점을 활용하려면 앱에서 실시간 데이터 처리와 호환되는 Performance Monitoring SDK 버전을 사용하는지 확인하면 됩니다.

실시간 호환되는 SDK 버전은 다음과 같습니다.

• iOS - v7.3.0 이상
• tvOS — v8.9.0 이상
• Android - v19.0.10 이상(또는 Firebase Android BoM v26.1.0 이상)
• 웹 - v7.14.0 이상

항상 최신 버전의 SDK를 사용하는 것이 좋지만 위에 나열된 버전을 사용하면 Performance Monitoring을 통해 실시간에 가까운 수준으로 데이터를 처리할 수 있습니다.

어떤 버전의 Performance Monitoring SDK가 실시간 호환되는 것으로 간주되나요?

다음은 실시간 데이터 처리와 호환되는 SDK 버전입니다.

• iOS - v7.3.0 이상
• tvOS — v8.9.0 이상
• Android - v19.0.10 이상(또는 Firebase Android BoM v26.1.0 이상)
• 웹 - v7.14.0 이상

항상 최신 버전의 SDK를 사용하는 것이 좋지만 위에 나열된 버전을 사용하면 Performance Monitoring을 통해 실시간에 가까운 수준으로 데이터를 처리할 수 있습니다.

실시간 호환 SDK 버전을 사용하도록 앱을 업데이트하지 않으면 어떻게 되나요?

앱에서 실시간 호환 SDK 버전을 사용하지 않는 경우에도 앱의 모든 성능 데이터가 Firebase Console에 계속 표시됩니다. 하지만 수집 시점부터 성능 데이터가 표시되기까지 36시간 정도의 지연이 발생합니다.

실시간 호환 SDK 버전으로 업데이트했지만 일부 사용자가 여전히 이전 버전의 앱을 사용하고 있습니다. Firebase Console에서 성능 데이터를 계속 확인할 수 있나요?

예. 앱 인스턴스에서 사용하는 SDK 버전과 관계없이 모든 사용자의 성능 데이터가 표시됩니다.

하지만 최신 데이터(약 36시간 이내)가 표시된다면 이 데이터는 실시간 호환 SDK 버전을 사용하는 앱 인스턴스 사용자의 데이터입니다. 그리고 최신이 아닌 데이터에는 모든 앱 버전의 성능 데이터가 포함됩니다.