2023年下半年，我接手了一个美国站的账号组。当时是4个店铺、7个广告账户，月广告花费在8万美元上下。接手第一周，我花了整整三天做一件很笨的事：把四个店铺后台的广告报表逐个导出成CSV，再用VLOOKUP拼到一张总表里，只为了回答老板最常问的那句话，这个月钱到底花到了哪些SKU上，赚没赚回来。
三天之后我得出一个结论：不是我不熟练，是这套管理方式本身就有问题。店铺数量一旦超过两个，亚马逊广告后台的管理颗粒度就会开始和你作对。这篇文章不讲工具功能清单，只讲我在多店经营里到底怎么管"亚马逊软件"这件事，以广告管理为核心，把店铺、SKU、预算、利润串成一条真正能用来决策的线。
如果把多店经营的所有管理动作拆开看，真正需要跨店铺横向比较的只有三件事：钱花在哪里、货卖给谁、利润还剩多少。这三件事里，唯一同时具备"跨店铺、跨SKU、跨时间"三个维度、又能做到按天更新的数据，就是广告数据。
广告数据是多店经营里性价比最高的管理抓手，没有之一。销售数据告诉你结果，库存数据告诉你约束条件，只有广告数据同时回答了"你为什么得到这个结果"以及"你还能不能改"这两个问题。
我见过太多团队把顺序搞反了：先买工具，再想办法让工具去适应自己已有的报表。结果是每个店铺一套算法，ACOS、TACOS、广告销售占比这三个指标，在不同人的表格里能算出四个不同的数。
正确的顺序应该是：先确定指标定义，再选承载这些定义的软件。软件管理的第一原则不是"管软件"，而是管住数据口径。口径统一了，用Excel也能跑；口径不统一，买再贵的系统也只是一堆好看但没法用来决策的图表。
我的经验是把所有软件塞进三层：数据源层、加工层、决策层。数据源层负责把亚马逊后台、广告后台、ERP、物流系统的数据捞出来；加工层负责清洗、对齐口径、计算派生指标；决策层负责把结果变成看板、预警和待办动作。
绝大多数卖家的工具栈是"功能堆"：听说某个工具能自动调价就买，听说另一个能做关键词挖掘也买，最后七八个系统各自为政，没人负责把它们连起来。多店经营真正缺的不是功能，而是连接。
一个店铺的时候，决策和执行可以是同一个人。到四个店铺、七个广告账户的时候，如果所有预算调整都要等总部拍板，前线就失去了响应速度；如果完全放手让各店运营自己定，资源又会往"自己店好看"的方向倾斜，而不是往"公司整体利润最高"的方向倾斜。
解决这个矛盾靠的不是制度文件，而是一套能被所有人看到的同一份数据。当每个运营都能在同一张表上看到自己店铺的TACOS、边际ACOS和利润贡献，分散执行反而会自然收敛到公司目标上。数据透明本身就是一种管理手段。
为了写这篇文章，我把手上账号组2023年10月到2024年6月的数据做了一次回溯整理。样本是6个店铺、11个广告账户、约1,800个在售SKU，其中实际投放广告的SKU大约420个，主力类目是家居与户外。这是单一样本观察，不具备行业统计意义，但方向性参考价值是有的。
大多数卖家的扩张路径是这样的：先开美国站，跑通了再开第二个店做差异化选品，然后欧洲站、日本站陆续跟上。每个新店铺都会带来新的广告账户、新的支付方式、新的时区和新的报表口径。
到第四个店铺的时候，一个典型场景会出现：北美和欧洲的日报时间是错开的，运营早上看欧洲数据、下午看美国数据，等到发现某个SKU的广告在烧钱，已经过去12个小时以上。多店管理的第一个失控点从来不是选品，而是广告响应速度。
我做过一次粗略的时间记录，把广告相关的工作按类型拆开，连续记了四周。结果和我原本的直觉差别很大：我以为最耗时间的是"调策略"，实际上真正占大头的是数据搬运。
四周加起来是160小时，其中超过一半花在了数据汇总和复盘汇报上。也就是说，团队里最贵的人，有一半时间在做机器该做的事。这是我决定动手改工具栈的直接原因。
很多人会问：亚马逊广告后台不是已经有跨账户的管理入口了吗，为什么还要外部工具？答案在于原生能力有三条边界，短期之内很难绕过。
第一条边界是数据口径。广告后台里的归因窗口、销售归属规则，和你的ERP、财务口径天然不一致，官方不会帮你做对齐。
第二条边界是指标派生。TACOS、边际ACOS、广告贡献利润这类指标，后台不会直接给，需要你自己用广告数据和销售、成本数据算出来。
第三条边界是动作闭环。后台能告诉你数据，但不能替你生成待办、不能按你的规则推送给对应的人、不能沉淀历史决策记录。
这三条边界决定了：无论你是否使用外部软件，只要店铺超过三个，你就必须自己定义一套口径和一套流程。软件只是把这套定义固化下来的容器。
下面的五个误区，不是我凭空总结的，是我在带团队和做咨询的过程中，至少在三个以上的账号组里反复见到过。每一个都对应着可以量化的损失。
ERP擅长的是订单、库存、采购、财务，它的数据模型是围绕"货"和"钱"建的。广告数据的核心是"流量"和"转化路径"，两者在SKU粒度上能对上，但在时间粒度、归因逻辑、数据结构上都对不上。
我见过一个团队，用ERP里的销售数据反推广告效果，得出的结论是某个SKU"广告很赚钱"，因为销售额涨了。实际情况是那个SKU当期上了秒杀活动，广告只是搭了顺风车。用ERP管广告，最大的风险不是数据不准，而是因果误判。
ACOS低不等于广告健康。一个成熟期的爆款，ACOS做到8%很正常；一个新品期的测试款，ACOS做到80%也可能完全合理。单看ACOS会得出两个错误结论：该加投的不敢加，该砍的舍不得砍。
正确的判断顺序是先看TACOS，再看边际ACOS，最后才看单品ACOS。TACOS告诉你广告在整体销售中的位置，边际ACOS告诉你下一美元投进去还能不能赚，单品ACOS只在需要定位到具体广告组的时候才有意义。
同一个SKU在美国站跑得好的打法，换到德国站大概率会失效。原因不只是语言，还有搜索词结构、竞争密度、客单价接受度和退货率的差异。我做过一次对比：同一款产品，美国站的转化率是12.4%，德国站只有7.1%，但德国站的客单价高出约23%。
这意味着在美国站该抢排名、把流量做宽，在德国站反而应该收紧流量、保住转化。策略复制失败的根源，是把"打法"当成了独立于市场的变量。
广告后台的归因窗口通常是7天或14天，意味着今天看到的广告销售数据，未来两周还会继续变化。用今天的数据下结论、明天就大幅调预算，等于在和统计噪音搏斗。
我给自己定过一条规则：任何超过20%的预算调整，必须基于至少连续7天的稳定数据，并且在调整后保留3天的观察期。这条规则执行之后，因为"手抖"造成的无效调整至少减少了一半。
自动化出价工具能做的事，是在你给定的目标下找更优解。它不能做的事，是告诉你目标本身定得对不对。我见过有人把自动规则设成"ACOS高于25%自动降竞价"，结果在大促期间自动把主力款竞价降到了竞品之下，排名掉出前三页，等发现时已经损失了两天的自然流量。
自动化是一把需要缰绳的刀。我现在的做法是：自动规则只允许做减法和保护动作（比如超支暂停、异常报警），不允许做加法和进攻动作。所有加预算、抢排名的动作，必须有人签字。
把上面这些误区对照一遍之后，我总结出一个四层模型。这四层不是工具的功能分类，而是管理动作的先后顺序，顺序错了，工具越强，错得越快。
在动任何数据之前，先把账户结构画出来：哪些是店铺级账户，哪些是品牌级账户，哪些是区域级账户，谁对谁有查看权限，谁对谁有操作权限。
结构没定清楚就接入数据工具，最典型的后果是重复计费：同一个广告活动被两个账户同时统计，预算看起来翻了一倍。我一般要求结构文档必须包含三个字段：账户ID、归属店铺、上级账户。这份文档是全套管理体系的地基。
口径层要回答的是"同一个词，在所有人嘴里是不是同一个意思"。我要求每个指标必须有一句话定义、一个计算公式、一个数据来源、一个更新频率。下面是我们团队实际使用的一份口径定义（以SQL形式固化）：
— 广告效率口径统一：店铺 × SKU × 自然周
SELECT
shop_id, — 店铺标识
sku, — SKU 编码
DATE_TRUNC('week', report_date) AS week, — 统计周
SUM(spend) AS ad_spend,
SUM(attributed_sales_14d) AS ad_sales_14d,
SUM(total_sales) AS total_sales,
ROUND(SUM(spend) / NULLIF(SUM(attributed_sales_14d), 0), 4) AS acos,
ROUND(SUM(spend) / NULLIF(SUM(total_sales), 0), 4) AS tacos,
ROUND(
(SUM(total_sales) – SUM(cogs) – SUM(spend) – SUM(fba_fee))
/ NULLIF(SUM(total_sales), 0), 4
) AS net_margin
FROM ads_daily
WHERE report_date >= DATE '2024-01-01'
GROUP BY 1, 2, 3;这段SQL本身没什么技术含量，价值在于它把"什么叫ACOS""用多长的归因窗口""利润算到哪一层"全部写死了。口径一旦落成代码，就不再依赖任何人的记忆和解释。
口径层解决"看什么"，执行层解决"看到什么该做什么"。我的做法是给每个关键指标配一条明确的分界线，越线就触发动作，而不是靠人临场判断。
这五条规则看起来简单，但它们覆盖了我日常80%以上的广告决策场景。规则的价值不在于复杂，而在于执行时不需要再讨论。
复盘节奏是最容易做错的一层。很多团队每天都在看数据，但看的都是同一个粒度的东西，结果既没发现异常，也没调整结构。
我的建议是按三个时间粒度分工：日看异常（超支、断货、零转化），周看结构（广告组增减、预算在SKU间的分布变化），月看利润（TACOS趋势、广告贡献利润、各店铺利润率对比）。日粒度不讨论策略，月粒度不纠结单日波动，这是节奏纪律。
下面这部分是我自己的实操记录。我在2024年初开始把手上的账号组从"人工拼表"切换到以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为核心的数据中台方案，前后观察了六个月。这里只讲真实发生的变化，不讲功能罗列。
很多人搭数据中台的第一反应是从ERP或订单系统切入，因为数据量最大、最"像正经数据"。我的判断恰恰相反：应该从广告口径切入，因为广告是唯一一个每天都在产生新决策需求的数据源。
订单数据是结果，一个月看一次也不会出大问题；广告数据是过程，晚看一天就多烧一天的钱。先解决广告，团队的感知最强，推进阻力最小，也最容易拿到可见的收益。
我把整个过程分成四步，前后大约用了三周时间，其中大部分时间花在对齐口径而不是配置系统。
下面的数据来自我手上这个账号组，2023年10月到2024年6月，美国站为主。它不是行业统计，只是我自己的观察记录，列出来是为了让判断有据可依，而不是让你照搬。
| 观察指标 | 切换前（2023年10-12月） | 切换后（2024年4-6月） | 变化 |
|---|---|---|---|
| 跨店广告数据汇总耗时 | 约18小时/周 | 约3小时/周 | 下降约83% |
| 广告异常平均发现延迟 | 约36小时 | 约4小时 | 下降约89% |
| TACOS（六店加权） | 9.8% | 7.1% | 下降2.7个百分点 |
| 广告花费（美元/月） | 约8.4万 | 约8.1万 | 基本持平 |
| 广告贡献利润（美元/月） | 约12.0万 | 约14.5万 | 上升约21% |
最值得说的一点是：广告花费几乎没变，利润却涨了21%。这不是靠多花钱买来的增长，而是靠把原本浪费在低效SKU上的预算，挪到了真正能赚钱的地方。
第一版我做了七张看板，涵盖了从曝光到库存的所有维度。两周之后我发现，团队每天真正打开的只有一张。后来我把七张砍成三张，把最关键的五个指标放在最上面，使用率才起来。看板的价值和数量成反比。
第二周我改了一次归因窗口的设置，第三周又调整了成本口径，结果发现前后数据没法直接比较。教训是：口径一旦公布，至少要稳定运行一个完整月度周期再考虑调整。如果非要改，必须保留旧口径的历史数据以便对比。
接入完成不等于问题解决。我在第四周就发现，数据接进来了，但没有人按新的节奏去用。后来我强制规定：每周一上午的例会必须基于新看板开，不允许再用旧表格。这条规定才真正让系统活起来。工具上线是技术问题，用起来是管理问题。
下面按店铺数量和广告花费规模分成三个阶段。这不是行业通用标准，是我根据自己经手的几个账号组总结出来的经验分界，你可以对照自己的情况做调整。
这个阶段不要买任何重型工具。你的核心任务是把口径文档写出来，而不是把系统搭起来。用一张结构清晰的表格就能覆盖日常需求。
具体动作：先把ACOS、TACOS、广告销售占比三个指标的定义写清楚；再建立一个最少字段的周报模板，只保留SKU、花费、广告销售、总销售、毛利五列；每周花两小时做一次结构复盘，重点看该砍的和该加的各有哪些。
这个阶段是管理成本开始失控的临界点。人工拼表的边际成本开始超过工具成本，同时团队里开始出现分工，口径不一致的问题会集中爆发。
建议动作：引入一个能同时接入广告和销售数据的数据工具（这个阶段数跨境这类方案是比较合适的起点，因为它的强项正好是多店广告数据聚合和SKU级效率分析）；建立三层看板，日看异常、周看结构、月看利润；指定一个人作为口径负责人，所有指标定义的变更必须经过他。
这个阶段的关键词是"自动化"和"权限"。你已经不可能靠人肉盯住所有账户，必须把规则固化到系统里，同时把权限分清楚，避免一个人误操作影响全盘。
建议动作：把执行层的五条阈值规则全部配置成系统预警和自动动作，但保留加法动作的人工审批；建立店铺级的权限矩阵，运营只能操作本店广告，跨店预算调度权限收归负责人；每月做一次跨店利润对标，重点看同样SKU在不同店铺的广告效率差异。
| 阶段 | 核心痛点 | 优先动作 | 工具投入建议 |
|---|---|---|---|
| 1-2店 | 口径不统一，报表靠手工 | 写口径文档，建周报模板 | 不采购专业工具，用表格 |
| 3-5店 | 数据汇总耗时、异常发现慢 | 接入广告+销售数据，建三层看板 | 引入数据中台型方案，年费控制在3万-5万元 |
| 5店以上 | 权限混乱、决策延迟、规则执行不一致 | 规则自动化、权限矩阵、跨店对标 | 中台方案+规则引擎，年费8万-15万元 |
工具是死的，用工具的人是活的。我见过最有效的配置是三个角色：一个数据负责人（负责口径和系统）、若干店铺运营（负责本店执行）、一个广告策略负责人（负责跨店调度）。
三个角色的人数比例大约是1:3:1。数据负责人不需要懂广告策略，但必须懂数据逻辑；策略负责人不需要天天盯报表，但必须看得懂结构变化。多店团队的效率瓶颈通常不在运营人手，而在这个"翻译"角色有没有人担任。
选型这件事没有标准答案，只有取舍。下面四个取舍点是我被问得最多、也最容易纠结的地方。
自建的好处是完全贴合自己的业务逻辑，数据在自己手里；坏处是前期投入大、迭代慢、依赖开发人力。我粗略算过，一个能覆盖多店广告+销售+成本的数据中台，从零开发到稳定可用，至少需要25万到60万元的前期投入，以及持续的人力维护。
采购的边界很清晰：年费3万到15万元，两周到一个月上线，但总会有20%左右的需求需要你改变流程去适应它。
我的判断标准是：如果你的业务模型是行业里常见的亚马逊多店模式，采购；如果你的业务有大量非标流程（比如自建站和亚马逊混营、复杂的海外仓调拨），才考虑自建中台。
全自动的诱惑很大，但我现在的立场很明确：只在防守端全自动，进攻端必须留人。
防守端指的是超支暂停、异常报警、库存断货前暂停广告这类动作，它们的特点是错了影响可控、对了能避免损失。进攻端指的是加预算、抢排名、开新广告组，这类动作错了的代价可能是整月利润。让机器做防守，让人做进攻。
集中管理的好处是资源分配更理性，坏处是响应慢；分权的好处是响应快，坏处是容易各自为政。我的做法是"数据集中、执行分权"：所有的数据口径、看板、预算总额由总部控制，具体到某个SKU的竞价调整、否定词添加，由店铺运营自己决定。
关键不在于集中还是分权，而在于分权之后有没有统一的度量。只要度量统一，分权的风险是可控的。
不是所有SKU都值得精细化运营。我的经验是按广告花费排序，前20%的SKU通常贡献80%以上的广告花费，这部分必须做到关键词级别的日常监控；剩下的80%只需要做到SKU级别的周度监控，触发阈值再深入。
追求全SKU全关键词级别的精细化，投入产出比会迅速恶化。精细化要跟着钱走，而不是跟着SKU数量走。
如果你决定开始，不要一次性把所有事做完。下面这份清单是我实际用过两遍的顺序，按周推进，每周只做一件事，做完可以验证再进入下一周。
这一周不开任何工具，只做一件事：把ACOS、TACOS、广告销售占比、广告贡献利润四个指标的定义写下来，团队所有人确认。产出物是一份不超过两页的口径文档。
这一周最容易出问题的地方是"大家以为自己知道"。建议做法是让每个人先独立写一遍定义，再对照讨论，差异往往会超出预期。
第二周开始接入数据。顺序很重要：先接广告数据，验证账户完整性和金额准确性；再接销售数据，验证SKU对齐率；最后接成本数据，验证利润计算是否符合预期。
每一步都要做交叉验证，最直接的方法是用系统算出来的某个SKU的月度ACOS，去和广告后台手工核对。误差超过2%就说明口径有问题，必须停下来查清楚。
第三周上线日、周、月三张看板。日看板只放五个指标：店铺总花费、超支预警、零转化广告组、断货风险SKU、异常CPC。周看板放SKU级别结构变化。月看板放利润和各店对标。
千万不要在第一版就做十几张看板。我第一版做了七张，结果团队每天只打开一张。砍到三张之后，使用率反而上去了。
第四周的任务是把复盘节奏固定下来。我的做法是周一会、周三查、周五结：周一定策略方向，周三检查执行情况，周五做数据结账和下周计划。
这个节奏跑满一个月之后，你会发现团队讨论的内容发生了变化，从"这个数据是多少"变成"这个数据为什么这样"。前一个问题消耗时间，后一个问题创造利润。
回到最初那个问题：亚马逊软件怎么管。我的答案可能和很多工具测评文章不一样，你要管的不是软件，是决策链条的长度。
从数据产生到发现异常，从发现异常到做出判断，从做出判断到执行动作，这条链上每一个环节的延迟，都会直接变成利润的流失。软件的作用是把这条链缩短，而不是把功能堆高。
我自己的经验是：六个店铺、十一个广告账户，靠人工拼表的时候，链条长度大约是三天；建立广告数据中枢之后，缩短到了四小时以内。这中间省下的每一天，都是真金白银。
如果你现在只有一两个店铺，先把口径文档写出来，这件事今天就能做，不花钱；如果已经到了三到五个店铺，可以着手评估数据中台型方案，重点看它能不能把广告、销售、库存三份数据在SKU粒度上对齐；如果已经在五个店铺以上，那你要解决的就不是工具问题了，而是权限和节奏问题。
最后给一个判断标准：当你发现团队里最贵的那个人，每周有超过十个小时在导出、拼接和解释数据，而不是在做判断，那就是该动手换方式的时候了。
我手上三个站点五个店，每天早上第一件事就是开五个后台挨个下载报表，再粘到 Excel 里做透视表，光这一套就要一个多小时，还经常粘错行。也试过找人写脚本，但亚马逊接口一改就废。所以一直纠结：到底有没有必要上统一管理的软件，还是继续手工扛着？
能做，但有前提，核心不是软件而是数据口径。统一管理的第一步是确立唯一事实源：以广告后台导出的报告为准，按“店铺，站点，广告账户，广告活动，广告组，关键词/ASIN”六层结构落库，币种和时区必须统一，建议以站点本地时间为准再折算结算币种。
实操分三步走：第一步先跑通 API 授权，把 SP、SB、SD 三类广告报告拉到同一张宽表，至少回补 90 天数据，覆盖 7 天和 14 天两种归因窗口；
第二步做口径校验，随机抽 3 天，把软件里的曝光、点击、花费、订单、销售额和后台下载的报表逐项对齐，误差超过 1% 就先别用，八成是时区或归因窗口没对齐；第三步才谈自动化。判断要不要上，看两个数字：店铺数≥3 个，或者广告活动总数≥200 个，统一管理的收益才明显超过迁移和学习成本。
只有一两个店、单站点，后台加透视表反而更省钱。
我之前图省事开了全自动竞价，结果几个本来稳定出单的词被一路抬价，ACOS 从 25% 冲到 45%，一周多烧了几千美金，那之后我就把自动全关了。可纯手工又真的顾不过来，五个店的预算调整一天就是几十次。所以特别想知道，自动化的边界到底在哪？
分三层推进，千万别一上来就全自动。第一层是监控告警，只读不写：设置 ACOS、花费占比、预算消耗速度、零曝光、断货仍投放等阈值，异常推送到工作群，这层几乎没有风险，却能覆盖大部分救火场景。
第二层是规则型半自动，只对条件明确的对象生效，比如“连续 7 天点击≥30 且零转化”的关键词降价 20% 或暂停，“ACOS 低于目标值 60% 且预算在 18:00 前耗尽”的广告组加预算 20%，同时必须设单次调整幅度上限（建议不超过 20%）和每日调整次数上限。
第三层才是算法托管，而且要先划出 10%，20% 的预算池和人工组做 A/B，跑满 14 天归因窗口再比。判断标准不要只看 ACOS：要看 TACOS 和自然位排名有没有一起变好。如果 ACOS 降了、TACOS 没降、自然单也掉了，说明你砍掉的是有效流量，不是浪费。
我们团队 6 个人管 5 个店，一开始图方便共用一个大号，结果有次某个主力词的竞价被改高了一倍，谁也说不清是谁动的，开会互相甩锅。另外我也担心员工离职顺手把广告数据和客户信息带走。这种权限到底怎么设计才既好用又不失控？
按“最小权限加操作留痕”设计三层角色。执行层是运营和投手，只给到站点或店铺级的广告读写权限，看不到财务数据和账号主信息，所有敏感操作（改竞价、改预算、暂停广告）必须写日志，记录操作人、时间、字段的原值和新值。管理层看跨店铺汇总看板和异常告警，有审批权，比如预算调整超过 30% 需要审批。
老板和财务层只看结果指标，TACOS、总销售额、广告花费占比、库存周转，不碰具体操作。落地时还有四个硬要求：所有账号开启两步验证；员工账号用企业邮箱而不是个人邮箱；API 授权走子账号而不是主账号；离职当天在广告平台和软件两侧同步收回授权。
检验一个方案合不合格，就问一句“能不能导出某个运营过去 30 天的完整操作记录”，做不到的话，后面一定会扯皮。
老板问我上软件一年能省多少钱、多久回本，我当时只答得出“省了不少时间”，被追问就卡壳了。省时间不等于省钱，这个账我自己也没算明白。想找一个能拿到台面上说的算法，最好有具体口径。
用三个口径算，别用“感觉提效了”。第一是人力口径：上线前统计团队每周花在下载报表、合并数据、手工调价上的小时数，五个店的团队通常落在 15，25 小时每周，乘以人力成本，这就是可量化的节省上限。
第二是广告效率口径：用 TACOS（总广告花费除以总销售额）而不是 ACOS，因为多店经营里广告本来就会带动自然单；对比上线前后各 30，60 天，剔除同期促销和大促干扰，TACOS 下降 1，2 个百分点属于正常水平，若五个店月销 50 万美金，一个点就是 5000 美金。
第三是风险口径：误操作、超预算、断货仍投广告造成的损失，看上线后这类事故的次数和金额是否下降。回本判断：软件年费除以（人力节省加上 TACOS 改善带来的利润增量），小于 12 个月算合格，小于 6 个月可以考虑加购模块。
要提醒的是，如果团队只有一两个店，这个账通常算不过来，优先补人和理顺流程，比上系统更划算。
读者评论
文章说先口径再工具，这点认同。但小团队实际很难先定完整口径，往往是边做边改，等口径稳定了业务窗口也过了。我的做法是先把最痛的跨店日报用表格模板强行统一，能跑起来再谈系统。只是表格维护依赖人，一旦换人又得重来，这一点文章偏乐观了。
用ERP数据反推广告效果那个坑我踩过。秒杀期间广告ACOS看着很低，其实是自然流量和活动流量混在一起。后来把广告订单和自然订单分开看才明白。但完全剥离广告和自然单也做不到，亚马逊归因就那样，最后很多判断还是凭经验加小步测试。
自动化只做减法和保护、加法必须人签字，这个规则在成熟团队合理，但多店多时区时，人签字反而成了瓶颈。我们试过夜间超支自动暂停，第二天经常误杀测试组。后来改成只报警不暂停，由值班人判断。自动化边界确实难画，不是一句话能定死。