Event data

What is event data?

Event data records that something happened at a particular moment. An event might say that an order was created, an invoice was approved, or a parcel was scanned.

Alongside the activity and the timestamp, event data usually carries an identifier for the case or object involved, plus extra attributes such as the employee, channel, amount, or status. That context is what makes later analysis possible.

Event data is broader than an event log built for process mining. Raw events can be scattered across transaction tables, audit logs, messages, and application logs. An event log is a modelled selection of that data, shaped to answer one specific process question.

From a system change to a process event

A database might record only that the status column moved from 2 to 3. For process analysis you need to know that this means Invoice approved, when it happened, and which invoice it belongs to.

Extraction is therefore also modelling. The analyst decides which technical records stand for one business event, what level of detail fits, and how events attach to cases or objects.

One business action can trigger several technical updates. The other way round, a single batch update can hold events for many files at once. Without this semantic mapping, the analysis ends up counting system behaviour instead of real business work.

An order example

An ERP keeps an order header, order lines, deliveries, invoices, and payments. The raw tables hold creation and change times, statuses, and references between records.

For an order-to-cash analysis, the team turns these into events such as Order created, Delivery posted, Invoice sent, and Payment received. Each event gets a timestamp, an activity label, and a link to the chosen case.

When one order has several deliveries, Delivery posted has to stay as several real events. When one invoice covers several orders, an object-centric event model often fits better than copying the invoice event onto every order.

Data lineage records which source fields and transformations produced each event, so an odd figure can be traced back to the underlying system record instead of taken on faith.

Event data versus status data

Status data describes how something is right now. An order record marked Paid says nothing about when the earlier steps happened or how often the file was reopened.

Event data keeps the changes over time. From the sequence Created, Blocked, Released, and Paid you can work out the order of steps and the waiting time between them.

A system that only overwrites the current status loses that history. Change data capture or an audit trail can sometimes help you reconstruct earlier changes, but their meaning still has to be translated into process activities.

Event data versus an event log and an audit log

An audit log is built for control and forensic review. It records technical changes and who made them, often down to the level of individual fields.

An event log arranges events for an analysis, using recognisable activity labels, cases or objects, and timestamps. XES is the IEEE standard for exchanging event logs and event streams.

The same audit data can feed several different event logs. Which case and which activities you choose depend on the process question, so there is not always one universally correct event log for a system.

Quality, time, and privacy

Check for missing identifiers, impossible orderings, duplicate events, mixed time zones, and events that share an identical timestamp. When a source keeps only a date or a rounded time, you may need an extra sort key to recover the real order.

Record whether a timestamp marks the start, the end, or the moment something was entered. An approval can be made well before it is keyed into the system.

Event data can expose the behaviour of employees and customers. Collect only the attributes you need, limit who can see them, and be clear about what the analysis is for. A clean process map does not repair a badly modelled event underneath it.