Event log quality

What is event log quality?

Event log quality is how well a set of event data fits the specific process-mining question you want to answer. A file can be technically valid and still be incomplete, wrongly linked, or too coarse to trust for the analysis at hand. It is data quality applied to process events: the same completeness and correctness concerns, judged against what a process question needs.

Quality is not one number. It covers completeness, correctness, consistency, timestamp accuracy, granularity, and relevance, and the question sets the bar for each. A log that records only completed activities may be enough to map the control flow, yet useless for measuring how long people actually worked on a case.

Everything downstream depends on it. Process mining rebuilds the story of a process from its event log, so a weak log produces a confident but wrong picture, which is worse than no picture at all.

Completeness

A log is complete for the question when the cases, events, and attributes it needs are all present for the intended population and period. Missing start or end events make cases look shorter than they were. A source that only records successful API calls hides every failed attempt.

Measure coverage against source totals, not just the share of non-empty fields in the extract. A field can be filled in for every row and still describe only half the cases that exist.

Correctness

Correctness asks whether a recorded event really happened, and whether its activity, time, resource, and attributes are right. A status update might be written by a nightly batch job long after a person did the work, so the database timestamp is the moment of recording, not the moment of execution.

Check samples against source records, audit logs, and what people on the ground know. A trace that looks plausible is not automatically a trace that is true.

Consistency and meaning

Activity labels have to mean the same thing across time and systems. Approved and status code 30 may stand for the same step, while Complete can mean something different from one team to the next.

Keep a mapping dictionary that records the source value, the target activity, its lifecycle stage, and the period it was valid. When the meaning of a label changes, version the mapping. Quietly relabelling old events with the new definition can hide a genuine shift in how the process runs.

Timestamps

Timestamps deserve their own scrutiny: check the time zone, clock drift, resolution, and what the source field actually means. Second-level resolution can produce many identical times, and a date-only field gives no reliable order within a day. Negative durations and impossible orderings are warning signs, though not every parallel event needs a strict total order. Keep the original timestamp alongside any transformation, and do not invent milliseconds without a documented tie-break rule.

Case correlation

The case ID ties events together into a single process instance. Wrong case IDs either merge independent processes or split one process across several traces, and both distort the frequencies and orderings you later read off the log.

Check cardinality, reused keys, cross-system mappings, and events with no case at all. When events genuinely belong to several business objects at once, an object-centric log can fit better than forcing one case notion.

Granularity

An event can stand for a mouse click, a task, a status change, or a whole process phase. Mixing these levels makes activity counts and durations hard to compare. Choose labels at the level of the process question, keep the finer source data for drill-down, and do not let raw logging detail dominate the business model. Two records written on different technical layers should not count as two activities that were carried out.

Imperfection patterns

Research into event log imperfections describes recurring problems as named patterns, such as missing events, inaccurate timestamps, and labels that either share a name for different things or use different names for the same thing. Each pattern names the symptom, the likely cause, the effect on analysis, and a possible repair, which makes cleaning more systematic than a pile of one-off scripts.

Not every oddity is a data problem, though. Rare or surprising behaviour is sometimes the process telling the truth, and it should not be scrubbed away just because it makes a model look untidy.

Validation, repair, and lineage

Write down contracts for the log: unique event IDs, an allowed set of activity labels, a sensible timestamp range, required case relationships, and matching lifecycle pairs. Profiling the data with distribution checks per day, source, and segment catches sudden drops, and counts compared against source systems catch silent gaps. Give every rule an owner, a threshold, and a fix path.

Repairs can map labels, remove duplicates, fill in relationships, or set aside impossible records. Whatever you change, keep the raw data, the repair rule, the reason, and the output version so an analyst can trace why an event was altered or excluded. Do not impute an activity or a time as if it had been observed. Mark derived values as derived, and test how sensitive the results are to them.