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
ObjectAction SchemeWithout 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.
- To ensure an understanding of what events are recorded in analytics: it’s obvious that an event called
TrialStartedmeans 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.
CamelCase Format
CamelCase FormatUse 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 name | Required parameters | Optional parameters |
|---|---|---|
ScreenView | screenClass | |
AppInstalled | ||
SubscriptionStarted | productId, productName, price, currencyCode, startDate, endDate, duration | productDescription |
TrialStarted | productId, productName, startDate, endDate, trialDuration | productDescription |
SubscriptionRenewed | productId, productName, price, currencyCode, startDate, endDate, duration | productDescription |
SubscriptionCanceled | productId, productName, endDate | productDescription |
ProductPurchased | productId, productName, price, currencyCode | productDescription |
Note
All events should include standard information about devices and contacts