---
name: liangzhu-daily-monthly-report-format
description: Use only when generating or validating Liangzhu daily/weekly/monthly ecommerce report workbooks from user-provided or already-prepared data. Focuses on data merge rules, sheet structure, metric formulas, promotion analysis, takeover comparison, and Excel validation. Not for database import, platform export, cron, GUI, dashboard deployment, Bot2/Kanban, or credential handling.
version: 1.1.0
author: Hermes Agent
license: Internal project
metadata:
  hermes:
    tags: [liangzhu, ecommerce, daily-report, weekly-report, monthly-report, excel, reporting-format]
    related_skills: []
---

# 良渚日报 / 周报 / 月报输出格式

## Scope

This is a narrow output-format skill. Use it only after the user has provided report source files, already-prepared tables, or a clear request to generate/check a Liangzhu report workbook.

It preserves reusable report-format rules only:

- how to classify and merge daily/weekly/monthly data;
- what Excel sheets to output;
- metric formulas and denominator rules;
- promotion-analysis workbook structure;
- takeover / IP-side comparison workbook structure;
- workbook validation and final delivery boundaries.

## Hard boundaries

Do not use this skill to operate the old broad automation pipeline.

Forbidden in this skill unless the user separately asks and a more specific export/automation skill is loaded:

- no database import/export/query as the default path;
- no 千牛 / 京东 / 阿里妈妈 platform operation, crawling, HAR replay, GUI, browser, or credential work;
- no Bot2, IT2, Kanban, operator, cron, watchdog, dashboard deployment, or cloud service work;
- no NAS/shared-knowledge writes;
- no Git/commit/repo mapping;
- no automatic project expansion when the user only asks for a small report or check.

If the user asks about automation status, data downloads, account login, dashboard, scheduled jobs, platform/API collection, or long-running system changes, this skill is not enough. Use the appropriate narrow operational/export/status skill only after confirming that scope.

## Input handling

1. Use the files or tables already provided for the current task.
2. If source files must be processed, copy them into the task workspace before editing; do not edit uploaded originals in place.
3. Keep raw files and generated workbooks separate:
   - `source/` for provided files;
   - `work/` for intermediate normalized tables;
   - `deliverables/` for final Excel outputs.
4. Missing fields must be marked as `待确认` or explained in a `口径说明` sheet. Do not fabricate metrics.
5. If the user says “只要 Excel / 不要 MD”, produce Excel only and keep internal notes out of the final delivery unless asked.
6. If there are multiple possible formats, follow the latest template/file/text provided in the current handoff. Do not reuse a one-off leader-speech/reporting style for normal weekly or monthly work unless explicitly requested.

## Data level decision first

Before merging data, decide whether the task is store-level, product/SKU-level, promotion-level, or narrative-only.

- Store-level metrics: platform, shop, date/period, visitors, views, payment/transaction amount, refund amount, actual transaction amount, buyers, units, conversion, 客单价, UV价值, 加购, 收藏,售后.
- Product/SKU metrics: product name, SKU/code, product category, amount, pieces, buyers/orders, refund, traffic, source shop/platform.
- Promotion metrics: spend, impressions, clicks, CTR, CPC, CPM, promoted transaction amount, promoted orders, ROI, CVR, scene/campaign/product dimension.
- Narrative fields: business actions, 下月计划, optimization actions, risk notes. These must come from user-provided notes or be marked as draft/待确认.

Do not substitute one data level for another. For example, product/SKU workbooks are not a replacement for weekly store-level data unless the user asks for product analysis.

## Daily / weekly report merge rules

Use these rules for 良渚日报、周报, or manually uploaded weekly source workbooks.

### Core source groups

- 淘宝/天猫 store workbooks: store-level UV/PV, payment amount, refund amount, pieces, buyers, conversion, 客单价 when available.
- 淘宝/天猫 product workbooks: product/SKU TOP rows and product sales metrics.
- 京东 store traffic workbook: UV/PV/stay-time and traffic fields.
- 京东 transaction overview workbook: transaction amount, pieces/buyers, conversion, 客单价, refund amount when present.
- 京东 product detail workbook: product TOP rows when available.

If the JD transaction overview workbook is supplied, use its refund amount. Do not assume JD refund is unavailable or treat it as zero. If JD refund/buyer count covers a shorter period than traffic/amount, calculate only safe metrics and write the caveat.

### Date windows

- Daily report: use the requested business date.
- Weekly report: use the requested Monday-Sunday range, or the latest completed Monday-Sunday week if the user asks for a normal weekly report and no date is specified.
- Comparison: use previous equivalent period when available in source files.
- Do not mix partial-period and full-period denominators without a visible note.

### Normalization keys

Normalize and merge by:

- platform/store name;
- business date or week/month window;
- product name plus SKU/code when available;
- source filename and sheet name for traceability.

Keep 淘宝、天猫、京东 bodies separate when the user requests separate outputs. Do not default to combining stores when the user asks for single-store or per-store reporting.

### Core metric formulas

Use these only when the required numerator and denominator are present:

- 实际成交金额 = 支付/成交金额 - 成功退款金额
- 客单价 = 支付/成交金额 ÷ 支付买家数
- 支付转化率 = 支付买家数 ÷ 访客数
- UV价值 = 支付/成交金额 ÷ 访客数
- 退款率 = 成功退款金额 ÷ 支付/成交金额
- CTR = 点击量 ÷ 展现量
- CPC = 花费 ÷ 点击量
- CPM = 花费 ÷ 展现量 × 1000
- ROI = 推广成交金额 ÷ 花费
- CVR = 推广成交笔数或买家数 ÷ 点击量

Ratio metrics should be recalculated from aggregated totals, not averaged from daily/exported ratios. If buyer count covers fewer dates than amount/traffic, mark 客单价/转化率 as partial instead of calculating a misleading full-period ratio.

### Recommended daily/weekly workbook sheets

- `00_口径说明`: period, source files, missing fields, formulas, caveats, source row counts.
- `01_店铺核心指标`: one row per platform/store with current-period metrics and prior-period comparison when available.
- `02_商品TOP`: product ranking by store/platform.
- `03_平台店铺对比`: cross-store/platform comparison for quick reading.
- `04_运营结论`: concise conclusions tied to data evidence.
- Optional: `05_原始汇总明细`: traceable normalized rows.

Weekly summary should normally include:

- 口径说明;
- 店铺数据增长点;
- 商品销售增长点;
- 主要优化动作;
- 下周建议.

### Product TOP rules

- Sort by `实际成交金额` when refund is available; otherwise sort by payment/transaction amount and state the limitation.
- Exclude zero-sales rows from TOP lists.
- Do not pad to TOP15/TOP20 with zero-sales products.
- Keep product name, SKU/code, amount, pieces, refund, and source row aligned.
- When source contains both current and previous periods, include change value/rate where meaningful.

## Monthly report format rules

Use these rules when the user asks for 良渚月报、月度运营报告、接店满月分析, or an IP/customer-facing monthly evidence workbook.

### Target monthly scope

A complete monthly workbook should support these sections when data is present:

1. 月度经营总览;
2. 新品表现 / 新品分类口径;
3. 天猫 / 淘宝 / 京东商品 TOP20;
4. 推广投放总计;
5. 推广分场景明细;
6. 流量来源结构;
7. 下月执行重点 / 文字口径.

Every target section must map to one of:

- provided source file/table;
- already-prepared normalized table;
- user-provided business note;
- explicit missing/待确认 status.

### Recommended monthly workbook sheets

- `00_口径说明`: month, source files, store scope, formulas, missing fields, caveats.
- `01_月度经营总览`: high-level store/platform totals and key conclusions.
- `02_店铺核心指标`: store-level UV/PV/payment/refund/buyers/pieces/客单价/转化率/UV价值/退款率.
- `03_商品TOP20`: product ranking by store/platform.
- `04_新品表现`: new-product rows only when first-seen/category evidence is available.
- `05_推广分析`: required when promotion data is included.
- `06_流量来源`: only when source/channel data is available.
- `07_下月执行重点`: use user-provided business notes, or mark as draft/待确认.
- Optional: `08_原始汇总明细`: normalized source rows.

### New-product rules

- Mark a product/SKU as new only when first-seen date, product master, category file, or explicit user/source evidence supports it.
- If a product existed previously but appears in a new promotion/product group, call it “本月重点商品/重点推广商品”, not 新品.
- New-product sheets should include product name, SKU/code, category, first-seen evidence, amount, pieces, buyers/orders, conversion/traffic if available, and source file.

### Traffic-source rules

- Only output traffic-source analysis when source/channel data is actually present.
- Separate channel share, visitor growth, and transaction efficiency. Do not infer conversion by channel unless the source includes channel-level transaction or buyer data.
- State whether the traffic-source table is store-level, product-level, or promotion-level.

### Monthly conclusions

Monthly reports should not be just raw data tables. Include concise business conclusions on:

- total monthly performance;
- store/platform differences;
- product TOP and product-structure changes;
- new products or重点商品;
- promotion efficiency;
- traffic-source changes;
- risks / missing data;
- next-month actions.

Use evidence-first phrasing. If data is missing, write “待补充数据” rather than guessing.

## 接手前后 / IP汇报 comparison

For takeover-period comparison around 2026-05-09, use these windows unless the user says otherwise:

- 接手前30天: 2026-04-09 至 2026-05-08
- 接手后30天: 2026-05-09 至 2026-06-07

Recommended sheets:

- `核心指标对比`: 三店合计/天猫/淘宝/京东 × 访客数、浏览量、支付/成交金额、退款金额、实际成交金额、支付买家数、支付件数、客单价、支付转化率、UV价值、加购、收藏, with change value/rate and notes.
- `分店铺宽表`: one row per store × period for direct copying into a customer-facing deck or report.
- `每日原始汇总`: daily rows used for traceability.
- `口径说明`: source files, date windows, formulas, caveats.

Important JD caveat: if JD traffic/transaction amount covers the full target period but buyer count/pieces/refund cover fewer days, do not divide full-period amount by partial buyer count. Mark 客单价/转化率 as partial or leave them blank with a note.

## Promotion analysis requirements

When promotion data is present, do not merely append raw tables. The workbook must show conclusions.

### Promotion total and detail separation

Promotion reports often contain overlapping dimensions. Do not sum campaign, scene, keyword, and product reports together as if they are independent spend sources.

Use one source as total basis, then use other dimensions as explanatory detail. If multiple reports cover the same month/store, reconcile spend totals and state whether differences are only rounding or source-scope differences.

### Promotion field mapping

Use these prepared-data fields when present:

| Workbook concept | Common source metric |
|---|---|
| 推广花费 | 花费 / 消耗 / cost |
| 展现量 | 展现量 / impressions |
| 点击量 | 点击量 / clicks |
| CTR | 点击量 ÷ 展现量 |
| CPC | 花费 ÷ 点击量 |
| CPM | 花费 ÷ 展现量 × 1000 |
| 推广成交金额 | 直接成交金额 + 间接成交金额, or source-provided 总成交金额 |
| 推广成交笔数 | 成交笔数 / orders |
| ROI | 推广成交金额 ÷ 花费 |
| CVR | 成交笔数或成交人数 ÷ 点击量 |

### Required promotion sheets

- `推广分析结论`: overall and per-store conclusion rows with before/after performance, changes, conclusion, and recommendation.
- `推广效果_前后变化`: per-store × metric comparison for 花费、展现量、点击量、CTR、CPC、推广成交金额、推广成交笔数、ROI、CVR.
- `推广场景_前后变化`: per-store × scene comparison for spend, transaction, ROI, clicks, CPC, and conclusion.
- Optional `推广商品TOP`: only when product-level promotion data is present.

### Interpretation rules

- Lower CPC is good.
- Higher ROI, CTR, CVR, clicks, transaction amount, and transaction count are good.
- Higher spend is neutral; interpret it against transaction growth and ROI.
- State whether growth appears to come from efficiency improvement, traffic expansion, product carrying capacity, or simply larger budget.
- Name the strongest store/scene/product and the area that needs attention.
- If promotion data is missing, write a missing-data note and ask for the specific prepared table; do not invent promotion conclusions.

## Promotion-fee / partner-facing workbooks

Use this only when the user asks for a promotion-fee application, partner/IP evidence workbook, or similar paid-promotion report built from provided promotion files.

Output shape:

- Build a single Excel workbook unless the user requests separate files.
- Split by business body first, e.g. 淘宝店 and 天猫店, when the requested application has separate主体.
- Do not default to combining stores if the user asks for a single-store workbook.
- First sheet should match the requested granularity: for a single-store deliverable, show that store's natural-month spend and core effects first.
- Plan/campaign report is usually the spend source of truth; scene/product reports explain where spend and effects came from.
- For product-level promotion requests, output each requested month’s 花费TOP商品 with spend and key effect metrics.

Recommended sheets:

- `00_口径说明`
- `01_主体总览` or `01_淘宝总览` / `01_天猫总览`
- `02_计划明细`
- `03_场景拆解`
- `04_商品TOP`
- `05_结论与申请依据`

## Workbook validation

Before delivering any Excel workbook:

1. Reopen it with `openpyxl` or equivalent.
2. Check nonzero file size.
3. Check expected sheet names exist.
4. Check date window/title cells.
5. Check representative totals and formulas.
6. Recalculate ratio metrics from totals; do not average ratios.
7. Check TOP sheets contain no zero-sales padding.
8. Check store-level and product/SKU-level sections are not mixed accidentally.
9. Check promotion dimensions are not double-counted.
10. Check missing fields are visible in `口径说明` or relevant notes.
11. If a source is incomplete, report exactly which section is partial instead of filling with invented numbers.
12. Do not include internal script logs, broad automation history, credential paths, database paths, signed URLs, or unrelated process notes in the workbook or final reply.

## Final reply pattern

Keep the final user reply short:

- attach or state the output file path;
- list the main sheets;
- summarize 2-4 key data conclusions if requested;
- state any missing/partial data caveats;
- do not include internal script logs, broad automation history, credential paths, database paths, or unrelated process notes.