ecom

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ecom -- Ecommerce Business Review Toolkit

ecom -- 电商业务复盘工具包

D2C ecommerce analytics system. The Python backend computes KPIs, runs health checks, and scores performance from order transaction data; you (Claude) interpret the numbers and write the human-readable report.
Input: Order transaction data only (CSV).
D2C电商分析系统。Python后端会基于订单交易数据计算KPI、运行健康检查并对表现评分;(Claude)负责解读数据并撰写人类可读的报告。
输入: 仅订单交易数据(CSV)。

Quick Reference

快速参考

CommandWhat it doesOutput
/ecom reviewFull business review (auto-selects periods from data)REVIEW.md
/ecom review 30dFocused on the last 30 daysREVIEW_30D.md
/ecom review 90dFocused on the last 90 daysREVIEW_90D.md
/ecom review 365dFocused on the last 365 daysREVIEW_365D.md
/ecom review [question]Answers a specific question from the dataInline response
One command. Two modes: full report or focused answer.

Command功能输出
/ecom review完整业务复盘(自动从数据中选择分析周期)REVIEW.md
/ecom review 30d聚焦过去30天的数据分析REVIEW_30D.md
/ecom review 90d聚焦过去90天的数据分析REVIEW_90D.md
/ecom review 365d聚焦过去365天的数据分析REVIEW_365D.md
/ecom review [问题]基于数据回答特定问题直接返回结果
一个命令,两种模式:完整报告或针对性问答。

Response Modes

响应模式

Mode 1: Full Review (default)

模式1:完整复盘(默认)

Triggered when: no natural-language question in the user's input. Output: REVIEW.md (or REVIEW_{PERIOD}.md for period-specific runs) following the full 6-part structure defined below.
Examples:
/ecom review
,
/ecom review 30d
,
/ecom review 365d
触发条件:用户输入中没有自然语言问题。 输出:REVIEW.md(若指定了分析周期则输出REVIEW_{PERIOD}.md),遵循下文定义的完整6部分结构。
示例:
/ecom review
/ecom review 30d
/ecom review 365d

Mode 2: Focused Query

模式2:针对性查询

Triggered when: user's input includes a natural-language question or topic. Output: inline conversational response (no file creation).
Examples:
  • "how was last month?" → extract from monthly_trend
  • "how was last year?" → 365d data
  • "how was Q4 last year?" → extract from monthly_trend
  • "how's retention looking?" → customer metrics focus
触发条件:用户输入包含自然语言问题或主题。 输出:对话式直接回复(不生成文件)。
示例:
  • "上个月表现如何?" → 从monthly_trend中提取数据回答
  • "去年表现如何?" → 使用365天数据
  • "去年第四季度表现如何?" → 从monthly_trend中提取数据回答
  • "留存情况怎么样?" → 聚焦客户指标

Query-to-Period Mapping

查询到周期的映射

Query patternData source
last 30 days
--period 30d
last 3 months / last 90 days
--period 90d
last year / this year
--period 365d
last month / specific month namefull run, extract from monthly_trend
Q1-Q4 / specific quarterfull run, extract from monthly_trend
Calendar-month questions ("last month", "January") use the 365d monthly_trend, NOT a 30d trailing window. Use
--period 30d
only when the user explicitly asks for "last 30 days".
Fallback when 365d coverage is unavailable: Calendar-month and quarter queries require 365d monthly_trend data. If 365d coverage is missing (data < 400 days):
  • Answer from the best available trailing window data
  • State that exact calendar-month/quarter breakdown is not available
  • Suggest running a full review for deeper analysis
monthly_trend limitation: no year-over-year comparison by month/quarter monthly_trend covers only the most recent 12 months. Comparing "Q4 this year vs Q4 last year" is not possible. Instead:
  • Present absolute values (revenue, orders) for the requested period
  • Calculate its share of annual revenue (seasonality concentration)
  • Compare against Q1-Q3 average for relative scale
  • Add 365d overall YoY growth rate as context
  • Do not mention the absence of YoY comparison (follow Handling Incomplete Data rules — omit what you can't measure)
If the query doesn't map to a clear period, run full (no --period flag) and answer from the most relevant data.
查询模式数据源
过去30天
--period 30d
过去3个月 / 过去90天
--period 90d
去年 / 今年
--period 365d
上个月 / 特定月份名称全量运行,从monthly_trend中提取数据
Q1-Q4 / 特定季度全量运行,从monthly_trend中提取数据
日历月相关问题("上个月"、"一月")使用365天的monthly_trend数据,而非30天滚动窗口数据。仅当用户明确要求"过去30天"时才使用
--period 30d
365天数据覆盖不足时的降级方案: 日历月和季度查询需要365天的monthly_trend数据。如果缺少365天数据覆盖不足(数据时长 < 400天):
  • 使用可用的最优滚动窗口数据回答
  • 说明无法提供精确的日历月/季度细分数据
  • 建议运行完整复盘以获得更深入的分析
monthly_trend限制:无法按月份/季度做同比对比 monthly_trend仅覆盖最近12个月。对比"今年第四季度 vs 去年第四季度"是不可行。 替代方案:
  • 提供请求时段的绝对值(收入、订单量)
  • 计算其占全年收入的占比(季节性集中度)
  • 与第一到第三季度的平均值做对比以体现相对规模
  • 补充365天整体同比增长率作为上下文
  • 不要提及缺少同比对比数据(遵循不完整数据处理规则——省略你无法衡量的内容)
如果查询没有对应明确的周期,运行全量分析(不加--period参数)并从最相关的数据中提取答案。

Focused Query Response Format

针对性查询响应格式

  1. Direct answer (2-3 sentences with key numbers from review.json)
  2. Supporting context (1-2 observations that add nuance — tensions, comparisons)
  3. One actionable takeaway (if warranted by the data)
Total: 10-30 lines. Headings, KPI tree, and Finding format are NOT required. Use whatever structure best fits the answer. For example, "what's the new vs returning split?" is clearest as a partial KPI tree. Apply the same data rules: all numbers from review.json only, match user's language. Do NOT create a REVIEW.md file.

  1. 直接回答(2-3句话,包含来自review.json的关键数据)
  2. 支撑上下文(1-2个补充细节的观察结果——矛盾点、对比数据)
  3. 一条可落地的结论(如果数据支持的话)
总长度:10-30行。不需要标题、KPI树和发现格式。使用最适合答案的结构即可。 例如,"新用户和复购用户的拆分情况如何?"用部分KPI树展示最清晰。 适用相同的数据规则:所有数字仅来自review.json,匹配用户的语言。 不要生成REVIEW.md文件。

Data Input

数据输入

Order transaction data (CSV). Each row = one order or line item.
Required columns:
  • Order ID, Order date, Customer ID (or email)
  • Revenue (after discounts, before tax/shipping)
  • Quantity, SKU/Product ID
  • Discount amount (if available)
bash
~/.claude/skills/ecom/bin/ecom review orders.csv --output <output-dir>
~/.claude/skills/ecom/bin/ecom review orders.csv --period 90d --output <output-dir>

订单交易数据(CSV)。每一行 = 一个订单或一个订单项。
必填列:
  • 订单ID、订单日期、客户ID(或邮箱)
  • 收入(折扣后,税费/运费前)
  • 数量、SKU/产品ID
  • 折扣金额(如有)
bash
~/.claude/skills/ecom/bin/ecom review orders.csv --output <output-dir>
~/.claude/skills/ecom/bin/ecom review orders.csv --period 90d --output <output-dir>

Workflow

工作流

Phase 1: Compute (Python)

阶段1:计算(Python)

bash
~/.claude/skills/ecom/bin/ecom review orders.csv --output <output-dir>
The engine internally:
  1. Period analysis -- computes KPIs for each time period (30d, 90d, 365d) with prior-period comparisons, decompositions, and trend detection.
  2. Health checks -- evaluates ~30 checks across Revenue, Customer, and Product. Each check produces a pass/watch/fail signal with severity weighting. These power the 🟢/🟡/🔴 markers in the KPI tree.
Output:
review.json
(or
review_{period}.json
for period-specific runs). See Schema section below.
bash
~/.claude/skills/ecom/bin/ecom review orders.csv --output <output-dir>
引擎内部执行:
  1. 周期分析 -- 计算每个时间段(30天、90天、365天)的KPI,包含上期对比、分解和趋势检测。
  2. 健康检查 -- 对收入、客户、产品三个维度的约30项检查。每项检查会产出带权重的通过/关注/失败信号,用于支撑KPI树中的🟢/🟡/🔴标记。
输出:
review.json
(如果指定了分析周期则输出
review_{period}.json
)。见下文的Schema部分。

Phase 2: Interpret (You -- Claude)

阶段2:解读(你 -- Claude)

  1. Read
    review.json
    (or
    review_{period}.json
    for period-specific runs)
  2. Load reference files on demand (see Reference Files below)
  3. Write REVIEW.md (or
    REVIEW_{PERIOD}.md
    ) following the Output Format below
Your job is to weave trends and diagnostics into one coherent story. Period analysis tells you where things are heading. Health checks tell you what's broken right now. The report combines both.

  1. 读取
    review.json
    (指定周期则读取
    review_{period}.json
  2. 按需加载参考文件(见下文参考文件部分)
  3. 按照下文输出格式撰写REVIEW.md(或
    REVIEW_{PERIOD}.md
你的工作是将趋势和诊断结果整合成连贯的业务叙事。 周期分析告诉你趋势走向,健康检查告诉你当前存在的问题,报告需要将两者结合起来。

review.json Schema

review.json Schema

This is the data contract between Python and Claude. Every field below is guaranteed to exist in the output. Claude reads this structure; Claude does NOT invent data that isn't here.
jsonc
{
  "version": "0.1.0",

  // --- Metadata ---
  "metadata": {
    "generated_at": "2026-03-05T18:00:00Z",
    "data_start": "2025-01-01",
    "data_end": "2025-12-31",
    "total_orders": 5784,
    "total_customers": 2765,
    "total_revenue": 1383651,
    "currency": "USD",
    "revenue_definition": "Net sales after discounts, before tax and shipping"
  },

  // --- Data quality warnings (empty array = no issues) ---
  "data_quality": [
    // Example entries (only present when issues detected):
    // { "type": "partial_period", "period": "2026-02", "days_with_data": 3,
    //   "message": "Latest month (2026-02) has only 3 days of data. MoM comparisons use prior complete months." }
    // { "type": "short_data_span", "days": 45, "message": "Data spans only 45 days..." }
    // { "type": "limited_data_span", "days": 200, "message": "Data spans 200 days (<1 year)..." }
  ],

  // --- Data coverage: which periods are available ---
  "data_coverage": {
    "30d": true,       // true if >=45 days of data exist
    "90d": true,       // true if >=120 days of data exist
    "365d": true       // true if >=400 days of data exist
  },

  // --- Period metrics (one block per available period) ---
  "periods": {
    "30d": {
      "summary": {
        "revenue": 98000,
        "revenue_change": -0.003,       // vs prior 30d
        "orders": 412,
        "orders_change": -0.03,
        "aov": 238,
        "aov_change": -0.001,
        "customers": 287,
        "customers_change": -0.05
      },
      "kpi_tree": {
        "new_customer_revenue": 38000,
        "new_customer_revenue_share": 0.388,
        "new_customers": 95,
        "new_customers_change": -0.08,
        "new_customer_aov": 400,
        "returning_customer_revenue": 60000,
        "returning_customer_revenue_share": 0.612,
        "returning_customers": 192,
        "returning_customers_change": -0.03,
        "returning_customer_aov": 312
      },
      "drivers": {
        "aov_effect": 1200,            // revenue change attributable to AOV
        "volume_effect": -1500,         // revenue change attributable to order count
        "mix_effect": 0                 // revenue change attributable to new/returning mix shift
      }
    },
    "90d": { /* same structure */ },
    "365d": {
      /* same structure as 30d (summary, kpi_tree, drivers) plus: */
      "repeat_purchase_rate": 0.38,   // only in 365d block
      "monthly_trend": [
        { "month": "2025-01", "revenue": 95000, "orders": 420, "aov": 226, "customers": 310, "new_customers": 180, "returning_customers": 130, "days_with_data": 31 },
        // ... only months with actual data (no zero-fill for future months)
        { "month": "2025-12", "revenue": 12000, "orders": 45, "aov": 267, "customers": 38, "new_customers": 10, "returning_customers": 28, "days_with_data": 3, "partial": true }
      ]
    }
  },

  // --- Health checks (powers 🟢/🟡/🔴 markers) ---
  "health": {
    "checks": [
      {
        "id": "monthly_revenue_trend",   // internal only, never expose
        "category": "revenue",
        "severity": "high",
        "result": "watch",              // pass | watch | fail
        "message": "MoM revenue growth: -3.8%",
        "value": -0.038,
        "threshold": 0.0
      }
      // ... more checks
    ],
    "top_issues": [
      // Pre-sorted by severity * impact. Max 10.
      {
        "id": "multi_item_order_rate",
        "category": "product",
        "severity": "high",
        "result": "fail",
        "message": "Multi-item order rate: 0.0%",
        "estimated_annual_impact": 77573
      }
      // ...
    ]
  },

  // --- Pre-computed action candidates ---
  "action_candidates": [
    {
      "action": "Introduce product bundles to increase multi-item orders",
      "source_check": "multi_item_order_rate",  // internal reference
      "severity": "high",
      "estimated_annual_impact": 77573,
      "timeline": "this_month"
    }
    // ... max 10 candidates, sorted by impact
  ]
}
这是Python和Claude之间的数据契约。下文所有字段都保证存在于输出中。Claude读取该结构,不能编造不存在的数据。
jsonc
{
  "version": "0.1.0",

  // --- Metadata ---
  "metadata": {
    "generated_at": "2026-03-05T18:00:00Z",
    "data_start": "2025-01-01",
    "data_end": "2025-12-31",
    "total_orders": 5784,
    "total_customers": 2765,
    "total_revenue": 1383651,
    "currency": "USD",
    "revenue_definition": "Net sales after discounts, before tax and shipping"
  },

  // --- Data quality warnings (empty array = no issues) ---
  "data_quality": [
    // Example entries (only present when issues detected):
    // { "type": "partial_period", "period": "2026-02", "days_with_data": 3,
    //   "message": "Latest month (2026-02) has only 3 days of data. MoM comparisons use prior complete months." }
    // { "type": "short_data_span", "days": 45, "message": "Data spans only 45 days..." }
    // { "type": "limited_data_span", "days": 200, "message": "Data spans 200 days (<1 year)..." }
  ],

  // --- Data coverage: which periods are available ---
  "data_coverage": {
    "30d": true,       // true if >=45 days of data exist
    "90d": true,       // true if >=120 days of data exist
    "365d": true       // true if >=400 days of data exist
  },

  // --- Period metrics (one block per available period) ---
  "periods": {
    "30d": {
      "summary": {
        "revenue": 98000,
        "revenue_change": -0.003,       // vs prior 30d
        "orders": 412,
        "orders_change": -0.03,
        "aov": 238,
        "aov_change": -0.001,
        "customers": 287,
        "customers_change": -0.05
      },
      "kpi_tree": {
        "new_customer_revenue": 38000,
        "new_customer_revenue_share": 0.388,
        "new_customers": 95,
        "new_customers_change": -0.08,
        "new_customer_aov": 400,
        "returning_customer_revenue": 60000,
        "returning_customer_revenue_share": 0.612,
        "returning_customers": 192,
        "returning_customers_change": -0.03,
        "returning_customer_aov": 312
      },
      "drivers": {
        "aov_effect": 1200,            // revenue change attributable to AOV
        "volume_effect": -1500,         // revenue change attributable to order count
        "mix_effect": 0                 // revenue change attributable to new/returning mix shift
      }
    },
    "90d": { /* same structure */ },
    "365d": {
      /* same structure as 30d (summary, kpi_tree, drivers) plus: */
      "repeat_purchase_rate": 0.38,   // only in 365d block
      "monthly_trend": [
        { "month": "2025-01", "revenue": 95000, "orders": 420, "aov": 226, "customers": 310, "new_customers": 180, "returning_customers": 130, "days_with_data": 31 },
        // ... only months with actual data (no zero-fill for future months)
        { "month": "2025-12", "revenue": 12000, "orders": 45, "aov": 267, "customers": 38, "new_customers": 10, "returning_customers": 28, "days_with_data": 3, "partial": true }
      ]
    }
  },

  // --- Health checks (powers 🟢/🟡/🔴 markers) ---
  "health": {
    "checks": [
      {
        "id": "monthly_revenue_trend",   // internal only, never expose
        "category": "revenue",
        "severity": "high",
        "result": "watch",              // pass | watch | fail
        "message": "MoM revenue growth: -3.8%",
        "value": -0.038,
        "threshold": 0.0
      }
      // ... more checks
    ],
    "top_issues": [
      // Pre-sorted by severity * impact. Max 10.
      {
        "id": "multi_item_order_rate",
        "category": "product",
        "severity": "high",
        "result": "fail",
        "message": "Multi-item order rate: 0.0%",
        "estimated_annual_impact": 77573
      }
      // ...
    ]
  },

  // --- Pre-computed action candidates ---
  "action_candidates": [
    {
      "action": "Introduce product bundles to increase multi-item orders",
      "source_check": "multi_item_order_rate",  // internal reference
      "severity": "high",
      "estimated_annual_impact": 77573,
      "timeline": "this_month"
    }
    // ... max 10 candidates, sorted by impact
  ]
}

Schema Rules

Schema规则

  • periods
    only contains keys for periods where
    data_coverage
    is
    true
  • All
    _change
    fields are proportional change vs prior period (e.g., 0.08 = +8%)
  • health.checks
    contains every check result;
    health.top_issues
    is a filtered/sorted subset (fail and watch only, max 10, sorted by severity × impact)
  • action_candidates
    are suggestions from Python; Claude refines, merges, and rewrites them in business language for the report
  • monthly_trend
    contains only months with actual order data (no zero-fill for future months)
  • monthly_trend
    entries with
    "partial": true
    have less than half the month's days with data
  • When
    data_quality
    is non-empty, mention relevant warnings in Data Notes

  • periods
    仅包含
    data_coverage
    true
    的周期键
  • 所有
    _change
    字段是相对上期的比例变化(例如0.08 = 增长8%)
  • health.checks
    包含所有检查结果;
    health.top_issues
    是过滤排序后的子集(仅失败和关注项,最多10条,按严重程度×影响排序
  • action_candidates
    是Python给出的建议;Claude需要优化、合并并改写为业务语言写入报告
  • monthly_trend
    仅包含有实际订单数据的月份(未来月份不补零)
  • monthly_trend
    中带有
    "partial": true
    的条目表示该月有数据的天数不足一半
  • data_quality
    非空时,在数据说明部分提及相关警告

Reference Files

参考文件

Load on-demand -- do NOT load all at startup.
Path:
references/
  • review-narratives.md
    -- Narrative templates by health level and growth trajectory, finding templates, period-specific guidance. Always load.
  • finding-clusters.md
    -- Cluster model for grouping related issues into themes. Load to identify themes.
  • recommended-actions.md
    -- Actionable recommendations per check with timeline and impact range. Load for watch/fail checks.
  • impact-formulas.md
    -- Revenue impact formulas with worked examples. Load when estimating impact.
  • health-checks.md
    -- Check definitions (R/C/P) with thresholds and interpretation.
  • benchmarks.md
    -- D2C ecommerce KPI benchmarks.

按需加载 -- 不要启动时全部加载。
路径:
references/
  • review-narratives.md
    -- 按健康等级和增长轨迹划分的叙事模板、发现模板、特定周期指导。始终加载。
  • finding-clusters.md
    -- 用于将相关问题分组为主题的聚类模型。识别主题时加载。
  • recommended-actions.md
    -- 每个检查项对应的可落地建议,包含时间线和影响范围。关注/失败检查项时加载。
  • impact-formulas.md
    -- 收入影响公式及示例。估算影响时加载。
  • health-checks.md
    -- 检查项定义(R/C/P)包含阈值和解读说明。
  • benchmarks.md
    -- D2C电商KPI基准数据。

Output Format: REVIEW.md / REVIEW_{PERIOD}.md

输出格式:REVIEW.md / REVIEW_{PERIOD}.md

The following structure applies to Full Review mode only. See Response Modes for Focused Query.
One report. Three parts. Target: ~150 lines. Tighter is better.
以下结构仅适用于完整复盘模式。针对性查询见响应模式部分。
一份报告包含三部分。目标:约150行。 越简洁越好。

Report Construction Checklist (MANDATORY)

报告构建检查清单(强制要求)

Before writing, verify your report contains ALL sections in this exact order. Missing or reordered sections are a format violation.
  1. Executive Summary -- narrative blockquote (4-6 lines) + Scoreboard table
  2. 30d Pulse section (if data available) -- KPI tree + max 1 finding
  3. 90d Momentum section (if data available) -- KPI tree + drivers + max 2 findings
  4. 365d Structure section (if data available) -- KPI tree + drivers + max 3 findings
  5. Action Plan -- max 5 items grouped by time horizon + Guardrails
  6. Data Notes -- 2-4 lines
Structural rules:
  • Sections MUST appear in this order. Do NOT reorganize by theme.
  • Period sections MUST use the KPI tree format with emoji markers.
  • Do NOT create standalone sections like "What's Working Well" or "Issues to Address".
  • Positive signals belong in Executive Summary narrative and KPI tree markers.

撰写前,确认你的报告严格按顺序包含以下所有部分。缺失或顺序错误属于格式违规。
  1. 执行摘要 -- 叙事块引用(4-6行)+ 记分板表格
  2. 30天动态部分(如有数据) -- KPI树 + 最多1项发现
  3. 90天趋势部分(如有数据) -- KPI树 + 驱动因素 + 最多2项发现
  4. 365天结构部分(如有数据) -- KPI树 + 驱动因素 + 最多3项发现
  5. 行动计划 -- 按时间范围分组的最多5项 + 防护栏
  6. 数据说明 -- 2-4行
结构规则:
  • 部分必须按此顺序出现。不要按主题重新组织。
  • 周期部分必须使用带emoji标记的KPI树格式。
  • 不要创建独立的部分如"做得好的地方"或"需要解决的问题"。
  • 正面信号属于执行摘要叙事和KPI树标记。

Part 1: Executive Summary

第一部分:执行摘要

Narrative (4-6 lines, blockquote)

叙事(4-6行,块引用)

Synthesize across all available periods. Structure:
[North Star result + trend across periods]
[What's working: 1-2 strengths confirmed by data -- 80/20 rule]
[What needs attention: the key tension/risk, with data]
[Most important action, with timeline]
Example:
Revenue reached $1.38M for the year (+25.7% YoY), but growth is decelerating -- the last 90 days grew only 8% vs prior 90 days, and last month was flat (+0.3%). Growth depends on existing customer AOV increases (+14.8%), while new customer acquisition has stalled (share: 42.3%, unchanged). Reallocate 20% of retention budget to acquisition channels by end of this month, targeting CPA below $XX.
综合所有可用周期的数据。结构:
[北极星指标结果+跨周期趋势
[做得好的地方:1-2个数据确认的优势 -- 遵循80/20规则]
[需要关注的点:关键矛盾/风险,附数据]
[最重要的行动,附时间线]
示例:
全年收入达到$1.38M(同比增长25.7%),但增长正在放缓 -- 过去90天相对上一个90天仅增长8%,上个月持平(+0.3%)。 增长依赖现有客户AOV提升(+14.8%),而新客户获取停滞(占比:42.3%,无变化)。本月底前将20%的留存预算重新分配到获客渠道,目标CPA低于$XX。

Scoreboard

记分板

          30d Pulse     90d Momentum    365d Structure
Revenue   $98K (= flat) $340K (+ 8%)    $1.38M (+ 26%)
Orders    412 (- 3%)    1,280 (+ 5%)    5,784 (+ 10%)
AOV       $238 (= flat) $266 (+ 12%)    $239 (+ 15%)
Customers 287 (- 5%)    812 (+ 3%)      2,765 (+ 10%)
+
improving,
-
deteriorating,
=
stable. Only show periods that data supports.

          30天动态     90天趋势    365天结构
收入   $98K (= 持平) $340K (+ 8%)    $1.38M (+ 26%)
订单量    412 (- 3%)    1,280 (+ 5%)    5,784 (+ 10%)
AOV       $238 (= 持平) $266 (+ 12%)    $239 (+ 15%)
客户数 287 (- 5%)    812 (+ 3%)      2,765 (+ 10%)
+
提升,
-
下降,
=
稳定。 仅展示数据支持的周期。

Part 2: Period Sections

第二部分:周期部分

CRITICAL: Each period gets its own heading and its own KPI tree. Do NOT merge periods into thematic sections.
All periods use the same skeleton. But they are not equal length:
PeriodDepthFindings capRole
30d PulseShallow -- KPI tree + 1-2 sentences + max 1 finding1Flag fires only
90d MomentumMedium -- KPI tree + drivers + max 2 findings2Main analytical body
365d StructureDeep -- KPI tree + drivers + max 3 findings3Strategic narrative
If only one period is available, give it the full depth (3 findings).
The total across all periods must not exceed 5-7 findings. If a theme appears in multiple periods, state it once at the most structural level and reference supporting signals from shorter periods.
关键:每个周期有独立的标题和独立的KPI树。不要将周期合并到主题部分。
所有周期使用相同的框架。但长度不同:
周期深度发现上限作用
30天动态浅 -- KPI树 + 1-2句话 + 最多1项发现1仅标记紧急问题
90天趋势中 -- KPI树 + 驱动因素 + 最多2项发现2主要分析主体
365天结构深 -- KPI树 + 驱动因素 + 最多3项发现3战略叙事
如果只有一个周期可用,给它完整深度(3项发现)。
所有周期的发现总数不得超过5-7项。 如果一个主题在多个周期出现,在最具结构性的层级表述一次,并引用更短周期的支撑信号。

Skeleton

框架

[Period Name]: [One-line headline -- the "so what"]
[周期名称]:[一行标题 -- "核心结论"]
KPI Tree:
Revenue $X (vs prior period: +X%)
|-- 🟢 New Customer Revenue $X (X% of total)
|   |-- New Customers: X (+X%)
|   |-- New Customer AOV: $X (+X%)
|-- 🟡 Existing Customer Revenue $X (X% of total)
    |-- Returning Customers: X (+X%)
    |-- Returning AOV: $X (+X%)
    |-- Repeat Purchase Rate: X% -- first-to-second purchase conversion (365d only)
🟢 healthy / 🟡 watch / 🔴 problem (driven by health check results).
Growth Drivers (1-2 sentences, 90d and 365d only):
Was the change volume-driven or price-driven? Connect to KPI tree nodes.
Findings (within period cap):
Each follows Finding Quality Standards. Findings should weave trend data and health check diagnostics together, not present them separately. Use this format:
KPI树:
收入 $X (相对上期: +X%)
|-- 🟢 新客户收入 $X (占总比X%)
|   |-- 新客户数: X (+X%)
|   |-- 新客户AOV: $X (+X%)
|-- 🟡 现有客户收入 $X (占总比X%)
    |-- 复购客户数: X (+X%)
    |-- 复购AOV: $X (+X%)
    |-- 复购率: X% -- 首次到二次购买转化率(仅365天有)
🟢 健康 / 🟡 关注 / 🔴 问题(由健康检查结果驱动)。
增长驱动因素(1-2句话,仅90天和365天有):
变化是由量驱动还是价驱动?关联到KPI树节点。
发现(在周期上限内):
每一项都遵循发现质量标准。发现应该将趋势数据和健康检查诊断结合起来,不要分开呈现。使用此格式:

[Finding title]

[发现标题]

What is: [1 sentence, quantitative fact]
Why it matters: [Data-backed tension with "however"/"despite"/"but"]
What to do: [Direction only — 1 sentence. Details go in Action Plan.]

现状: [1句话,量化事实]
重要性: [数据支撑的矛盾点,用"然而"/"尽管"/"但是"]
行动方向: [仅方向 -- 1句话。细节在行动计划中。]

Part 3: Action Plan (unified, max 5 items)

第三部分:行动计划(统一,最多5项)

Hard cap: 5 action items. Exceeding 5 is a format violation.
Action Plan is the single source of truth for deadlines and success metrics. Findings point to the problem and direction; Action Plan specifies the execution.
One list synthesizing across all periods. Group by time horizon:
Immediate (from 30d signals)
1. ...

This Month (from 90d findings)
2. ...

This Quarter (from 365d insights)
3. ...
For each item:
  • What (one concrete sentence)
  • Why (reference specific data)
  • When (specific deadline)
  • Success metric (measurable)
End with (REQUIRED -- omitting Guardrails is a format violation):
Guardrails: [2-3 metrics that must not deteriorate while executing above actions]
Example: AOV must stay above $X | Repeat purchase rate must not drop below X% | Discount rate must stay under X%

硬上限:5项行动。超过5项属于格式违规。
行动计划是截止日期和成功指标的唯一来源。发现指向问题和方向;行动计划明确执行细节。
一个综合所有周期的列表。按时间范围分组:
立即(来自30天信号)
1. ...

本月(来自90天发现)
2. ...

本季度(来自365天洞察)
3. ...
对于每一项:
  • 内容(一句具体的话)
  • 原因(引用具体数据)
  • 时间(具体截止日期)
  • 成功指标(可衡量)
结尾必须包含(强制要求 -- 省略防护栏属于格式违规):
防护栏: [2-3个执行上述行动时不能恶化的指标]
示例:AOV必须保持在$X以上 | 复购率不得低于X% | 折扣率必须保持在X%以下

Data Notes (2-4 lines)

数据说明(2-4行)

Always include:
  • Revenue definition (from
    metadata.revenue_definition
    )
  • Data period and order count
  • Periods included/omitted

始终包含:
  • 收入定义(来自
    metadata.revenue_definition
  • 数据周期和订单数
  • 包含/省略的周期

Period Interaction Rules

周期交互规则

  • Confirm or contradict across periods. Don't let periods exist in isolation.
  • Zoom in: If 90d shows a break, check 30d for continuation.
  • Never repeat a finding across periods. State once at the structural level.
  • Executive Summary synthesizes, does not summarize sequentially.

  • **跨周期验证或矛盾验证。不要让周期孤立存在。
  • 向下钻取: 如果90天显示异常,检查30天是否延续。
  • 不要跨周期重复发现。 在结构性层级表述一次。
  • 执行摘要综合,不要按顺序总结。

Finding Quality Standards

发现质量标准

Every finding follows: What is → Why it matters → What to do
  • What is: 1 sentence. Quantitative fact. No interpretation.
  • Why it matters: Data-backed tension. Must show contrast ("despite", "however"). Abstract concerns like "growth must be validated" are PROHIBITED.
  • What to do: Direction and rationale only — 1 sentence. Deadlines and success metrics belong in the Action Plan. "Consider", "improve", "optimize", "explore" are PROHIBITED.
Good:
What is:       Annual revenue grew 25.7% YoY.
Why it matters: However, despite a 25.4% reduction in discount rate, new customer
               revenue share remains at 42.3% -- growth depends entirely on
               existing customer AOV increases (+14.8%).
What to do:    Reallocate retention budget toward acquisition channels to diversify growth sources.
Bad (PROHIBITED):
What is:       Revenue grew 25.7%.
Why it matters: Rapid growth must be validated. <-- no data, no tension
What to do:    Consider improving acquisition. <-- banned verb, no deadline

**每项发现遵循:现状 → 重要性 → 行动方向
  • 现状: 1句话。量化事实。无解读。
  • 重要性: 数据支撑的矛盾点。必须体现对比("尽管","然而")。 禁止抽象担忧如"增长必须验证"。
  • 行动方向: 仅方向和理由 -- 1句话。截止日期和成功指标属于行动计划。禁止使用"考虑"、"改进"、"优化"、"探索"等词。
正面示例:
现状:       全年收入同比增长25.7%。
重要性: 然而,尽管折扣率降低了25.4%,新客户收入占比仍保持在42.3% -- 增长完全依赖现有客户AOV提升(+14.8%)。
行动方向: 将留存预算重新分配到获客渠道,以实现增长来源多元化。
负面示例(禁止):
现状:       收入增长25.7%。
重要性: 快速增长必须验证。 <-- 无数据,无矛盾点
行动方向:    考虑改进获客。 <-- 禁用动词,无截止日期

Handling Incomplete Data

不完整数据处理

  • Omit what you can't measure. No N/A, no empty sections.
  • Don't apologize. Never say "unfortunately..."
  • Shorter data = shorter report.
  • All gaps noted in Data Notes only.

  • 省略你无法衡量的内容。不要出现N/A,不要有空部分。
  • 不要道歉。永远不要说"不幸的是..."
  • 数据越短,报告越短。
  • 所有缺口仅在数据说明部分提及。

Language and Data Scope Rules

语言和数据范围规则

Language

语言

  • Write entire report in ONE language (match user's prompt/store language)
  • Data Notes follows same language as body
  • 整个报告用一种语言撰写(匹配用户提示/店铺语言)
  • 数据说明与正文语言一致

Data Scope: review.json Only

数据范围:仅来自review.json

  • All numbers MUST come from review.json or be derived from its values
  • Do NOT reference external sources (Shopify Analytics, GA, etc.)
  • If additional data would help, note as recommended investigation in "What to do"
  • PROHIBITED: "CVR from Shopify shows 2.1%" (CVR not in review.json)
  • ALLOWED: "Investigate CVR in Shopify Analytics to determine root cause"
  • 所有数字必须来自review.json或从其值派生
  • 不要引用外部来源(Shopify Analytics、GA等)
  • 如果需要更多数据,在"行动方向"中注明建议调查
  • 禁止:"CVR从Shopify显示2.1%"(CVR不在review.json中)
  • 允许:"在Shopify Analytics中调查CVR以确定根本原因"

data_quality Warnings

data_quality警告

  • When
    data_quality
    array is non-empty, mention relevant warnings in Data Notes
  • Do NOT present partial-month MoM as real performance signals

  • data_quality
    数组非空时,在数据说明部分提及相关警告
  • 不要将部分月的环比作为真实表现信号

Quality Gates

质量门槛

  • Never present numbers without interpretation
  • Always explain why, not just the value
  • Specific, actionable recommendations only
  • Business language, not jargon (explain terms on first use)
  • Connect related findings into systemic patterns
  • No internal check IDs in the report
  • No check counts in the report
  • No repeated findings across sections
  • Finding Quality Standards on every finding
  • Guardrails on every action plan
  • 80/20 rule: ~80% confirmation (builds trust), ~20% surprise (drives action)

  • 永远不要呈现没有解读的数字
  • 始终解释为什么,而不仅仅是值
  • 仅提供具体、可落地的建议
  • 使用业务语言,而非行话(首次使用术语时解释)
  • 将相关发现关联为系统模式
  • 报告中不要出现内部检查ID
  • 报告中不要出现检查计数
  • 不要跨部分重复发现
  • 每项发现都符合发现质量标准
  • 每个行动计划都有防护栏
  • 80/20规则: ~80%的确认信息(建立信任),~20%的意外发现(驱动行动)

Internal: Health Check Engine

内部:健康检查引擎

Each check returns pass / watch / fail. These power the 🟢🟡🔴 KPI tree markers. Check definitions in
references/health-checks.md
. Do NOT use numeric scores, letter grades, or percentage-based health ratings.

每项检查返回通过/关注/失败。这些支撑KPI树的🟢🟡🔴标记。 检查定义在
references/health-checks.md
中。 不要使用数字分数、字母等级或百分比健康评级。

Runtime

运行时

The skill uses a local Python runtime installed in
~/.claude/skills/ecom/.venv/
. Use the wrapper command:
bash
~/.claude/skills/ecom/bin/ecom review orders.csv --output <output-dir>
~/.claude/skills/ecom/bin/ecom review orders.csv --period 90d --output <output-dir>
Modules:
loader
,
metrics
,
decomposition
,
cohort
,
product
,
checks
,
report
,
review_engine
,
config
,
normalize
,
periods
.
该技能使用安装在
~/.claude/skills/ecom/.venv/
的本地Python运行时。 使用包装命令:
bash
~/.claude/skills/ecom/bin/ecom review orders.csv --output <output-dir>
~/.claude/skills/ecom/bin/ecom review orders.csv --period 90d --output <output-dir>
模块:
loader
metrics
decomposition
cohort
product
checks
report
review_engine
config
normalize
periods