Naming Custom Events

Set up standard naming for your custom events and their parameters from the beginning of working with Reteno. This will make your code easier to interpret so anyone on your team can easily understand what each event means.

What Is Standardized Naming

Standardizing naming is following certain rules when naming events and their parameters sent from your application to other platforms. Standardized names will streamline analytics and simplify tracking setup.

Benefits of Standardized Naming

With standardized naming, your data will be consistent and convenient to use and understand:

  • Unification. When all data types and events have consistent names across all platforms, it simplifies their utilization.
  • Usability. As your business grows, you will need to keep track of more and more new events. Standardized naming will simplify the implementation of their transferring and save time for your developers.
  • Transparency. Different teams work with the same data: developers, marketers, analysts, etc. Standardized names make it easy for everyone to understand an event and its parameters for further analysis, experimentation, and other actions.

ObjectAction Scheme

Without clear and standard rules for events’ naming, your analytics will become increasingly confusing and unclear. For example, when a user logs in to your app, you can send this event as Log in, Login or User logged in.

To avoid such problems and use all app data effectively, create a standard naming scheme and stick to it when creating all events and their parameters.

We recommend creating events’ names from two parts: objects and actions related to them. For example, SubscriptionStarted, SubscriptionRenewed, SubscriptionCanceled.

Use verbs in the past tense to underline that events created after actions happened.

The ObjectAction scheme of events’ naming will help you

  • To build a funnel for analyzing interactions with particular features of your app: you will see object-related actions in alphabetical order.
  • To easily find events in the event history.
Event history
  • To ensure an understanding of what events are recorded in analytics: it’s obvious that an event called TrialStarted means a user subscribed to the trial app version.

Event Parameters

The more parameters you send in an event, the bigger picture of the interaction with your app you get. For example, you can transfer in ProductPurchased event the total cost and cost of each item, discount value, product description, delivery method, etc.

Create a list of standard parameters for all events. For example, for the TrialStarted and SubscriptionRenewed events, you must collect parameters such as productId, productName, productDescription, startDate, endDate, and so on.

Standardized event parameters will allow you to build dynamic segments based on contact behavior in your app for marketing analytics and target campaigns.

Dynamic segment

CamelCase Format

Use exceptional CamelCase format:

  • Write the event name by capitalizing the first letter of each word and not using spaces, underlines, and other special characters: ProductPurchased.
  • Write the parameter name by making the first letter of the first word lowercase and every subsequent word capitalized, not using spaces, underlines, and other special characters: trialDuration.

List of Standard Events and Parameters

Event nameRequired parametersOptional parameters
ScreenViewscreenClass
AppInstalled
SubscriptionStartedproductId, productName, price, currencyCode, startDate, endDate, durationproductDescription
TrialStartedproductId, productName, startDate, endDate, trialDurationproductDescription
SubscriptionRenewedproductId, productName, price, currencyCode, startDate, endDate, durationproductDescription
SubscriptionCanceledproductId, productName, endDateproductDescription
ProductPurchasedproductId, productName, price, currencyCodeproductDescription

📘

Note

All events should include standard information about devices and contacts

More on launching event tracking >