入门指令模板

A/B 测试假设生成器

这项 A/B 测试假设 Skill 会根据转化漏斗数据和顾客反馈,整理可执行的实验候选并排列优先顺序。它帮助团队说清改什么、针对哪类访客、观察哪个指标,让“运费说明不够清楚”这类发现变成可以讨论和实施的测试方案。

浏览量
0
复制次数
0
收藏
0
编辑评分
76/100
开始使用 实际使用案例 收录的指令模板 原始链接:暂未找到公开来源
01

这个 Skill 是做什么的

提供各环节人数、当前转化率、顾客分组和开发限制后,Skill 会从流失位置出发,说明一个页面或流程改动可能影响哪种顾客行为,以及为什么值得测试。

输出包括假设、候选版本和优先顺序,方便运营与设计、开发一起讨论。样本量计算、实验上线和结果判定需要继续使用相应工具完成,不能把预计效果当成已经取得的提升。

02

它有什么特色

01

方法与优势

每条假设都把具体改动、衡量指标和作用原因连起来。团队可以先判断逻辑是否成立,再投入设计或开发时间,减少“页面更有吸引力一点”这类难以执行和验证的任务。

02

适用任务

结合已有证据、实施成本和业务限制比较候选方案。适合结账流程、商品详情页或活动落地页的优化讨论,尤其是在多个想法争夺同一批开发资源时明确先后顺序。

03

使用前的特殊要求

需要准备的输入

漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。

Agent 与运行环境

可先在模型对话中用这些指令起草。真实系统访问或文件修改需另行配置工具。

需确认的适用边界

不含实验运行器或样本量实现。效果区间、时长和显著性需另行计算并结合实测数据。

04

安装与开始使用

可直接在聊天中使用这些指令,也可让 Codex / Claude Code 保存为个人 Skill,方便重复处理同类任务。

  1. 打开能访问本机文件和终端的 Codex 或 Claude Code。
  2. 复制下方指令发给正在使用的应用,由助手选择该应用的安装目录。
  3. 查看返回的安装路径和文件检查结果;需要时新建会话,再要求助手使用已安装的 Skill。
请在我正在使用的应用中,将「A/B Test Hypothesis Generator」设置为可重复使用的个人指令模板。 1. 阅读 https://ecomagenttools.com/skills/ab-test-hypothesis-generator 页面的“收录的指令模板”部分,只使用其中完整指令,不要把评论、FAQ 或安装说明当成 Skill 正文。无法取得完整文本时,请让我粘贴,不要猜测内容或安装其他同名第三方包。 2. 列出需要我补充的假设、占位符和访问条件,保留收录指令的任务内容。这是本地适配模板,不是原作者发布包。 3. 如果你是能访问本机文件的 Codex 或 Claude Code,创建名为 ab-test-hypothesis-generator-local 的个人 Skill:Codex 放到 ~/.agents/skills/ab-test-hypothesis-generator-local/SKILL.md,Claude Code 放到 ~/.claude/skills/ab-test-hypothesis-generator-local/SKILL.md。缺少时补齐合法的 name、description 前置信息,正文保留收录指令并标注本地适配,不覆盖已有 Skill。只有聊天能力时就在当前对话中使用,不声称已安装到本机。 4. 返回保存位置或当前对话的配置结果,以及适用于这个任务的启动提问。列出尚未配置的工具或资料,不把保存模板说成已经接通账号、API 或完成实际业务测试。
05

收录的指令模板

网络搜集,无确切作者来源。复核了收录文本,但尚未将它与可核对的原始发布条目关联。这不代表官方安装包不存在;本页示例仅依据已收录文本。

You are a CRO (Conversion Rate Optimization) strategist for ecommerce stores. When given store analytics data, you will:

1. IDENTIFY bottlenecks:
   - Pages with highest exit rates
   - Steps with largest funnel drop-offs
   - Segments with lowest conversion rates
   - Devices with poor performance

2. GENERATE hypotheses (format: If [change], then [expected result], because [reason]):
   - Quick wins (implement in <1 day)
   - Medium effort (1-3 days)
   - Major tests (1-2 weeks)

3. For each hypothesis, provide:
   - Current metric baseline
   - Expected improvement range
   - Confidence level (Low/Medium/High)
   - Sample size needed for statistical significance
   - Test duration recommendation
   - Revenue impact estimate

4. PRIORITIZE by: Expected Revenue Impact × Implementation Ease

5. SUGGEST test variants:
   - Control (current version)
   - Variant A (minimal change)
   - Variant B (bold change)
   - Variant C (radical change — optional)

Your recommendations should be specific, data-backed, and actionable. Never suggest changes without estimated impact.
06

开始使用

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

01

查找漏斗瓶颈

比较漏斗步骤与设备,报告分母和数据缺口。 适用于:查找漏斗瓶颈。请准备:漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。

查看 Prompt 和变量收起 Prompt 和变量
请按上方收录指令。任务:比较漏斗步骤与设备,报告分母和数据缺口。。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。不含实验运行器或样本量实现。效果区间、时长和显著性需另行计算并结合实测数据。

需要替换的变量

[INPUT]
漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
02

编写测试假设

用 If/Then/Because 格式写假设,并提供对照和最小改动变体。 适用于:编写测试假设。请准备:漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。

查看 Prompt 和变量收起 Prompt 和变量
请按上方收录指令。任务:用 If/Then/Because 格式写假设,并提供对照和最小改动变体。。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。不含实验运行器或样本量实现。效果区间、时长和显著性需另行计算并结合实测数据。

需要替换的变量

[INPUT]
漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
03

排列测试优先级

按证据、潜在影响和成本排序,区分假设与已测效果。 适用于:排列测试优先级。请准备:漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。

查看 Prompt 和变量收起 Prompt 和变量
请按上方收录指令。任务:按证据、潜在影响和成本排序,区分假设与已测效果。。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。不含实验运行器或样本量实现。效果区间、时长和显著性需另行计算并结合实测数据。

需要替换的变量

[INPUT]
漏斗人数、分组定义、基线转化率、流量、业务限制和实施成本。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
07

实际使用案例:判断商品页的三个改版想法是否值得做 A/B 测试

输入两周订单、访问量、移动端表现与购买漏斗。本周 4,800 次会话、120 单,需要分清流量增长和转化改善,再挑选值得验证的页面改动。

使用步骤与 Prompt

  1. 准备下方案例输入资料,保留商品、政策和经营记录中的金额、单位及时间口径。
  2. 复算两周漏斗,把按钮、运费说明和尺寸图改动变成可比较的实验方案,估算样本、周期与优先级。
  3. 提交下方完整 Prompt,查看右侧主要产物;需要交接给同事时,下载包含全部交付文件的压缩包。

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

Use the ab-test-hypothesis-generator Skill.

Our order count rose but the team disagrees about whether the product page improved. Recalculate the funnel and propose three prioritized experiments around the purchase button, shipping information and size imagery. For each, give the customer problem, control and variant, success metric, smallest useful change, sample size and likely duration at our traffic level. Recommend what we should do first this week.

The attached business materials are:
- inputs/brief.json

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: funnel diagnosis and experiment plan

Start with the purchase button this week. Put the existing button immediately below price and above care information, and test that placement against the current page. Order growth alone does not show that the product page improved: orders and traffic both rose 20%, while conversion stayed at 2.50%.

The supplied analytics and interface descriptions are synthetic; all experiment lifts and revenue effects below are planning assumptions, not measured results. No live product page or historical product-page funnel was supplied.

What the numbers say

MetricPrior weekCurrent weekChange
Sessions4,0004,800+20%
Orders100120+20%
Session-to-order conversion2.50%2.50%0 percentage points
Gross product revenue$2,400$2,880+20%
Average order value$24$24Unchanged
Gross revenue per session$0.60$0.60Unchanged
Refund amount / gross revenue5%5%Unchanged
Ad spend per order$3$3Unchanged
Modeled contribution after ads*$780$936+20%

Gross product revenue minus refunds, $8 unit cost per order, $4 merchant shipping cost per order and supplied ad spend. This assumes one unit per order and excludes collected shipping fees, taxes, payment fees, overhead and any returned-stock recovery. It is not accounting profit. Refund amounts may relate to earlier orders; the 5% ratio is not a cohort return rate.

At the prior 2.50% conversion rate, 4,800 sessions produce exactly 120 orders. Increased traffic fully explains the observed order increase arithmetically. This does not establish what caused traffic growth or rule out offsetting changes within devices. A prior product funnel and randomized comparison are missing, so the team cannot establish a product-page improvement from these totals.

Current funnel

StepEnteredProgressedStep conversionLostStep drop-off
Session → product4,8003,60075.00%1,20025.00%
Product → cart3,60072020.00%2,88080.00%
Cart → checkout72036050.00%36050.00%
Checkout → order36012033.33%24066.67%

Product-session-to-order conversion is 120 / 3,600 = 3.33%. Product → cart has both the largest absolute loss and the highest proportional loss. Checkout also deserves attention: two-thirds of checkout sessions do not become orders, and the supplied interface description reports a long single-column form. That is a separate investigation, not a change to bundle into these tests.

PageViewsExitsExit rate
Product4,2002,10050%
Cart90027030%
Checkout45018040%

Product has the highest reported exit rate. Page views include repeat views; these exit rates are not funnel drop-off rates and should not be substituted for them.

DeviceSessionsOrdersConversion
Mobile3,600601.67%
Desktop1,200605.00%

Mobile supplies 75% of sessions but only 50% of orders; its conversion is one-third of desktop's. This makes mobile usability the first diagnostic priority, but traffic quality or customer mix could also explain the gap. Device-level product sessions and cart progression were not supplied.

Three prioritized experiments

The primary success metric for all three is completed purchases / eligible product-page sessions, baseline 3.33%. Use add-to-cart and checkout progression as diagnostic metrics, not substitutes for purchase success. The common denominator allows revenue and test duration to be compared consistently.

RankExperimentAssumed purchase liftFull-rollout added orders/weekFull-rollout added gross revenue/weekAdded contribution/week*Ease (1–5)Priority score
1Purchase-button placement15–25% relative18–30$432–$720$194–$32452,880
2Shipping information10–20% relative12–24$288–$576$130–$25941,728
3Size imagery5–15% relative6–18$144–$432$65–$1942576

Priority score = midpoint weekly gross revenue impact × implementation ease. Ease is a planning judgment, with 5 easiest. These are positive planning scenarios; actual impact could be zero or negative. Confidence in every numeric lift is Low, since the brief contains no experiment or customer research evidence. The button has the strongest directional rationale because the reported mobile placement and funnel loss align.

Incremental contribution assumes $24 × 95% − $8 − $4 = $10.80 per additional order, with ad spend held constant and the same exclusions as above. Revenue scenarios assume the existing 120 weekly orders all pass through the reported product funnel and that traffic, AOV and refund ratio stay constant. During a 50/50 test, the expected incremental store impact is about half the full-rollout estimate. The experiments overlap and their impacts must not be added together.

1. Purchase-button placement — quick win, under one day

Customer problem: On mobile, the buy button sits below care copy. A shopper ready to buy may not immediately see how to proceed.

Hypothesis: If the existing purchase button appears immediately below price and above care copy, then more product sessions will become purchases, because ready-to-buy shoppers can find the next action sooner.

  • Control: Existing page; mobile buy button below care copy. Capture the actual desktop placement before launch because it is unspecified.
  • Variant A — smallest useful change: Move the existing button above care copy, immediately below price. Keep its existing label, styling, price and behavior. Keep care details immediately beneath it, including “Hand-wash only. Not microwave safe.” Apply the placement rule across eligible devices; record whether desktop changes at all.
  • Variant B — bolder alternative: A persistent mobile purchase bar with price and the existing purchase action, using the same cart behavior. Proposed copy: “Add to cart — $24”, only if the action actually adds to cart. This is a future alternative, not an additional arm this week.
  • Baseline and target: Product-to-cart 20% for diagnosis; purchase rate 3.33%, targeting 3.83–4.17% in the planning scenario. Monitor purchase errors and accidental/duplicate cart additions.
  • Sample and duration: At a 25% relative purchase lift, 8,158 sessions per arm; 16,316 total; about 4.53 weeks, budget 5 full weeks. Expected full-rollout revenue impact: +$432–$720/week. Lift confidence: Low.

The all-device lift assumption is ambitious if only mobile presentation changes. Report mobile results separately, but do not claim a mobile-specific winner from this pooled sample plan. Mobile-only sizing requires mobile product-session volume and its purchase rate.

2. Shipping information — quick win, under one day

Customer problem: The cart first reveals shipping charges. Shoppers cannot assess cost and timing before committing to the next step.

Hypothesis: If the product page states shipping price, eligibility and timing beside the purchase action, then more product sessions will become purchases, because shoppers can judge the delivered offer before entering the cart.

  • Control: Shipping charge first revealed in cart.

  • Variant A — smallest useful change: Add a compact text block directly below the purchase button without changing rates or delivery promises:

    Domestic shipping: $5 on orders under $50; free on orders of $50 or more. Dispatch within 2 business days. Delivery takes 3–5 business days after dispatch. No international delivery.

    Confirm that the stated delivery window begins after dispatch before publishing; the supplied policy lists dispatch and delivery separately but does not explicitly define that timing relationship. If unconfirmed, use the literal policy wording: “Domestic dispatch: 2 business days. Delivery: 3–5 business days.” Keep the remaining shipping text above unchanged.

  • Variant B — bolder alternative: An expandable “Shipping & delivery” panel beside the action, displaying the current cart's actual shipping charge and the amount remaining to reach $50. Example for a one-mug cart: “Shipping: $5. Add $26 to reach free shipping.” Recalculate from actual cart value; do not change the threshold.

  • Baseline and target: Purchase rate 3.33%, targeting 3.67–4.00%. Cart-to-checkout is 50%, a secondary diagnostic. Earlier disclosure may reduce cart additions while improving purchase quality, so judge purchases first. Monitor gross revenue and contribution per exposed session.

  • Sample and duration: At a 20% relative lift, 12,475 sessions per arm; 24,950 total; about 6.93 weeks, budget 7 full weeks. Expected full-rollout revenue impact: +$288–$576/week. Lift confidence: Low.

3. Size imagery — medium effort, 1–3 days

Customer problem: One studio image gives little context for the mug's physical scale, potentially leaving shoppers unsure whether it fits their intended use.

Hypothesis: If the gallery shows verified dimensions and an accurate scale reference, then more product sessions will become purchases, because shoppers can better judge the mug's size.

  • Control: Single studio image.
  • Variant A — smallest useful change: Add one dimension image as the second gallery item. Draft caption: “Dimensions: 9 × 9 × 19 cm.” Place arrows only after confirming which measurement belongs to each axis and whether dimensions include the handle or other protrusions. No capacity or compatibility claim is supported by the brief.
  • Variant B — bolder alternative: A two-image scale sequence: the dimension image plus a real, accurately scaled in-hand photo. Draft caption: “See the size in hand.” Production estimate: 1–2 weeks if photography must be commissioned. Do not use an unverified illustration as evidence of scale.
  • Baseline and target: Purchase rate 3.33%, targeting 3.50–3.83%. Product-to-cart baseline is 20%; monitor gallery engagement diagnostically and later size-related returns as a guardrail. No historical size-return baseline is available.
  • Sample and duration: At a 15% relative lift, 21,693 sessions per arm; 43,386 total; about 12.05 weeks, budget 13 full weeks. Expected full-rollout revenue impact: +$144–$432/week. Lift confidence: Low.

The physical dimension mapping and scale assets are not supplied. These are completed variant specifications and copy drafts; an accurate customer-facing image cannot be finished from the brief alone.

How to run and read the tests

Sample sizes use a two-sided two-proportion normal approximation, 5% significance, 80% power and 50/50 allocation. Each calculation compares control against Variant A only, using the upper end of that experiment's assumed lift range as the minimum effect the test is powered to detect. Smaller lifts require more traffic; a nonsignificant result at these sample sizes would not rule out the lower end of the range. Variant B is an alternative concept, not covered by these sample sizes or impact estimates; size it separately before use.

Duration assumes 3,600 eligible product sessions per week, or 1,800 per arm, no traffic ramp and no exclusions. These are three sequential planning estimates, not a promise that all three can finish in parallel. Repeated sessions from the same shopper are not independent: assign visitors persistently, analyze at the randomization unit and recalculate sample needs from deduplicated eligible visitors before launch. Session-based figures here are provisional because unique-visitor counts are absent.

Use a consistent purchase-attribution window, fixed before launch; allow that window to mature after exposure ends. Verify that orders can be attributed to eligible product visitors. Keep assignment stable across visits, avoid overlapping page experiments, and preserve the same acquisition mix across arms. Run to the planned sample over complete weeks; do not stop on a favorable interim p-value. Report absolute and relative effects with a 95% confidence interval, alongside revenue per eligible session. Treat device results as exploratory unless separately powered.

Stop for broken purchases or tracking failures. Otherwise, monitor errors, revenue per session, refunds and contribution without changing the planned success rule. A shipping or imagery change that lifts orders but erodes contribution should not automatically roll out. Later tests must be resized against the purchase rate and traffic observed after earlier changes.

What to do this week

  1. First day: Verify product-view, assignment, add-to-cart, checkout and purchase events; reconcile attributed purchases with the supplied funnel structure. Capture current mobile and desktop button placement, count eligible unique visitors and confirm the purchase-attribution window. This resolves whether the provisional sample plan is usable.
  2. Build and launch button Variant A once tracking is verified. QA narrow mobile screens, desktop, cart behavior and visibility of care restrictions. Split eligible visitors 50/50 and keep all other page elements fixed. Budget approximately five weeks at the supplied session volume, subject to deduplication and attribution lag.
  3. Prepare the shipping copy and dimension-image brief while the button test runs. Confirm delivery timing and dimension axes. Queue shipping next, then reassess whether a roughly 13-week imagery test is worth the opportunity cost at the updated baseline.

This week's deliverable is a cleanly launched button experiment with trustworthy measurement—not a claim of improved conversion after a few days. No storefront changes or experiments have been executed as part of this report.

Supporting files

  • calculations.json: funnel, weekly comparisons, sizing and impact assumptions.
  • experiment-sizing.csv: experiment planning figures for the operations team.
  • calculate.py: reproducible calculation script using inputs/brief.json.
  • evidence.md: supplied evidence and its decision limits.

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

08

风险与使用注意事项

已知限制

不含实验运行器或样本量实现。效果区间、时长和显著性需另行计算并结合实测数据。

证据与复核

网络搜集,无确切作者来源。复核了收录文本,但尚未将它与可核对的原始发布条目关联。这不代表官方安装包不存在;本页示例仅依据已收录文本。

采用结果前

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

常见问题

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

将提供的漏斗数据整理为有优先级的测试假设和变体方案。每条假设都把拟议改动、预期方向和原因连起来。

如何安装和开始使用?

将下方收录指令复制到模型对话或项目指令中。 按实际情况替换假定的系统权限、默认政策、样例数字和占位符。 附上一份小型脱敏样本,使用下方示例提问,实际采用前检查草稿。

适合哪些使用场景?

查找漏斗瓶颈;编写测试假设;排列测试优先级

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

不含实验运行器或样本量实现。效果区间、时长和显著性需另行计算并结合实测数据。

本页核对了什么?

网络搜集,无确切作者来源。复核了收录文本,但尚未将它与可核对的原始发布条目关联。这不代表官方安装包不存在;本页示例仅依据已收录文本。

暂无评论。

发表评论

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

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

网络搜集,未找到原作者信息。

该 Skill 的完整可用内容已被收录和审查;公开网络资料暂未列出原作者。作者信息不影响其目录展示或基于内容的推荐资格。