内容运营6 阅读

如何让 Codex 分析订单数据和复购率

很多团队做订单分析时，只看 GMV、订单数和客单价。问题是，这些指标只能说明“卖了多少”，不能说明“用户会不会回来买”。如果一个活动当天销售额很高，但大部分订单来自一次性低价用户，后续没有复购，这个增长质量并不一定好。

发布时间 2026/07/04

一、为什么订单数据不能只看销售额

Codex 适合处理这类问题，因为它可以在项目仓库里读取 CSV、SQL、数据脚本、埋点说明和报表文档，然后把散落的数据口径整理成一套可执行的分析流程。但前提是：你不能只让它“分析一下订单数据”，而要让它先确认字段、口径、时间范围和排除规则。

这篇文章讲的不是让 Codex 随便生成一段分析文案，而是让它完成一条完整链路：读取订单数据、识别字段含义、定义指标口径、编写 SQL 或 Python 脚本、计算复购率、输出结论，并把每个结果都写清楚来源和公式。

二、Codex 在订单分析任务里应该做什么

这类任务不要让 Codex 直接改业务代码。更安全的做法是让它在 analysis、scripts 或 docs 目录下工作，把分析过程变成可复查的文件。

读取订单表、用户表、支付表、退款表、商品表或 CSV 样本，先梳理字段含义。
建立 metric_definitions.md，写清楚每个指标的公式、分母、分子、时间口径和排除条件。
生成 SQL 或 Python 脚本，用代码计算订单数、销售额、客单价、购买用户数和复购率。
输出 order_repurchase_report.md，把数据结果、异常、趋势和业务建议写成报告。
保留中间表或计算明细，方便人工抽样核对，避免只给一个无法验证的结论。

关键原则订单数据分析不能只看 Codex 的自然语言结论。任何指标都必须能追溯到字段、过滤条件、时间范围和计算代码。

三、开始前需要准备哪些数据

你可以把数据放在项目里的 data、exports、fixtures、analysis/input 目录，也可以让 Codex 读取已有的数据查询脚本。为了降低风险，建议先使用脱敏后的样本数据，不要直接把真实手机号、地址、身份证、支付账号等敏感信息交给 Codex。

字段	说明	为什么重要
order_id	订单唯一 ID	用于去重，避免同一订单被重复计算。
user_id / customer_id	用户唯一 ID	复购率必须按用户计算，没有用户 ID 很难算准确。
paid_at / order_time	支付或下单时间	用于按天、周、月统计趋势，也用于 cohort 分析。
order_status	订单状态	需要排除取消、未支付、关闭、测试订单。
payment_amount	实付金额	用于计算销售额、客单价、用户消费金额。
refund_amount	退款金额	用于区分支付 GMV 和净收入，避免高退款订单误导结论。
sku_id / product_id	商品或 SKU	用于分析哪些商品带来首购，哪些商品带来复购。
channel / source	渠道来源	用于判断投放渠道、自然流量、社群、直播等渠道的复购质量。
coupon_amount	优惠金额	用于判断复购是否依赖折扣。
is_test / internal_flag	测试标记	用于排除内部测试订单和刷单数据。

四、先把复购率口径说清楚

复购率最容易算错，因为不同团队说的“复购率”可能不是同一个指标。让 Codex 分析前，必须让它先输出口径说明，而不是直接计算。

指标	推荐口径	回答的问题	常见误区
购买用户数	观察期内至少有 1 笔有效订单的去重用户数	这个周期有多少真实购买用户？	把订单数当用户数。
用户复购率	观察期内有效订单数 >= 2 的购买用户数 / 观察期内购买用户数	这个周期内有多少用户买了不止一次？	未排除取消、退款、测试订单。
老客订单占比	老客订单数 / 总有效订单数	订单里有多少来自老用户？	这不是用户复购率，只是订单结构。
首购 cohort 复购率	某首购 cohort 用户中，在 N 天内再次购买的人数 / 该 cohort 首购用户数	首购用户后续会不会回来？多久回来？	时间窗口不一致，导致不同月份不可比。
平均购买间隔	用户相邻两次有效购买之间的平均天数	用户大概多久复购一次？	没有排除异常高频刷单或拆单。
客单价 AOV	有效实付金额 / 有效订单数	每笔订单平均多少钱？	把退款前金额和退款后金额混用。
人均消费金额	有效实付金额 / 购买用户数	每个购买用户平均贡献多少钱？	和客单价混为一谈。

推荐公式： 用户复购率 = 观察期内有效订单数 >= 2 的购买用户数 / 观察期内有效购买用户数 Cohort 30 日复购率 = 首购 cohort 用户中，首购后 30 天内再次购买的用户数 / 该 cohort 首购用户数 老客订单占比 = 由非首购用户产生的有效订单数 / 观察期内总有效订单数

五、第一步：让 Codex 先审查数据字段

不要一开始就让 Codex 计算复购率。第一步应该让它读取数据文件或 SQL 表结构，输出字段说明和风险清单。这样可以提前发现 user_id 缺失、订单状态不明确、时间字段混乱、金额字段含义不清等问题。

请你先审查当前项目中与订单分析有关的数据文件和脚本。 目标： 1. 找到订单表、用户表、支付表、退款表、商品表或 CSV 样本。 2. 列出每个字段的含义、数据类型、示例值和可能的问题。 3. 判断哪些字段可以用于计算订单数、销售额、客单价、购买用户数和复购率。 4. 不要直接修改业务代码，不要直接生成最终结论。 输出： - docs/order_data_field_audit.md - 字段清单 - 缺失字段 - 需要人工确认的问题 - 复购率计算是否具备基本条件

六、第二步：让 Codex 生成指标口径说明

字段清楚之后，再让 Codex 生成 metric_definitions.md。这个文件比最终报告更重要，因为后续所有结论都应该基于它。

请根据订单字段审查结果，生成一份指标口径说明文档。 文档路径：docs/order_metric_definitions.md 必须包含： 1. 有效订单的定义：包含哪些状态，排除哪些状态。 2. 销售额口径：使用支付金额、退款后净额，还是原始订单金额。 3. 订单数口径：是否按 order_id 去重，是否排除拆单或测试订单。 4. 购买用户数口径：使用 user_id 还是 customer_id。 5. 用户复购率公式：分子、分母、时间范围。 6. 老客订单占比公式：不要和用户复购率混淆。 7. cohort 复购率公式：首购时间、复购窗口、N 天范围。 8. 所有不确定字段必须标记为“需要人工确认”，不能自行假设。

七、第三步：让 Codex 编写可运行的分析脚本

当数据是 CSV 或 Excel 导出时，可以让 Codex 写 Python 脚本；当数据在数据库中时，可以让 Codex 写 SQL。重点是让它保存中间结果，而不是只输出最终数字。

请基于 docs/order_metric_definitions.md 编写订单数据分析脚本。 要求： 1. 如果数据源是 CSV，使用 Python pandas 读取；如果是数据库脚本，优先生成 SQL。 2. 不要修改原始数据文件，只在 analysis/output 下生成结果。 3. 计算以下指标： - 有效订单数 - 有效销售额 - 客单价 AOV - 购买用户数 - 用户复购率 - 老客订单占比 - 首购 cohort 30/60/90 日复购率 - 平均购买间隔 4. 输出中间表，方便人工抽样核对。 5. 生成 docs/order_repurchase_report.md，总结核心发现、异常和下一步建议。 完成后请运行脚本，并在回复中说明运行命令、生成文件和需要人工确认的问题。

八、第四步：让 Codex 分析订单趋势和复购结构

复购率不是一个单点数字。真正有价值的是看它在时间、渠道、商品、用户层级上的变化。比如整体复购率不低，但某个投放渠道的复购很差；或者某个爆款商品带来很多首购，但后续复购很弱。

按月份分析：订单数、销售额、购买用户数、复购用户数、复购率趋势。
按渠道分析：不同渠道带来的用户质量和复购差异。
按商品分析：首购商品、复购商品、复购带动 SKU。
按用户分层分析：首购用户、复购用户、高价值用户、流失风险用户。
按优惠强度分析：复购是否依赖优惠券、满减、直播间低价。
按购买间隔分析：用户第二单通常发生在第几天，是否适合做召回。

请在现有订单分析脚本基础上，补充维度分析。 请输出： 1. 按月趋势表：month, valid_orders, paid_users, repeat_users, repeat_purchase_rate, revenue, aov。 2. 按渠道表：channel, paid_users, repeat_users, repeat_purchase_rate, revenue_per_user。 3. 按商品表：product_id, first_purchase_users, repeat_purchase_users, repeat_contribution。 4. 用户分层表：one_time_users, repeat_users, high_value_users, dormant_users。 5. 购买间隔分析：second_purchase_days 的分布和中位数。 请在报告中说明每个维度的业务含义，不要只罗列数据。

九、第五步：让 Codex 检查计算是否可靠

数据分析最怕“结果很漂亮，但口径错了”。完成计算后，应该让 Codex 自查一次，专门找计算风险。

请对刚才生成的订单数据和复购率分析做一次质量检查。 重点检查： 1. 是否把订单数误当成用户数。 2. 是否把老客订单占比误写成用户复购率。 3. 是否排除了取消、未支付、退款、测试订单。 4. 是否存在重复 order_id 或空 user_id。 5. 是否存在跨时区导致的日期归属错误。 6. cohort 复购率的时间窗口是否一致。 7. 退款金额是否影响销售额口径。 8. 报告中的每个结论是否能追溯到具体表格或代码。 输出：docs/order_repurchase_quality_check.md 请列出：通过项、风险项、需要人工确认项、建议修复方式。

十、可直接复制给 Codex 的完整任务指令

下面这段可以作为一键执行指令，适合直接丢给 Codex。实际使用时，把数据目录、数据库连接方式、业务时区和有效订单状态改成你的项目规则。

任务：请分析当前项目中的订单数据和复购率，并生成可复核的数据分析报告。 背景： 这是一个电商 / SaaS / 内容付费项目，需要从订单数据中分析订单趋势、销售额、客单价、购买用户数、用户复购率、老客订单占比和 cohort 复购情况。 数据范围： - 请优先查找 data、exports、fixtures、analysis/input、database、sql、docs 目录中与订单、支付、用户、退款、商品相关的文件。 - 如果存在多个订单数据源，请先列出并说明差异，不要直接合并。 - 所有个人敏感信息只做统计，不要输出明细。 执行要求： 1. 先生成 docs/order_data_field_audit.md，说明可用字段、缺失字段和需要人工确认的问题。 2. 再生成 docs/order_metric_definitions.md，写清楚每个指标的公式、分子、分母、时间口径、排除条件。 3. 编写 scripts/analyze_order_repurchase.py 或 analysis/order_repurchase.sql。 4. 计算有效订单数、销售额、AOV、购买用户数、用户复购率、老客订单占比、cohort 30/60/90 日复购率、平均购买间隔。 5. 输出 analysis/output 下的中间表和结果表。 6. 生成 docs/order_repurchase_report.md，包含核心结论、趋势变化、异常数据、业务建议和下一步验证项。 7. 最后生成 docs/order_repurchase_quality_check.md，检查是否存在口径错误、重复数据、状态过滤错误、时间窗口错误。 限制： - 不要修改原始数据。 - 不要连接生产库执行写操作。 - 不要凭空补全缺失字段。 - 不要把老客订单占比写成用户复购率。 - 不要输出任何手机号、地址、身份证、支付账号等敏感信息。 完成标准： - 每个指标都能追溯到字段和公式。 - 每个结论都能追溯到结果表或脚本。 - 报告中明确列出所有需要人工确认的问题。 - 输出文件路径清晰，可以被团队复查和复用。

十一、推荐的文件结构

为了让 Codex 的输出更稳定，可以提前规定文件结构。这样它不会把脚本、报告和临时文件到处乱放。

/data /sample_orders.csv /sample_users.csv /sample_refunds.csv /analysis /input /output /scripts analyze_order_repurchase.py /docs order_data_field_audit.md order_metric_definitions.md order_repurchase_report.md order_repurchase_quality_check.md AGENTS.md

十二、适合写进 AGENTS.md 的项目规则

如果你经常让 Codex 做数据分析，建议把复购率和订单分析规则写进 AGENTS.md。这样每次执行任务时，Codex 都能先读取这些项目规则，减少口径漂移。

# AGENTS.md ## 数据分析规则 - 所有订单分析必须先生成字段审查文档，再生成指标口径文档，最后再计算。 - 默认只统计有效订单：已支付、已完成、未被取消、非测试订单。 - 销售额口径必须说明使用支付金额、退款前金额还是退款后净额。 - 用户复购率按 user_id / customer_id 去重计算，不得用订单数替代用户数。 - 老客订单占比不是用户复购率，报告中必须分开命名。 - cohort 复购率必须写清楚首购周期、复购窗口和时区。 - 不得输出个人敏感信息，如手机号、收货地址、身份证、支付账号。 - 所有分析脚本必须写入 scripts 或 analysis 目录，所有报告必须写入 docs 目录。 - 修改或新增脚本后，必须说明运行命令和输出文件。

十三、报告应该长什么样

最终报告不要只写“复购率为 18%”。一个合格的复购报告至少要回答：复购率怎么算、哪个周期变好了、哪个渠道拖后腿、哪些商品带来复购、哪些结论不确定。

报告模块	应包含内容
摘要	用 3 到 5 条说明本期订单和复购的核心变化。
指标口径	有效订单、销售额、购买用户、复购用户、cohort 复购率的定义。
整体表现	订单数、销售额、AOV、购买用户数、复购率、老客订单占比。
趋势分析	按日、周、月观察订单和复购变化。
渠道分析	不同渠道的购买用户、复购用户、客单价和收入贡献。
商品分析	首购商品、复购商品、复购贡献商品。
用户分层	一次购买用户、复购用户、高价值用户、沉默用户。
异常说明	重复订单、退款异常、状态缺失、用户 ID 缺失、时间字段异常。
业务建议	召回时机、复购商品组合、优惠策略、渠道优化方向。
待确认问题	需要业务、财务、数据团队确认的口径和字段。

十四、常见错误

只统计订单数量，不按 user_id 去重，导致把“多订单”误判为“多用户”。
把老客订单占比当成用户复购率，导致复购表现被高频用户放大。
没有排除退款、取消、未支付、测试订单，导致销售额和复购率虚高。
不同月份使用不同时间窗口，导致 cohort 复购率不可比。
只看整体复购率，不拆渠道、商品和用户分层，找不到真正问题。
报告只给结论，不给脚本、公式和中间表，后续无法复查。
让 Codex 直接猜字段含义，没有让它标记“需要人工确认”。

十五、验收清单

检查项	通过标准
字段审查	已经列出订单、用户、支付、退款、商品等相关字段，并标记缺失项。
指标口径	每个指标都有公式、分子、分母、时间范围和排除条件。
复购率	用户复购率、老客订单占比、cohort 复购率已分开命名。
脚本可运行	SQL 或 Python 脚本可以重新运行，输出文件路径明确。
中间表	保留按用户、按订单、按 cohort 的中间结果，便于抽样核对。
异常处理	重复订单、空 user_id、退款、取消订单、测试订单已处理或标记。
隐私保护	报告不输出个人敏感信息。
业务建议	建议能对应到具体数据，不是泛泛而谈。

十六、FAQ

1. 没有用户 ID，还能算复购率吗？

很难准确计算。可以用手机号、邮箱、设备 ID 或会员 ID 做映射，但这些字段涉及隐私和去重问题，必须脱敏处理，并在报告中说明误差。

2. 退款订单要不要算进复购率？

要看业务口径。通常建议有效订单排除全额退款和取消订单；部分退款可以保留订单，但销售额使用退款后净额。关键是写清楚口径。

3. 复购率低一定说明产品不好吗？

不一定。低频高客单产品天然复购周期长，不能和快消品用同一套标准。更合理的是看购买间隔、品类特征和 cohort 变化。

4. Codex 可以直接连接数据库分析吗？

技术上可以通过项目已有脚本或只读连接完成，但不建议让它直接操作生产库。更安全的做法是使用只读账号、脱敏样本或导出的 CSV。

5. 订单数据分析适合 ChatGPT 还是 Codex？

如果只是解释指标，可以用 ChatGPT。如果要读取项目文件、写 SQL、跑脚本、生成报告和检查口径，Codex 更适合。

6. 为什么要让 Codex 生成中间表？

因为复购率不是一个不可验证的结论。中间表可以让你抽查某个用户、某个订单、某个 cohort 是否被正确统计。

十七、达灵感发布

建议

推荐 URL：/codex/analyze-order-data-repeat-purchase-rate
推荐分类：数据分析、运营增长、电商运营、AI 任务指令。
推荐内链：如何让 Codex 生成指标口径说明文档、如何让 Codex 自动整理数据分析结论、如何用 Codex 把 CSV 数据整理成报告、如何用 Codex 分析用户分群数据。
推荐 CTA：复制这套订单分析指令，让 Codex 帮你把订单表变成可复核的复购率报告。

参考资料

OpenAI Developers：Codex web 文档，用于核对 Codex 可以读取、编辑和运行代码的能力说明。
OpenAI Developers：Custom instructions with AGENTS.md，用于核对 AGENTS.md 的项目规则加载方式。
OpenAI Developers：Codex Best Practices，用于核对提示词、验证步骤和完成标准的组织方式。
Google Analytics Help：Set up a repeat purchasers audience，用于核对“多次购买用户”和 purchase / ecommerce_purchase 事件的常见分析思路。

Codex电商内容运营订单分析复购率