Firebase Performance: ano ito, metrics at kung paano subaybayan

Ano ang Firebase Performance Monitoring

Firebase Performance Monitoring ay isang SDK at cloud platform para sa pagkolekta, pag-aggregate at pag-visualize ng mga sukatan ng performance ng mobile application. Ang SDK ay naka-embed sa application at awtomatikong nag-i-instrument ng mga pangunahing punto: lifecycle ng Activity (Android) o ViewController (iOS), mga network request sa pamamagitan ng URLSession (iOS) o OkHttp (Android), at mga system call. Ang nakolektang data ay ipinapadala sa Firebase server, kung saan ito ay ina-aggregate ayon sa mga bersyon ng application, device, bansa at iba pang attribute.

Ang arkitektura ng Performance SDK ay binuo sa prinsipyo ng minimal na overhead: ang instrumentasyon ay nagdaragdag ng hindi hihigit sa 1–2% sa oras ng pagpapatupad ng mga sinusukat na operasyon. Ang data ay kinokolekta nang asynchronous at ini-buffer sa device bago ipadala, na nag-aalis ng epekto sa performance ng UI thread. Ang pagpapadala ng data ay nangyayari ayon sa iskedyul (default bawat 30 minuto) o kapag naabot ang buffer na 100 KB.

Ang pangunahing pagkakaiba ng Firebase Performance mula sa mga profiler ng Android Studio (CPU Profiler) o Xcode Instruments ay production monitoring. Ang Firebase Performance ay kumokolekta ng data mula sa mga totoong device ng user, hindi lamang mula sa mga device ng developer. Ito ay nagpapahintulot sa pag-detect ng mga problemang lumalabas lamang sa mga partikular na modelo, bersyon ng OS o sa mga tiyak na rehiyon — iyong mga problemang hindi maaaring i-reproduce sa isang kontroladong kapaligiran.

Paano kinokolekta ng SDK ang data nang hindi binabago ang code

Awtomatikong instrumentasyon ang pangunahing tampok ng Firebase Performance. Para sa Android, awtomatikong nagre-register ang SDK ng ActivityLifecycleCallbacks at sinusukat ang oras sa pagitan ng onCreate at onResume (oras ng rendering ng screen). Para sa iOS — sini-swizzle ang mga pamamaraan na viewDidLoad at viewDidAppear. Ang mga network request ay na-i-intercept sa antas ng OkHttpInterceptor (Android) o NSURLProtocol (iOS). Ang developer ay hindi kailangang magdagdag ng mga start/stop na tawag para sa mga karaniwang sukatan.

Pag-activate at pag-deactivate ng Performance SDK ay pinamamahalaan sa pamamagitan ng Google Services plugin (Android) o Info.plist (iOS). Para sa debugging, maaaring i-activate ang verbose logging ng Performance SDK, na magpapakita kung anong mga sukatan ang kinokolekta at ipinapadala. Sa produksyon, inirerekomenda na panatilihin ang logging sa antas ng warning upang hindi punuin ang mga log ng hindi kinakailangang impormasyon. Para sa mga proyekto sa Flutter o React Native, ang awtomatikong instrumentasyon ay maaaring limitado — higit pang detalye sa seksyon ng mga halimbawa ng code.

Mga libreng limitasyon at pagpepresyo

Firebase Performance ay inaalok sa libreng Spark na taripa nang walang mga limitasyon sa bilang ng mga trace o dami ng data. Ang bayad na Blaze na taripa ay hindi rin naniningil para sa Performance Monitoring — ito ay isa sa ilang serbisyo ng Firebase na ganap na libre sa parehong taripa. Mayroon lamang isang limitasyon: ang data ay iniimbak ng 30 araw (sa Spark) at hanggang 365 araw (sa Blaze). Para sa pangmatagalang pagsusuri, i-export ang data sa pamamagitan ng BigQuery export.

Walang bayad ay ginagawang perpektong pagpipilian ang Firebase Performance para sa anumang proyekto — mula sa prototype hanggang enterprise application na may milyun-milyong user. Ang tanging item ng gastos ay ang papalabas na trapiko ng data ng Performance SDK, ngunit ito ay bale-wala kumpara sa iba pang operasyon ng network ng application (mas mababa sa 1 MB bawat buwan bawat device). Sa BigQuery export, may bayad para sa pag-iimbak at mga query, ngunit ang Performance SDK mismo ay libre.

Awtomatikong sukatan: ano ang sinusukat nang walang code

Firebase Performance ay awtomatikong kumokolekta ng limang kategorya ng mga sukatan nang walang kahit isang linya ng code: oras ng pagsisimula ng application (app start), mabagal na request (slow HTTP requests), bilis ng rendering ng screen (screen rendering), paggamit ng memorya (memory usage, Android lang) at rate ng frame (frame rate, Android lang). Ang mga sukatang ito ay available sa Firebase console kaagad pagkatapos ikonekta ang SDK at unang session ng user.

App Start Time — oras mula sa pagsisimula ng proseso hanggang sa ganap na kahandaan ng UI para sa interaksyon. Nahahati sa cold start (nagsisimula ang application mula sa simula) at warm start (naibalik ang application mula sa background state). Ang cold start ay kinabibilangan ng pag-load ng mga DEX file, pagsisimula ng mga static field, pagtawag sa Application.onCreate at Activity.onCreate. Awtomatikong inuuri ng Firebase ang uri ng pagsisimula at ipinapakita ang distribusyon ng oras para sa bawat uri.

Screen Rendering Time — oras mula sa simula ng pag-load ng screen (onCreate para sa Android, viewDidLoad para sa iOS) hanggang sa ang screen ay handa para sa interaksyon (onResume, viewDidAppear). Ang Firebase ay nag-a-aggregate ng data para sa bawat screen (ayon sa pangalan ng klase o custom screen name), na nagpapahintulot na matukoy kung aling screen ang pinakamatagal mag-load. Para sa Android, karagdagang sinusukat ang dropped frames — bilang ng mga frame na nalaktawan sa panahon ng rendering ng screen (jank).

Mga network request (HTTP/HTTPS)

Performance SDK ay awtomatikong pumipigil at sumusukat sa bawat HTTP/HTTPS request na ipinadala mula sa application sa pamamagitan ng URLSession, OkHttp o URLConnection. Para sa bawat request ay nai-record: URL (path nang walang query parameter para sa seguridad), HTTP method, response code, laki ng response sa bytes, tagal ng request at bilis ng koneksyon (WiFi, Cellular). Ang data ay ina-aggregate sa dashboard na „Network Requests” ng Firebase console.

Slow Requests — mga request na ang tagal ay lumalampas sa itinakdang threshold. Ang default na threshold para sa „mabagal na request” ay 4000 ms. Ang sukatang ito ay kritikal para sa pagtukoy ng mga problema sa bahagi ng server: kung pagkatapos ng update ng backend ang bilang ng mabagal na request ay tumaas mula 1% hanggang 15%, ito ay senyales para sa agarang pagsusuri ng server logs. Ang mga user ay hindi maghihintay ng tugon nang higit sa 5 segundo — ang data ng Firebase ay nagpapakita na 53% ng mga user ay nagsasara ng application kung ang isang request ay tumatagal nang higit sa 3 segundo.

Mga limitasyon ng awtomatikong instrumentasyon

Mga limitasyon sa iOS: sa iOS, hindi masusukat ng Performance SDK ang dropped frames (ito ay pribadong API). Para sa pagsukat ng jank sa iOS, gamitin ang MetricKit o CADisplayLink. Gayundin sa iOS, hindi pinipigilan ng SDK ang mga request na isinagawa sa pamamagitan ng third-party na HTTP client na hindi gumagamit ng URLSession (halimbawa, SwiftNIO). Para sa mga ganitong kaso, gumamit ng custom na trace na may HTTP attribute.

Mga limitasyon sa Android: sa Android, ang awtomatikong pagsukat ng memorya ay available lamang sa mga device na may Android 8.0+ (API 26+). Para sa mas lumang bersyon, gumamit ng custom na trace na may pagkuha ng data sa pamamagitan ng Debug.getMemoryInfo(). Hindi rin pinipigilan ng SDK ang mga WebSocket connection — para sa mga ito ay kailangan ng hiwalay na trace. Sa kabila ng mga limitasyon, ang mga awtomatikong sukatan ay sumasaklaw sa 80% ng mga pangangailangan sa pagsubaybay ng performance.

Mga custom na trace at HTTP attribute

Mga custom na trace ay mga pinangalanang agwat ng oras na manu-manong ginagawa ng developer para sa pagsukat ng performance ng mga tiyak na senaryo: pag-load ng news feed, pagproseso ng imahe, pag-sync ng data, pag-execute ng kumplikadong database query. Ang mga custom na trace ay nagpupuno sa mga awtomatikong sukatan at nagpapahintulot sa pagsukat ng mismong mga bahagi ng code na itinuturing ng developer na kritikal para sa performance.

Ang bawat trace ay may pangalan (maximum na 100 character) at maaaring maglaman ng hanggang 5 custom na sukatan (metrics) — numerikal na halaga na nai-record sa loob ng trace. Halimbawa, sa trace na „image_processing” ay maaaring sukatin ang mga sukatan na „original_file_size” at „processed_file_size”. Ang mga sukatan ay ipinapakita sa Firebase console bilang mga distribusyon (min, max, average, percentiles), na nagpapahintulot sa pagsusuri hindi lamang ng tagal kundi pati na rin ng mga katangian ng operasyon.

HTTP attribute — espesyal na uri ng custom na trace para sa mga network request na hindi awtomatikong na-intercept ng SDK (halimbawa, sa pamamagitan ng WebSocket o third-party na library). Ang HTTP attribute ay kinabibilangan ng URL, HTTP method, response code at laki ng response. Ipinapakita ng Firebase ang mga ito sa seksyong „Network Requests” kasama ng mga awtomatikong nakolektang request, na nagbibigay ng nagkakaisang larawan ng network interaction.

Kailan gagamit ng custom na trace

Custom na trace ay kailangang-kailangan para sa pagsukat ng: oras ng pag-load ng data mula sa lokal na database (Room, CoreData), tagal ng kumplikadong pag-compute (encryption, compression), performance ng animation at transition, oras ng tugon ng third-party SDK (maps, payment, analytics). Para sa bawat ganitong senaryo, lumikha ng trace, balutin ang sinusukat na code sa start/stop at magdagdag ng attribute para sa susunod na segmentation.

Huwag abusuhin ang mga custom na trace. Ang bawat trace ay karagdagang konsumo ng baterya at trapiko. Inirerekomenda na hindi hihigit sa 10–15 aktibong trace sa production na bersyon ng application. Para sa debugging, maaaring magdagdag ng higit pang trace, ngunit bago ang release, i-deactivate ang mga sobra sa pamamagitan ng Remote Config (gamitin ang flag na performance_tracing_enabled). Ito ay nagpapahintulot ng detalyadong pagsubaybay para lamang sa mga piling user o session.

Attribute ng trace para sa segmentation

Custom attribute ay mga key-value pair na maaaring idagdag sa trace para sa susunod na pag-filter sa Firebase console. Halimbawa, sa trace na „feed_load” ay maaaring idagdag ang mga attribute na „feed_type” (main, explore, following) at „cache_status” (cold, warm). Sa console, ang data ng trace ay maaaring i-filter ayon sa mga attribute na ito upang matukoy kung aling uri ng feed ang pinakamabagal mag-load.

Mga limitasyon: bawat trace ay maaaring magkaroon ng hanggang 5 custom attribute. Ang halaga ng attribute ay string hanggang 100 character. Ang mga attribute ay dapat itakda bago magsimula ang trace; ang pagbabago ng attribute pagkatapos magsimula ay hindi papansinin. Ang limitasyong ito ay nauugnay sa performance: ang pagtatakda ng attribute pagkatapos magsimula ay mangangailangan ng karagdagang synchronization.

Mga threshold ng performance at alerto

Mga threshold ay mga nako-configure na hangganan ng mga sukatan, kapag nalampasan ay nag-ge-generate ang Firebase Performance ng babala. Ang mga threshold ay itinatakda sa Firebase console (seksyong Performance > Thresholds) para sa bawat awtomatikong sukatan: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Maaaring magtakda ng pandaigdigang threshold para sa lahat ng bersyon ng application o partikular para sa mga tiyak na bersyon.

Alerto ay mga awtomatikong notification na ipinapadala ng Firebase kapag nalampasan ang threshold. Ang mga alerto ay maaaring i-configure para sa email, Slack webhook, PagerDuty o Cloud Functions (para sa custom na pagproseso). Ang bawat alerto ay naglalaman ng: pangalan ng sukatan, kasalukuyang halaga, halaga ng threshold, bersyon ng application, segment (device, bansa). Ang mga alerto ay nagpapahintulot ng reaksyon sa pagkasira ng performance bago ito maging nakikita ng mga user.

Inirerekomendang threshold ayon sa pamantayan ng industriya (Google I/O 2025): cold start — mas mababa sa 2 segundo, warm start — mas mababa sa 1 segundo, rendering ng screen — mas mababa sa 500 ms, tagal ng HTTP request — mas mababa sa 3000 ms (95th percentile), proporsyon ng mabagal na request — mas mababa sa 5%. Para sa mga application na may mataas na kompetisyon (Social, E-commerce), ang target na threshold ay maaaring mas mahigpit: cold start < 1.5 segundo, HTTP < 1000 ms.

Pag-configure ng threshold sa Firebase console

Sa Firebase console pumunta sa seksyong Performance, buksan ang tab na Thresholds. Para sa bawat sukatan, itakda ang ninanais na halaga ng threshold at porsyento ng mga user na dapat maapektuhan ng paglampas. Halimbawa: „itinuturing naming mabagal ang cold start kung lumalampas ito ng 2 segundo para sa higit sa 10% ng mga user”. Ipapakita ng Firebase ang kasalukuyang halaga ng mga sukatan at kasaysayan ng paglampas upang makatulong sa pagpili ng makatotohanang threshold.

Mahalaga: ang mga threshold ay hindi nakakaapekto sa pagkolekta ng data, pinamamahalaan lamang nila ang pagbuo ng mga notification. Kung ang threshold ay masyadong mababa (halimbawa, cold start 1 segundo, kahit na 50% ng mga device ay nagsisimula sa 3 segundo), ang mga alerto ay patuloy na darating at magiging „ingay” na hindi na napapansin ng mga developer. Itakda ang mga threshold batay sa kasalukuyang indicator, pagkatapos ay unti-unting higpitan ang mga ito habang ino-optimize mo ang application.

Performance Dashboard sa Firebase console

Performance Dashboard ay nagpapakita ng mga pangunahing sukatan bilang time series na may paghahati ayon sa bersyon ng application, device, bansa, uri ng koneksyon at bersyon ng OS. Para sa bawat sukatan ay available: average, median, 95th percentile, 99th percentile. Ang 95th percentile ay ang pinaka-impormatibong sukatan para sa pagsusuri ng performance dahil ipinapakita nito kung paano gumagana ang application sa mahihinang device, na binabalewala ang mga outlier.

Sinusuportahan ng Dashboard ang pagkukumpara ng bersyon: pumili ng dalawang bersyon ng application (kasalukuyan at nauna) para sa visual na pagkukumpara ng mga sukatan. Kung pagkatapos ng update ang 95th percentile ng oras ng pagsisimula ay tumaas mula 2.1 hanggang 3.4 segundo — ang regression ay halata at kailangang hanapin ang commit na nagdulot ng pagbagal. Ang Firebase Performance ay naka-integrate sa GitHub, GitLab at Bitbucket, na nagpapahintulot sa pag-uugnay ng mga pagbabago ng sukatan sa mga partikular na commit.

Mga halimbawa ng code para sa Performance Monitoring

Tingnan natin ang mga halimbawa ng integrasyon ng Firebase Performance Monitoring sa Android application sa Kotlin. Ipinapakita ng code ang paglikha ng custom na trace para sa pagsukat ng pag-load ng news feed, pagdaragdag ng HTTP attribute para sa hindi awtomatikong na-intercept na request at paggamit ng Trace para sa pagsukat ng oras ng pagproseso ng imahe. Lahat ng halimbawa ay isinasaalang-alang ang posibilidad ng pag-deactivate ng pagsubaybay sa pamamagitan ng Remote Config.

Bago gamitin, idagdag ang dependency: implementation("com.google.firebase:firebase-perf") sa pamamagitan ng Firebase BOM. Para sa awtomatikong instrumentasyon, hindi kinakailangan ang karagdagang configuration — awtomatikong pinipigilan ng SDK ang mga karaniwang operasyon pagkatapos ikonekta ang dependency.

Custom na trace para sa pag-load ng feed

Unang halimbawa — pagsukat ng oras ng pag-load ng news feed mula sa server. Binabalot ng trace ang asynchronous na operasyon na fetchFeed, na kumukuha ng data mula sa network at nagpa-parse ng JSON. Sa trace ay idinagdag ang mga custom attribute: source ng data (cache o network) at bilang ng mga natanggap na post. Ito ay nagpapahintulot sa segmentation ng data at pag-unawa sa mga kondisyon kung saan ang feed ay pinakamatagal mag-load.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

Ang function na loadFeedWithTrace ay tumatanggap ng parameter na source („cache” o „network”), na ginagamit bilang attribute ng trace. Pagkatapos ng asynchronous na operasyon, ang trace ay hihinto sa finally block, na ginagarantiyahan ang paghinto kahit na may exception. Ang sukatan na items_count ay nagpapahintulot sa pagsusuri kung paano nakakaapekto ang bilang ng mga post sa oras ng pag-load. Sa Firebase console, ang mga trace ay maaaring i-filter ayon sa attribute na source at makita na ang pag-load mula sa network ay 3 beses na mas mabagal kaysa sa cache.

HTTP attribute para sa hindi karaniwang request

Pangalawang halimbawa — HTTP attribute para sa request na isinagawa sa pamamagitan ng WebSocket (hindi awtomatikong na-intercept). Ginagamit ang class na HttpMetric, na nagpapahintulot sa manu-manong pagrehistro ng URL request, method nito, response code at laki. Ipapakita ng Firebase ang request na ito sa seksyong Network Requests kasama ng mga awtomatikong na-intercept.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

Sa halimbawa, ang sendWithHttpMetric ay gumagamit ng newHttpMetric para sa pagrehistro ng hindi karaniwang HTTP call. Hindi ito awtomatikong pinipigilan ng SDK, kaya manu-manong itinatakda ng developer ang URL, method, response code at laki. Mahalagang itakda ang URL nang walang query parameter (para sa seguridad at aggregation) — iyon ay /data, hindi /data?token=abc. Awtomatikong pinapangkat ng Firebase ang mga katulad na pattern ng URL.

Pagsukat ng oras ng pagproseso ng imahe

Pangatlong halimbawa ay nagpapakita ng pagsukat ng oras ng pagproseso ng imahe (compression, pagbabago ng laki) gamit ang custom na trace. Sa kasong ito, binabalot ng trace ang synchronous na operasyon, ngunit para sa produksyon ay gumamit ng coroutine o RxJava upang hindi ma-block ang UI thread.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

Ang function na compressImage ay sumusukat sa oras ng compression ng imahe sa JPEG na may kalidad na 80%. Ang attribute na format ay nagpapahintulot sa hinaharap na pagkukumpara ng oras ng compression ng JPEG vs WebP. Ang sukatan na output_size_kb ay nagpapakita kung gaano kabisa ang compression. Sa Firebase console, makikita ang distribusyon: sa mahihinang device (budget Android) ang compression ay tumatagal ng 4 na beses na mas mahaba kaysa sa flagship, na maaaring maging sanhi ng pagkaantala sa pagpapadala ng mga imahe sa server.

Paano pagbutihin ang performance batay sa data

Firebase Performance ay nagbibigay ng data, ngunit hindi nagbibigay ng mga handa na solusyon. Ang pagsusuri ng mga sukatan ay nangangailangan ng pag-unawa sa mga karaniwang sanhi ng pagkasira ng performance para sa bawat sukatan. Tingnan natin ang mga pangunahing pattern ng pagkasira at mga paraan ng diagnosis batay sa data ng Performance Monitoring. Approach: maghanap ng anomalya sa sukatan → suriin ang mga karaniwang sanhi → ilapat ang optimization → suriin ang resulta pagkalipas ng isang linggo.

Mabagal na cold start (> 2 segundo): mga sanhi — mabigat na initialization ng SDK sa Application.onCreate (analytics, crash reporting, map SDK), pag-load ng malalaking resources (fonts, themes), synchronous na operasyon sa main thread sa pagsisimula. Mga solusyon: lazy initialization ng SDK, deferred loading ng resources, paggamit ng SplashScreen API (Android 12+) para magpakita ng placeholder sa panahon ng initialization. Ipapakita ng Firebase Performance kung aling bersyon ng application ang naging mas mabagal magsimula — suriin kung anong mga dependency ang idinagdag o na-update.

Mabagal na rendering ng screen (> 500 ms): mga sanhi — kumplikadong hierarchy ng View (nested ConstraintLayout, maraming Fragment), pag-load ng data sa UI thread (network o disk), mabibigat na draw operation (malalaking imahe, custom View). Mga solusyon: optimization ng layout hierarchy (Layout Inspector sa Android Studio), paglipat ng data sa background thread, pag-cache ng mga imahe sa pamamagitan ng Glide o Coil. Gamitin ang Screen Rendering filter sa Firebase upang mahanap ang pinakamabagal na screen at i-optimize ito muna.

Optimization ng network request

Mabagal na HTTP request (> 3 segundo): mga sanhi — mabagal na server, malalaking payload, kawalan ng caching, hindi optimal na protocol (HTTP/1.1 sa halip ng HTTP/2), DNS resolution. Mga solusyon: suriin ang server side (uptime, latency), bawasan ang laki ng response (pagination, GraphQL, protobuf sa halip ng JSON), i-activate ang caching sa pamamagitan ng HTTP headers (Cache-Control), gamitin ang OkHttp Interceptor para sa pagdaragdag ng timeout at retry logic.

Ipinapakita ng Firebase Performance ang distribusyon ng oras ng request: DNS resolution, TCP handshake, TLS handshake, pagpapadala ng request, pagtanggap ng response. Kung ang karamihan ng oras ay napupunta sa DNS — gumamit ng preloading ng DNS (OkHttp DNS-over-HTTPS). Kung sa TLS — gumamit ng session resumption at pag-aayos ng cipher suites. Kung sa pagtanggap ng response — suriin ang laki ng response at bilis ng network ng user. Ang data ng Firebase ay nagpapahintulot sa localization ng problema sa antas ng protocol, hindi lamang sabihin na „mabagal ang request”.

Integrasyon ng Remote Config para sa pag-deactivate ng pagsubaybay

Para sa produksyon inirerekomenda na magdagdag ng Remote Config flag na performance_tracing_enabled, na nagpapahintulot sa remote na pag-deactivate ng mga custom na trace. Kung ang Firebase Performance SDK sa client ay gumagawa ng masyadong maraming data o nakakaapekto sa performance (sa mahihinang device), maaaring i-deactivate ang mga trace para sa lahat ng user, na iiwan lamang ang mga awtomatikong sukatan na may minimal na overhead.

Halimbawa ng logic: sa pagsisimula ng application, suriin ang Remote Config parameter na performance_tracing_enabled. Kung false — lahat ng tawag sa Firebase.performance.newTrace() ay nagbabalik ng stub object na hindi kumokolekta ng data. Ito ay ipinapatupad sa pamamagitan ng wrapper class na sumusuri sa flag bago lumikha ng trace. Ang ganitong approach ay nagpapahintulot ng detalyadong pagsubaybay para sa mga partikular na user (beta tester, developer) nang hindi naaapektuhan ang buong audience.