Campaign data into a weekly report with anomalies called out separately
Recipe template · not yet tested on this site
This page is a recipe template, not yet tested here. Run logs, tokens and time go in after re-testing; until then no estimated numbers are filled in.
When to use
Weekly campaign data must become a report. Numbers are easy; deciding which one is off is not. The value sits in the anomaly section, not the numbers.
Preparation
- Host version
- To fill (record the exact rc version when testing)
- Model
- To fill
- Mode / permissions
- Standard mode + modify-within-workspace is enough to start
- Plugins required
- None (add name & version after testing if used)
- Input materials
- Keep in a separate workspace; back up originals first
Full instruction
Read this week's campaign data under data/ and produce weekly.md.
[Input]
- Possibly a mix of csv and xlsx with slightly different field names
- At minimum: date, channel, impressions, clicks, orders, revenue
[Output structure]
1. One-sentence headline (the single thing worth knowing this week)
2. Summary table: channel by metric, with week-over-week change
3. Anomaly list: for each, which metric, which channel, how far off, likely cause, and how to verify
4. Data quality notes: which fields are missing, which definitions are suspect
[Requirements]
1. State the anomaly rule, for example 'flag when week-over-week changes by more than 30 percent and the base exceeds 1000'. Put the rule above the list.
2. No adjectives without numbers: never 'a clear drop' or 'performed well'. Every claim carries a figure and a baseline.
3. State the calculation basis: is revenue counted by order time or payment time, and how are refunds handled. If it cannot be computed, say which field is missing.
4. When the denominator is zero or missing, write 'cannot compute' with the reason; never paper over it with 0 or 100 percent.
5. Report at the end: number of channels, number of anomalies, number of data quality issues.Run log
| Item | Value | Note |
|---|---|---|
| Time spent | to be tested | |
| Result | to be tested | |
| In / out tokens | to be tested | |
| Leftovers | to be tested |
Output
After a successful run, list files and screenshots here, and note whether originals changed.
Acceptance checklist
Tap to tick each item off as you verify.
- The anomaly rule sits above the list and can be used to re-check each row
- No adjective appears without a number
- The calculation basis is stated: order versus payment time, and refund handling
- Missing denominators read 'cannot compute', never zero
- The headline does not contradict the anomaly list
Failures & boundaries
- A fixed 30 percent threshold misses large swings on small bases and false-positives on large ones, so a base threshold must accompany it
- The most common failure is reporting numbers without stating the basis. The same data counted by payment time and order time can support opposite conclusions
- Anomaly causes are inferences: label them and give a verification step, or next week repeats the same guess
- Blocked on: Needs real consecutive-week campaign data. Without genuine variance there is no way to see whether the anomaly rule under- or over-reports, which is this recipe's only substance.