sourcing-signals-report
How the weekly sourcing signals report is written — the five fixed sections and the wording inside them, from signals that are already gathered, clustered and ranked. Read this ONLY when the scheduler has started a sourcing-signals turn. It has no entry of its own, no merchant is waiting on it, and it must never be entered from a chat message; a merchant asking what to sell is asking for a selection scan, which is not offered right now — say so in one sentence.
name: sourcing-signals-report description: >- How the weekly sourcing signals report is written — the five fixed sections and the wording inside them, from signals that are already gathered, clustered and ranked. Read this ONLY when the scheduler has started a sourcing-signals turn. It has no entry of its own, no merchant is waiting on it, and it must never be entered from a chat message; a merchant asking what to sell is asking for a selection scan, which is not offered right now — say so in one sentence. tags: [internal, ops, requires-yepai-tools] license: MIT-0
Writing the weekly sourcing signals report
The schedule started this turn. The signals are already collected, clustered and ranked; your job is the prose around them, in the register of a trade briefing — short declarative sentences, no marketing warmth, no second person.
One call, then write
SOURCING_SIGNAL_SNAPSHOT returns the whole period — pass the period when the
scheduler named one, otherwise leave it out and take the latest. That one call is
your entire input. Do not fetch a figure that is missing, do not open the store's
own data, and do not go looking for a source the snapshot did not give you.
has_demand: false means there was no product demand this period: write nothing at
all. No report, no "nothing found this week" placeholder — an empty issue teaches the
merchant to stop opening them.
The keywords and market in the snapshot are this report's own subscription, deliberately separate from the store's Brand IQ keywords. Report what the snapshot carries and never substitute either of the others for it.
The five sections, in this order
Fill them in; do not rename, reorder, merge or add one.
1 Masthead
Market · the period's dates · the keywords this period ran on
2 What shoppers are talking about
Up to three clusters, each: the cluster's product idea, the pain quoted from a
post word for word, the representative threads as links, and a region tag where
the posts named one
3 What people are searching · Google Trends
Grouped by keyword. Each rising query in its own words, its growth figure or
BREAKOUT, the reading label, and the market it is rising in
4 Amazon Best Sellers · top 5
The five rows: rank · product with its image · the demand figure · price band ·
Market tag · note
**First settle whether this is a board at all.** `amazon.board_source` says so.
`search` means the category mapping did not resolve and these are keyword-search
shelf rows standing in for a board: head the section "Top Amazon results for your
keywords", and say in one line that these are search results rather than a
category board — no rank positions, and the demand figures are not comparable
across rows. Do not write "Best Sellers" over them, and do not cite a row's
position as a rank. When the field is absent the snapshot predates it and every
one of those was a real board, so absent reads exactly like `category` rather
than as a third, unlabelled state. `mixed` also takes the `category` wording:
the rows carry no per-row provenance yet, so there is nothing to mark row by row.
**Then name the shelf this board actually is.** `amazon.board_category` says which
one — the data platform maps a keyword to a top-level DEPARTMENT, so "ski
goggles" comes back as the Sports & Outdoors board. Write "top of the Sports &
Outdoors board", never "the top ski goggles". A #3 on a department board is not
a #3 in the keyword's own category, and the merchant will act as though it were.
When the field is absent, say the board is Amazon's without naming a category —
do not fill in the keyword.
**The demand figure names what it actually holds.** Amazon publishes a "N+ bought"
band for some listings and not others. Where `sales` is there, give it with its
estimate marking. Where it is not, the row still carries `heat_proxy` — the demand
proxy the MVP builds instead of buying a sales estimate, and it is exactly three
things: board rank, review count, review velocity. Report the evidence, in the
register of 熱度/趨勢, and never as a monthly sales figure: "1,240 reviews, +37
this week". Three numbers on three different scales do not add up to one, so do
not blend them into a score — an invented "heat: 78" is the same false precision
the estimate marking exists to avoid. Leave `rank` out of this figure: it is
already the row's own rank, and a second copy of it reads as a second fact. Give
the velocity only when it is above zero — the producer clamps this field at zero,
so a zero means the listing is new to us with no comparable week, and "+0 this
week" would state the different and false claim that nobody reviewed it.
Name the column for what is in it: sales where every row has a band, "sales /
heat" where both appear, heat where no row has a band but a proxy renders. When
a row has neither — a search shelf, or a snapshot older than the proxy — keep
calling it sales and leave the figures empty. A column of blanks headed "heat"
announces data that is not there, which is this rule in reverse.
5 Where to source next
One subsection per signal family, matching the picks, each carrying the product
thumbnail, its source label and the Market tag:
Reddit blue ocean — discussion heat, the Amazon look-alike card (name,
price, rating, review count), Google Trends corroboration
Google Trends surge — the growth figure, the Amazon cross-check, and the
suggested price band and margin the snapshot carries
Amazon Best Seller — rank, the demand figure on the same terms as section 4,
price band, what corroborates it, and how long the window
looks
Claim an ordering for section 4 only where the table has one. The pipeline orders it by estimated sales and breaks ties on board rank, so "top 5 by sales" is true as long as some row carries a sales band. With not one band in the table that phrase describes a basis the table does not have — and naming the fallback basis instead ("by best-seller rank") is falsifiable in its own way, because market-gap rows carry no rank by design and lead the table. In that case claim no ordering at all: head it "Amazon Best Sellers · top 5" and let the part that survives every payload stand — this is Amazon's board, and these are five of its rows.
Every sales figure carries its estimate marking wherever it appears — see the rule below.
In section 4's note column, say something only when the ranking listing is not from this market: that is the supply gap worth naming. Rows from this market need no note.
Hard rules
Consume the results, never re-derive them. How a product idea was identified out of a post, how clusters were scored, how sources were matched to each other: none of that goes in the report and none of it gets redone. You would reach a different answer than the pipeline did, and the merchant would see both.
A rising query keeps the searcher's own words, and a cluster's pain sentence stays the words of the post it came from. Do not tidy, translate, singularise, generalise or polish either one — the modifier is the product signal, the quote is the evidence, and those exact words get reused as listing keywords later.
Every sales figure is an estimate and reads as one. It is modelled, not reported by anyone who sells the product, so it keeps the estimate marking the snapshot gave it, is never restated to more precision than that, and is never turned into a revenue figure or into a claim about what the product "sells". An estimate presented as an exact number is the one number a merchant will check and find wrong.
Product facts come from the Amazon row and only from there — the title, the image, the price band, the rating and review count. Never take a price out of a Reddit post or pair a cluster's product idea with a price from somewhere else; one product idea, one source of fact. Where a row was reached by falling back to another market's site, keep the proxy label the snapshot put on it.
Keep the snapshot's own cautions. A row resting on a single source keeps that marking; a look-alike card marked as the closest available match keeps that framing and never counts as evidence of a crowded shelf; a family whose look-alike search came back empty is reported as a thin shelf in the snapshot's own words. These markings are what tell the merchant which lines to verify before spending money.
Region tags come from the posts, not from inference. Tag a market where the snapshot
recorded one, leave it untagged where it did not, and never tag anything Global — a
global search is the absence of a region, not a region.
A degraded section still goes out when it carries rows. degraded says the source
could not be read in FULL this period — it never says the section is empty, and the two
cases need opposite treatment. Which one applies is decided by that section's OWN row
array and nothing else: reddit.clusters for ②, trends.risers for ③, amazon.top5
for ④. eliminated, all_clusters and the rest of the bookkeeping are not rows — a
cluster the pipeline threw out stays out, and writing it back in is re-deriving the
result.
- That array is non-empty — write the section as usual, and open it with this
sentence, verbatim: Part of this section didn't come back this issue. What follows is
what did, not the whole picture. Nothing beyond it: not what failed, not which
keywords, not why. You did not run the pipeline, and a cause you infer is a cause you
invent. It qualifies COVERAGE only — an issue whose
data_sourceis notrealstill carries its sample-data labelling in the normal way, and neither sentence replaces the other. The rows are findings the merchant paid for; withholding them is not a way of being careful. - That array is empty — leave the section out, silently: no gap note, no apology, no explanation. Writing "nothing came up" would present our own outage as this market's answer (05 硬规则 6). The report is worth sending with four sections.
The report page splits it on exactly these three arrays, and the emailed issue is the same period's report — a section a merchant can read in the tab must not be missing from their inbox.
When this period reverses what the last one concluded, say why in the section that reversed. The snapshot carries the comparison against the previous period; a pick that was worth chasing last week and is not this week needs one sentence of reason, because changing a verdict silently is how the report stops being believed. In a first period there is nothing to compare against and the comparison comes back empty — leave it empty rather than computing or backfilling one.
How a signal was found — name the sources, not the machinery. Three sources, and what each is for: Reddit is the complaint before anyone sells the thing, Google Trends is the search climbing, Amazon is what already sells. That is the whole answer. Do not describe how the pipeline groups posts, picks a product name, or decides a match — you did not run it, you cannot see inside it, and a mechanism you infer is a mechanism you invent (Reddit is searched by keyword, globally — not by subreddit, not by market).
Download
ZIP package — ready to use
Skill Info
- Creator
- Yepai
- License
- MIT-0
- Downloads
- 0
- Published
- Oct 26, 2026
- Updated
- Oct 29, 2026