A fresh sales, finance, marketing, or operations CSV arrives every week. The rows change, but the questions usually do not. Rebuilding the same totals, rankings, trends, and quality checks by hand is slow and easy to vary. A reusable analysis recipe keeps the method fixed while recalculating every answer from the new file.
A recurring report has two parts. The definition is stable: questions such as “What is total Revenue?”, “Top 5 Products by Revenue”, and “Show missing values”, plus the report title and analyst context. The data is temporary: this week's exported rows and every answer calculated from them.
Keeping those parts separate is the key. You want to reuse the definition without carrying last week's customer rows, totals, evidence, or filenames into the next run.
Start with one representative export. Ask the concrete questions the report must answer, then inspect the matched columns, calculation, and evidence for each result. Pin only the findings that belong in the recurring brief and arrange them in the order a reader needs.
This first run is where you catch ambiguous column names and weak questions. “Top products” is incomplete; “Top 5 Products by Revenue” states the ranking size, grouping, and metric. A precise question is easier to rerun and easier for someone else to audit.
Save the brief as an analysis recipe. The portable JSON contains only five fields: a schema version, recipe name, report title, analyst context, and ordered question strings. It does not contain the CSV filename, rows, answers, formulas, chart points, or evidence.
That boundary makes the recipe safe to reuse on the same device and practical to export for another browser or teammate. The recipient gets the method, not the old dataset.
On the next reporting cycle, choose the saved recipe and then load the new CSV or Excel export. Each question is parsed again against the current columns and recalculated from the current rows. The resulting brief keeps the saved order and framing, but every number and evidence table is new.
If a question no longer matches—perhaps a column was renamed or removed—the run skips it and names it. That is a schema-change warning, not an invitation to invent a result. Fix the export or revise the question, then rerun.
Recurring analysis works best when column names and meanings remain stable. A column changing from Revenue to Net Sales, or from numeric values to formatted text, changes what a deterministic question can match and calculate.
Treat the skipped-question message as a lightweight contract test. If the upstream system often changes headers, add a cleaning step first and save that as a pipeline profile; then run the analysis recipe against the normalized output.
Download the rebuilt brief as self-contained HTML for a readable, printable handoff or as Markdown for a wiki, repository, or ticket. Both preserve the original question, deterministic formula, and bounded evidence for every finding.
A recipe intentionally does not compare periods by itself: it answers the same questions on the new file. When the decision depends on week-over-week change, join or compare the two exports explicitly so the old and new values are both present and verifiable.
No. It contains only a version, name, report title, analyst context, and ordered questions. Filenames, rows, answers, formulas, charts, and evidence are excluded.
Compatible questions run normally. Questions whose required columns or intent no longer match are skipped and named so you can fix the export or update the recipe.
Yes. Export the analysis recipe as JSON. They can import it, inspect its plain-text questions, and run it locally against their own compatible file without receiving your source data.
No. This is a local, deliberate rerun: choose the recipe and load the current file. It avoids accounts, background uploads, and stored datasets. Use a server-side BI or automation tool when unattended scheduling is the requirement.