shield_lock
JinDaGe
← Back to skills
extension
Category: Data & AnalyticsNo API key required

视频数据追踪

双平台(视频号+抖音)视频数据追踪，Excel解析→落库

personAuthor: user_d68814aehubcommunity
downloadDownload package

video-data-tracker — 双平台数据燃料供应商

定位：仅负责 Excel 解析、数据落盘、移交门禁，不直接调用复盘引擎。 v2.2 变更：头条/小红书已退出复盘体系，仅解析视频号+抖音。

⚙️ 工作区路径

默认工作区：<workspace> 若当前工作区不同，优先使用当前工作区路径下的 .workbuddy/data/ 目录。 以下所有路径引用 ${WORKDIR} 表示：当前工作区 → 默认工作区（fallback）

触发条件

  1. 用户提供 .xlsx 文件，且列头匹配以下平台特征：
    • 视频号：含「完播率」「推荐」「关注」
    • 抖音：含「完播率」「5s 完播率」「主页访问量」
  2. 用户明确指令：「把这个数据落盘到 tracking」「更新追踪数据」

执行流程

1. 确定文件路径

默认 tracking.json 路径：<workspace>/.workbuddy/data/tracking/video-performance.json，支持用户自定义。

2. 运行解析脚本

执行边界测试 → 解析合并 → 增量追加：

python3 <workspace>/.workbuddy/skills/video-data-tracker/scripts/test_boundary.py
python3 <workspace>/.workbuddy/skills/video-data-tracker/scripts/parse_and_merge.py ${tracking_path} ${excel_paths}

边界测试未全通过 → 终止，输出失败项，不追加数据。

3. 微型健康检查（读阈值文件）

解析成功后，读取 account-thresholds.json 执行快速校验：

  • 抖音：2s 跳出 ≥ 阈值文件 douyin.alarm_threshold.2s_drop → 标记 health_alert: "douyin_2s_high"
  • 视频号：完播 ≤ 阈值文件 wechat_channels.alarm_threshold.completion → 标记 health_alert: "wechat_completion_low"
  • 阈值文件不存在 → fallback 到内置告警默认值（与 alarm_threshold 对齐）：抖音 2s跳出≥35% / 视频号完播≤10%。阈值文件存在时优先使用 alarm_threshold 字段。

📝 阈值语义区分（R11 修复）：健康告警用 alarm_threshold（某项超标即标 health_alert）；复盘红线用 golden_threshold（见发布后复盘 E2 红线检查）。二者字段不同、用途不同，勿混用。

4. 匹配发布记录，移交 复盘向导

匹配前预处理（v2.1 新增）：

  1. 去除双方标题的「徐州」「君启」「小张哥说房」等品牌前缀
  2. 保留核心关键词（板块名/数据词/动词）
  3. 模糊匹配阈值：≥ 0.4（v2.1 放宽，原≥0.5）

📝 阈值语义区分（R10 修复）：此处 0.4 是**「tracking↔publish_log 发布记录匹配」阈值；脚本内 SIMILARITY_THRESHOLD=0.5 是「视频号↔抖音跨平台合并」**阈值。二者语义不同，勿混用。

  1. 日期窗口辅助：发布日 ±1 天内的记录优先匹配

  2. 读取 ${WORKDIR}/.workbuddy/data/publish_log.json

  3. 标题模糊匹配（含预处理）milestones.video_published != null 的记录：

✅ 匹配成功：

  1. 🔒 强制执行 Read publish_log.json
  2. 🔒 data_collected 原子写（与发布后复盘铁律 #5 一致，不再裸 Edit）：用 atomic_write.py 的 update_json_atomic 定位 "id": "${video_id}" 写入 "milestones.data_collected": "${当前ISO时间}"： 
    import sys
sys.path.insert(0, r"C:/Users/87800/.workbuddy/skills/post-publish-review/scripts")
import atomic_write
PLOG = r"<workspace>/.workbuddy/data/publish_log.json"
def patch(doc):
    for e in doc["entries"]:
        if e.get("id") == video_id:
            e.setdefault("milestones", {})["data_collected"] = data_collected_at
            return True
    return False
atomic_write.update_json_atomic(PLOG, patch)

2.5 🔒 performance 原子写回（P0-2 闭环命脉 · 仅对有效发布样本）： - 取本批匹配到的视频在 tracking/video-performance.json 中解析出的表现数据（视频号+抖音：views/likes/comments/shares/completion_rate/avg_watch_sec/follows）。 - 🔒 写回铁律：仅对 milestones.video_published 有值（或本步同步置位，见下）的条目执行；绝不为创作稿/定稿稿写 performance（否则污染 F6 训练集，违反 PUB-GATE）。 - 定位 "id": "${video_id}" → 用 atomic_write.update_json_atomic 原子写 performance，结构对齐 model_weights 消费格式： json "performance": { "shipinhao": {"views":, "likes":, "comments":, "shares":, "completion_rate":, "avg_watch_sec":, "follows":}, "douyin": {"views":, "likes":, "comments":, "shares":, "completion_rate":, "avg_watch_sec":, "follows":} } - 🔒 PUB-GATE 边界 case（"复盘数据了"=真发布信号）：若写 performance 时 milestones.video_published 为 null，视为用户已确认发布（等价于"已发布"），在 2.5 的同一 update_json_atomic 调用里同步将 milestones.video_published 置为 ${data_collected时间}（或用户提供的发布时间），再写 performance。→ 确保"已发布"/"复盘数据了"两种表述都落到 video_published=True ∧ performance≠∅，F6 才能吃到。 - ⚠️ 写回机制：performance 为结构化数据，必须走 atomic_write.py（与发布后复盘铁律 #5 一致）；调用示例： python import sys sys.path.insert(0, r"C:/Users/87800/.workbuddy/skills/post-publish-review/scripts") import atomic_write PLOG = r"<workspace>/.workbuddy/data/publish_log.json" def patch(doc): for e in doc["entries"]: if e.get("id") == video_id: e["performance"] = {"shipinhao": {...从 tracking 取...}, "douyin": {...}} if not e.get("milestones", {}).get("video_published"): e.setdefault("milestones", {})["video_published"] = data_collected_at return True return False atomic_write.update_json_atomic(PLOG, patch) - 验证：再次 Read 确认 performance 非空且 video_published 符合 PUB-GATE。 3. 验证：再次 Read 确认 data_collected ≠ null（步骤 2）且 performance 非空（步骤 2.5，若执行）。 4. 输出：「✅ 数据已入库 + data_collected 时间戳已写入，匹配到发布记录 ${video_id}：${title}，正在移交复盘门禁...」 5. 调用 复盘向导，传递参数： - trigger_source: "video-data-tracker" - video_id: "${video_id}" - title: "${title}" - health_snapshot: "${health_alert || 'normal'}" 6. 若 publish_log 中存在 reminder_id → 调用 automation_update mode="delete" 取消提醒

❌ 匹配失败（v2.1 候选列表 + 部分标记）：

  1. 列出前 3 个候选记录（按标题相似度排序 + 日期窗口 ±1 天优先）
  2. 输出候选列表格式： 
    ✅ 数据已入库（+${新增条数}条）
⚠️ 未自动匹配到发布记录。以下是发布时间接近的候选记录：
  1. ${video_id} | ${title} | 相似度 ${score} | 发布日 ${date}
  2. ...
  3. ...
请选择匹配的记录编号，或输入「跳过」：
  3. 用户选择 → 走 ✅ 匹配成功分支
  4. 用户跳过/无法确定 → 写入 milestones.data_collected: "partial_${时间}" + meta.match_status: "manual_confirm_needed"
  5. 输出：「数据已标记为待确认。稍后说「复盘 ${标题}」可手动触发」

示例（Few-Shot）

例1 · 标准正向（落盘 + 匹配 + 移交）

用户拖入抖音 xlsx。 执行：test_boundary → parse_and_merge 写入 tracking/video-performance.json → 读阈值做微型健康检查 → 标题预处理(去品牌前缀)+模糊匹配(≥0.4) publish_log → 写 milestones.data_collected(ISO) → 调用 复盘向导(trigger_source:"视频数据追踪" + video_id + title + health_snapshot) → 若有 reminder_id 则取消提醒。

例2 · 边界（匹配失败）

模糊匹配无高置信记录 → 列前 3 候选(相似度+日期窗口) → 用户选/跳过 → 跳过则写 data_collected:"partial_时间" + meta.match_status:"manual_confirm_needed"。

例3 · 禁止项

❌ 绝不直接调用 发布后复盘，所有复盘请求必须移交 复盘向导。 ❌ 不得修改复盘阈值，仅读取 account-thresholds.json 做健康检查。 ❌ 增量追加必须去重，不得覆盖已有数据。

🚨 联动说明

  • ❌ 不直接调用 发布后复盘，所有复盘请求必须移交 复盘向导
  • ❌ 不修改复盘阈值，仅读取阈值文件做健康检查
  • ✅ 仅负责数据落盘和移交，不做任何复盘逻辑
  • ✅ 增量追加时严格去重，不覆盖已有数据

版本记录

| 版本 | 日期 | 核心变更 | |------|------|----------| | v2.3 | 2026-07-16 | P0-2 闭环：匹配成功分支新增 performance 原子写回 + PUB-GATE 边界（video_published 同步置位）；data_collected 同步改 atomic_write；结构对齐 model_weights 消费格式 | | v2.2 | 2026-07-03 | 复盘平台瘦身：头条/小红书退出，仅解析视频号+抖音 | | v2.1 | 2026-06-28 | 候选匹配+预处理+data_collected强制写入+workdir可配置+阈值注释清晰化 | | v2.0 | 2026-06-24 | publish_log v2.0 适配 — 读取 milestones.video_published / 写入 milestones.data_collected | | v1.4 | 2026-06-24 | 微型健康检查阈值改为读取 account-thresholds.json | | v1.3 | 2026-06-24 | 移交时携带健康快照，辅助门禁快速识别故障 | | v1.2.1 | 2026-06-24 | 联动对齐，统一移交参数 | | v1.2 | 2026-06-24 | 重构触发逻辑，移交 复盘向导 而非直连引擎 | | v1.1 | 2026-06-19 | 新增自动触发复盘逻辑 | | v1.0 | 2026-06-12 | 初始版本，四平台解析合并 |