An event is a structured record created when instrumentation observes selected product or system activity.
That wording matters. The product does not capture behaviour in full. It records a deliberately chosen piece of evidence: a service request was published, a provider submitted a quote, a customer sent a message, or a quote was accepted.
Events make activity visible. They do not make it self-explanatory.
What an event can and cannot prove
Consider a marketplace where customers request, compare and accept service quotes.
| Event | What the record supports | What it does not prove |
|---|---|---|
service_request.published |
The platform made a request available under the defined publication rules | That every relevant provider saw it or found it suitable |
quote.submitted |
A provider submitted a quote for a request | That the quote was competitive, understandable or appropriate |
conversation.message_sent |
A message was sent through the product | That the question was resolved or that all discussion stayed on-platform |
quote.revised |
A provider submitted a new version of a quote | Why it changed or whether the revision improved the offer |
quote.accepted |
A customer accepted a recorded quote | That the work was scheduled, completed well or delivered value |
job.completion_reported |
An actor reported that the work was complete | That completion was independently verified or satisfactory |
The event records an observable fact under a defined condition. The stronger interpretation requires more evidence.
Several actors create one workflow
The service-quotes workflow contains customer behaviour, provider behaviour and platform activity.
A customer may publish requirements and compare responses. Several providers may review the same request, submit quotes, ask questions or withdraw. The platform may send notifications, apply eligibility rules or close an expired request.
These are related parts of one workflow, but they are not interchangeable units. Ten quote.submitted events do not mean ten successful customers. One service request may attract several providers and several versions of the same quote.
Event design therefore needs stable relationships such as:
request_id
quote_id
provider_id
customer_account_id
quote_version
actor_role
The purpose of these identifiers is to connect evidence at the correct level. Their collection and access should still follow the organisation’s privacy, security and retention rules.
Absence is weak evidence
When an expected event is missing, several explanations are possible.
The activity may not have happened. It may have happened outside the product. The instrumentation may have failed. A delayed data pipeline may not have delivered the record yet. Identity or request relationships may be incomplete.
For example, no conversation.message_sent event does not prove that the customer and provider had no conversation. They may have spoken by telephone after exchanging contact details. No quote.accepted event does not prove that the customer chose nobody; they may have agreed to proceed outside the platform.
Treat missing event evidence as something to interpret, not automatic proof of abandonment or failure.
Properties add only the context you need
An event name says what happened. Properties provide the minimum context needed to answer the intended questions.
A quote.submitted event might need:
request_idquote_idprovider_idquote_versionservice_typesubmission_routerequires_site_visit
A quote.accepted event might add the number of active quotes available at the moment of acceptance or the time since request publication.
Do not copy the entire business object into analytics. Message bodies, customer addresses, telephone numbers and detailed service descriptions should not become event properties merely because they are available. Collect the smallest amount of context needed for a named question, and apply the appropriate privacy and governance review.
Event evidence needs other evidence
Event records can show patterns such as:
- which requests received no quotes
- how long the first response took
- how often quotes were revised
- whether customers with several quotes accepted at a different rate
- where activity stopped inside the platform
They cannot explain whether customers trusted the providers, whether the quotes were genuinely comparable, why providers declined to respond, or whether completed work met expectations.
Those questions may require research interviews, support contacts, provider feedback, operational records, quality checks or outcome surveys. Event data is valuable partly because it tells the team where to investigate. It becomes dangerous when the team treats it as the complete experience.
A trustworthy event makes one piece of behaviour observable and leaves its limitations visible. That is stronger evidence than an event name that quietly claims more than the product can know.