Узнайте о данных о производительности сетевых запросов HTTP/S (любое приложение)

• Используйте фильтр по версии приложения , чтобы просмотреть данные о предыдущих или последних версиях.
• Отфильтруйте результаты по устройству , чтобы узнать, как ваше приложение работает на старых устройствах.
• Используйте фильтр по стране , чтобы убедиться, что местоположение вашей базы данных не влияет на конкретный регион.

Узнайте больше о просмотре данных ваших трассировок .

Следующие шаги

• Узнайте больше об использовании атрибутов для анализа данных о производительности.

• Узнайте больше о том, как отслеживать проблемы с производительностью в консоли Firebase .

• Настройте оповещения о сетевых запросах, которые ухудшают производительность вашего приложения. Например, вы можете настроить оповещение по электронной почте для вашей команды, если время ответа для определенного шаблона URL-адреса превысит установленный вами порог.

• Просматривайте подробные отчеты о пользовательских сессиях , в которых можно увидеть конкретную трассировку в контексте временной шкалы других трассировок, собранных в течение той же сессии.

Performance Monitoring использует трассировку для сбора данных о контролируемых процессах в вашем приложении. Трассировка — это отчет, содержащий данные, полученные в вашем приложении в промежутке времени между двумя точками.

Для всех типов приложений Performance Monitoring автоматически собирает трассировку для каждого сетевого запроса, отправляемого вашим приложением, называемую трассировкой сетевого запроса HTTP/S . Эти трассировки собирают метрики за время между отправкой вашим приложением запроса к конечной точке сервиса и получением ответа от этой конечной точки. Для любой конечной точки, к которой ваше приложение отправляет запрос, Performance Monitoring собирает несколько метрик:

• Время ответа — время между отправкой запроса и получением полного ответа.

• Размер полезной нагрузки ответа — размер в байтах сетевой полезной нагрузки, загружаемой приложением.

• Размер полезной нагрузки запроса — размер в байтах сетевой полезной нагрузки, загружаемой приложением.

• Показатель успешности — процент успешных ответов (коды ответов в диапазоне 100–399) по сравнению с общим числом ответов.

Данные из этих трассировок можно просмотреть на вкладке «Сетевые запросы» таблицы трассировок, которая находится в нижней части панели мониторинга производительности (подробнее об использовании консоли см. далее на этой странице).

Performance Monitoring автоматически собирает метрики для сетевых запросов, использующих следующие сетевые библиотеки:

Настройка агрегации данных сетевых запросов

Помимо стандартных инструментов и агрегации данных для сетевых запросов, Performance Monitoring также поддерживает следующие опции:

• Ручная настройка трассировки сетевых запросов: встроенная функция мониторинга включает большинство сетевых запросов для вашего приложения. Однако некоторые запросы могут не отображаться, или вы можете использовать другую библиотеку для выполнения сетевых запросов. В таких случаях вы можете использовать API Performance Monitoring для ручной настройки пользовательской трассировки сетевых запросов .
• Агрегирование данных по пользовательским шаблонам URL: если Firebase не распознает определенные URL-адреса с помощью автоматического сопоставления шаблонов URL, вы можете создать пользовательские шаблоны URL для мониторинга определенного набора URL-адресов в течение определенного времени.
• Настройте способ расчета коэффициента успешности: иногда для определенных конечных точек API ожидается код ошибки, или же эта ошибка уже обрабатывается в вашем приложении. В таких случаях вы можете настроить способ расчета коэффициента успешности и более точно отслеживать успешность сетевых вызовов вашего приложения.

Агрегация данных по шаблонам URL

Firebase Performance Monitoring автоматически собирает данные по аналогичным сетевым запросам, помогая вам понять тенденции в производительности ваших сетевых запросов.

Для каждого запроса Firebase проверяет, соответствует ли URL-адрес сетевого запроса шаблону URL. Если URL-адрес запроса соответствует шаблону URL, Firebase автоматически объединяет данные запроса в соответствии с этим шаблоном. Firebase отображает шаблоны URL и их объединенные данные на вкладке «Сеть» в панели мониторинга «Производительность » консоли Firebase .

Что такое шаблон URL?

Шаблон URL-адреса содержит домен и шаблон, который может соответствовать пути URL-адреса, например: example.com/*/animals/** .

• Шаблоны URL-адресов могут содержать следующие сегменты пути:

  • Обычный текст — соответствует точной строке
  • * — соответствует любой строке в одном сегменте пути
  • ** — соответствует произвольному суффиксу пути

• Шаблоны URL-адресов могут быть следующими:

  • Шаблоны, полученные из Firebase, — так называемые автоматические шаблоны URL.
  • Шаблоны, определяемые пользователем, — так называемые пользовательские шаблоны URL-адресов.

Например: Любой из следующих URL-запросов может соответствовать шаблону URL-адреса example.com/*/animals/** .

• example.com/singapore/animals
• example.com/australia/animals/spiders
• example.com/australia/animals/marsupials/koala.png

Домен в шаблоне URL также может содержать * в качестве первого сегмента, например: *.example.com/*/fruits/** .

Firebase сопоставляет каждый запрос только с одним шаблоном URL . Если вы настроили какие-либо пользовательские шаблоны URL , Firebase сначала пытается сопоставить URL-адреса запросов с этими шаблонами. Если Firebase не находит подходящего пользовательского шаблона URL, то он сопоставляет URL-адрес запроса с наиболее репрезентативным автоматическим шаблоном URL . Подробнее об автоматических и пользовательских шаблонах URL см. в следующих разделах.

Автоматические шаблоны URL

Без какой-либо настройки с вашей стороны, Performance Monitoring пытается отразить последнее поведение вашего приложения при использовании, сопоставляя запросы вашего приложения с автоматическими шаблонами URL-адресов .

Как работает автоматическое сопоставление шаблонов URL-адресов?

Firebase сопоставляет каждый запрос с наиболее репрезентативным автоматическим шаблоном URL, полученным из запросов, отправленных вашим приложением. Однако обратите внимание, что Firebase сначала пытается сопоставить URL-адреса запросов с любыми настроенными пользовательскими шаблонами URL .

Ниже приведён базовый пример того, как Firebase пытается сопоставить запросы с наиболее типичным шаблоном URL-адреса для вашего приложения.

1. Ваше приложение отправляет множество запросов на URL-адреса, например:

   • example.com/germany/animals/bears
   • example.com/germany/animals/birds
   • example.com/germany/cars

   Firebase определяет, что example.com/germany/** является распространенным шаблоном запроса для вашего приложения, и добавляет его в качестве автоматического шаблона URL в ваш проект.

   Для всех новых запросов, соответствующих этому шаблону URL, Firebase агрегирует данные запросов в рамках автоматического шаблона URL example.com/germany/** .

2. Через неделю большинство запросов вашего приложения будет направлено на example.com/germany/animals/bears и example.com/germany/animals/birds . Таким образом, Firebase формирует более репрезентативный шаблон URL-адреса: example.com/germany/animals/** .

   Для всех новых запросов, соответствующих этому новому шаблону URL, Firebase агрегирует данные запросов только в рамках нового шаблона URL. Firebase продолжает агрегировать данные для запросов к example.com/germany/cars в рамках example.com/germany/** .

3. Однако в течение следующих нескольких недель количество запросов вашего приложения к example.com/germany/animals/bears и example.com/germany/animals/birds существенно уменьшается. Firebase определяет, что example.com/germany/animals/** не отражает последнее поведение вашего приложения, поэтому Firebase начинает сопоставлять эти два запроса с example.com/germany/** .

   Firebase больше не собирает данные о запросах по адресу example.com/germany/animals/** поскольку это больше не является наиболее репрезентативным шаблоном автоматического URL-адреса.

Поскольку автоматическое сопоставление шаблонов URL-адресов является динамическим процессом, обратите внимание на следующее:

• Новые шаблоны URL-адресов не влияют на совпадения и агрегированные данные из предыдущих запросов. Firebase не выполняет ретроспективную повторную агрегацию данных запросов.

• Новые шаблоны URL-адресов влияют только на будущие запросы. Firebase сопоставляет каждый новый запрос с наиболее подходящим автоматическим шаблоном URL-адреса. Однако следует отметить, что Firebase сначала пытается сопоставить URL-адреса запросов с любыми настроенными пользовательскими шаблонами URL-адресов .

Просмотрите автоматические шаблоны URL-адресов и их данные.

Firebase отображает все шаблоны URL-адресов и их агрегированные данные во вкладке «Сетевые запросы» таблицы трассировки, которая находится в нижней части панели мониторинга производительности консоли Firebase .

Вы можете увидеть шаблоны URL-адресов с пометкой «Без категории» . Это «общие» автоматические шаблоны URL-адресов, в рамках которых Firebase может агрегировать данные для запросов, которые не соответствуют ни одному более конкретному шаблону URL-адреса.

Когда истекает срок хранения данных , агрегированных по шаблону URL, Firebase удаляет эти данные из шаблона URL. Если срок действия всех данных, агрегированных по автоматическому шаблону URL, истекает, Firebase удаляет этот шаблон URL из консоли Firebase .

Пользовательские шаблоны URL

Вы можете создавать пользовательские шаблоны URL-адресов для отслеживания определенных шаблонов URL-адресов, которые Firebase не распознает с помощью автоматического сопоставления производных шаблонов URL-адресов . Например, вы можете использовать пользовательский шаблон URL-адреса для устранения неполадок с конкретным URL-адресом или для мониторинга определенного набора URL-адресов в течение определенного времени.

Для получения дополнительной информации посетите раздел «Создание пользовательских шаблонов URL-адресов» .

Отслеживайте, просматривайте и фильтруйте данные о производительности.

Для просмотра данных о производительности в реальном времени убедитесь, что ваше приложение использует версию SDK для мониторинга производительности, совместимую с обработкой данных в реальном времени. Узнайте больше о данных о производительности в реальном времени .

Отслеживайте конкретные показатели на своей панели управления.

Чтобы узнать, как меняются ваши ключевые показатели, добавьте их на доску метрик в верхней части панели мониторинга производительности . Вы можете быстро выявить регрессии, увидев изменения за неделю, или убедиться, что недавние изменения в вашем коде улучшают производительность.

Чтобы добавить метрику на доску метрик, выполните следующие действия:

1. Перейдите на панель мониторинга «Производительность» в консоли Firebase .
2. Щелкните по пустой карточке показателя, затем выберите существующий показатель, чтобы добавить его на доску.
3. Нажмите кнопку more_vert на заполненной карточке показателя, чтобы получить дополнительные параметры, например, заменить или удалить показатель.

На панели показателей отображаются собранные данные о метриках за определенный период времени, как в графическом виде, так и в виде числового процентного изменения.

Узнайте больше об использовании панели управления .

Просмотр трассировок и их данных

Чтобы просмотреть трассировки, перейдите на панель мониторинга «Производительность» в консоли Firebase , прокрутите вниз до таблицы трассировок, а затем щелкните соответствующую подвкладку. В таблице отображаются некоторые ключевые показатели для каждой трассировки, и вы даже можете отсортировать список по процентному изменению для конкретного показателя.

В консоли Firebase Performance Monitoring предоставляет страницу устранения неполадок, которая отображает изменения метрик, что позволяет быстро выявлять и минимизировать влияние проблем с производительностью на ваши приложения и пользователей. Вы можете использовать эту страницу устранения неполадок, когда узнаете о потенциальных проблемах с производительностью, например, в следующих сценариях:

• Вы выбираете соответствующие показатели на панели мониторинга и замечаете большую разницу.
• В таблице результатов вы сортируете данные таким образом, чтобы наибольшие изменения отображались вверху, и видите значительное процентное изменение.
• Вы получите уведомление по электронной почте о проблеме с производительностью.

Доступ к странице устранения неполадок можно получить следующими способами:

• Используйте фильтр по версии приложения , чтобы просмотреть данные о предыдущих или последних версиях.
• Отфильтруйте результаты по устройству , чтобы узнать, как ваше приложение работает на старых устройствах.
• Используйте фильтр по стране , чтобы убедиться, что местоположение вашей базы данных не влияет на конкретный регион.

Узнайте больше о просмотре данных ваших трассировок .

Следующие шаги

• Узнайте больше об использовании атрибутов для анализа данных о производительности.

• Узнайте больше о том, как отслеживать проблемы с производительностью в консоли Firebase .

• Настройте оповещения о сетевых запросах, которые ухудшают производительность вашего приложения. Например, вы можете настроить оповещение по электронной почте для вашей команды, если время ответа для определенного шаблона URL-адреса превысит установленный вами порог.

• Просматривайте подробные отчеты о пользовательских сессиях , в которых можно увидеть конкретную трассировку в контексте временной шкалы других трассировок, собранных в течение той же сессии.

Performance Monitoring использует трассировку для сбора данных о контролируемых процессах в вашем приложении. Трассировка — это отчет, содержащий данные, полученные в вашем приложении в промежутке времени между двумя точками.

Для всех типов приложений Performance Monitoring автоматически собирает трассировку для каждого сетевого запроса, отправляемого вашим приложением, называемую трассировкой сетевого запроса HTTP/S . Эти трассировки собирают метрики за время между отправкой вашим приложением запроса к конечной точке сервиса и получением ответа от этой конечной точки. Для любой конечной точки, к которой ваше приложение отправляет запрос, Performance Monitoring собирает несколько метрик:

• Время ответа — время между отправкой запроса и получением полного ответа.

• Размер полезной нагрузки ответа — размер в байтах сетевой полезной нагрузки, загружаемой приложением.

• Размер полезной нагрузки запроса — размер в байтах сетевой полезной нагрузки, загружаемой приложением.

• Показатель успешности — процент успешных ответов (коды ответов в диапазоне 100–399) по сравнению с общим числом ответов.

Данные из этих трассировок можно просмотреть на вкладке «Сетевые запросы» таблицы трассировок, которая находится в нижней части панели мониторинга производительности (подробнее об использовании консоли см. далее на этой странице).

Performance Monitoring automatically collects metrics for network requests that use the following networking libraries:

Customize network request data aggregation

In addition to the out-of-the-box tooling and data aggregation for network requests, Performance Monitoring also supports the following options:

• Manually instrument network request traces: The out-of-the-box monitoring includes most network requests for your app. However, some requests might not be reported or you might use a different library to make network requests. In these cases, you can use the Performance Monitoring API to manually instrument custom network request traces .
• Aggregate data under custom URL patterns: If there are specific URLs that Firebase isn't capturing with its derived automatic URL pattern matching, you can create custom URL patterns to monitor a specific set of URLs over time.
• Customize how success rate is calculated: Sometimes an error code is expected for certain API endpoints or is already handled in your app. In these cases, you can configure how the success rate is calculated and monitor the success rate of your app's network calls more accurately.

Data aggregation under URL patterns

Firebase Performance Monitoring automatically aggregates data for similar network requests to help you understand trends in your network request performance.

For each request, Firebase checks if the network request's URL matches a URL pattern. If the request URL matches a URL pattern, Firebase automatically aggregates the request's data under the URL pattern. Firebase displays URL patterns and their aggregated data in the Network tab in the Performance dashboard of the Firebase console.

What's a URL pattern?

A URL pattern contains a domain plus a pattern that can match a URL path, for instance: example.com/*/animals/** .

• URL patterns can contain the following path segments:

  • plain text — matches an exact string
  • * — matches any string in a single path segment
  • ** — matches an arbitrary path suffix

• URL patterns can be either:

  • Firebase-derived patterns — called automatic URL patterns
  • User-defined patterns — called custom URL patterns

For example: Any of the following URL requests could match the URL pattern example.com/*/animals/** .

• example.com/singapore/animals
• example.com/australia/animals/spiders
• example.com/australia/animals/marsupials/koala.png

The domain for a URL pattern can also contain * as its first segment, for instance: *.example.com/*/fruits/** .

Firebase maps each request to only one URL pattern . If you've configured any custom URL patterns , Firebase attempts to match request URLs to those patterns first. If Firebase finds no matching custom URL pattern, then it matches a request URL to the most representative automatic URL pattern . Learn more about automatic and custom URL patterns in the following sections.

Automatic URL patterns

Without any configuration by you, Performance Monitoring attempts to reflect your app's latest usage behavior by matching your app's requests to automatic URL patterns .

How does automatic URL pattern matching work?

Firebase matches each request to the most representative automatic URL pattern that it has derived from requests sent by your app. Note, though, that Firebase attempts to match request URLs to any configured custom URL patterns first.

The following is a basic example for how Firebase attempts to match requests to the most representative automatic URL pattern for your app.

1. Your app sends many requests to URLs like:

   • example.com/germany/animals/bears
   • example.com/germany/animals/birds
   • example.com/germany/cars

   Firebase determines that example.com/germany/** is a common request pattern for your app and adds it as an automatic URL pattern in your project.

   For any new matching requests to this URL pattern, Firebase aggregates the requests' data under the automatic URL pattern example.com/germany/** .

2. After one week, the majority of your app's requests are to example.com/germany/animals/bears and example.com/germany/animals/birds . So, Firebase derives a more representative URL pattern of example.com/germany/animals/** .

   For any new matching requests to this new URL pattern, Firebase aggregates the requests' data only under the new URL pattern. Firebase continues to aggregate data for requests to example.com/germany/cars under example.com/germany/** .

3. However, over the next several weeks, your app's requests to example.com/germany/animals/bears and example.com/germany/animals/birds decrease substantially. Firebase determines that example.com/germany/animals/** is not representative of your app's latest usage behavior, so Firebase starts matching these two requests back to example.com/germany/** .

   Firebase does not aggregate any further request data under example.com/germany/animals/** because it's no longer the most representative automatic URL pattern.

Because automatic URL pattern matching is dynamic, be aware of the following:

• Matches and aggregated data from previous requests aren't affected by new URL patterns. Firebase does not retroactively re-aggregate request data.

• Only future requests are affected by new URL patterns. Firebase maps each new request to the most representative automatic URL pattern. Note, though, that Firebase attempts to match request URLs to any configured custom URL patterns first.

View automatic URL patterns and their data

Firebase displays all URL patterns and their aggregated data in the Network requests subtab of the traces table, which is at the bottom of the Performance dashboard of the Firebase console.

You might see URL patterns with an Uncategorized label. These are "broad" automatic URL patterns under which Firebase can aggregate data for requests that don't match to any more specific URL pattern.

When the data retention period ends for the data aggregated under a URL pattern, Firebase deletes that data from the URL pattern. If all the data aggregated under an automatic URL pattern expires, then Firebase deletes that URL pattern from the Firebase console.

Custom URL patterns

You can create custom URL patterns to monitor specific URL patterns that Firebase isn't capturing with its derived automatic URL pattern matching . For example, you can use a custom URL pattern to troubleshoot a specific URL or to monitor a specific set of URLs over time.

Visit Create custom URL patterns to learn more.

Track, view, and filter performance data

To view real-time performance data, make sure that your app uses a Performance Monitoring SDK version that's compatible with real-time data processing. Learn more about real-time performance data .

Track specific metrics in your dashboard

To learn how your key metrics are trending, add them to your metrics board at the top of the Performance dashboard. You can quickly identify regressions by seeing week-over-week changes or verify that recent changes in your code are improving performance.

To add a metric to your metrics board, follow these steps:

1. Go to the Performance dashboard in the Firebase console.
2. Click an empty metric card, then select an existing metric to add to your board.
3. Click more_vert on a populated metric card for more options, for example to replace or remove a metric.

The metrics board shows collected metric data over time, both in graphical form and as a numerical percentage change.

Learn more about using the dashboard .

View traces and their data

To view your traces, go to the Performance dashboard in the Firebase console, scroll down to the traces table, then click the appropriate subtab. The table displays some top metrics for each trace, and you can even sort the list by the percentage change for a specific metric.

Performance Monitoring provides a troubleshooting page in the Firebase console that highlights metric changes, making it easy to quickly address and minimize the impact of performance issues on your apps and users. You can use the troubleshooting page when you learn about potential performance issues, for example, in the following scenarios:

• You select relevant metrics on the dashboard and you notice a big delta.
• In the traces table you sort to display the largest deltas at the top, and you see a significant percentage change.
• You receive an email alert notifying you of a performance issue.

You can access the troubleshooting page in the following ways:

• Filter by App version to view data about a past release or your latest release
• Filter by Device to learn how older devices handle your app
• Filter by Country to make sure your database location isn't affecting a specific region

Learn more about viewing data for your traces .

Следующие шаги

• Learn more about using attributes to examine performance data.

• Learn more about how to track performance issues in the Firebase console.

• Set up alerts for network requests that are degrading the performance of your app. For example, you can configure an email alert for your team if the response time for a specific URL pattern exceeds a threshold that you set.

• View detailed reports of user sessions in which you can see a specific trace in a timeline context of other traces collected during the same session.

Performance Monitoring uses traces to collect data about monitored processes in your app. A trace is a report that contains data captured between two points in time in your app.

For all app types, Performance Monitoring automatically collects a trace for each network request issued by your app, called an HTTP/S network request trace . These traces collect metrics for the time between when your app issues a request to a service endpoint and when the response from that endpoint is complete. For any endpoint to which your app makes a request, Performance Monitoring captures several metrics:

• Response time — Time between when the request is made and when the response is fully received

• Response payload size — Byte size of the network payload downloaded by the app

• Request payload size — Byte size of the network payload uploaded by the app

• Success rate — Percentage of successful responses (response codes in the 100 - 399 range) compared to total responses

You can view data from these traces in the Network requests subtab of the traces table, which is at the bottom of the Performance dashboard (learn more about using the console later on this page).

Performance Monitoring automatically collects metrics for network requests that use the following networking libraries:

Customize network request data aggregation

In addition to the out-of-the-box tooling and data aggregation for network requests, Performance Monitoring also supports the following options:

• Manually instrument network request traces: The out-of-the-box monitoring includes most network requests for your app. However, some requests might not be reported or you might use a different library to make network requests. In these cases, you can use the Performance Monitoring API to manually instrument custom network request traces .
• Aggregate data under custom URL patterns: If there are specific URLs that Firebase isn't capturing with its derived automatic URL pattern matching, you can create custom URL patterns to monitor a specific set of URLs over time.
• Customize how success rate is calculated: Sometimes an error code is expected for certain API endpoints or is already handled in your app. In these cases, you can configure how the success rate is calculated and monitor the success rate of your app's network calls more accurately.

Data aggregation under URL patterns

Firebase Performance Monitoring automatically aggregates data for similar network requests to help you understand trends in your network request performance.

For each request, Firebase checks if the network request's URL matches a URL pattern. If the request URL matches a URL pattern, Firebase automatically aggregates the request's data under the URL pattern. Firebase displays URL patterns and their aggregated data in the Network tab in the Performance dashboard of the Firebase console.

What's a URL pattern?

A URL pattern contains a domain plus a pattern that can match a URL path, for instance: example.com/*/animals/** .

• URL patterns can contain the following path segments:

  • plain text — matches an exact string
  • * — matches any string in a single path segment
  • ** — matches an arbitrary path suffix

• URL patterns can be either:

  • Firebase-derived patterns — called automatic URL patterns
  • User-defined patterns — called custom URL patterns

For example: Any of the following URL requests could match the URL pattern example.com/*/animals/** .

• example.com/singapore/animals
• example.com/australia/animals/spiders
• example.com/australia/animals/marsupials/koala.png

The domain for a URL pattern can also contain * as its first segment, for instance: *.example.com/*/fruits/** .

Firebase maps each request to only one URL pattern . If you've configured any custom URL patterns , Firebase attempts to match request URLs to those patterns first. If Firebase finds no matching custom URL pattern, then it matches a request URL to the most representative automatic URL pattern . Learn more about automatic and custom URL patterns in the following sections.

Automatic URL patterns

Without any configuration by you, Performance Monitoring attempts to reflect your app's latest usage behavior by matching your app's requests to automatic URL patterns .

How does automatic URL pattern matching work?

Firebase matches each request to the most representative automatic URL pattern that it has derived from requests sent by your app. Note, though, that Firebase attempts to match request URLs to any configured custom URL patterns first.

The following is a basic example for how Firebase attempts to match requests to the most representative automatic URL pattern for your app.

1. Your app sends many requests to URLs like:

   • example.com/germany/animals/bears
   • example.com/germany/animals/birds
   • example.com/germany/cars

   Firebase determines that example.com/germany/** is a common request pattern for your app and adds it as an automatic URL pattern in your project.

   For any new matching requests to this URL pattern, Firebase aggregates the requests' data under the automatic URL pattern example.com/germany/** .

2. After one week, the majority of your app's requests are to example.com/germany/animals/bears and example.com/germany/animals/birds . So, Firebase derives a more representative URL pattern of example.com/germany/animals/** .

   For any new matching requests to this new URL pattern, Firebase aggregates the requests' data only under the new URL pattern. Firebase continues to aggregate data for requests to example.com/germany/cars under example.com/germany/** .

3. However, over the next several weeks, your app's requests to example.com/germany/animals/bears and example.com/germany/animals/birds decrease substantially. Firebase determines that example.com/germany/animals/** is not representative of your app's latest usage behavior, so Firebase starts matching these two requests back to example.com/germany/** .

   Firebase does not aggregate any further request data under example.com/germany/animals/** because it's no longer the most representative automatic URL pattern.

Because automatic URL pattern matching is dynamic, be aware of the following:

• Matches and aggregated data from previous requests aren't affected by new URL patterns. Firebase does not retroactively re-aggregate request data.

• Only future requests are affected by new URL patterns. Firebase maps each new request to the most representative automatic URL pattern. Note, though, that Firebase attempts to match request URLs to any configured custom URL patterns first.

View automatic URL patterns and their data

Firebase displays all URL patterns and their aggregated data in the Network requests subtab of the traces table, which is at the bottom of the Performance dashboard of the Firebase console.

You might see URL patterns with an Uncategorized label. These are "broad" automatic URL patterns under which Firebase can aggregate data for requests that don't match to any more specific URL pattern.

When the data retention period ends for the data aggregated under a URL pattern, Firebase deletes that data from the URL pattern. If all the data aggregated under an automatic URL pattern expires, then Firebase deletes that URL pattern from the Firebase console.

Custom URL patterns

You can create custom URL patterns to monitor specific URL patterns that Firebase isn't capturing with its derived automatic URL pattern matching . For example, you can use a custom URL pattern to troubleshoot a specific URL or to monitor a specific set of URLs over time.

Visit Create custom URL patterns to learn more.

Track, view, and filter performance data

To view real-time performance data, make sure that your app uses a Performance Monitoring SDK version that's compatible with real-time data processing. Learn more about real-time performance data .

Track specific metrics in your dashboard

To learn how your key metrics are trending, add them to your metrics board at the top of the Performance dashboard. You can quickly identify regressions by seeing week-over-week changes or verify that recent changes in your code are improving performance.

To add a metric to your metrics board, follow these steps:

1. Go to the Performance dashboard in the Firebase console.
2. Click an empty metric card, then select an existing metric to add to your board.
3. Click more_vert on a populated metric card for more options, for example to replace or remove a metric.

The metrics board shows collected metric data over time, both in graphical form and as a numerical percentage change.

Learn more about using the dashboard .

View traces and their data

To view your traces, go to the Performance dashboard in the Firebase console, scroll down to the traces table, then click the appropriate subtab. The table displays some top metrics for each trace, and you can even sort the list by the percentage change for a specific metric.

Performance Monitoring provides a troubleshooting page in the Firebase console that highlights metric changes, making it easy to quickly address and minimize the impact of performance issues on your apps and users. You can use the troubleshooting page when you learn about potential performance issues, for example, in the following scenarios:

• You select relevant metrics on the dashboard and you notice a big delta.
• In the traces table you sort to display the largest deltas at the top, and you see a significant percentage change.
• You receive an email alert notifying you of a performance issue.

You can access the troubleshooting page in the following ways:

• Filter by App version to view data about a past release or your latest release
• Filter by Device to learn how older devices handle your app
• Filter by Country to make sure your database location isn't affecting a specific region

Learn more about viewing data for your traces .

Следующие шаги

• Learn more about using attributes to examine performance data.

• Learn more about how to track performance issues in the Firebase console.

• Set up alerts for network requests that are degrading the performance of your app. For example, you can configure an email alert for your team if the response time for a specific URL pattern exceeds a threshold that you set.

• View detailed reports of user sessions in which you can see a specific trace in a timeline context of other traces collected during the same session.