管理多个 Meta 广告账户：代理商设置清单

要管理多个 Meta 广告账户，先为每个客户建立一份记录，写明其资产、获授权的操作人员和决策人。然后整理浏览器工作区，并判断是否真的存在单独的网络需求。出现故障时，先判断它是访问问题、选错了账户、安全事件还是限制，再去改动设置。

这份清单适用于在客户授权下管理客户账户的代理商。它提供一份可复用的私密客户记录，以及在操作人员无法继续时分配下一步行动的方法。

在配置工具之前先约定客户的控制权

每次合作都要约定：谁应控制这些资产、谁批准支出、谁负责恢复访问。我们的建议是保留客户希望拥有的控制权，同时只给代理商操作人员完成工作所需的访问权限。请在创建资产之前把这件事定下来：“以后再理清归属”的计划会让一个重要决定悬而未决。

Meta 关于业务资产组合的培训课程涵盖账户、用户和权限，其 Marketing API 文档也介绍了由多人以不同访问级别共同管理的广告账户。这些都是梳理合作关系的良好起点。下面的清单是我们推荐的运营记录，而不是 Meta 的官方表单。Meta Blueprint 资产组合课程，Meta Marketing API 文档。

为每个客户把这份记录复制到你的私密项目系统中：

• 客户和业务所有者：
• 业务资产组合 ID 和广告账户 ID：
• 本项工作所需的辅助资产：主页、Instagram 账户、数据集或目录 ID（视情况而定）。
• 客户方的访问与恢复负责人，以及备用联系人：
• 代理商的业务 ID：
• 指定的操作人员及已批准的任务：
• 账单决策人：
• 报表应用的所有者、已批准的权限和移除流程：
• 设备或工作区标签；如相关，网络负责人：
• 访问核查日期：日期及核查人。
• 离场负责人及目标日期：

不要在这份记录中保存密码、API 令牌、恢复码和支付卡号。资产 ID 和业务联系方式同样应放在具有适当内部访问控制的系统中。

在开始投放工作之前，让指定的操作人员将目标广告账户 ID 与实际选中的账户进行比对，并确认所需的操作可用。如果客户还没有任何现成设置，先约定记录中的归属和账单字段，再查看 Meta 中可用的创建选项。本清单不假定存在任何通用的账户数量上限。

让工作上下文一眼可辨

在工单和浏览器工作区中使用统一的客户标签。在修改广告系列或预算之前，先将选中的账户与工单核对。容易辨认的名称有帮助；当名称相似时，账户 ID 提供了可以核对的具体值。

Chrome 个人资料可以将书签、历史记录、密码和设置分开。它们是有用的整理工具，但 Google 提醒，能接触设备的人可以切换到其他个人资料。应把浏览器个人资料视为工作区，而不是设备访问控制的替代品。Google 关于 Chrome 个人资料的说明。

保护用于管理这些账户的身份和设备。Meta 建议启用双重验证、登录提醒并检查会话。其关于针对企业的恶意软件的报告还描述了针对与广告资产关联的个人账户的攻击，包括能够绕过双重验证的恶意软件。在计划中要把设备安全与身份验证放在同等位置。Meta 关于企业恶意软件的指南。

对于报表自动化，在客户记录中单独保留一条应用访问条目。Meta 的 Marketing API 有其自身的应用、访问令牌和权限要求；浏览器中已有的登录并不代表具备这种授权。明确谁拥有该应用、它需要做什么，以及合作结束时由谁移除访问权限。Meta Marketing API 文档。

判断网络变更是否有明确目的

VoidMob 关于 2026 年运营多个 Meta 广告账户的指南从供应商的角度介绍了账户组织和技术隔离，包括分开的浏览器和移动网络设置。在比较这些工作流时，它是有用的参考。对于代理商的实际落地，先写下网络变更要解决的具体问题。

例如，缺少账户分配应由授予访问权限的人处理。有文档记录且经过授权的网络测试需求则由技术负责人处理。IP 检查可以帮助描述一条路由；它并不能证明操作人员有权管理客户的资产。

还要区分独立设备和独占的公网地址。运营商级 NAT 可能让多个用户共享公网 IPv4 地址，因此仅凭专用硬件不足以证明独占使用公网 IPv4。这也说明不了 Meta 会如何评估某个具体账户。IETF RFC 6888。

如果确实存在路由需求，在选择基础设施之前，先定义目标地址、连续性要求和故障证据。我们的轮换代理与粘性代理指南解释了会话连续性方面的区别。对于选定的浏览器实现，MostLogin 代理设置指南介绍了具体配置。两者都不是完成客户访问记录的前提。

把问题交给能采取行动的人

把这张表当作建议的首次响应流程。它有助于收集证据和分配责任；它不能诊断所有原因，而且多个故障可能同时存在。

安全那一行采用了上文 Meta 的指南。其余的分配是我们的运营建议。请按实际收到的通知和可用的控制项处理，而不要假定每种限制都有相同的审核路径或结果。

实例：一名分析师，两个客户

设想两个虚构客户 Cedar Bikes 和 Harbor Home，由代理商的同一名分析师负责。Cedar 的广告账户可见；Harbor 的账户却不在账户选择器中。

下一步是将 Harbor 记录在案的账户 ID 和已批准的任务，与该分析师实际获得的分配进行比对。然后由获授权的客户方访问负责人修正不完整的授权。在核查完成之前，暂停 Harbor 的投放工作。仅凭这一现象，没有理由去购买代理或创建另一个账户。

现在换一个前提：Harbor 可见，但出现了一个无人认识的管理员。这属于安全那一行。上报给 Harbor 的恢复负责人，并保护受影响的身份和设备。仅仅重命名浏览器工作区，事件依然没有解决。

在离场时，使用同一份记录移除离开的操作人员或代理商的已批准访问权限，以及你所控制的任何应用凭据，然后确认客户指定的所有者仍保有访问权限。按照合作中约定的保留规定清除本地工作数据。记录由谁在何时完成了交接。

方法说明：ipvolt 根据 Meta 和供应商的文档以及一个虚构实例编写了这份清单。没有测试任何 Meta 账户、代理、浏览器个人资料或设备，本文内容也不描述 Meta 如何评估某个具体账户。

如果将来经授权的工作需要代理基础设施，加入 ipvolt 候补名单。目前尚未开放访问。开放时只发一封邮件，没有别的。

标签：ProxiesChoosing proxies