Skip to content

Bringing your own data

The demo log was chosen to behave. Your own data will not, and that is normal — getting the export right is most of the work in a first real analysis.

A CSV (or XES, if a system produces it) where one row is one event, with at least:

  • a column identifying the case,
  • a column naming the activity,
  • a column with a timestamp.

That is genuinely it. If your export has one row per case with columns like created_at, approved_at, shipped_at, you have a table that needs pivoting into one row per event first — one row per timestamp column, with the activity name taken from the column it came from.

Import the CSV; Promenade asks which column is which. Two things to get right:

Timestamp format. If parsing fails or produces nonsense dates, everything downstream is wrong. Check the time range immediately after import — a range starting in 1970 or ending in 2087 means the format was misread.

Activity granularity. The activity column should hold a modest number of distinct values — dozens, not thousands. If it holds Approved order 10482, the case number needs stripping first, or every case gets its own unique activity and no model can be discovered.

Ask what question you are answering, then pick the case ID that matches it:

  • “How long do customers wait for an order?” → case is the order.
  • “Where do parcels get stuck?” → case is the delivery.
  • “Why are invoices paid late?” → case is the invoice.

If the answer is genuinely “all of them, and they interact”, that is the point at which object-centric event data stops being an advanced topic and becomes the right tool.

Install and run the Log Quality plugin before discovering anything. It checks the things that quietly ruin an analysis: events with missing timestamps, cases with a single event, timestamps that go backwards within a case, activity names that differ only by whitespace or capitalization.

Fixing those first is much cheaper than discovering a strange model and spending an afternoon working out whether the process or the export is at fault.

An export covering January to March contains cases that started in December and cases that will finish in April. Both look like they take an unusual amount of time, and both are artifacts of where you cut.

Filter to cases that both started and finished inside your window before drawing conclusions about duration. Then check how many cases that removed — if it is most of them, your window is too short for the process you are studying.

A browser tab handles a great deal — comfortably into the millions of events — but not everything. If your log is genuinely large, the analysis does not change, only where it executes: see Engines and scaling.