Omniata BlogAugust 19, 2015

Planning for Custom Analytics & Metrics

Basic packaged metrics only provide a high-level view of your product and business health. To get a detailed understanding of your product and business, you need to carefully start thinking about integrating custom analytics and events.

After integrating basic, out-of-the-box metrics, it won’t take long to realize that they are insufficient to answer real questions about your product. You will feel a compelling need to understand the underlying drivers behind metrics and possible actions to improve them. You will start asking hard questions about your product’s health.

  • Why is your day three retention low?
  • What segment of users is contributing most towards revenue?
  • What are the characteristics of a product that sells the most?
  • Why are users dropping out after two days?
  • Who are your most valuable users?
  • Why are users storing items in the cart, but not buying?
  • Why do users start the purchase process but do not complete the final transaction?

You will realize the need of having custom events and metrics in your product. Unlike basic out of the box metrics, the custom analytics and metrics differ significantly across different tools available in the market. Most tools are also limited in flexibility that would allow you to define custom analytics that meet all your use cases.

Hence, it is critical to spend time evaluating and planning your custom analytics needs and the tools that you plan to use at this moment. You may decide to use one or more third-party tools or you may choose the option to build it all internally. Regardless of your choice, the factors you need to consider to get maximum value from custom analytics remain the same. Mentioned below are some of the points that you should pay attention to while thinking about custom analytics.

Event Taxonomy

Your analytics tools should always support flexible event taxonomy because your needs will evolve with time. You will have to modify the format of your events as your product grows or as you identify more metrics to track. Hence, your event schema must be flexible to allow adding or removing parameters at any time.

For example, assume that you have defined an event to track In App Purchases within your app. Your initial definition would look something like:



  • In_App_Purchase


  • api_key
  • user_id
  • product_category
  • product_name
  • currency_type
  • country
  • transaction_amount


This event will help you create basic reports such as:

  • Revenue by product category
  • Number of purchases by product category

However, as your product evolves and your store grows, you may realize that you now have too many products in each category that increases the difficulty in analyzing reports. You easily understand information, you now need the following reports:

  • Revenue by product categories and subcategories.
  • Number of purchases by product categories and subcategories.

These reports can easily be generated by sending another parameter “product_subcategory” within the event. Hence, it is critical to have a flexible method of changing event taxonomy anytime.

Cross-Platform User Profiles

Another factor to pay attention is how you will deal with user identity. With so many devices available, the same user can have have multiple identities over time across different platforms.

For example, a user may initially visit your web page and browse anonymously. At this stage, you can identify the user using a cookie. After a while, the user may decide to register and create a user id. The same user can then download the application on a mobile device and use your app without signing in, and hence will be recognized with the device identifier. After some time, the same user returns to your app and decides to sign in with the user id that was created on your website.

If you don’t plan in advance how to handle user profiles, you might assume there were four different users instead of one. Hence it is important to support multiple user profiles, both per individual platform and cross-platform, with different sets of user attributes, and link these profiles in context of user behavior.

Spending some time to amply plan for custom analytics will avoid many expensive headaches later. In subsequent blog posts, we will explore the integration of custom analytics and event design in detail.

QA Data During Integration

Bad data can make your analysis useless, or worse, lead to incorrect interpretation. Many issues can cause data to go bad; for example, you might misspell a parameter, or you might skip a required parameter, or the value of a parameter might not be in accordance with its data type. If not corrected during integration, your dashboards will show you inaccurate metrics.

At Omniata, we provide a comprehensive set of QA tools that allow you to send events in real time, and validate its format and data types. It is essential that your solution provide something similar to this.

We will cover this topic in detail in our next blog post.

SDKs for Robust and Flexible Client-Side Data Tracking

You also need to ensure that you have a robust way of collecting data and maintaining its integrity. If you are planning to use third party vendors, it is good practice to create your own event SDK and wrap vendor SDKs inside it. Your SDKs should be able to be configured remotely. Furthermore, try to build a smart retry logic that would make sure that no events are lost. It is also important to compress the data before sending to save bandwidth, and sign events with a private key for security.

To learn more on how Omniata enables custom analytics, please feel free to contact us.