2024 年旺季前两周，一个做厨房小家电的卖家把周报发给我，让我帮他看一个问题：他的广告到底赚不赚钱。他手上有 7 个亚马逊店铺、覆盖 5 个站点，在跑的 SP、SB、SD 广告活动加起来 800 多个。报表上写着"整体 ACoS 26%"，看起来还挺健康。
但我让他把美国站和德国站分开看的时候，问题立刻出来了：美国站的 ACoS 是 22%，德国站是 31%，而那个 26% 是把两个站点的广告花费按当日汇率折算成人民币、销售额也折算成人民币之后加总算出来的。这个算法在财务上没错，在经营决策上是错的，因为德国站的 31% 里，有相当一部分是 VAT 在广告销售额口径上的差异，以及退货在 14 天归因窗口内的延迟体现。两边的口径根本不在一个平面上。
这不是个别现象。我接触过的多店卖家里，超过一半的人第一反应都是"我多开几个后台不就行了"，真正卡住他们的从来不是登录问题，而是数据模型问题、口径问题、时区问题、权限问题。这篇文章我想把"亚马逊多店经营下的广告管理软件方案"拆开讲清楚，讲我实际做过的设计、踩过的坑，以及不同规模卖家该怎么选。
在展开之前，我先把核心判断放在最前面。如果你只看一段，看这一段就够了。
很多卖家理解的"多店管理"是把 7 个店铺的账号密码放进一个密码本，或者用一个浏览器多开工具统一登录。这是操作层面的效率优化，价值有限，天花板也很低。真正有价值的是把 7 个店铺的广告数据落到同一套数据模型里，让"同一个指标在所有店铺里含义完全相同"。
这两件事的差别有多大？我做过的对比是：只做登录合并的团队，每周花在报表汇总和口径对账上的时间大约 16-18 小时；做了数据模型合并的团队，同样的工作量降到 2 小时以内，而且错误率从两位数百分比降到个位数。
如果你要自建或者深度定制广告系统，事实表的粒度必须是站点 × 店铺主体 × 广告类型 × 实体层级 × 当地日期。少任何一个维度，你后面一定会返工。
我见过最典型的返工案例，是一个团队一开始只按"店铺 × 日期"存广告数据，做了三个月发现需要看搜索词报告，而搜索词是挂在投放目标下面的，之前的数据全部要重新拉。亚马逊广告报表的历史数据拉取有窗口限制，重新拉三个月的数据花了整整一周，还漏了部分已经过期的数据。
投放能力是可以复制的，招一个有经验的运营，或者买一套投放建议工具，都能解决。但口径一致性没法外包，因为它取决于你自己对业务的定义：退货算不算扣减？品牌光环订单算不算广告归因？VAT 含不含在广告销售额里？
口径不统一的多店经营，规模越大越危险。因为你会用错误的汇总数字做预算分配决策，而错误的决策会被放大到所有店铺。
我的建议顺序是：先做"看得见"（数据自动汇总 + 看板），再做"管得住"（告警 + 人工确认的执行），最后做"自己跑"（规则自动执行 + 护栏）。跨过第二阶段直接做第三阶段的团队，我见过的失败率超过 70%，失败的典型症状是旺季某天某个店铺的广告预算被规则脚本连续下调 12 次，直接损失掉了类目排名。
要设计系统，得先把现状描述清楚。我把一个中等规模多店卖家的广告日常拆成时间轴，你会发现时间几乎都花在"搬运"和"对账"上，而不是"决策"上。
我跟着一个团队走过完整的早会流程。9 点到 10 点半，运营负责人做三件事：一是从 7 个店铺后台分别下载前一天的广告报表；二是把 7 份 Excel 的字段对齐（有的用"花费"，有的用"Spend"，有的用"广告投入"）；三是把数字贴进汇总表。
就在这个过程中，三个问题暴露出来了：
这三个问题都不难解决，但如果没有系统约束，它们会每天重复发生一次。
亚马逊广告后台的"昨日"是按站点所在时区计算的，不是按北京时间，也不是按 UTC。美国站按太平洋时间，德国站按中欧时间，日本站按日本时间，澳大利亚站按悉尼时间。这些时区之间的最大时差接近 19 小时。
这意味着当你在北京时间早上 9 点打开汇总表的时候，美国站的"昨日"数据还差大约 9 个小时才结束。如果你在这个时点拉数，美国站拿到的实际上是"前天"的完整数据和"昨天"的部分数据混在一起。
我在做数据模型时的处理方式是：事实表里存站点当地日期（stat_date），另存一个报表拉取时间（report_pulled_at）。所有分析口径一律按当地日期聚合，拉取时间只用于判断数据新鲜度和触发补拉。
亚马逊广告的归因窗口默认是 7 天，部分报表可选 14 天。这意味着用户今天点击广告、三天后下单，这笔订单会"回溯"计入三天前的广告数据里。
所以如果你在 T+0 拉取了昨天的数据，然后在 T+1 又拉取一次，你会发现同一个日期、同一个广告活动的销售额变了。这不是数据错误，是归因回填。
系统的设计要点是：历史数据必须支持幂等覆盖写入。我通常会在事实表上加一个 report_pulled_at 字段，然后用"同一主键最后一次拉取覆盖"的方式更新，同时保留一份原始快照用于审计。这个设计听起来简单，但如果没有从第一天做进去，后面想补是很难的。
多站点经营绕不开币种。我的经验是：事实表存原始币种金额 + 币种代码，汇总层才做换算。千万别在接入层就把所有金额换成人民币，因为汇率会变，历史数据一旦固化就永远算不出正确的历史汇率口径。
换算汇率我建议用固定来源（比如欧洲央行每日收盘价或者你财务用的结算汇率），并且把汇率日期规则写进口径字典：是取报表日期当天的汇率，还是取拉取当天的汇率。这两个选择在汇率波动大的月份能差出 2-3 个百分点。
多店经营的团队往往不是一个人管所有店。常见的分配方式是：每个店配 1-2 个运营，一个投放负责人横跨所有店，一个财务看汇总。
这要求系统在权限层做三档控制：店铺级可见性、指标级可见性、操作级可见性。运营只能看自己负责的店；投放负责人能看所有店但不能改财务口径；财务能看汇总但不能改广告出价。
如果是代运营或者服务商场景，权限还要再细一层：A 客户的店铺数据不能出现在 B 客户的看板里，这是商业信誉问题，不是技术问题。
这一节我讲的是我在实际项目中反复看到的错误判断。这些误区之所以顽固，是因为它们在 1-2 个店铺的规模下确实没问题，只有到多店铺、多站点之后才会暴露。
这是最普遍也最省事的理解。它的隐含假设是"我只要能看到所有店铺的数据，我就能管好"。
但看到和管住是两件事。当你有 7 个店铺、800 个广告活动时，"看到"本身就已经超出了人的工作记忆容量。你看到的是一堆数字，不是一组判断。
正确的理解是：多店管理的第一目标是让异常自己浮出来，第二目标才是让正常的部分自动运行。如果系统只能给你呈现所有数据，那它和一个更漂亮的 Excel 没本质区别。
这是我在开头提到的那个案例。加总不同站点的 ACoS，会掩盖掉三件事：
我的做法是：汇总结论只用于看趋势和总量，任何单点决策必须下钻到站点层级。看板上永远同时展示"总计"和"分站"，并且标注"总计口径仅用于趋势判断"。
这个问题非常隐蔽。很多人会把下载报表的当天日期当作数据日期写进表里，结果是同一天的销售业绩被记在了不同的日期上，环比和同比全部失准。
更麻烦的是跨时区：北京时间周一上午下载，美国站的数据实际归属是周日，日本站可能归属周一。如果用下载日期统一标记，两个站点的周维度数据会错位一天，月度汇总的时候偏差能到 3-5%。
用 Excel 宏做自动化调价，在小规模时确实能用。问题是它有三个硬伤：
我见过一个案例：某团队用 Excel 宏做分时调价，某天文件里多插入了一行，导致所有广告活动的出价被乘以了一个错误系数，等到第二天发现时，已经跑了 14 个小时。
这是我最想劝退的一件事。自动化调价的收益很直观，省人力、反应快，但它的风险是非对称的：调对了赚一点，调错了亏很多，而且亏的是广告花的钱加上错失的排名。
我的建议是走"影子模式"：规则先只输出建议，不实际执行，跑 2-4 周，对比"如果执行了会怎样"和"实际发生了什么"。等规则的准确率稳定在 80% 以上，再开放执行权限，并且必须带护栏。
讲完误区，我把它翻译成可落地的设计骨架。这套分层是我在多个项目里收敛出来的，五层，从下到上依次是接入层、模型层、指标层、策略层、权限层。
接入层要解决的是"数据怎么进来"。三个关键点：
亚马逊广告 API 能拿到大部分结构化数据，但有两个限制：一是速率限制，二是部分报表类型（比如搜索词报告）只能通过异步报表任务获取。所以设计上要同时支持两条通道：API 拉结构化数据，异步报表任务补搜索词和长周期数据。
不要设一个统一的"每天凌晨 2 点拉数据"。正确做法是按站点当地时间的次日凌晨错峰触发，比如美国站按太平洋时间次日 1 点、德国站按中欧时间次日 1 点。同时保留 T+0、T+1、T+3、T+7 四次拉取，用于归因回填。
API 失败是常态，不是异常。我的经验阈值是：单任务失败重试 3 次，指数退避；连续 3 个周期失败则触发告警到人。没有这个机制，你会遇到"看板上数据很正常，其实是三天前的老数据"这种最危险的情况。
这是整个系统里最难改的部分，一旦定错就要重来。我的建议是事实表粒度定为站点 × 店铺主体 × 广告类型 × 实体层级 × 当地日期，实体层级包括 campaign、adgroup、target、searchterm 四级，用 entity_level 字段区分，而不是建四张表。
CREATE TABLE fact_ads_daily (
stat_date DATE NOT NULL, — 站点当地日期
marketplace VARCHAR(8) NOT NULL, — US / DE / JP / UK
store_id BIGINT NOT NULL, — 店铺主体ID
ad_type VARCHAR(4) NOT NULL, — SP / SB / SD
entity_level VARCHAR(12) NOT NULL, — campaign/adgroup/target/searchterm
entity_id VARCHAR(64) NOT NULL,
parent_id VARCHAR(64), — 上级实体，用于上卷
impressions BIGINT,
clicks BIGINT,
cost_local DECIMAL(18,4), — 原始币种金额
currency VARCHAR(4),
attributed_sales_7d DECIMAL(18,4),
attributed_sales_14d DECIMAL(18,4),
attributed_orders INT,
report_pulled_at TIMESTAMP, — 拉取时间，用于幂等覆盖
PRIMARY KEY (stat_date, marketplace, store_id,
ad_type, entity_level, entity_id)
);
这个设计的关键决策点有三个：一是保留原始币种，二是保留两套归因窗口，三是用 parent_id 支持上卷。三个决策都会在后面某个时刻救你一命。
这是我认为多店经营中最被低估的一层。口径字典不是文档，是配置，应该被系统读取并作用于计算过程。
{
"metric": "ad_sales",
"display": "广告销售额",
"formula": "SUM(attributed_sales_14d)",
"attribution_window": "14d",
"currency_normalize": "CNY",
"fx_source": "ecb_daily_close",
"fx_date_rule": "report_date",
"timezone_basis": "marketplace_local",
"exclude": ["brand_halo_orders", "cancelled_after_14d"],
"owner": "ad_ops",
"last_reviewed": "2025-01-15"
}
把它做成配置而不是文档的好处是：当有人想改口径时，必须走审批，系统会记录谁在什么时候改了什么，以及改完之后哪些历史指标需要重算。
策略层的核心不是"能自动做什么"，而是"做错了会不会失控"。我推荐用声明式的规则 DSL，而不是写代码。
rule: budget_guard_us_kitchen
scope:
marketplace: [US, CA]
portfolio: "Kitchen-2025Q2"
ad_type: [SP]
condition:
metric: spend_pace_ratio # 已花费 / 预算 / 时间进度
op: ">"
value: 1.35
window: "today_rolling_6h"
action:
type: reduce_bid
target: campaign
ratio: 0.85
max_times_per_day: 1
guardrail:
min_bid: 0.35
exclude_campaigns: ["brand-defense-*"]
max_daily_spend_delta_pct: 20
audit:
require_approval: false
log_level: full
这段配置里有三个护栏值得单独说：max_times_per_day 防止同一活动被反复调整；min_bid 防止出价被压到无效区间；exclude_campaigns 保护品牌防守类活动不被误伤。最后一个特别重要，很多团队第一次做自动化就是被品牌词活动坑的。
权限的隔离粒度我建议按店铺主体划分，而不是按站点。原因是：一个店铺主体可能同时在多个站点销售，如果按站点隔离，会出现在同一个主体下数据被割裂的奇怪情况；而按主体隔离，天然对应"谁负责哪家公司"的管理现实。
另外，任何对外的看板（给老板看、给客户看、给财务看）都必须走单独的只读视图，不能直接暴露原始事实表。
讲完设计逻辑，我拿一个具体工具来落地。多店广告数据层这件事，我接触过的方案里，数跨境是比较贴合跨境电商场景的一类选择，它和九数云是同一套数据分析体系下的产品，官网在 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys 。我在实际项目里用过它做多店铺广告数据的汇总和看板，下面讲我看到的东西。
很多人选工具的第一反应是看功能列表：能不能自动调价、能不能做分时、能不能做智能选词。我的判断顺序正好相反，先看数据层能不能把多店铺广告数据稳定、可对账地拉进来，再看上层。
原因是：上层的功能是可以随时替换的，数据层一旦迁移成本极高。如果你在 A 工具里积累了 18 个月的口径化广告数据，换成 B 工具时这些数据带不走，你会损失掉所有同比、环比和长期趋势判断能力。
所以我的选型标准里，数据层的权重占到 60%，功能层占 40%。
从我的使用体感看，它在多店广告场景里主要承担三件事：
我更看重第三点。因为广告的最终检验标准不是 ACoS 好不好看，而是广告带来的增量订单，在扣掉广告费、退货、FBA 费用之后，还剩多少毛利。这需要广告数据和经营数据在同一个模型里算，这也是为什么我倾向于用一套完整的数据分析工具，而不是一个纯广告调价工具。
我做过一个小规模验证：3 个店铺主体，分别在美国站、德国站和日本站有投放，共 2 个主要站点（美、德），在跑的广告活动大约 120 个。
接入过程大致分四步：授权店铺、配置数据拉取周期、建立指标口径、搭建看板。前两步基本是标准化流程，半天内能跑通。真正花时间的是第三步，把三个店铺历史上各自习惯用的 ACoS 口径统一成一套。这一步花了我大约一天，主要是在确认退货和 VAT 的处理方式。
第四步搭看板又花了半天。我做的是最基础的三块：多店广告总览、单店下钻、异常预警。总览页只放六个指标：广告花费、广告销售额、ACoS、TACoS、广告订单占比、广告毛利。
我不想把任何工具说成万能的。以数跨境这类数据分析工具为例，它有三条明确边界，你在选型时必须心里有数：
工具能告诉你哪个广告活动在烧钱，但不能告诉你该不该关。关掉一个 ACoS 高但带自然排名提升的活动，可能是错的。这个判断依赖你对品类的理解，工具给不了。
广告毛利需要订单成本、FBA 费用、退货率等数据，这些数据如果本身不准，广告分析再精细也是空中楼阁。我见过太多团队在广告口径上抠到小数点后两位，但退货率用的是三个月前的估值。
这是最现实的一条。很多团队买了工具，最后只是把后台报表换成了一张更漂亮的看板，因为没人愿意花一天时间坐下来把口径写清楚。工具不能替你做这件事。
下面我按店铺规模给建议。判断标准不只是店铺数，还要看月广告花费和团队人数。
这个阶段我明确不建议做系统化建设。理由很简单：人的工作记忆足够覆盖这个规模，上系统的固定成本（时间成本和学习成本）大于收益。
你应该做的事只有两件：一是用 Excel 固定一张日报模板，把字段名和口径写死；二是每周花 1 小时做一次趋势回顾。模板里一定要写清楚"这个数字是从哪个站点、哪个报表、哪一天拉的"，这个习惯会在你扩张到 5 个店的时候救你。
这是最典型的"该上系统"的区间，也是投入产出比最高的区间。我的建议是：优先把数据层和看板搭起来，暂时不要碰自动化执行。
具体动作：接入所有店铺的广告数据源，建立一份不超过 20 个指标的口径字典，搭建 3 张看板（多店总览、单店下钻、异常清单）。这个阶段的目标是"每周省下 12 小时以上的人工汇总时间"，而不是"自动调价"。
到了这个规模，数据层就是基础设施，没有讨论空间。同时必须加两件事：权限隔离和审计日志。
代运营场景尤其要注意：客户的店铺数据必须物理或逻辑隔离，任何跨客户的数据混合都是重大风险。我在设计代运营看板时，会要求每个客户有独立的视图层，并且所有导出操作都记录操作人。
如果有自研能力，我的建议是自研策略层，采购或复用数据层。原因是数据接入的工程量很大且高度标准化，各种 API 版本、速率限制、报表类型、时区处理，自研这块投入产出比很低。而策略层才是你业务的差异化所在，值得自己写。
方案设计到最后，本质都是取舍。我把多店广告系统里最常见的四组取舍列出来，每组给出我的倾向和适用条件。
这组取舍没有标准答案，取决于你的决策类型。
| 决策类型 | 应该用哪套数据 | 原因 |
|---|---|---|
| 预算超支拦截 | T+0 小时级数据 | 准确性要求低，时效性要求极高，宁可误报不可漏报 |
| 出价调整 | T+3 数据 | 归因已回填 93% 以上，足以支撑大多数出价决策 |
| 周报与绩效 | T+7 数据 | 准确性优先，且需要所有站点口径完全对齐 |
| 年度复盘与预算分配 | T+30 数据 | 需要包含退货、结算价调整等最终数据 |
我的倾向是：把不同时效的数据分开放在不同看板上，并明确标注口径，而不是试图用一套数据满足所有决策。
统一口径是多店管理的价值来源，但过度统一会掩盖站点的真实差异。
我的处理方式是：计算口径统一，判断基准不统一。也就是说，ACoS 的算法在所有站点完全一致，但"什么算健康"的标准按站点分别设定。美国站可能 20% 算健康，德国站 30% 才算健康。系统里这两件事要分开存放。
我做过一个粗略的投入对比，供参考：
| 方案 | 初始投入 | 年度维护成本 | 灵活度 | 适用条件 |
|---|---|---|---|---|
| 纯手工 + Excel | 2-3 人天 | 约 12 人天/年 | 低 | 1-2 个店铺 |
| 采购数据分析工具 | 3-5 人天 | 订阅费用 + 约 5 人天/年 | 中 | 3-15 个店铺 |
| 自研数据层 + 策略层 | 25-40 人天 | 约 40 人天/年 | 高 | 10 个店铺以上且有技术团队 |
| 采购数据层 + 自研策略层 | 10-15 人天 | 订阅费用 + 约 15 人天/年 | 较高 | 有技术团队但不想重造数据层 |
我个人的倾向是第四种。数据层的本质是"把别人的 API 变更风险接过来"，这件事外包出去是合理的；策略层的本质是"把你的品类理解固化下来"，这件事自己写才有价值。
自动化的每一步都在放大你的判断。判断对了放大收益，判断错了放大损失。所以自动化程度应该和你对业务的把握程度成正比。
这个顺序不能颠倒。我见过太多团队因为跳步，在旺季把一年的广告预算在两周内烧掉一大截。
写到这里，我把这篇文章里我认为最值得记住的三个判断再强调一次，它们都不太符合直觉。
第一个判断：多店广告管理的核心矛盾不是"看不到"，而是"对不齐"。大多数人以为难点在于汇聚 7 个店铺的数据，其实汇聚技术早就成熟了，真正的难点在于让 7 个店铺的数字在同一张表里具有可比性。这件事 90% 靠人的定义，10% 靠工具。
第二个判断：越实时的数据，决策参考价值不一定越高。归因窗口的存在决定了 T+0 的数据天然是残缺的。把实时数据用在超支拦截上是对的，用在出价调整上就是错的。系统设计要按决策类型分配时效档位。
第三个判断：工具解决不了口径问题，但好工具会强迫你面对它。这也是我在评估以数跨境这类平台时最看重的一点，它把"必须先把口径写清楚"变成了一个绕不过去的步骤，而不是让你继续用一张看起来差不多、实际各算各的 Excel 糊过去。
接下来 30 天，如果你在 3 个店铺以上，我建议按这个节奏走：
多店经营最难的部分从来不是把店铺数量做多，而是在店铺变多之后，仍然能用一个统一的视角看清全局。广告管理只是这个问题最尖锐的一个切面，因为它每天都在花钱，而且花得很快。
先把口径对齐，再谈自动化。这个顺序错了，投入越多，亏得越快。
我们公司现在有8个亚马逊店铺，横跨美国、日本、德国三个站点，之前一直用一个共享的运营表格在管广告，谁都能改。上个月有个运营离职，把手里几个店铺的广告活动批量停了，我们两天后才发现。我现在想重新设计权限体系，但又怕切得太细导致主管看不到全局。
建议按“店铺 × 站点 × 角色”三层做数据域隔离，而不是单纯按人或按店铺一刀切。落地时在数据层给每条广告记录打上 store_id + marketplace_id 两个字段，账号侧建一张“人，店铺，角色”的多对多关系表，角色最少分四档：只读、运营、主管、管理员。
核心判断依据是亚马逊的授权本身就是店铺维度的，LWA 的 refresh token 是按店铺存的，所以从接入层开始就要以 store_id 为主键存 token 和限流队列，权限只是把这套天然隔离映射到界面上。
具体做法上，运营只对自己被授权的店铺有写权限（改预算、改竞价、暂停活动），主管对本部门店铺有汇总读权限但看不到别人店铺的明细花费流水，管理员才拿全局。
另外务必加两条硬约束：一是删除/暂停类操作全部走软删除并记录操作人、时间、变更前后值，二是批量操作（比如一次改 50 个活动的预算）强制二次确认并把单次影响金额上限做成阈值告警。我们后来把权限切完之后，误操作导致的损失基本归零，代价是新人上手大概多花半天理解权限模型，这个成本值得付。
我们之前用脚本每天凌晨拉一次广告数据，结果白天运营在后台手动调了预算，系统里第二天才看到，报表和实际完全对不上。后来想改成准实时，又频繁触发 API 限流，一个店铺超限把其他店铺的同步全拖垮了。
我的经验是分两条链路走，不要用一个频率打通所有数据。第一条是报表链路，用于归因和结算分析，用异步报表接口按天拉，同时开一个 30 天的滚动回溯窗口每天补数，因为亚马逊的广告归因会滞后，昨天的数据今天看经常还没跑完，只拉“昨天”会长期偏差 5%~15%。
第二条是状态链路，用于预算监控和自动规则，拉 campaign / ad group 层级的花费、预算、状态这类轻量指标，频率控制在 15~30 分钟一次就够了，真正的竞价和预算调整没必要做到秒级。
限流这一块，工程上关键是给每个店铺建独立的任务队列加令牌桶，单店铺并发压到 1~2，全局并发控制在 5~10，再按店铺权重分配配额，这样某个大店跑批也不会挤掉小店。
还有一个容易被忽略的点：所有写入都要用 lastUpdated 或 reportId 做幂等 upsert，否则补数任务重跑一次，报表里的花费就可能翻倍，我们早期就踩过这个坑，一个店铺的 ACOS 莫名其妙高了一倍，查了两天才发现是重复写入。
我们做多店之后，老板要求每周给一个“整体 ACOS”，我一开始是用所有店铺总花费除以总销售额算的。但做完发现日本站 ACOS 才 12%，美国站 35%，一平均变成 28%，看起来还行，实际上美国站是亏的。我到底该用哪个口径来做预算分配和团队考核？
混合 ACOS 不能直接用于考核，只能用于观察趋势。原因是不同店铺处在不同生命周期、不同站点的 CPC 和转化率差异很大，新品期 ACOS 40% 可能是健康的，成熟期 20% 可能就偏高了，把两者平均会同时掩盖问题和成绩。我建议做三层口径：第一层是店铺级 ACOS，只用于预算池分配和环比趋势判断；
第二层是广告活动级的目标 ACOS 区间，按活动类型定（比如品牌词防守 5%~10%，品类词拓量 25%~35%，ASIN 定投 30%~45%）；
第三层也是真正该拿来做考核的，是 SKU 级的盈亏平衡 ACOS，公式大致是（售价 − 采购成本 − 平台佣金 − FBA 配送费 − 头程摊分 − 其他费用）÷ 售价，算出来是多少，广告就最多烧到多少。
跨店铺统一看的时候，我建议用“花费、销售额、广告带来的利润”三件套代替单一 ACOS，再配合广告销售占比，这样能一眼看出哪个店铺是在用广告买增长、哪个是在用广告买亏损。我们后来按这个口径调整，把美国站几个低于盈亏平衡线的定投活动砍掉，整体花费降了 18%，总利润反而涨了。
我们团队从 3 个店铺做到 11 个店铺，一直在用第三方工具加手工 Excel 补。最近老板问要不要自己开发一套，说外面工具的规则引擎太死板，我想给出一个有依据的判断，而不是拍脑袋说“自研更灵活”。
我给一个可量化的判断线：店铺数少于 5 个且活跃 SKU 少于 500，直接买现成工具，自研的维护成本一定超过收益；5~20 个店铺，用“买 + 自建报表层”的混合模式最划算，也就是数据仍从工具里出，但把原始数据同步到自己的库做跨店口径统一和自定义看板；
超过 20 个店铺，或者你同时做多个市场、多币种，甚至跨平台（比如还做独立站或别的电商平台），自研才真正成立。
成本上心里要有数：一个最小可用版本（多店铺数据同步 + 报表 + 规则引擎 + 权限）大概是 2~3 个人做 3 个月，之后每年还要留出至少 1 个人力专门应对 API 变更和报表补数，这块是长期成本，不是一次性投入。更关键的是想清楚自研的收益点在哪，如果只是“看得更清楚”，那买工具就够了；
自研真正的价值在自动执行，比如跨店铺预算再分配（早上把低效店铺的剩余预算挪给高效店铺）、自动暂停连续 7 天花费超过阈值且零转化的关键词。只有当你需要跑的规则库超过 20 条、且这些规则必须跨店铺联动时，自研的 ROI 才算得过来。
读者评论
事实表粒度里加"站点×店铺主体"我理解，但"实体层级"具体切到哪一层文章没展开。搜索词挂在投放目标下，那曝光和花费是不是也要按同一层级冗余存一遍？不然汇总时又要重新关联。我踩过的坑是层级没定死，后面加了 SB 和 SD，字段全对不齐，重拉数据比重新建模还费劲。
代运营那句"A 客户数据不能出现在 B 客户看板"说得太轻了，这不是权限配置能兜住的。我们做过类似项目，真正出问题的是导出和截图这两个口子，系统里隔离得再干净，运营一份 Excel 发群里就全废了。另外投放负责人横跨所有店这个角色，权限给到操作级还是只读，不同客户接受度差别很大，得一个个谈。