Many Customer Insights visualizations center around events and event types. For example, the following chart shows the total number of events - broken down by event type - that have occurred during each hour of the day:
Is that useful information? You bet it is … provided that you know what an event like “entity_create” actually is, and when an event like that might be triggered. You’ll find a brief overview of the Customer Insights event types in the sections below:
Note that this event is fired only during a login, and not during a registration.
Note that this event is fired only during a social login, and not during a social registration.
A single-sign on (SSO) federation event. The signin.sso event is triggered any time a user is automatically authenticated (logged on) to another site within an SSO federation of sites; this is true regardless of whether the user initially logged on by using traditional sign-in or social sign-in.
For example, suppose a user employs traditional sign-in to log on to Site A; at that point, the sign-in.traditional event is fired. The user then clicks a link and is taken to Site B, a site within the same federation of sites as Site A. When the user arrives at Site B, the user is automatically logged on, and the signin.sso event occurs.
That, by the way, is why Akamai collects entity_create events in addition to signin.social_register and signin.traditional_register events. For example, suppose 25 users register for a site using traditional registration; you then add 20 more users by using bulk import. In Customer Insights, you will see 25 signin.traditional_register events, one for each user who signed up by using traditional registration. What you will not see are signin.traditional_register events for the users added by using bulk import: bulk import does not trigger registration events. However, there will be 45 event_create events: 25 for the traditional registrations plus 20 for the bulk import.
An entity (user profile) has been updated or changed. The entity_update event is triggered any time a profile is edited , either by the user, an administrator, or any other person or process. This event is also fired each time a user authenticates; that’s because, with every logon, the last login date attribute is updated. In turn, that means the user profile is updated.
Note that the entity_update event is not triggered when an entity.replace API call is made. During an entity replace, the user profile is not really updated; instead, it is effectively replaced by a new user profile.
An entity (user profile) has been deleted. This event is triggered only when a user profile is deleted from the system; deactivating an account does not fire the entity_delete event. That’s because deactivation simply changes the deactivation date attribute, an action that fires an entity_update event instead. The account itself is not deleted (and can be restored, in full, simply by clearing the deactivation date attribute).