Eventtracks

This table contains records of the trackings implemented in the Bots, existing only after implementation during the development of the smart contact for data generation.

Normally, trackings are recorded in the routers, but for clients who do not have an active router context, the data is generated in each subbot. We recommend enabling the router context if it is not yet in use.

Nominal latency: 5 minutes
Maximum latency: 15 minutes
Object: clients_trustedzone.deltashare_core.eventtracks
Retention: 3 days (D-0, D-1, D-2)
Initial historical load (in a separate object): 360 days

The historical load must be combined with Blip for availability; the object remains available for ingestion for 7 days.

Using eventtracks for analysis

Calculation in Events or in Unique Users:

To build metrics, it is important to understand the difference between counting events and counting unique users.

Metrics by U.U. (unique users) are generally used to understand the expansion of the base; however, to understand the smart contact journey, we recommend calculating based on events. Let’s look at an example to make this clearer:

Suppose a user accessed the bot four times in one day, trying to contact an agent and succeeding only once.

If we calculate the transfer rate by user, we will have:

Transfer rate = (1 transferred user) / (1 user who started the conversation) = 100%

It is easy to see how this calculation represents a vanity metric, where the result looks spectacular but does not reflect the user’s real difficulty in being served.
The best way to build this metric is to consider the events, resulting in:

Transfer rate = (1 effective transfer) / (4 conversations started) = 25%

Defining the start of a conversation/journey

This definition will occur according to the rule of your smart contact. Some common practices are: the sum of the events that mark the start of conversations (main menus, onboarding, entries, etc.), DAUs (daily active unique users).

In some cases, points in the flow are defined where a new code is generated marking a new session; this data can be recorded as an extra in the events, thus allowing the counting of conversations started.

Analyses in the documentation roadmap

Journey Funnel: should be developed from the implemented categories, performing a mapping of the macro points of the flows.

Using tracking extras as global journey filters.

Unexpected inputs in the menu: association with messages to identify unrecognized messages.

Abandonment: developed from trackings; the points where the user interrupts the journey should be observed.

For more information, visit the discussion on the subject in our community or the videos on our channel. 😊