中级Agent Skill

产品数据分析

根据 CSV 用户活动资料开展同期群留存分析,并检查产品指标。这项 Skill 将指标框架与 Python 计算器结合起来,帮助团队把用户 ID、日期和阶段记录整理成留存表、同期群表及阶段人数,先看清变化发生在哪里,再决定产品体验中哪些环节值得进一步排查。

浏览量
0
复制次数
0
收藏
0
编辑评分
82/100
01

这个 Skill 是做什么的

Product Analytics 同时处理“应该衡量什么”和“怎样计算”。它提供 AARRR、北极星指标和 HEART 等参考,并配有可以检查输入与计算过程的代码,适合已有导出资料、需要统一分析方法的团队。

留存按日期偏移计算,比较同期群前要确认观察时间是否足够。漏斗函数统计的是各阶段用户数,不会验证事件顺序,也不会证明用户依次经过前面的步骤;如果问题涉及完整路径,应另用能够检查事件顺序的分析方式。

02

它有什么特色

01

方法与优势

先用指标框架把业务问题转成明确口径,再运行计算。统一用户识别方式、什么行为算活跃,以及观察时间范围,才能让不同报告中的留存表具有可比较的含义,避免数字相同却实际衡量了不同事情。

02

适用任务

Python 输出可以回到 CSV 输入核对,便于检查留存和阶段人数的来源。解读变化前先确认同期群是否成熟、阶段统计能说明什么,再决定要深入分析哪种行为,避免把不同阶段人数差直接当成路径流失。

03

安装前的特殊要求

需要准备的输入

一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。

Agent 与运行环境

使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。

需确认的适用边界

留存按天偏移计算,需检查同期群是否已充分观察。漏斗只统计各阶段用户,不校验事件顺序或递进关系,因此不是有序事件漏斗。

04

安装与开始使用

将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。

  1. 打开能访问本机文件和终端的 Codex 或 Claude Code。
  2. 复制下方指令发给正在使用的应用,由助手选择该应用的安装目录。
  3. 查看返回的安装路径和文件检查结果;需要时新建会话,再要求助手使用已安装的 Skill。
请在我当前使用的应用中安装 product-analytics,直接执行文件安装,不要只解释步骤。 原始仓库:https://github.com/alirezarezvani/claude-skills.git 固定提交:6d2f02ea077eead1bee5411a31bcc6db5a11a70c Skill 路径:product-team/skills/product-analytics 1. 将这个版本下载到新目录。执行随包脚本前,先阅读 SKILL.md 和安装参考文件,不替换成其他作者的包。 2. Codex 安装到 ~/.agents/skills/product-analytics,Claude Code 安装到 ~/.claude/skills/product-analytics,只安装到我正在使用的应用。安装完整 Skill 文件夹,保留 scripts、references、assets 和随包声明;将仓库根目录许可证一并保留。先检查所有目标目录;已有安装时,说明差异后再决定是否替换。 3. 比较来源和安装目录的文件清单、文件哈希,检查文档要求的运行时、依赖及外部连接。只配置此 Skill 所需的本地依赖,适用时使用隔离环境;账号登录由我在本地完成,不把凭据贴进聊天。 4. 返回来源提交、实际安装路径、文件检查结果及尚未完成的运行环境配置,说明如何调用 product-analytics。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。
05

原始 Skill.md

以下为已核对版本未经改写的 SKILL.md。安装完整包才能保留引用的脚本、素材和指引。下方启动提示词为 EcomAgentTools 编写的示例。

---
name: product-analytics
description: Use when defining product KPIs, building metric dashboards, running cohort or retention analysis, or interpreting feature adoption trends across product stages.
---

# Product Analytics

Define, track, and interpret product metrics across discovery, growth, and mature product stages.

## When To Use

Use this skill for:
- Metric framework selection (AARRR, North Star, HEART)
- KPI definition by product stage (pre-PMF, growth, mature)
- Dashboard design and metric hierarchy
- Cohort and retention analysis
- Feature adoption and funnel interpretation

## Workflow

1. Select metric framework
- AARRR for growth loops and funnel visibility
- North Star for cross-functional strategic alignment
- HEART for UX quality and user experience measurement

2. Define stage-appropriate KPIs
- Pre-PMF: activation, early retention, qualitative success
- Growth: acquisition efficiency, expansion, conversion velocity
- Mature: retention depth, revenue quality, operational efficiency

3. Design dashboard layers
- Executive layer: 5-7 directional metrics
- Product health layer: acquisition, activation, retention, engagement
- Feature layer: adoption, depth, repeat usage, outcome correlation

4. Run cohort + retention analysis
- Segment by signup cohort or feature exposure cohort
- Compare retention curves, not single-point snapshots
- Identify inflection points around onboarding and first value moment

5. Interpret and act
- Connect metric movement to product changes and release timeline
- Distinguish signal from noise using period-over-period context
- Propose one clear product action per major metric risk/opportunity

## KPI Guidance By Stage

### Pre-PMF
- Activation rate
- Week-1 retention
- Time-to-first-value
- Problem-solution fit interview score

### Growth
- Funnel conversion by stage
- Monthly retained users
- Feature adoption among new cohorts
- Expansion / upsell proxy metrics

### Mature
- Net revenue retention aligned product metrics
- Power-user share and depth of use
- Churn risk indicators by segment
- Reliability and support-deflection product metrics

## Dashboard Design Principles

- Show trends, not isolated point estimates.
- Keep one owner per KPI.
- Pair each KPI with target, threshold, and decision rule.
- Use cohort and segment filters by default.
- Prefer comparable time windows (weekly vs weekly, monthly vs monthly).

See:
- `references/metrics-frameworks.md`
- `references/dashboard-templates.md`

## Cohort Analysis Method

1. Define cohort anchor event (signup, activation, first purchase).
2. Define retained behavior (active day, key action, repeat session).
3. Build retention matrix by cohort week/month and age period.
4. Compare curve shape across cohorts.
5. Flag early drop points and investigate journey friction.

## Retention Curve Interpretation

- Sharp early drop, low plateau: onboarding mismatch or weak initial value.
- Moderate drop, stable plateau: healthy core audience with predictable churn.
- Flattening at low level: product used occasionally, revisit value metric.
- Improving newer cohorts: onboarding or positioning improvements are working.

## Anti-Patterns

| Anti-pattern | Fix |
|---|---|
| **Vanity metrics** — tracking pageviews or total signups without activation context | Always pair acquisition metrics with activation rate and retention |
| **Single-point retention** — reporting "30-day retention is 20%" | Compare retention curves across cohorts, not isolated snapshots |
| **Dashboard overload** — 30+ metrics on one screen | Executive layer: 5-7 metrics. Feature layer: per-feature only |
| **No decision rule** — tracking a KPI with no threshold or action plan | Every KPI needs: target, threshold, owner, and "if below X, then Y" |
| **Averaging across segments** — reporting blended metrics that hide segment differences | Always segment by cohort, plan tier, channel, or geography |
| **Ignoring seasonality** — comparing this week to last week without adjusting | Use period-over-period with same-period-last-year context |

## Tooling

### `scripts/metrics_calculator.py`

CLI utility for retention, cohort, and funnel analysis from CSV data. Supports text and JSON output.

```bash
# Retention analysis
python3 scripts/metrics_calculator.py retention events.csv
python3 scripts/metrics_calculator.py retention events.csv --format json

# Cohort matrix
python3 scripts/metrics_calculator.py cohort events.csv --cohort-grain month
python3 scripts/metrics_calculator.py cohort events.csv --cohort-grain week --format json

# Funnel conversion
python3 scripts/metrics_calculator.py funnel funnel.csv --stages visit,signup,activate,pay
python3 scripts/metrics_calculator.py funnel funnel.csv --stages visit,signup,activate,pay --format json
```

**CSV format for retention/cohort:**
```csv
user_id,cohort_date,activity_date
u001,2026-01-01,2026-01-01
u001,2026-01-01,2026-01-03
u002,2026-01-02,2026-01-02
```

**CSV format for funnel:**
```csv
user_id,stage
u001,visit
u001,signup
u001,activate
u002,visit
u002,signup
```

## Cross-References

- Related: `product-team/experiment-designer` — for A/B test planning after identifying metric opportunities
- Related: `product-team/product-manager-toolkit` — for RICE prioritization of metric-driven features
- Related: `product-team/product-discovery` — for assumption mapping when metrics reveal unknowns
- Related: `finance/saas-metrics-coach` — for SaaS-specific metrics (ARR, MRR, churn, LTV)
06

开始使用

以下是主要功能的用例提示词,可以直接复制使用。

01

为电商功能定义产品指标树

为电商功能定义产品指标树 适用于:为电商功能定义产品指标树。请准备:一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-analytics Skill。任务:为电商功能定义产品指标树。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。留存按天偏移计算,需检查同期群是否已充分观察。漏斗只统计各阶段用户,不校验事件顺序或递进关系,因此不是有序事件漏斗。

需要替换的变量

[INPUT]
一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
02

根据清洗后导出比较已成熟留存同期群

根据清洗后导出比较已成熟留存同期群 适用于:根据清洗后导出比较已成熟留存同期群。请准备:一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-analytics Skill。任务:根据清洗后导出比较已成熟留存同期群。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。留存按天偏移计算,需检查同期群是否已充分观察。漏斗只统计各阶段用户,不校验事件顺序或递进关系,因此不是有序事件漏斗。

需要替换的变量

[INPUT]
一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
03

检查阶段人数并单独校验漏斗顺序

检查阶段人数并单独校验漏斗顺序 适用于:检查阶段人数并单独校验漏斗顺序。请准备:一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-analytics Skill。任务:检查阶段人数并单独校验漏斗顺序。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。留存按天偏移计算,需检查同期群是否已充分观察。漏斗只统计各阶段用户,不校验事件顺序或递进关系,因此不是有序事件漏斗。

需要替换的变量

[INPUT]
一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
07

实际使用案例:从用户事件算出漏斗和有完整观察期的留存

输入两周经营汇总、8 人事件样本和明确分析截止日。任务是把订单/会话指标与用户漏斗分开,并只对已完成 D7 观察期的同期群计算留存。

使用步骤与 Prompt

  1. 准备下方案例输入资料,保留商品、政策和经营记录中的金额、单位及时间口径。
  2. 核对用户去重、事件定义和观察窗口,分析购买漏斗与成熟队列,把回访、关键动作和复购分别解释。
  3. 提交下方完整 Prompt,查看右侧主要产物;需要交接给同事时,下载包含全部交付文件的压缩包。

案例输入资料:business-inputs.zip

Use the product-analytics Skill.

Analyze our customer events, purchase funnel and weekly trading data. Deduplicate users, define conversion and observation windows, calculate the main funnel losses and mature retention cohorts, and prepare a management report. Distinguish return visits or key actions from repeat purchases and prioritize the next investigation.

The attached business materials are:
- inputs/events.csv
- inputs/funnel.csv
- inputs/merchant.json
- inputs/weekly.csv

Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.

运行结果

下方直接展示本次 Prompt 产生的主要文件,保留实际输出语言。

HarborMug management report

Prioritize an investigation of the activate-to-pay journey, starting with event definitions and checkout instrumentation. It has the highest proportional funnel loss: 2 of 4 activated users do not appear at pay (50%). Each transition loses two users, so checkout is not uniquely the largest loss by count. Weekly sales growth comes with equal growth in traffic and advertising spend; conversion and revenue efficiency are unchanged. These results do not justify scaling advertising or claiming that the checkout copy revision improved performance.

All supplied business data are synthetic examples; no operational change or sales lift has been measured.

Measurement basis

Use AARRR for this growth-stage business: acquisition through visit and signup, activation through the supplied activate label, retention through recorded activity, and revenue through pay reach and weekly trading totals. Referral is unmeasured. The supplied activation label still needs a business definition before it can represent customer value.

The activity observation cutoff is November 2, 2026, inclusive. Dates have day-level resolution; no timezone is supplied. Retain each distinct user once in each denominator, each distinct user/cohort/activity-date combination for activity, and each distinct user/stage pair for funnel reach. This removes one duplicate activity row (18 to 17) and one duplicate funnel row (21 to 20). Each file contains eight distinct users. Cohort dates are consistent within users, and all activity falls between its cohort anchor and the cutoff.

The two files use different user identifiers with no overlap or mapping. Do not join them or infer retention for paying users. Deduplication is by supplied ID only; cross-device or cross-account identity cannot be resolved.

Current conversion definition: distinct users reaching each supplied stage divided by users in the preceding stage, across the undated funnel extract. Stage sets are nested, but sequence and elapsed time cannot be verified. The extract has no date range; November 2 cannot be asserted as its cutoff. Thus 25% visit-to-pay is stage reach, not a verified time-bounded purchase conversion rate.

Proposed production conversion window: follow users from first eligible visit for seven elapsed days; require visit → signup → a defined activation → confirmed payment in chronological order. Count each user once, attribute to the first-visit cohort, and exclude users lacking the full seven-day follow-up from the mature denominator. This is a measurement proposal, not a recalculation possible from the current files. Confirm whether signup and activation are required purchase steps before enforcing this path; track direct-purchase paths separately if permitted.

Retention definition: use the supplied cohort_date as an anchor of unspecified business meaning, not an assumed signup or first-purchase date. W0 is anchor days 0–6, W1 days 7–13, W2 days 14–20, and so on. A user is retained if at least one activity occurs in that window. Count a window only once it has fully elapsed for the cohort. Exact-day retention is separate and requires only that day to have elapsed. Missing activity in a fully observed window counts as zero, conditional on the supplied event coverage being complete.

Funnel losses

StageUnique usersConversion from preceding stageUsers lostLoss rateShare of visitors
Visit8———100%
Signup675.0%225.0%75.0%
Activate466.7%233.3%50.0%
Pay250.0%250.0%25.0%

Six of eight visitors do not reach pay: a cumulative 75% loss. Activate-to-pay has the largest proportional drop, while all three transitions tie in absolute loss. With only four activated users, one additional payer would change that transition rate by 25 percentage points. Treat the ranking as an investigation priority, not proof of a persistent checkout problem or an estimate of recoverable revenue.

Mature retention cohorts

Values are active users / cohort users and rate. N/A means the full window has not elapsed; it does not mean churn.

Anchor cohortUsersW0W1W2W3W4
October 544/4 (100%)2/4 (50%)0/4 (0%)0/4 (0%)N/A
October 1944/4 (100%)2/4 (50%)N/AN/AN/A

The October 5 W4 window is November 2–8, and the October 19 W2 window is November 2–8. Both are incomplete. The older cohort's W2 and W3 are complete and show no recorded activity. The newer cohort has the same W1 rate; there is no observed improvement in that comparable window. Across both mature W1 cohorts, retention is 4/8 (50%). Do not blend the older cohort's mature W2 zero with the newer cohort's unfinished W2.

Anchor cohortD1 exact dayD7 exact dayD14 exact dayD28 exact day
October 52/4 (50%)2/4 (50%)0/4 (0%)0/4 (0%)
October 193/4 (75%)2/4 (50%)0/4 (0%)N/A

Both D14 observations are mature, yielding 0/8, even though the newer cohort's full W2 is immature. Older-cohort D28 is also mature on the cutoff date while its full W4 is not. Exact-day zeros do not prove absence of activity throughout a week.

The curve shows activity at anchor, a drop to 50% in W1, and disappearance in later mature windows for the older cohort. Four users per cohort are too few to establish a stable curve or a release effect. W0 is not repeat retention because every user already has anchor-day activity. Five of eight users have at least one activity on a later date, but this cumulative return measure has unequal follow-up and should not replace the mature cohort comparison.

Recorded activity is not identified as a visit, key action, or purchase. These results describe generic activity retention only. Return visits and repeated key actions require event types; repeat purchases require customer-linked, distinct paid order IDs and payment dates. Neither repeat-purchase rate nor purchase frequency is measurable here. The funnel's two pay users and weekly order totals cannot supply those missing links.

Weekly trading performance

Dollar amounts are treated as USD for this US merchant. The weekly extract labels periods only as prior/current, so their dates, equal duration and relationship to the release cannot be verified.

MetricPriorCurrentChange
Sessions4,0004,800+20%
Orders100120+20%
Gross sales$2,400$2,880+20%
Refund value$120$144+20%
Sales less refunds$2,280$2,736+20%
Advertising spend$300$360+20%
Orders / sessions2.50%2.50%0.00 percentage points
Gross average order value$24$240%
Refund value / gross sales5.00%5.00%0.00 percentage points
Gross sales / ad spend8.00×8.00×0%
Sales less refunds / ad spend7.60×7.60×0%
Ad spend / order$3$30%

At the prior order/session rate, 800 additional sessions imply 20 additional orders, matching the observed increase. At unchanged $24 AOV, that accounts arithmetically for the $480 gross-sales increase. This is a decomposition, not evidence that advertising caused the increase. Sales less refunds rose $456 with $60 more ad spend, but this is not profit: fulfillment, goods, payment fees, tax and refund accounting are not fully specified at order level.

The sales/ad-spend ratios are blended store ratios, not attributed advertising ROAS. Ad spend/order is not customer acquisition cost because orders are not distinct newly acquired customers. Refund value rate is not the percentage of orders refunded. The 2.5% order/session ratio and 25% user funnel reach measure different populations and denominators and must not be reconciled as if they were one conversion metric.

The October 19 checkout copy revision has no causal evidence. The newer cohort starts on that date, but neither feature exposure nor dated funnel events nor dated trading periods are available. Seasonality and same-period-last-year comparisons are also unavailable.

Next investigation and operating dashboard

First priority — validate activate-to-pay and locate the failure. Assign the product/checkout owner, with analytics support, to define activation, confirm whether stage skipping is allowed, and reconcile the two activated non-payers against checkout starts, payment attempts, errors and confirmed orders in the source system. Obtain timestamped events with a common customer identifier, event type, order ID, release exposure, device and acquisition channel. First separate instrumentation gaps from actual abandonment, then compare mature seven-day funnels across equivalent periods and segments. These are recommended investigations; none has been performed in this analysis.

The next retention investigation should examine why the October 5 cohort has no W2/W3 activity: verify tracking coverage and identify which later visits or actions would represent customer value. Track visit retention, key-action retention and second-purchase incidence separately. For purchases, anchor on first confirmed paid order and measure a second distinct paid order within 30 days among customers with complete 30-day follow-up. A durable mug may have a longer repurchase cycle; validate the horizon against purchasing history before adopting a commercial target.

Use six executive metrics below, with weekly cohort filters and counts alongside percentages. Thresholds are proposed operating rules based on this small baseline, not established performance standards; rebaseline after obtaining comparable production coverage.

MetricCurrent baselineProposed target / alertOwnerDecision rule
Ordered seven-day visit-to-payUnavailable; undated reach 2/8 (25%)Establish mature baseline; alert below 25% provisionallyAnalytics leadRepair coverage first; investigate a mature decline before changing acquisition spend
Activate-to-payUndated reach 2/4 (50%)Above 50%; alert at or below 50%Checkout ownerReview payment and abandonment evidence; prioritize a specific fix only after diagnosis
Mature W1 activity retention4/8 (50%)At least 50%; alert below 50%Product ownerInspect onboarding and later value actions; do not infer repurchase
Orders / sessions2.50% in both periodsAt least 2.50%; alert below 2.50%Operations leadCheck dated comparable periods and segment mix before attributing movement
Sales less refunds / ad spend7.60× in both periodsAt least 7.60×; alert below 7.60×Growth leadReview acquisition mix and contribution economics before scaling
Refund value / gross sales5.00% in both periodsAt most 5%; alert above 5%Finance leadReconcile refund timing and reasons before diagnosing product quality

Below the executive layer, show acquisition → activation → pay by cohort, channel and device, followed by the mature retention matrix. At feature level, add checkout-copy exposure, adoption, repeat key actions, payment errors and purchase outcomes once instrumented; those measures cannot be inferred from these inputs. Annotate the release on dated charts without attaching causal claims.

Supporting deliverables

  • funnel_metrics.csv: unique stage counts, transition losses and conversion rates.
  • retention_weekly.csv: cohort windows, maturity flags, counts and rates; immature cells are blank.
  • retention_exact_day.csv: exact-day maturity and retention, separate from weekly windows.
  • weekly_metrics.csv: source totals and calculated trading ratios.
  • events_deduplicated.csv and funnel_deduplicated.csv: cleaned business records.
  • verification.json: row counts, duplicate removal and consistency checks.
  • calculate.py: reproducible calculations; run python3 deliverables/calculate.py from the folder containing inputs/ and deliverables/.

Rates are stored as fractions in the CSV files. Weekly formulas are orders/sessions, gross/orders, refunds/gross, gross/adspend, (gross−refunds)/adspend and adspend/orders. Supporting checks confirm nested funnel membership, consistent cohort dates and events within the observation period.

案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。

08

风险与使用注意事项

已知限制

留存按天偏移计算,需检查同期群是否已充分观察。漏斗只统计各阶段用户,不校验事件顺序或递进关系,因此不是有序事件漏斗。

证据与复核

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

采用结果前

使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。

常见问题

它能做什么,有什么优势?

定义产品指标,并从 CSV 计算留存、同期群表和漏斗人数。Python 计算器让输入与计算可检查,并配合 AARRR、北极星和 HEART 指引。

如何安装和开始使用?

按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 一致的用户 ID、同期群日期、活动日期或阶段标签、指标定义和观察窗口。 开启新 Agent 会话,明确要求使用 product-analytics。先用小型样本尝试下方一个场景,并检查输出。

适合哪些使用场景?

为电商功能定义产品指标树;根据清洗后导出比较已成熟留存同期群;检查阶段人数并单独校验漏斗顺序

使用前需要了解哪些限制?

留存按天偏移计算,需检查同期群是否已充分观察。漏斗只统计各阶段用户,不校验事件顺序或递进关系,因此不是有序事件漏斗。

本页核对了什么?

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

暂无评论。

发表评论

请先为每一项打分,再分享你的真实使用体验。

任务有效性
安装与使用难度
稳定性与边界
文档清晰度
首次获得有效结果
作者 / 维护者

Alireza Rezvani

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。