GA4 Property 是什麼？資源規劃、設定與 ID 差異

加入為 Google 偏好來源

GA4 Property（台灣介面常稱「資源」）是網站與／或 App 資料的群組，也是報表、資料收集、歸因、隱私設定與產品連結的共同管理邊界。規劃時不要只看有幾個網域，而要判斷這些資料是否屬於同一邏輯使用者群、是否需要一起分析，以及是否適合整組連到相同產品。

一句話理解： Property 就像一間分析工作室；不同資料串流把網站或 App 的資料送進來，團隊在同一個範圍內看報表並管理設定。

Property 是什麼？

Google 將 Property 定義為「來自網站與／或 App 的一組資料」。在同一個 Property 裡，可以查看報表，並管理資料收集、歸因、隱私設定和產品連結。因此，Property 不只是放數字的資料夾，而是 GA4 中很關鍵的分析與設定邊界。這項定義可在 Google 的 Property 詞彙說明查到。

台灣繁體中文介面常把 Property 翻成「資源」，有些教學或從業者則稱為「屬性」。兩者在本文指的是同一個 GA4 概念；為了貼近官方介面，下文主要使用「Property（資源）」。

Property 也不必等於一個網域。shop.example.com、member.example.com 是否應該放在同一個 Property，要看它們是不是同一段使用者旅程，以及團隊是否要一起分析，而不是看到兩個網址就先拆成兩項資源。

Account、Property、Data stream 在哪一層？

初學者可以先記住這條階層：

Account（帳戶） → Property（資源） → Data stream（資料串流）

項目	它主要代表什麼	和 Property 的關係
Account	可包含一個或多個 Property 的上層管理容器	Property 隸屬於某個 Account
Property	一組資料、報表和多項設定的共同邊界	本文核心
Data stream	網站、iOS App 或 Android App 的資料入口	位於 Property 內，將資料送進 Property

Google 的帳戶結構說明把 Property 描述為某一「邏輯使用者群」的資料。這個概念比「一個網站」更有用：同一品牌的網站與 App 可能服務同一批會員，適合一起分析；兩個看似相近的網站若由不同品牌、不同團隊管理，資料分享需求也不同，就可能適合分開。

Property 如何運作？

從建立到看到資料，可以拆成四個步驟：

在正確的 Analytics Account 下建立 Property。
在 Property 內新增 Web、iOS 或 Android Data stream。
網站透過 Google tag、App 透過相應 SDK 等方式傳送事件。
資料進入 Property 後，依這項資源的設定處理並呈現在報表中，供分析、目標對象、歸因與產品連結等用途使用。

Google for Developers 的網站設定流程也是先建立 Property，再新增網站資料串流，最後為網站加入代碼。換句話說，建立 Property 只是在 GA4 中建立容器，不代表網站或 App 已經開始送資料。

同一 Property 可以接收相關網站與 App 的不同串流，讓這些資料位於同一分析範圍。不過，放在同一 Property 不代表 GA4 會自動把所有跨裝置互動正確辨識成同一個人。事件設計、使用者識別、同意設定、標記品質與平台差異，仍會影響最後看到的結果。

為什麼 Property 規劃很重要？

Property 的邊界會決定「哪些資料被放在一起」。這會進一步影響團隊查看的報表範圍、建立的目標對象、使用的歸因設定、隱私相關設定，以及連結其他產品時所面對的整組資料。

拆得太細，網站與 App 明明屬於同一會員旅程，卻分散在不同 Property，日後的整體判讀與協作會變困難。混得太廣，兩個獨立品牌或不同治理要求的資料放在一起，報表、存取與產品連結的範圍又可能變得不清楚。

這也是為什麼「多建幾個，以後再說」並不是可靠策略。比起先追求資源數量，應先把業務、使用者旅程、團隊責任與資料分享範圍畫清楚。

另外，Property 結構設計正確也不代表報表一定完整或精準。GA4 的觀測結果仍受標記、同意、識別、資料處理與模型等因素影響；歸因報表是在特定規則下分配貢獻，不能直接證明某個接觸點造成了結果。

一個網站或 App 該用一個還是多個 Property？

Google 的帳戶結構文件提供了三個很實用的判斷方向：資料是否屬於同一邏輯使用者群、是否通常需要一起分析，以及連結其他產品時是否適合分享整個資料範圍。

建立前可以依序問：

這些網站與 App 是否服務同一批邏輯使用者？例如同一會員可在官網瀏覽、App 收藏並完成購買。
團隊是否經常需要把資料放在一起分析？如果幾乎每次報表都要合看，放在同一邊界通常較自然。
連結其他產品時，是否適合分享整組資料？若廣告、搜尋或資料匯出需求只應接觸其中一部分，就要重新評估邊界。

情境	較合理的思考方向	原因與注意事項
單一品牌、單一官網	通常可從一個 Property 開始	資料與團隊需求單純
同一會員服務的網站、iOS 與 Android App	可考慮同一 Property	旅程相關；每個平台仍有自己的 Data stream
同一旅程跨越多個網域	不要因網域數直接拆 Property	通常先評估同一 Web stream 與跨網域設定；詳細作法屬其他詞條
獨立品牌、不同分析團隊，或資料不應整組分享	考慮不同 Property	管理、報表與產品連結邊界不同
開發／測試事件可能污染正式報表	先設計清楚隔離方案	不要讓測試資料直接混入正式決策資料

這張表不是硬性規則。大型企業、Google Analytics 360 或特殊資料治理情境還可能使用其他結構；本文的重點是先建立可解釋的判斷原則，不列容易改動的完整方案與配額。

建立 Property 前要決定哪些設定？

1. 使用能長期辨識的名稱

Property 名稱是給人看的。與其取名為「新版 GA4」或「官網」，不如使用固定規則，例如：

TW｜Brand A｜正式環境

名稱可包含品牌、市場與環境，讓新進同事也能判斷用途。Google 官方的編輯 Property 說明顯示，Property name 是可修改欄位；不過，改名後也應同步更新公司的量測規格與交接文件，避免同一項資源在不同地方使用不同稱呼。

2. 選對報表時區

報表時區不是裝飾設定，而是 GA4 報表切分日期的邊界。如果主要營運與結算以台灣時間為準，通常就應用符合團隊報表需求的時區。

Google 在建立 GA4 資源的說明與 Admin API Property 文件都提醒：更改時區只影響未來資料，不會回溯套用。變更前要先確認報表交接日，也不要期待歷史數字會全部重新排列。

3. 選擇報表貨幣並記錄治理資料

建立 Property 時也會選擇貨幣。跨國電商應先確認主要報表要用哪種貨幣，以及團隊如何解讀跨市場收入；不要只因網站顯示某種幣別就草率決定。

此外，建議在公司自己的量測文件記錄 Property owner、代表的使用者群、納入哪些網站／App、主要用途、時區、貨幣與產品連結範圍。這些是治理紀錄，不代表已完成任何法律或隱私合規判斷；涉及個資、同意與資料保留時，仍應由組織內適當的法務或隱私負責人確認。

Property 名稱、Property ID 與 Measurement ID 不一樣

這三個項目很常因為都出現在設定畫面而被混用：

項目	常見樣貌	主要用途
Property name	`TW｜Brand A｜正式環境`	給人在 GA4 介面辨識，可修改
Property ID	數字；API 形式如 `properties/123456789`	識別整個 Property，常用於 Data API 等情境
Measurement ID／Google tag ID	Web stream 常見 `G-XXXXXXXXXX`	讓網站資料送到相應目的地

Google 的 Admin API 文件把 displayName 與 properties/{property_id} 的資源識別名稱分開；Data API 的 Property ID 文件則明確要求數字 Property ID。Web stream 的 G- ID 可在資料串流的 Google tag ID 說明中查到。

最簡單的記法是：名稱給人看，Property ID 識別整項資源，G- ID 用於網站資料串流。若要完整理解各種 ID 與查找位置，請接著閱讀 GA4-007。

網站＋App 的電商實例

假設一家台灣會員電商有官網、iOS App 與 Android App。顧客可能先在官網看商品，之後用 App 收藏，最後在另一台裝置購買。若三個平台服務同一會員旅程，團隊也要一起分析，可以規劃一個 GA4 Property，內含一個 Web stream、一個 iOS stream 與一個 Android stream。

這樣做的價值，是把相關平台放在同一個資料與報表邊界，而不是保證所有互動自然合併。團隊仍需對齊事件名稱與參數、處理使用者識別、驗證同意設定，並檢查各平台是否把資料送到正確的串流。

反過來，如果同一集團另有一個完全獨立品牌，由不同團隊負責，廣告帳戶、使用者群與資料分享需求也不同，就應考慮獨立 Property。真正的判斷依據是業務與資料治理邊界，不是公司名稱相同就全部合併。

易混淆概念比較

容易混淆的說法	更準確的理解
Property 就是一個網站	Property 是資料與設定邊界，可包含相關網站與 App 資料
Property 就是 Google 登入帳號	登入帳號是使用者身分；Property 是 Analytics 中的資源
Property 與 Data stream 相同	Property 包含資料串流；串流是資料入口
同一 Property 一定能辨識跨裝置同一人	共用資料範圍不等於身分與同意實作已完成
改 Property 名稱等於換了一項資源	顯示名稱與數字 Property ID 是不同概念

常見錯誤與自我檢查

常見錯誤包括：看到不同網域就各建一個 Property；建立容器後沒有確認串流與代碼；把顯示名稱當 Property ID；把 G- ID 填入需要數字 Property ID 的工具；任意改時區並期待歷史資料重算；或因為資料在同一 Property，就認為跨裝置使用者一定已正確合併。

建立完成後，可用以下清單自我檢查：

[ ] 我能用一句話說明這個 Property 代表哪個邏輯使用者群。
[ ] 放入其中的網站與 App 通常需要一起分析。
[ ] 連結其他產品時，讓對方接觸整組資料是合理的。
[ ] Property 名稱、數字 Property ID 與各 Data stream 的 ID 已分開記錄。
[ ] 報表時區與貨幣符合主要營運和報表需求。
[ ] 已確認 Web／App 資料送到正確 Property，而不是只看到任意即時數字就算完成。
[ ] 測試資料、內部流量、同意與隱私責任都有明確處理人。

FAQ

一個 GA4 Property 可以同時放網站和 App 嗎？

可以。GA4 Property 可包含網站、iOS App 與 Android App 的相關資料串流。是否放在一起，應看它們是否屬同一邏輯使用者群、是否需要一起分析，而不是只看平台種類。

一個網域一定要一個 Property 嗎？

不一定。多個網域若屬同一段使用者旅程，通常應先評估同一分析邊界與跨網域評估；不同品牌或不應共享整組資料的業務，才更有理由拆分。

Property 名稱可以修改嗎？

可以。Google 官方將 Property name 列為可編輯欄位。改名不等於 Property ID；改名後應同步更新內部量測文件，避免團隊認錯資源。

Property ID 和 Measurement ID 一樣嗎？

不一樣。Property ID 是識別整個 GA4 Property 的數字；Web stream 的 Measurement／Google tag ID 常以 G- 開頭，用於資料收集目的地。不要在 API 或 CMS 欄位中互相替代。

報表時區設錯可以改嗎？

可以修改，但官方說明指出變更只影響未來資料，不會回溯重算。更改前應記錄切換日期並告知報表使用者，避免把時間邊界造成的變化誤判為業務波動。

官方參考資料

研究截止日：2026-07-31。Google Analytics 的介面名稱、角色、產品連結與服務功能可能更新；正式操作前請再查看官方最新文件。

Property（資源／屬性）：GA4 的資料、設定與報表邊界