Designing Events

In Countly, events are used as the basic tracking blocks.

An event is a data that you can record with your SDKs that, at a minimum, consists of a name (key). An event would usually indicate a user action which you would record on behalf of them. After sending this data to your server you would be able to see it at that user's profile:

For a very basic tracking strategy only recording an event with a name is enough. However you can send some predefined or custom properties if you want. Predefined properties that you can send with each event are:

• count: if applicable, to report the count of the event (ex: count of items purchased)
• sum: if applicable, to report a number which can be cumulated in server for that event (ex: money spent for the purchase)
• duration: if applicable, to report the duration of the event (ex: 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 point events would look something like this to the SDK and the server:

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

You can check further how you can view and use events from here:

Deciding on Events

Tracking everything you possibly can is a recipe for disaster and a great way to stress your server. It is much better to start with minimum amount of events and add more along the way if you need more.

This also means that the less amount of unique events you have, the better for your server performance. Unique events means events with different names. A general rule of thumb is to not have more than 500 different unique events.

Key categories you can think about while creating events are:

• Feature usage
• User journey
• Technical output

You will use events for answering questions so it is better to start with formulating those questions clearly and then creating events which can help you answer those. You can use the above key categories to formalize these questions if you are not sure where to start.

Imagine a customer onboarding process where the customer goes through:

For this process, using the above categories, you can imagine questions like:

1. How many customers get stuck in each step?
2. What is the overall completion rate?
3. How long does it take to complete document upload/verification and mobile number confirmation steps?

To answer these questions with the help of 'less is more principle' mentioned above you should consider designing a way to send the most amount of information with the least amount of events.

You will need to:

• Record user journey started
• Record a step is completed.
• Record which step is completed.
• Record how long did user take to complete that step.

For indicating the user journey started, you do not need to create an event (for this scenario) if you are using sessions with your SDK. A session will start when user opens the app so a new user with a session can be seen as started the onboarding.

For recording the step completion you do not need multiple events like 'onboarding complete 1', 'onboarding complete 2' etc. instead you can create a single event and report the step number and duration in the segmentation of that event:

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

You can use the logic mentioned here in other places and create events as compact as possible to give a clear picture of what is going on on your application with the least amount of unique events.