個人號、粉絲團、BM、廣告號、開發者帳戶：一張圖看懂誰掛在誰底下

這幾個詞會一直混在一起，是因為講的人把兩套語言摻著用：一套是 Meta 後台真的存在的物件，一套是市場上的商品名。 先把物件排好，商品名就自己對得上位置了。

圖裡只有一個根：個人 FB 帳號。其他東西全部掛在它上面，沒有例外。看圖的時候先認這個根，再看三條線分別長出什麼，名詞就不會再互相打架。

這篇是從 2026 年 9 月 11 日一段客服對話長出來的。一位剛開始碰廣告的客人連問了三題：權杖可以用買的嗎、買來的權杖是 BM 的嗎、買了開發者帳戶還要不要另外開一個 FB 帳號去綁。三題聽起來是三個問題，其實是同一個誤解：他把開發者帳戶當成跟個人號、粉絲團、BM 平行的「第五種帳號」。

這個誤解的代價不是答錯考題，是買錯東西。把開發者帳戶當成獨立帳號的人，最常見的兩種花錢方式是：買了一顆開發者帳號卻發現還是投不出廣告（因為缺粉絲專頁），或是為了「拿 API」多付一筆，而他要做的事其實在廣告管理員裡點一點就好。兩種都是先付錢、事後才知道自己缺的是別的東西。

一、五個名詞的一句話定義

名詞	後台叫什麼	一句話	沒有它會怎樣
個人號	個人帳號	你的身分，登入用的那一個	什麼都做不了
粉絲團	粉絲專頁 Page	廣告掛在誰名下刊登	廣告發不出去
BM	商務管理平台	裝廣告帳戶、像素、人員的容器	只能有一個廣告帳戶，也不能授權給別人
廣告帳戶	廣告帳戶 Ad Account	錢從這裡花出去	沒有東西可以扣款
開發者帳戶	開發者帳戶	同一個人的另一個角色，用來建 App	不能用程式打 API，但可以照常用介面投廣告

最後一列是這張表真正的用處。「缺哪一層」的症狀各不相同，你不需要記住定義，只要認得症狀。

那「廣告號」呢

「廣告號」不在上面那張表裡，因為它不是 Meta 的物件，是商品名。

市場上講的廣告號，指的是「已經開好廣告帳戶的個人帳號」，你拿到的是第一層加上廣告帳戶那一層。同一個邏輯還有幾個詞：

市場用語	實際上是
廣告號 / 廣告戶	個人帳號 ＋ 已開好的廣告帳戶
分享戶	別人的廣告帳戶把操作權分享給你，擁有權不是你的
BM3 / BM50	BM 的規格，數字是能裝幾個廣告帳戶
開發者帳號	一組已經註冊過開發者的個人 FB 帳密
二解 / 三解	個人帳號的歷史狀態，不是另一種物件

看懂這張表，「我到底買到了什麼」就不會再猜。 每一個商品名都能還原成「哪一層 ＋ 什麼狀態」。

把這張表倒過來看更有用：你付的每一筆錢，買的都是某一層的時間。 老號買的是註冊到現在那兩年、粉絲專頁買的是貼文與粉絲累積的那段歷史、廣告帳戶買的是開戶跟過驗證那幾天、開發者帳號買的是「不用自己過驗證」那一次。時間長的貴、能自己做的便宜，這條規則解釋了目錄上九成的價差。反過來也成立：任何一層你自己有時間做，就不該花錢買。

號的等級怎麼挑、什麼預算配什麼，在各種號型的適用場景。

二、掛在個人帳號底下的三條線

回頭看圖。從個人帳號往外只有三條線，而且三條線的性質完全不同。

第一條：粉絲專頁。 廣告必須以某個粉絲專頁的身分刊登，這是硬性規定。粉絲專頁可以放進 BM 管理，也可以獨立存在。

第二條：BM。 容器。裡面裝廣告帳戶、像素、人員權限與付款方式。BM 本身不投廣告也不花錢，詳見BM 是什麼。

第三條：開發者帳戶。 這條線跟前兩條不一樣，它不產生任何廣告資產，只產生「操作的另一條路徑」。下一節單獨講。

為什麼「只有一個根」這件事很重要

因為它決定了出事時的連坐範圍：

哪一層出事	其他層會怎樣
個人帳號被停	三條線全部進不去（除非事先加了第二個管理員）
粉絲專頁被檢舉	關聯的廣告帳戶會被多看一眼
BM 被停	底下的廣告帳戶通常受影響，粉絲專頁多半還在
廣告帳戶被停	其他廣告帳戶不一定受影響，但會被記錄
App 被停	只有程式那條路斷掉，介面投放照跑

第一列是最貴的一列。 個人帳號是唯一的根，它倒了，你在 Meta 上的所有東西同時失聯。事先把 BM 與廣告帳戶分享給第二個 FB 帳號當管理員，是成本為零而且當天就有價值的動作。

三、開發者帳戶到底是什麼

它是你的個人 FB 帳號多出來的一個角色，不是新的一個帳號。

用同一組帳密登入 developers.facebook.com，在那裡建立「應用程式（App）」，App 再產生「存取權杖」，程式拿著權杖去打 Meta 的 API。整條路是這樣：

個人 FB 帳號 → 開發者角色 → 應用程式 App → 存取權杖 → 打 API

官方文件寫的驗證條件很單純：開發者帳戶要綁一組付款方式，或設定雙重驗證。這是官方頁面上的門檻。

實測回報的部分要分開講：2026 年以來，同業普遍反映新註冊的開發者帳戶要通過驗證比以前難，這也是市場上開始有人賣「現成開發者帳號」的原因。這一句是社群回報不是官方公告，我把它標出來，因為兩者的可靠度不一樣。

權杖有五種，你會碰到的是其中兩種

官方文件把存取權杖分成五類：應用程式權杖、用戶端權杖、粉絲專頁權杖、系統使用者權杖、使用者權杖。

實務上跟廣告有關的只有兩種：

權杖	代表誰	適合什麼
使用者權杖	某一個人	手動測試、一次性的腳本
系統使用者權杖	一個系統，不是人	長期自動化。不需要有人反覆重新授權

要長期跑程式的話，答案是系統使用者權杖，它在 BM 裡建立。這一點很多人不知道，於是繞去買開發者帳號，其實用自己的 BM 就能建。

權杖會過期，這是設計而不是故障

短期權杖以小時計，長期權杖以天或月計，系統使用者權杖可以設定成不過期。但「不過期」不等於不會失效：授權的那個人被移除權限、離職被踢出 BM、或是那個廣告帳戶被停用，權杖當下就不能用了，而且不會有人通知你。

所以程式那一端要先假設權杖會壞。實務上的差別只在你是「某天早上發現廣告沒跑」還是「當下就收到一則告警」，而這兩者的成本差很多。

權杖的權限不會比人大

這是最常被誤會的一件事：權杖能做的事，等於授權它的那個人在 BM 裡能做的事。

所以權杖不是繞過權限的捷徑。一個對廣告帳戶只有分析師權限的人，他授權出來的權杖也只讀得到資料，改不了廣告。反過來說，權杖外流等於那個人的權限外流，這是要把權杖當密碼保管的原因。

四、「權杖可以用買的嗎」

可以買到東西，但買到的跟你以為的不一樣。

賣的是帳號，不是權杖。 權杖是你拿到帳號之後自己建 App 產生的，而且會過期。沒有人能賣你一串長期有效的權杖，那不是這個系統的運作方式。

你買到的是「一組已經註冊過開發者、而且驗證過的個人 FB 帳密」。 換句話說，那是第一層的商品，只是那顆號多了一個開發者角色。

買之前先確認你是不是真的需要

大部分人不需要。判斷只有一句話：你要不要用程式操作廣告？

你要做的事	需要開發者帳戶嗎
在廣告管理員建廣告、看成效	不需要
用 Excel 或後台匯出報表	不需要
安裝像素、接轉換 API	像素不需要；轉換 API 需要一組權杖
用程式自動建立幾百組廣告	需要
做給客戶用的投放工具	需要，而且要送 App Review

前兩列涵蓋了九成的投放者。 如果你是自己投自己的廣告，開發者帳戶這條線可以完全不碰。

要不要送審，官方規則寫得很清楚

一句話：只給「在這個 App 上有角色的人」使用，不需要 App Review；要給沒有角色的第三方使用，才要送審。

自己投自己的廣告屬於前者，所以不用送審。真正需要送審的是「你做一個工具給別人用」。

另外，Marketing API 的存取分級在 2026 年 5 月 4 日改過名字：原本的 Ads Management Standard Access 改叫 Marketing API Access Tier，下層從 Standard Access 改叫 Limited Access，上層從 Advanced Access 改叫 Full Access。上層的門檻是過去 15 天有 500 次以上 API 呼叫，且最近 500 次的錯誤率低於 15%。

這段的意思是：門檻是「用量與品質」，不是「有沒有買到對的帳號」。 沒有任何一筆消費能讓你升一級，賣家也做不到，因為條件是你自己的呼叫量與錯誤率。

買來的開發者帳號，風險在哪

風險	為什麼
身分不是你的	原持有人握有申訴管道，帳號可能被取回
驗證關卡隨時會回來	平台要求上傳證件時，你沒有那個人的證件
App 綁在那顆號上	號沒了，App 與所有權杖一起失效
連坐	那顆號如果還有別的用途，一處出事全部受影響

第三列最容易被低估。 你把自動化程式寫好、接上線，整條流程就綁在一顆你控制不了的號上。那顆號哪天要求驗證身分，你的程式當天停擺。

我們自己的目錄裡沒有這一類

2026 年 9 月 11 日查我們目錄的即時資料，Facebook 類共 50 個顯示群組，價格帶 10 到 80 USDT。型態分布是帳號 15 組、老號 13 組、粉絲專頁 12 組，接著是個人號與自註冊號各 3 組、廣告帳號 2 組，接碼服務與直播推廣各 1 組。

50 組裡沒有一組是權杖或開發者帳號。 那不是缺貨，是我們不收這一類：交付的當下看起來沒問題，但它的失效條件不在買賣雙方手上，客訴會在三個月後回來。

同一張表還有一個可以拿來對照的數字：粉絲專頁 12 組、廣告帳號只有 2 組。市場願意為粉絲專頁備貨六倍，因為廣告帳戶自己開得出來，粉絲專頁的信任分要靠時間。你缺的那一層是哪一層，市場的備貨量會先告訴你。

已經買了一顆，怎麼降低風險

買都買了，這幾件事現在做還來得及：

第一，不要把任何你在意的資產掛上去。那顆號拿來當「跑 API 的執行者」就好，粉絲專頁、BM、廣告帳戶全部留在你自己的個人帳號底下，用權限把它請進來，不要把擁有權交出去。第二，能改用系統使用者權杖的地方就改掉，讓那顆號只剩「建 App」這一個用途，哪天它掉了你損失的是一個 App，不是整條營運線。第三，把它當成會在任何一天消失的東西來寫程式：權杖過期、權限被撤、帳號被要求驗證，三種都要有對應的失敗處理，而不是在噴錯的那天才開始想。

真的需要程式那條路的話，最短路徑

假設你確定要用程式跑（例如一天要建幾百組廣告、或要接轉換 API），不必買任何東西，順序是這樣：

先用你自己的個人帳號登入開發者後台、建一個 App，把 Marketing API 這個產品加進去。接著回到你自己的 BM，在「系統使用者」那裡建一個系統使用者，指派它對目標廣告帳戶的權限，然後從那裡產生權杖。程式拿這一組權杖去打 API，全程沒有第三方帳號、沒有 App Review，因為使用者只有你自己。

這條路會卡住的地方只有一個：你在那個 BM 裡的角色不夠。權限不足時 API 回的錯誤訊息通常長得像設定錯誤，於是人會回頭一直改 App，改一整天。先確認角色，比什麼都快。

五、從症狀往回推，比從名詞往下猜快

真正實用的不是背定義，是看到症狀能指出是哪一層：

你看到的	卡在哪一層	去哪裡處理
登入被要求驗證身分	個人帳號	被檢查點卡住時怎麼辦
建廣告時選不到粉絲專頁	粉絲專頁	先建立或取得一個粉絲專頁
開不了第二個廣告帳戶	BM 額度	BM3 / BM50 的差別
廣告建得出來但發布失敗	廣告帳戶	廣告帳號是什麼
不知道從哪開始按	廣告管理員介面	廣告管理員完整導覽
API 回 permission 相關錯誤	權限或 App	先看授權的那個人在 BM 裡是什麼角色

最後一列的除錯順序值得記一下： API 報權限錯誤時，九成不是 App 設定錯，是「授權的那個人本來就沒有那個權限」。先去 BM 看角色，比去改 App 設定快。同一個順序也適用在前面幾列：症狀出現在哪一層，就先去那一層看設定與權限，不要從最遠的那一端開始拆。

六、第一次要準備什麼

如果你是從零開始，需要的是三樣東西，開發者帳戶不在裡面：

1. 一個個人 FB 帳號（買來的要先養，見前 7 天養號）
2. 一個粉絲專頁（廣告的刊登身分，沒有它發不出去）
3. 一個 BM 加一個廣告帳戶（BM3 對新手就夠）

這三樣配起來才跑得動，缺一樣前面買的都用不上。第一次買第一次投放包會比單買省事，不是因為便宜多少，是因為它已經把「缺哪一層」這件事處理掉了。

完整的第一支廣告流程在Facebook 廣告投放完整指南。

一句話總結

只有一個根，三條線。 個人帳號是根，粉絲專頁給你刊登身分，BM 裝廣告帳戶，開發者帳戶只是同一個人的另一個角色，用來開程式那條路。九成的人不需要第三條線；需要的人，要的通常也是 BM 裡的系統使用者權杖，不是一顆買來的開發者帳號。

---

資料來源（官方頁面查證於 2026-09-11）。文中標為「實測回報」的內容來自投放社群的公開討論與我們自己的工單，不出自這些頁面：

• Meta 技術的存取權杖 — Meta for Developers — developers.facebook.com
• 應用程式開發 — Meta for Developers — developers.facebook.com
• App Review 介紹 — Meta for Developers — developers.facebook.com
• Update to Ads Management Standard Access: New Name, Revised Requirements, and More Transparency（2026-05-04）— Meta for Developers — developers.meta.com
• 建立及管理商家資產管理組合 — Meta 商家使用說明 — facebook.com