Files

T

blueming3andClaude Opus 5.5 012475ff71 docs(launch-watch): add 89109-1 and the launch-time lessons

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>

2026-09-30 20:35:31 +08:00

5.2 KiB

Raw Permalink Blame History

name, description, disable-model-invocation

name	description	disable-model-invocation
swads-minis-launch-watch	新户 Minis 冷启动开投后的盯盘:每 10 分钟一轮看全户、计划、主力广告,按四个真实户总结出的判断点提示该关、该等、该加还是该关户;同时记录生命周期(开投、起量、变差、干预、停投),停投或被罚时对照基准户写小结并沉淀经验。只经 swads MCP 网关读数,写平台一律等运营点名。运营开投后手动 /swads-minis-launch-watch 触发。	true

新户冷启动盯盘

盯的是刚开投的 Minis 户:从开投、起量、判断好坏、放量、收尾到关户,一整天。判断点全部来自 references/playbook.md(四个真实户:一个赚钱、一个开局就亏、两个被罚), 基准数据在 references/benchmarks.json。通用的 4 条规则盯盘是 swads-delivery-watch,那一份和服务端自动提案保持一致;这一份专门管冷启动,阈值不同,不要混用。

开始前问运营三件事

账户 id(external_account_id)。说不清就用 intake_list_accounts 列出来让他选。
实际开投时间(账户时区,精确到分钟)。已经开了就问几点开的;还没开就开完再来。阶段划分全靠这个时间,用计划的创建时间或原定时间都会算错。
工作目录,默认 ~/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。

停掉这个户的定时盯盘。
跑 scripts/summary.py --account <id> --date <开投日> --dir <工作目录>(隔天写就加 --window yesterday)。
按 references/summary-template.md 写小结给运营:结果、时间线、钱、广告、同生命周期对比、经验。
把这个户追加进 references/benchmarks.json,在运营的记忆里存一条这个户的生命周期; 阈值被推翻的改 playbook.md 和 watch.py。基准户越多,判断越准。

边界

只读数和给建议;平台写操作只做运营点名的那几个。
不改预算、出价、国家去「优化」;运营没说的都不动。
不帮忙规避平台审核或处罚:不改图「去重」,不换户继续跑被罚素材。

5.2 KiB Raw Permalink Blame History