blueming3andClaude Opus 5.5
012475ff71
Sync from SW-ads-global: six benchmark accounts through 89109-1 (2026-09-30), playbook and watch.py thresholds updated to match. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
77 lines
5.2 KiB
Markdown
77 lines
5.2 KiB
Markdown
---
|
|
name: swads-minis-launch-watch
|
|
description: 新户 Minis 冷启动开投后的盯盘:每 10 分钟一轮看全户、计划、主力广告,按四个真实户总结出的判断点提示该关、该等、该加还是该关户;同时记录生命周期(开投、起量、变差、干预、停投),停投或被罚时对照基准户写小结并沉淀经验。只经 swads MCP 网关读数,写平台一律等运营点名。运营开投后手动 /swads-minis-launch-watch 触发。
|
|
disable-model-invocation: true
|
|
---
|
|
|
|
# 新户冷启动盯盘
|
|
|
|
盯的是**刚开投的 Minis 户**:从开投、起量、判断好坏、放量、收尾到关户,一整天。
|
|
判断点全部来自 `references/playbook.md`(四个真实户:一个赚钱、一个开局就亏、两个被罚),
|
|
基准数据在 `references/benchmarks.json`。通用的 4 条规则盯盘是 `swads-delivery-watch`,那一份和
|
|
服务端自动提案保持一致;这一份专门管冷启动,阈值不同,不要混用。
|
|
|
|
## 开始前问运营三件事
|
|
|
|
1. **账户 id**(`external_account_id`)。说不清就用 `intake_list_accounts` 列出来让他选。
|
|
2. **实际开投时间**(账户时区,精确到分钟)。已经开了就问几点开的;还没开就开完再来。
|
|
阶段划分全靠这个时间,用计划的创建时间或原定时间都会算错。
|
|
3. **工作目录**,默认 `~/minis-watch/<户名或账户尾号>`。同一个户每一轮都用同一个目录,生命周期记录在里面。
|
|
|
|
顺带确认:这个户用的素材有没有碰 `playbook.md` 的素材红线,尤其是被罚户用过的素材。碰了就先说清风险,
|
|
这比盯盘重要。
|
|
|
|
## 每一轮
|
|
|
|
```
|
|
python3 <skill 目录>/scripts/watch.py --account <id> --start "YYYY-MM-DD HH:MM" --dir <工作目录>
|
|
```
|
|
|
|
- 用 `/loop 10m` 或 `CronCreate`(`*/10 * * * *`)每 10 分钟跑一轮。它们只在会话开着、空闲时触发:
|
|
会话关了就不跑,忙的时候会迟到,漏掉的轮次要在汇报里说明。
|
|
- 脚本自己连 swads 网关:读 `SWADS_MCP_URL` / `SWADS_MCP_TOKEN`,没有就读 `~/.claude.json` 里的 `swads`
|
|
服务器配置。运营没配过 swads MCP 就先帮他配,token 不要写进任何文件。
|
|
- 输出第一部分是预警(可能为空),最后一行是状态行:阶段、今天合计、最近 30 分钟、消耗前三的计划、
|
|
数据截至几点,以及和基准户同阶段的累计 ROAS。
|
|
|
|
### 怎么转述
|
|
|
|
- 无预警:一句「一轮无异常,数据截至 HH:MM」+ 今天合计。起量后第一次出现广告行时,核对一下广告名
|
|
是不是「剧名 Ad N(图文/视频)」;全是数字 id 说明对不上,查 `watch.py` 的 `admap`。
|
|
- 有预警:逐条列,关停建议附广告 id 和依据(引 playbook 里的那一条、那个案例)。
|
|
- 状态行里有「按天数据落后」:以 TikTok 小时数为准,不要按旧数下结论,更不要报停量。
|
|
- `‼ 建议暂停关户` 开头的:放在最前面,说清是哪条健康度规则、现在亏多少,问运营关不关。
|
|
- 运营问「怎么办 / 哪些该留」:按最近 30 分钟每条广告的 ROAS 分成「留」(≥ 1)和「关」(< 0.8 且消耗 ≥ 10),
|
|
并按当前 ROAS 算出回到 0.9、回本各需要再花多少钱、大概几点;超过这个户「起量后 6 小时」的直接说不现实。
|
|
|
|
## 写平台:只在运营点名后
|
|
|
|
| 运营说 | 调用 | 之后 |
|
|
|---|---|---|
|
|
| 关这条广告 | `campaign_set_ad_delivery(campaign_id, external_ad_id, status="stopped", external_account_id)` | 看返回 `remote_status` |
|
|
| 关这个计划 / 关户 | `campaign_set_delivery(campaign_id, status="stopped", external_account_id)`,关户就逐个关所有在投计划 | `account_sync` 后读回计划状态 |
|
|
| 加预算到 N | `campaign_set_budget(campaign_id, daily_budget=N, external_account_id)` | 看 `changed`、`previous_daily_budget` |
|
|
|
|
- 加预算每次都单独确认金额;起量已满 5 小时还要加,先把 playbook 里「起量满 5 小时后加预算没赚到」告诉运营。
|
|
- 所有阶段都按这个户自己的开投、起量时间顺延,不套别的户的钟点(晚开的户不能按 18 点判衰退)。
|
|
- 批量关(「亏的都关」)先列出清单(广告名、id、消耗、ROAS)让运营点「好」。
|
|
- 每次写平台后,在工作目录的 `events.jsonl` 追加一行(`kind` 用 关广告 / 关计划 / 加预算 / 停投 / 方案),
|
|
写清是谁确认的、当时的数。运营定下的止损或收尾方案也记一行 `方案`。
|
|
- 工具报错原文转告,不重试绕过,不去读服务源码。
|
|
|
|
## 停投或被罚时:小结
|
|
|
|
触发:运营说关户、计划全部变停用、或出现 `ADVERTISER_ACCOUNT_PUNISH`。
|
|
|
|
1. 停掉这个户的定时盯盘。
|
|
2. 跑 `scripts/summary.py --account <id> --date <开投日> --dir <工作目录>`(隔天写就加 `--window yesterday`)。
|
|
3. 按 `references/summary-template.md` 写小结给运营:结果、时间线、钱、广告、同生命周期对比、经验。
|
|
4. 把这个户追加进 `references/benchmarks.json`,在运营的记忆里存一条这个户的生命周期;
|
|
阈值被推翻的改 `playbook.md` 和 `watch.py`。基准户越多,判断越准。
|
|
|
|
## 边界
|
|
|
|
- 只读数和给建议;平台写操作只做运营点名的那几个。
|
|
- 不改预算、出价、国家去「优化」;运营没说的都不动。
|
|
- 不帮忙规避平台审核或处罚:不改图「去重」,不换户继续跑被罚素材。
|