Since events and messages have different purposes, they will contain different embedded information.
Messages contain any information necessary to perform the requested action. For example, a message may contain the ID of the user that requested the operation, the ID of the business entity that will be affected, and the new value of any properties.
Events will only contain the ID of the item affected, and the data that was changed. They should be lightweight in that they do not include all aggregate data; just the data that changed. If the aggregate is small (less than 5 properties including the ID), I will bend this rule and include the entire aggregate.
When planning what data to include in the event, remember that it should be usable as an event source. An Event Source is a stream of changes made to a particular object that, when added all together, will result in the current state of that object. In a true Event Sourcing system, the only data persisted will be the stream of events so if any data is excluded from an event, the change will not be reflected in the final state. In many systems, the current state of an object is often saved in a database and the stream of events is only used as an historical record of how the entity got to the state it is in. However, event content should be planned as if no database exists.