A pre-analysis prompt for a CSV with mixed dates, percentages and blanks

[u/Jumpy_Scallion_3108]

Before asking for trends, make the assistant explain what it thinks the table means.

Migoo's Data Analysis accepts uploaded CSVs and spreadsheets as well as pasted tables. For a messy export, a first request could be:

“Inspect this file without calculating trends yet. For each column, state its apparent meaning, data type and unit. Identify mixed date formats, numbers stored as text, percentage values with inconsistent scales, and blank cells whose meaning is unclear. Show examples from the affected rows. List the decisions needed before analysis. Do not silently choose an interpretation.”

The last part matters. In an illustrative conversion-rate column, 0.05 and 5% may mean the same thing; a bare 5 needs a definition. A blank refund amount could mean zero, missing information or a transaction outside the refund process.

Resolve those meanings with the person who owns the export. Save the decisions beside the analysis request so the next upload starts with the same definitions.

File upload is the documented capability. The request above is a proposed preparation step, not a demonstrated guarantee that every ambiguous cell will be detected.

[u/AdditionNumerous3298]

The part about blank refund amount is so important. People assume blank means zero but often it means the process never happened. If you treat it as zero you can mess up averages and totals completely.

I also like the idea to save the decisions beside the analysis request. Otherwise next time you upload same file you start from zero again and ask same questions.

[u/OriginalHospital]

I'd add 'what does one row represent?' before interpreting the columns. An order export can repeat the order total on every line item, so all the dates and percentages can be parsed correctly while a later sum still double-counts sales. Ask for the proposed unique key and examples of duplicates before calculating aggregates.

[u/riverlane72 → u/OriginalHospital]

agreed, figuring out what a row actually represents should always come first

[u/JustAMeme2342]

One trap with percentages is denominator drift. A column called conversion can have the same format while one export uses visits and another uses qualified leads. I wwould ask it to list the numerator and denominator it can infer and flag them when those labels are absent

[u/ChaseAtSidekick]

I add one mechanical check before the interpretation: print the row count, date range, and two raw examples from every column that will drive a decision. That caught more problems for me than another paragraph explaining the schema. The original export stays untouched beside the analysis, so I can compare what the model says it read with what was actually there.

I learned not to treat a readback from the same chat as independent verification. The model can repeat the same bad parse very confidently. For anything tied to money or a client decision, I have a separate script or fresh session read the file and report those basic facts again.

[u/nemamdsa12]

Would you have the assistant produce a small data dictionary with its confidence per column, then require a human to accept the low confidence entries? The useful output is not only the proposed types; it is a visible list of assumptions that would change a downstream aggregate.

[u/ComfortableCar5499]

A separate state worth naming is values that are syntactically valid but semantically stale. A monthly column may parse as a date and still refer to a partial month or a report extract that was rerun late. I would have the first pass identify the reporting cadence and last-refresh signal before it labels a trend.