這篇整理 Meta、Google Tag Manager（GTM）與 Google Analytics 4（GA4）三家服務商（vendor）的帳號結構：網站上的追蹤資產屬於哪一層的擁有者、誰能對它做什麼、它能不能換到另一個擁有者底下。範圍是擁有關係與權限的結構，各家後台的操作步驟以官方說明為準。內容依據 2026 年 10 月讀取的各家說明頁，帳號規則由服務商決定、會改，引用時要回原頁確認；文中由權限設計推出、說明頁沒有直接寫的做法，會在句子裡標明。

網站程式碼引用的 ID 與它所屬的擁有者

三家的追蹤碼放進網站時，程式碼裡都寫著一個 ID，而這個 ID 指向一個由某一層擁有者持有的資產：

• Meta：網站程式碼裡寫的是 Pixel ID（一串數字）。Pixel 收到的事件在 Meta 那一端整理成一個資料集（dataset），本文稱它為 Meta 資料集，事件管理工具（Events Manager）的資料集頁面顯示的 ID 就是網站要填的 Pixel ID。Meta 資料集的擁有者是商家資產管理組合（business portfolio，舊名 Business Manager，下文簡稱組合）；廣告帳號與粉絲專頁也是組合底下的資產。Facebook 的個人帳號不擁有組合底下的資產，它是組合裡的一位成員，透過組合取得權限。另一條路徑是還沒有建組合、直接在某個人的廣告帳號底下建立 Pixel，這時 Pixel 跟著那個廣告帳號，而那個廣告帳號由建立它的人以自己的 Facebook 帳號管理。
• GTM：網站程式碼裡寫的是 GTM- 開頭的容器 ID。GTM 容器（container）是存放代碼（tag）、觸發條件（trigger）與變數的設定單位，網站上的一段片段載入它；容器屬於一個 GTM 帳戶（account），一個帳戶底下可以有多個容器。Google 的說明寫一家公司通常只需要一個帳戶。
• GA4：直接安裝 GA4 時，網站程式碼裡寫的是 G- 開頭的評估 ID（Measurement ID）。評估 ID 屬於網站資料串流（data stream），資料串流屬於一個 GA4 資源（property，一個網站或 App 的報表與設定單位），資源屬於一個 GA4 帳戶。Google 對帳戶的定義是「一個法律實體擁有其資料的一組資源」。

判斷一個資產的歸屬時要確認兩件事：它屬於哪一層的擁有者，以及它能不能換到另一個擁有者底下。資產換得了擁有者時，網站程式碼不必動；換不了時，要讓新擁有者持有它就只能建一個新資產，網站上的 ID 跟著改，舊資產累積的資料留在原擁有者那裡。三家的資產各屬於哪一種，在〈追蹤資產換擁有者的條件〉一節逐家說明。

Meta 的服務條款規定每個人只建立一個自己的個人帳號，所以「另開一個個人帳號給公司用」這條路在 Meta 不成立。組合是公司資產與員工個人帳號之間的分隔：資產屬於組合，個人帳號只是進出組合的身分。

Meta、GTM 與 GA4 的權限分級

三家都把權限分成兩層：管理擁有者本身（組合或帳戶）的權限，與操作底下個別資產的權限。

Meta 的組合分成完整存取權限（full access，舊名完整控制權）與部分存取權限（partial access）。部分存取權限再分成基本（Basic，舊名員工）與應用程式和整合（Apps and integrations，舊名開發人員）；財務相關的權限是另外加上的附加權限。持有完整存取權限的成員也可以給其他人 3 到 75 天的暫時存取權限，暫時存取只有基本權限、到期自動失效，適合只需要短期協助的外部人員。持有完整存取權限的成員可以新增與移除成員、變更組合的設定，Meta 建議至少兩位成員擁有完整存取權限。成員對個別資產（某個 Meta 資料集、某個廣告帳號）的權限另外指派。

GTM 在帳戶層有管理員（Admin）與使用者（User）兩種角色，在容器層有五級權限：無權限、讀取（Read）、編輯（Edit）、核准（Approve）、發布（Publish）。持有編輯權限的成員可以修改容器裡的代碼、觸發條件與變數，但不能建立版本也不能發布；持有核准權限的成員另外可以建立版本與工作區（workspace，容器尚未發布的草稿），但不能發布。Google Tag Manager 的自訂 HTML 一節說明過發布權限等同於在網站上執行任意程式碼的權限，容器層的分級讓這個權限可以只交給少數人。GTM 沒有「擁有者」這個角色，帳戶只有管理員，後台不允許把所有管理員移除；Google 建議至少有兩位管理員。

GA4 的角色是管理員（Administrator）、編輯者（Editor）、行銷人員（Marketer）、分析師（Analyst）、檢視者（Viewer），可以指派在帳戶層或資源層。分析師在檢視者的權限之上，可以把自己建立的探索分析分享給資源的其他成員；行銷人員在分析師的權限之上，可以建立與編輯目標對象、事件與關鍵事件（key events），並修改歸因模式的設定；資源層的完整設定權由編輯者持有。另外有兩項可以加在角色上的資料限制：不含成本指標（No Cost Metrics）與不含營收指標（No Revenue Metrics），各自讓成員看不到那一類指標，用在外部人員只該看流量與成效、不該看到營收或廣告花費的情況。GA4 的使用者管理說明頁沒有提到權限到期的設定，和 Meta 的暫時存取權限不同：只需要短期看報表的外部人員，要由管理員在期限到時自己移除。

追蹤資產換擁有者的條件：Meta 資料集、GTM 容器與 GA4 資源

Meta 資料集不能轉移，也不能刪除。 Meta 的說明頁在建立資料集的步驟之前寫明這一點，替代做法是把資料集分享給合作夥伴（partner，另一個組合，例如代理商的組合）或加入成員。分享只能由擁有資產的組合發起，取得分享的合作夥伴即使有完整權限，也不能再分享給第三方。同樣固定的還有廣告帳號：在某個組合裡建立的廣告帳號永久屬於那個組合，不能刪除也不能轉出；不屬於任何組合的廣告帳號可以被認領進一個組合，而廣告帳號屬於別人時，要由那個擁有者批准認領的要求。粉絲專頁可以換組合，流程是原擁有者先把它從自己的組合移除，另一個組合再加入它。

所以 Pixel 建在某個組合底下之後，要讓另一方使用它只有兩條路：原組合把 Meta 資料集分享給對方，資料集仍屬於原組合；或對方在自己的組合另建一個資料集、把網站上的 Pixel ID 換掉，代價是原資料集累積的事件資料留在原組合裡。

GTM 容器沒有官方的搬移功能。 Google 的說明頁沒有寫容器能不能從一個帳戶移到另一個帳戶，有文件記載的路徑是把容器匯出成 JSON 檔，再匯入到另一個帳戶的容器裡（匯入時可選擇覆寫或合併）。匯入的目標是另一個容器，它有自己的容器 ID，所以走這條路之後網站上的容器片段要換成新的 ID。不換 ID 的做法是不搬容器、換人移交：在原帳戶加入新擁有者的管理員，再移除原本的管理員。先加後移的順序是因為後台不允許把所有管理員移除，反過來做時移除最後一位會失敗。這是由權限設計推出的做法，前提是整個帳戶裡只有要移交的容器。

GA4 資源可以搬到另一個帳戶。 執行搬移的人要在來源帳戶與目的帳戶都同時有管理員與編輯者兩個角色。Google Marketing Platform 機構（organization）是位在帳戶之上、由公司建立用來集中管理 Google 行銷產品的單位，搬移受它限制：兩個帳戶分屬不同機構時不能搬；只有目的帳戶屬於機構時，由目的帳戶所屬機構的管理員把來源帳戶連結進同一個機構。說明頁沒有列出兩個帳戶都不屬於任何機構時的限制。搬移時報表資料是移過去而不是複製一份，資料串流與它的設定、資源設定、與其他產品的連結都一起移動，所以網站上的評估 ID 不必改；搬移之前的變更記錄留在來源帳戶。連結本身跟著資源移動；被連結的 Google Ads 帳戶與 BigQuery 專案的歸屬，不在本篇範圍。不能搬的情形包括資源連結了 Google Ad Manager、還有未抽樣報表（GA4 360 付費版才有的報表）正在處理、目的帳戶的資源數已達上限（預設 50 個），以及 GA4 360 資源的機構連結還沒有驗證。

三家可以換擁有者的單位不同：Meta 資料集與組合內建立的廣告帳號不能換，GTM 容器只能複製設定、不能保留 ID，GA4 資源能整個搬。三家共通的是最高的那一層（組合、帳戶）可以換人移交：把新擁有者的人加成完整存取權限或管理員，再移除原本的人，底下的資產與 ID 全部不動。換人移交是由三家的權限設計推出的做法，說明頁沒有寫成移交流程。它的前提是那一層裡只放著要移交的資產，而且三件事要先處理：Meta 組合裡由別的組合以合作夥伴身分分享進來的資產，換人之後會連同存取一起交出去；廣告帳號綁的付款方式仍是原擁有者的，換人不會改掉它；GA4 與 GTM 帳戶若連結在原擁有者的 Google Marketing Platform 機構底下，換人不會讓帳戶離開那個機構（機構管理員之後還保有哪些權限，本篇沒有查證）。

追蹤資產的歸屬安排：公司自營與委託代理商

Meta 資料集不能轉、GTM 容器不能保留 ID、GA4 資源跨機構不能搬，這三項限制推出一個安排原則：追蹤資產建在公司自己的組合與帳戶底下，代理商以合作夥伴或成員的身分取得權限。 反過來由代理商在自己的組合或帳戶裡建立 Pixel、容器與資源再給公司用，日常運作沒有差別，差別出現在合作結束的時候：Meta 資料集留在代理商的組合裡，公司要嘛繼續靠代理商分享才看得到，要嘛另建一個並改網站上的 Pixel ID；GTM 容器要匯出匯入並換 ID；GA4 資源要搬到公司的帳戶，而兩邊分屬不同機構時搬不了。GTM 的說明頁直接寫了這個建議：帳戶要由組織內部的人管理，不要交給外部代理商。

各家對應的做法，以及這樣分的理由：

• Meta：公司建立自己的組合，Meta 資料集與廣告帳號建在組合底下，再以合作夥伴的方式分享給代理商的組合。代理商自己的員工由代理商在它的組合裡增減，公司不必追蹤代理商的人事異動；合作結束時，公司撤銷對代理商組合的分享，就一次收回所有代理商員工的存取。
• GTM：帳戶由公司建立，公司的管理員把代理商的人員加成帳戶的使用者，再給容器層的權限。發布權限等同在網站上執行任意程式碼，所以權限給到哪一級取決於公司是否在發布前審查代理商的變更：有人審查時，公司把容器層權限給到核准（Approve）這一級，發布由公司的人做；不審查而把發布權限交給代理商時，代理商發布的自訂 HTML 會直接在每一位讀者的瀏覽器上執行，出事的後果由公司承擔。
• GA4：帳戶與資源由公司建立，公司的管理員把代理商的人員加在資源層，角色依代理商要做的事、給到剛好夠用的那一級（最小權限）：看報表與做分析給分析師角色，需要調整目標對象、關鍵事件與歸因設定給行銷人員角色，需要改資源的其他設定才給編輯者角色；代理商不該看到營收或廣告花費時，再加上對應的資料限制。GA4 的說明頁沒有針對代理商的建議，這一條是由角色設計推出的安排。

擁有最高管理權的成員（Meta 的完整存取權限、GTM 與 GA4 的管理員）至少兩位，而且至少一位是公司裡長期在職的人。 Meta 與 GTM 的說明頁都建議至少兩位，GTM 還禁止移除所有管理員；GA4 的說明頁沒有這項建議，而它的帳戶同樣只能由管理員增減成員。只有一位時的失效不會立刻出現：組合由一個人就建得起來，建立的人自動取得完整存取權限；其他成員各自握有廣告帳號與資料集的權限，已經指派給其他成員的投放與報表權限不需要完整存取權限，所以唯一的管理員離職或帳號遺失之後，日常的投放與看報表照常運作（由權限設計推出），要等到需要加入新代理商或移除離職者的那一天，才發現沒有人做得到。另一種情形來得比較快：那一位的個人檔案被 Meta 限制刊登廣告時，Meta 的說明寫明，只連結他一個人的廣告帳號也可能一起被停用。

唯一的管理員已經不在、才發現沒有人管理得了之後，三家能不能救回各不相同。

Meta 有一條申訴路徑（管理員爭議），說明頁列出的適用情形有：持有完整存取權限的是沒有所有權的前員工或承包商；公司換了擁有者而失去組合的存取權；組合裡沒有任何人持有完整存取權限；持有完整存取權限的人已過世（附死亡證明）；有法院命令證明申請人是組合所屬公司的合法擁有者。申請時要附上申請人的身分證明、證明擁有這家公司的文件與簽名的聲明書，並且要登入與這個組合有關聯的 Facebook 個人檔案，從 Meta 的商家支援中心送出；核准之後申請人取得完整存取權限，原有成員不會被移出組合。前承包商握著組合不交還，是說明頁明列的情形；唯一一位管理員自己的 Facebook 帳號遺失則不在清單裡，而且那時公司手上可能已經沒有任何與組合有關聯的個人檔案可以登入送件，所以要先走 Facebook 個人帳號的復原，帳號找不回來時，這條申訴路徑很可能走不通（依送件條件推出，本站沒有實際送件驗證）。

GA4 的復原方式是在帳戶裡每一個送資料的網站上放一個寫有驗證資訊的 analytics.txt 檔（放在根網域或送資料的子網域，不能上傳檔案時改在頁面加 meta tag），證明網站屬於自己，帳戶連結了 Google Ads 或 AdSense 時也要證明那些帳戶屬於自己，再填 Google 的聯絡表單。

GTM 的情形寫在同一份 GA4 復原說明頁裡：GTM 目前沒有復原途徑，失去所有管理員的 GTM 帳戶救不回來，只能另建容器、換掉網站上的容器 ID。事先多設一位管理員，省下的就是這些申訴與重建。

只有一個人的公司也適用同一個理由：第二位成員承擔的責任是在唯一的帳號遺失時，還有另一個身分能繼續管理，所以第二位不必是員工，可以是合夥人、家人或委託的會計事務所，給他完整存取權限或管理員。這個人同樣有權限移除原本的管理員，所以人選的條件是可以信任，而不只是方便聯絡。Meta 的條款不允許同一個人另開帳號充當第二位。找不到第二位時，風險集中在那唯一一個帳號上。Meta 的說明頁要求從與組合有關聯的個人檔案送出管理員爭議，那個帳號本身遺失時，這條申訴路徑可能走不通（依送件條件推出，本站沒有實際送件驗證），所以能做的是降低那個帳號遺失的機率、並保住它的復原途徑：替自己的 Facebook 與 Google 帳號開啟兩步驟驗證，把帳號綁定的復原電子郵件與手機號碼設成自己長期持有、不隨公司網域或門號變動的那一組。

帳號是被盜而不是遺失時，情形不同：盜用者以那個帳號的完整存取權限持有組合，網站上的 Pixel 仍把訪客的事件送進他控制的資料集，廣告帳號綁定的付款方式也還能被使用。這時有兩件事不必等帳號復原、也不需要那個帳號的權限，可以同時做：從網站拿掉那個 Pixel 的程式碼，切斷網站送進去的資料；向發卡機構停用廣告帳號綁的那張卡，擋住持續中的扣款（由權限設計推出）。之後走 Facebook 帳號的復原，帳號拿不回來時，在新的組合另建資料集，放回網站的是新的 Pixel ID。

成員的身分屬於個人，資產屬於擁有者。 三家的成員都是個人身分：Meta 是個人的 Facebook 帳號，GTM 與 GA4 是 Google 帳號。成員用的是公司 Google Workspace 的帳號時，公司在 Workspace 停權或刪除那個帳號，他就登不進 GTM 與 GA4（由帳號機制推出：GTM 與 GA4 以 Google 帳號登入）；用的是個人 Gmail 或個人 Facebook 帳號時，公司停用內部帳號碰不到它們，要到每一個組合與帳戶裡逐一移除；整份離職撤權清單見 職務交接與存取撤銷設計。資產建在公司的組合與帳戶底下時，員工離職只要由公司的管理員把他從成員中移除，公司就收回了他的權限，資產本身不受影響；資產建在員工自己的組合或帳戶底下時，那位員工就是擁有者，公司沒有可以移除他的權限。

資產與權限的移交方式：換代理商與事業轉手

移交的每一條路，除了看資產屬於哪一層，還要看兩件事：這一步要哪一方動手，以及那一方是否還聯絡得上、願意配合。下文的「對方」指公司以外要動手的那一方：換代理商時是舊代理商或廣告帳號的擁有者，事業轉手時是賣方；標「由權限設計推出」的做法，是本篇依三家的權限規則推導、Meta 與 Google 的說明頁沒有寫成流程的做法。認領廣告帳號要擁有者批准，分享舊的 Meta 資料集、匯出 GTM 容器、把帳戶連結進 Google Marketing Platform 機構都要對方的人操作，GA4 資源的搬移還要求執行的人在兩個帳戶都同時是管理員與編輯者。對方的狀態分成三種，出口各不相同。對方聯絡得上而且配合時，那段期間是處理這些事的窗口。對方失聯或拒絕配合、但手上沒有公司網站還在使用的資產權限時，剩下的只有不需要對方的路：另建資產、換掉網站上的 ID，以及 Meta 的管理員爭議與 GA4 的 analytics.txt 驗證這兩條由公司自己提出的復原途徑；管理員爭議要從與組合有關聯的個人檔案送件，公司的人從來不是那個組合的成員時這條路可能走不通，analytics.txt 要放在帳戶裡每一個送資料的網站上，所以資源放在代理商、帳戶裡還有其他客戶網站時，analytics.txt 這條路用不上（兩者皆依送件條件推出）。對方不只不配合、還握著資產的權限時（盜用帳號的人、與公司起爭議的代理商），對方能繼續收到網站送出的資料，透過 GTM 容器的發布權限還能在網站上執行程式碼，所以先切斷網站對那個資產的引用：拿掉頁面上屬於對方帳戶的 Pixel 與容器片段，再談移交或另建（由權限設計推出）。

換代理商時，資產若一開始就建在公司的組合與帳戶底下，要處理的只有權限：公司撤銷舊代理商的合作夥伴分享與成員身分，再把 Meta 資料集與廣告帳號以合作夥伴的方式分享給新代理商的組合，把 GTM 與 GA4 的成員權限給新代理商的人員。撤銷之前先列出舊代理商在公司資產上建立的整合（由權限設計推出）：GTM 容器裡指向代理商自己帳戶的代碼、GA4 連結的代理商 Google Ads 帳戶、Meta 上由代理商系統發出的 Conversions API 存取權杖。這些整合不會因為撤銷權限而消失：指向代理商帳戶的代碼與產品連結會繼續把資料送給代理商；依賴代理商發出的存取權杖的伺服器端事件，可能在撤銷後停止運作。

資產建在舊代理商的組合或帳戶底下時，網站上載入的 ID 是處理的起點。網站上可能同時留著舊代理商建立的 ID，以及更早之前的代理商或員工留下的 ID，而追蹤碼依 ID 送事件：留著的舊 Pixel ID 會讓事件繼續送進舊代理商的資料集，新的資料集也照常收事件，網站畫面與新報表都不會顯示異常；留著的舊 GTM 容器片段更嚴重，舊代理商仍持有那個容器的發布權限，等於仍能在公司網站上執行程式碼。所以要先查清每個網站實際載入的 Pixel ID、容器 ID 與評估 ID（查法見 用 Playwright 擷取追蹤碼請求，或在瀏覽器開發者工具的 Network 面板篩選 Meta 與 Google 的網域），再依各家處理：

• Meta：Meta 資料集無法轉給另一個組合，公司在自己的組合建新資料集、把網站上的 Pixel ID 換掉。查看舊資料的管道只能由擁有舊資料集的組合開放，合作結束後能不能開放只取決於舊代理商是否配合，所以要在換掉 Pixel ID 之前請舊代理商以合作夥伴的方式把舊資料集分享給公司。Pixel 建在舊代理商某一位人員自己的廣告帳號底下時，那個廣告帳號若不屬於任何組合，公司可以提出認領，由那位人員批准之後進入公司的組合；Meta 的說明頁沒有寫 Pixel 會不會隨廣告帳號一起進來，認領之後要在公司組合的資料集清單裡確認。那位人員不批准、舊代理商與那位人員都聯絡不上，或認領之後 Pixel 不在清單裡時，公司另建新資料集、換掉 Pixel ID，舊的歷史事件拿不回來。
• GTM：公司請舊代理商把容器匯出成 JSON 檔，由公司的人匯入公司帳戶裡的新容器，再換掉網站上的容器片段。舊代理商的帳戶專為這家公司建立、帳戶裡沒有其他客戶的容器時，也可以換人移交（由權限設計推出）：舊代理商把公司的人加成那個帳戶的管理員，再移除代理商的人，帳戶整個移交、容器 ID 不變。舊代理商的帳戶放著多個客戶的容器時，換人移交會把其他客戶的容器一起交出去，所以只有匯出匯入一途。舊代理商聯絡不上或不配合時，公司依網站上實際執行的追蹤碼（Network 面板裡看得到的 Pixel ID、評估 ID 與各家請求）在自己的帳戶建一個新容器，重新設定代碼，再換掉容器片段；舊容器的設定拿不回來。
• GA4：GA4 資源（property）的搬移受 Google Marketing Platform 機構（帳戶之上的管理單位）限制，說明頁寫明擋下的情形是兩個帳戶分屬不同機構，以及只有目的帳戶屬於機構而來源帳戶不屬於；執行的人在兩個帳戶都要同時是管理員與編輯者。依兩個帳戶目前與機構的關係：
  • 兩個帳戶屬於同一個機構：資源可以直接搬到公司的帳戶，評估 ID（Measurement ID）不變。
  • 只有公司的帳戶屬於機構：公司是目的帳戶，這正是說明頁擋下的狀態，所以要先由公司所屬機構的管理員把舊代理商的帳戶連結進公司的機構，兩個帳戶屬於同一個機構之後再搬；連結這一步要舊代理商配合。
  • 只有舊代理商的帳戶屬於機構：Google 的說明頁沒有寫這一種情形，本篇沒有驗證能不能直接搬。說明頁寫明可以搬的是兩個帳戶屬於同一個機構的情形，所以符合說明頁條件的做法是請舊代理商機構的管理員把公司的帳戶連結進同一個機構再搬，這要舊代理商配合（依說明頁的條件推出）。搬完之後公司的帳戶仍在舊代理商的機構底下，能不能移出、機構管理員還保有哪些權限，本篇沒有查證（見〈追蹤資產換擁有者的條件〉末段）。
  • 兩個帳戶分屬不同機構：Google 的說明頁寫明不能搬。
  • 兩個帳戶都不屬於任何機構：說明頁沒有寫是否能直接搬。符合說明頁條件的做法是公司建立機構、把兩個帳戶連結進同一個機構再搬；舊代理商的帳戶專為這家公司建立時，也可以把整個帳戶換人移交（由權限設計推出）。
  • 以上各種情形都搬不了，或需要配合的舊代理商聯絡不上、不配合時（任一成立）：公司另建資源、換掉網站上的評估 ID，歷史報表留在舊帳戶。

事業轉手時，買方要的是整套資產連同歷史資料。Meta、GTM 與 GA4 三家都能用換人的方式移交最上層的擁有者（Meta 的組合、GTM 帳戶、GA4 帳戶；由權限設計推出）：賣方把買方指定的人加成組合的完整存取權限，以及 GTM 帳戶與 GA4 帳戶的管理員，再移除賣方的人。在移除賣方的人之前，要先由買方確認自己登得進去、管理得了，因為移除之後賣方已經沒有權限補救；買方這時才發現自己管理不了的話，Meta 只剩管理員爭議、GA4 只剩 analytics.txt 驗證、GTM 沒有復原途徑。這條路徑底下的 Pixel ID、容器 ID、評估 ID 與歷史資料都不動，前提是三件事先處理好（理由見〈追蹤資產換擁有者的條件〉一節末段）：組合裡沒有別的組合分享進來的資產、廣告帳號的付款方式改成買方的、GA4 與 GTM 帳戶不在賣方的機構底下。

賣方的組合或帳戶裡如果還放著與這個事業無關的資產，整個組合或帳戶不能直接交出去。GA4 與 GTM 還有一條路：賣方先把無關的 GA4 資源搬到賣方另一個帳戶、把無關的 GTM 容器匯出匯入到賣方的新帳戶（那些無關容器原本所在的賣方網站要換成新容器 ID，買方的網站不受影響），帳戶裡只剩這個事業的資產之後再整個移交，買方手上的評估 ID 與容器 ID 都不動（由權限設計推出）。Meta 的組合做不到這一步，因為資料集與組合內建立的廣告帳號搬不出去，只能逐項處理；GA4 與 GTM 不走上面那條路時也一樣逐項處理：粉絲專頁移到買方的組合；Meta 資料集只能由賣方以合作夥伴的方式分享給買方，或由買方另建，組合內建立的廣告帳號也只能由賣方分享給買方或由買方另建；GA4 資源依換代理商那一段 GA4 條列的機構條件搬到買方的帳戶，買賣雙方分屬不同機構時搬不了，只能由買方另建；GTM 容器匯出匯入。

所以一個組合或帳戶只放一個事業的資產，轉手時才有整包移交這個選項。Google 說一家公司通常只需要一個 GTM 帳戶，本篇認為這適用於只經營一個事業的公司；同一家公司經營日後可能分拆出售的事業時，按事業各開一個組合與帳戶。

本站實測資產的擁有者

本站為 Meta Pixel 實測頁 與 Google Tag Manager 實測頁 建立的測試資產，套用的是同一個原則：一個擁有者只放一個用途的資產。Meta 另開一個組合、GTM 與 GA4 各另開一個帳戶，裡面只放實測用的 Meta 資料集、GTM 容器與 GA4 資源，不放進登入帳號原本就有的組合或帳戶；實測結束時，GTM 與 GA4 的帳戶可以整個刪除（刪除後分別有 30 天與 35 天可以從垃圾桶救回），Meta 資料集依規則刪不掉，會一直留在這個只放實測資產的組合裡，不會混進其他用途的組合。建立過程中三家各自的檢查與預設值（Meta 的組合名稱審查、資料集表單預設勾選的 Conversions API 選項、GA4 預設勾選的資料共用選項），以及這些資產上做的擷取，記錄在 用 Playwright 擷取追蹤碼請求 的測試帳號一節與各次結果。

延伸閱讀：資產建立之後的資料路徑與部署權限

這篇處理的是資產屬於誰；資產建立之後，事件怎麼從網站送進那個 Meta 資料集或 GA4 資源，由各家的機制文說明。Pixel 的瀏覽器端與伺服器端兩條路徑，以及兩條路徑送出同一個事件時靠 event_id 去重，見 Meta Pixel 與 Conversions API；代理商取得 GTM 容器的發布權限之後能在網站上做什麼、發布前怎麼驗證，見 Google Tag Manager 的預覽模式與自訂 HTML 兩節。