I usually follow a two step step process. Emit an event for every create/update /delete of entity. The event includes the old state of the entity and the fields which have changed so that new state of the entity can be generated by overlaying the latter over the former. This “base” event can enable most use-cases.

However, where the entity’s domain is complex and meanings can be derived by different combinations of fields, I write processors to consume the “base” event stream and build one or more event streams which are more specific and carry the interpretation of the data change in them. e.g. in you customer example, I might build a CUSTOMER_REGISTRATION stream, a CUSTOMER_ADDRESS_CHANGE stream etc. Essentially, this just wraps the base event data with more context and allows downstream systems to subscribe to more specific sets of events.