Designing Events

In Countly, events are the basic building blocks of tracking.

An event is a piece of data that you record with your SDK. At a minimum, it has a name (also called its key). An event usually marks an action that a user took, recorded on their behalf. Once the event reaches your server, you can see it in the activity of that user's profile:

For a very basic tracking strategy, recording an event with a name is enough. You can also send predefined or custom properties with it. The predefined properties you can send with each event are:

• count: if applicable, how many times the event happened (for example, the number of items purchased)
• sum: if applicable, a number that the server adds up for that event (for example, the money spent on the purchase)
• duration: if applicable, how long the event took (for example, the time it took to make the purchase)

In addition to these predefined values, you can report any custom values you want with an event. We call this custom data segmentation.

On a slightly more technical level, an event looks something like this to the SDK and the server:

{
    "key": "Pencil Purchase",
    "count": 5,
    "sum": 15,
    "segmentation": {
        "hardness": "2B"
    }
}

To learn how to view and use events in Countly, see:

Deciding on Events

Tracking everything you possibly can is a recipe for disaster, and a sure way to stress your server. It is much better to start with a minimum number of events and add more along the way as you need them.

This also means that the fewer unique events you have, the better your server performs. Unique events are events with different names. As a rule of thumb, do not have more than 500 unique events.

Key categories to think about while creating events are:

• Feature usage
• User journey
• Technical output

You use events to answer questions, so start by formulating those questions clearly, then create the events that help you answer them. If you are not sure where to start, use the categories above to shape these questions.

Imagine a customer onboarding process where the customer goes through these steps:

For this process, using the categories above, you can come up with questions like:

1. How many customers get stuck at each step?
2. What is the overall completion rate?
3. How long do the identification upload and contact confirmation steps take?

To answer these questions while following the "less is more" principle above, design your tracking to send the most information with the fewest events.

You need to record:

• That the user journey started
• That a step is completed
• Which step is completed
• How long the user took to complete that step

In this scenario, you do not need an event to mark the start of the journey if your SDK tracks sessions. A session starts when the user opens the app, so a new user with a session can be counted as having started onboarding.

To record step completion, you do not need separate events such as "onboarding complete 1" and "onboarding complete 2". Instead, create a single event, and report the step number in its segmentation and the time the step took as its duration:

{
    "key": "Onboarding Status",
    "count": 1,
    "dur": 28,
    "segmentation": {
        "step": 2
    }
}

You can apply the same logic elsewhere: keep your events as compact as possible to get a clear picture of what is happening in your application with the fewest unique events.