The below fields are present in all our events, however platform and user_agent might be blank for system-generated events.
Note that all IDs are stored as strings and all booleans are stored as the strings "0" or "1".
|user_id||the user who performed this action (aka the logged in user)|
|analytics_version||this will always be 2.0.0|
|event||the name of the event that took place|
|platform||the detected platform: one of android, ios, web, forum, extension|
|user_agent||the actual user agent from the request|
|is_system_generated||boolean representing whether the platform is blank|
|is_admin_request||boolean representing whether the action performed on |
For any event name ending in
_edited, we use the below fields.
Note that old_val and new_val are always strings (if they're not null).
|changed_column||the name of the field which was changed|
|old_val||the original value (may be blank)|
|new_val||the new value|
This field always refers to the "actor" - the person performing the action. In most cases this user "acts upon" themself. However, this is not the case for some admin actions. For example, an admin might upload a list of 500 users through CSV. In these case "user_id" would refer to the admin because they are the one performing the action. But to refer to the created users, we need a different reference. We define these on a case-by-case basis. For user creation, it is "created_user_id", for user deletion, it is "deleted_user_id", and so on.