Send custom events
addEvent() records something the SDK can’t work out on its own: a signup, a checkout, a plan upgrade. The rest of RUM tells you how the app behaved. Custom events tell you what the visitor got done.
Every event carries the session, route, and user it fired in, so it can be used as a funnel step and appears on that session’s timeline. Events are counted per session and per user, rolled up hourly, and kept for 400 days, so you can still compare this quarter against last quarter after the raw sessions have aged out.
With the npm package, import it instead: import { addEvent } from '@kloudmate/rum-web';
Attributes become breakdowns and filters
Section titled “Attributes become breakdowns and filters”Every attribute you send with an event can be used as both a group-by key and a filter. For example, currency and items from the snippet above are immediately available in the Events tab for grouping and filtering. You don’t need to define them ahead of time.
Make sure numeric values are sent as numbers. If you send 4999 as a string, it will be stored as text, so a filter such as items > 2 won’t work as expected.
It’s also a good idea to keep attribute names consistent, just like event names. If the attribute key itself changes between events, you end up creating a new key for every event, which makes it impossible to use that attribute effectively for grouping or filtering.
Keep the event name constant
Section titled “Keep the event name constant”The event name should describe what happened, not the specific object or user it happened to.
For example, checkout_completed is a good event name. checkout_user_8f21c is not: it creates a separate event name for every user.
Each workspace has a daily limit on the number of distinct event names it can store. Once that limit is reached, additional names are grouped into a single bucket that appears as Over the daily name limit in the Events tab. Dynamic event names therefore don’t give you more detailed data; they just end up in the same bucket.
If something about the event needs to vary, put that information in an attribute instead.
value is reserved
Section titled “value is reserved”The value attribute has a special meaning. It’s the attribute the platform uses for calculations such as sums and percentiles, which makes it useful for things like revenue or transaction values without requiring a separate schema for every customer.
For example, you can select Event value as the measure in the Events tab and calculate a sum or view its p90.
You can also select an individual event to see a distribution of its values.
As with other numeric attributes, value must be sent as a number. A string such as 4999 is stored as text and can’t be aggregated by the query layer.
These rules apply across all supported platforms. Events from web, mobile, and other platforms are all stored and queried in the same way.