<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Remote-Config on Tarragon</title><link>https://tarrragon.github.io/blog/tags/remote-config/</link><description>Recent content in Remote-Config on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 19 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/remote-config/index.xml" rel="self" type="application/rss+xml"/><item><title>Firebase 套件</title><link>https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/firebase-suite/</link><pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/firebase-suite/</guid><description>&lt;p>Firebase 把 client-side 監控拆成多個獨立產品：Crashlytics 負責 crash 報告、Analytics（GA4）負責行為分析、Remote Config 負責功能旗標和 A/B test。三個產品各自有 SDK、dashboard 和計費模型，但共享 Firebase project 的使用者識別。&lt;/p>
&lt;h2 id="crashlytics">Crashlytics&lt;/h2>
&lt;p>Firebase Crashlytics 專注在 crash 報告 — fatal crash（app 當機）和 non-fatal exception（被捕獲但值得記錄的錯誤）。&lt;/p>
&lt;h3 id="自動-crash-報告">自動 crash 報告&lt;/h3>
&lt;p>Crashlytics SDK 在 app crash 時自動收集 crash 資訊（stack trace、device info、OS version），在下次 app 啟動時上傳。不需要開發者寫程式碼 — SDK 初始化後自動運作。&lt;/p>
&lt;h3 id="issue-分群">Issue 分群&lt;/h3>
&lt;p>和 Sentry 類似，Crashlytics 用 stack trace 自動把 crash 分群成 issue。每個 issue 有影響的使用者數、趨勢、crash-free session 比率。&lt;/p>
&lt;h3 id="和-analytics-的關聯">和 Analytics 的關聯&lt;/h3>
&lt;p>Crashlytics 可以在 crash 報告中附加 Analytics 的使用者屬性和自訂 key。但兩者的 dashboard 獨立 — crash 資料在 Crashlytics console，行為資料在 Analytics console。要從「crash」追蹤到「crash 前使用者做了什麼」需要在兩個 console 之間切換。&lt;/p>
&lt;h2 id="analyticsga4">Analytics（GA4）&lt;/h2>
&lt;p>Firebase Analytics 是 Google Analytics 4（GA4）的 mobile SDK 版本。記錄使用者操作事件（screen view、button click、purchase）和使用者屬性。&lt;/p>
&lt;h3 id="自動收集事件">自動收集事件&lt;/h3>
&lt;p>GA4 SDK 自動收集一組預定義事件：&lt;code>first_open&lt;/code>、&lt;code>session_start&lt;/code>、&lt;code>screen_view&lt;/code>、&lt;code>user_engagement&lt;/code>。開發者不需要手動埋點就能得到基礎的使用統計。&lt;/p>
&lt;h3 id="自訂事件">自訂事件&lt;/h3>
&lt;p>開發者用 &lt;code>logEvent(name, parameters)&lt;/code> 記錄自訂事件。事件名稱和參數的命名有限制（名稱 40 字元、參數 25 個、參數值 100 字元）。&lt;/p>
&lt;h3 id="和四類事件的對應">和四類事件的對應&lt;/h3>
&lt;p>GA4 主要處理 Event 類和 Lifecycle 類事件（&lt;a href="https://tarrragon.github.io/blog/monitoring/01-mental-model/four-event-types/" data-link-title="四類事件的完整定義" data-link-desc="Event / Error / Metric / Lifecycle 四類事件各自的語意、觸發時機和典型用途 — 分類是監控體系的統一語言">模組一&lt;/a>）。Error 類由 Crashlytics 處理。Metric 類沒有原生支援 — 需要把 metric 包裝成 event 的 parameter。&lt;/p>
&lt;h2 id="remote-config">Remote Config&lt;/h2>
&lt;p>Firebase Remote Config 讓開發者在不更新 app 的情況下修改 app 的行為 — 功能旗標（feature flag）、UI 文案、數值參數。&lt;/p>
&lt;h3 id="和-ab-test-的整合">和 A/B test 的整合&lt;/h3>
&lt;p>Remote Config 和 Firebase A/B Testing 整合：定義實驗（variant A: 舊 UI / variant B: 新 UI），Remote Config 自動分配使用者到 variant，Analytics 收集兩組使用者的行為數據，A/B Testing console 顯示統計結果。&lt;/p>
&lt;p>這個整合是 Firebase 生態的獨特優勢 — config 分發、使用者分群、行為收集、統計分析在同一個平台完成，不需要整合多個工具。&lt;/p>
&lt;h2 id="firebase-的取捨">Firebase 的取捨&lt;/h2>
&lt;p>Firebase 的設計取捨是「拆分但整合」— 每個產品獨立運作（可以只用 Crashlytics 不用 Analytics），但組合使用時有整合優勢（Crashlytics + Analytics 的 user ID 共享）。&lt;/p></description><content:encoded><![CDATA[<p>Firebase 把 client-side 監控拆成多個獨立產品：Crashlytics 負責 crash 報告、Analytics（GA4）負責行為分析、Remote Config 負責功能旗標和 A/B test。三個產品各自有 SDK、dashboard 和計費模型，但共享 Firebase project 的使用者識別。</p>
<h2 id="crashlytics">Crashlytics</h2>
<p>Firebase Crashlytics 專注在 crash 報告 — fatal crash（app 當機）和 non-fatal exception（被捕獲但值得記錄的錯誤）。</p>
<h3 id="自動-crash-報告">自動 crash 報告</h3>
<p>Crashlytics SDK 在 app crash 時自動收集 crash 資訊（stack trace、device info、OS version），在下次 app 啟動時上傳。不需要開發者寫程式碼 — SDK 初始化後自動運作。</p>
<h3 id="issue-分群">Issue 分群</h3>
<p>和 Sentry 類似，Crashlytics 用 stack trace 自動把 crash 分群成 issue。每個 issue 有影響的使用者數、趨勢、crash-free session 比率。</p>
<h3 id="和-analytics-的關聯">和 Analytics 的關聯</h3>
<p>Crashlytics 可以在 crash 報告中附加 Analytics 的使用者屬性和自訂 key。但兩者的 dashboard 獨立 — crash 資料在 Crashlytics console，行為資料在 Analytics console。要從「crash」追蹤到「crash 前使用者做了什麼」需要在兩個 console 之間切換。</p>
<h2 id="analyticsga4">Analytics（GA4）</h2>
<p>Firebase Analytics 是 Google Analytics 4（GA4）的 mobile SDK 版本。記錄使用者操作事件（screen view、button click、purchase）和使用者屬性。</p>
<h3 id="自動收集事件">自動收集事件</h3>
<p>GA4 SDK 自動收集一組預定義事件：<code>first_open</code>、<code>session_start</code>、<code>screen_view</code>、<code>user_engagement</code>。開發者不需要手動埋點就能得到基礎的使用統計。</p>
<h3 id="自訂事件">自訂事件</h3>
<p>開發者用 <code>logEvent(name, parameters)</code> 記錄自訂事件。事件名稱和參數的命名有限制（名稱 40 字元、參數 25 個、參數值 100 字元）。</p>
<h3 id="和四類事件的對應">和四類事件的對應</h3>
<p>GA4 主要處理 Event 類和 Lifecycle 類事件（<a href="/blog/monitoring/01-mental-model/four-event-types/" data-link-title="四類事件的完整定義" data-link-desc="Event / Error / Metric / Lifecycle 四類事件各自的語意、觸發時機和典型用途 — 分類是監控體系的統一語言">模組一</a>）。Error 類由 Crashlytics 處理。Metric 類沒有原生支援 — 需要把 metric 包裝成 event 的 parameter。</p>
<h2 id="remote-config">Remote Config</h2>
<p>Firebase Remote Config 讓開發者在不更新 app 的情況下修改 app 的行為 — 功能旗標（feature flag）、UI 文案、數值參數。</p>
<h3 id="和-ab-test-的整合">和 A/B test 的整合</h3>
<p>Remote Config 和 Firebase A/B Testing 整合：定義實驗（variant A: 舊 UI / variant B: 新 UI），Remote Config 自動分配使用者到 variant，Analytics 收集兩組使用者的行為數據，A/B Testing console 顯示統計結果。</p>
<p>這個整合是 Firebase 生態的獨特優勢 — config 分發、使用者分群、行為收集、統計分析在同一個平台完成，不需要整合多個工具。</p>
<h2 id="firebase-的取捨">Firebase 的取捨</h2>
<p>Firebase 的設計取捨是「拆分但整合」— 每個產品獨立運作（可以只用 Crashlytics 不用 Analytics），但組合使用時有整合優勢（Crashlytics + Analytics 的 user ID 共享）。</p>
<table>
  <thead>
      <tr>
          <th>優勢</th>
          <th>代價</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>自動收集、零配置啟動</td>
          <td>自訂彈性受限（事件命名限制、參數數量限制）</td>
      </tr>
      <tr>
          <td>Crashlytics 免費且無量限制</td>
          <td>Analytics 的進階功能需要 BigQuery export（另收費）</td>
      </tr>
      <tr>
          <td>A/B test 整合開箱即用</td>
          <td>鎖定 Google 生態（資料 export 有限制）</td>
      </tr>
      <tr>
          <td>Mobile 優先，Flutter 支援佳</td>
          <td>Web 的支援較弱（GA4 web 是獨立產品線）</td>
      </tr>
  </tbody>
</table>
<h2 id="下一步路由">下一步路由</h2>
<ul>
<li>Datadog 的全棧 APM → <a href="/blog/monitoring/06-commercial-comparison/datadog-rum/" data-link-title="Datadog RUM" data-link-desc="全棧 APM 的 client-side 觀點 — client action 到 server trace 的完整鏈路追蹤">Datadog RUM</a></li>
<li>行為分析專用方案 → <a href="/blog/monitoring/06-commercial-comparison/mixpanel-amplitude/" data-link-title="Mixpanel / Amplitude" data-link-desc="行為分析專用方案 vs 通用監控的差異 — Mixpanel 和 Amplitude 的 funnel / cohort / retention 分析能力">Mixpanel / Amplitude</a></li>
<li>自架 vs 商業的判斷 → <a href="/blog/monitoring/06-commercial-comparison/self-hosted-vs-commercial/" data-link-title="自架 vs 商業的判斷決策表" data-link-desc="使用者數、網路範圍、功能需求、合規要求四個維度判斷該自架還是用商業方案">自架 vs 商業的判斷決策表</a></li>
</ul>
]]></content:encoded></item></channel></rss>