Field | Data Type | Format |
account_id | string | Unique identifier for account |
user_id | string | Unique identifier for user |
feature_id | string | Name of the feature. Eg: "Project Created", "Project Status Updated", "Project Deleted" ​ Points to Note:
Limit:
|
module_id | string | Name of the Module. Eg: "Project", Dashboard", "Users". ​ Points to Note:
Limit:
​ |
product_id | string | Name of the Product. Eg: "MySaaSProductName". ​ Points to Note:
Limit:
|
timestamp | timestamp | ​ISO 8601 format The date in the timestamp (in GMT) of the feature usage event should be the same as the date (in GMT) when the event was pushed to CustomerSuccessBox Backdated events will not be aggregated and hence should not be pushed to CustomerSuccessBox |
total | integer | This is optional. If NO value is passed, this is equivalent to "1". If "0" (zero) is passed, then it will be treated as zero. i.e. feature usage was zero. As good as that feature event was never used / never sent / never received for that particular account/user combination for that date/time. We discourage passing "0" (zero) since it will unnecessary make an additional call for your systems as well our systems, and can consume your rate limit. It best NOT to make that call, instead of passing it with zero. The effect will be the same. ​ When to use this? Rather than sending each feature usage event individually, you can choose to make on end of day api call for each feature (for every relevant account/user combination) with the total feature usage count for the day. ​ This will be helpful, if you're pulling out the value from your internal product database. And can save engineering effort in cases where data is available in your internal product database. |
​