How to use the Countly building blocks in your product?

Recommendations for App Separation / Segregation

In an example scenario where you have one web application, one iOS application, and one Android application, the questions you should ask to decide the structure on the Countly side are:

1. Are the apps logically similar? Do they provide access to similar services (such as web banking vs. mobile banking)?
   
   If the answer is yes, you should continue with questions 2 and 3.
   If the answer is no, we recommend having separate apps on the Countly side for logically different applications.

2. Do you have a single user identifier across these 3 apps, such as an email address or account number?
   
   If the answer is yes, you can take advantage of the user merging capabilities mentioned in the User Identification section to have one app on the Countly side. Furthermore, you can use the Consolidation plugin to create one or more additional apps on your Countly Server that can duplicate data into separate applications for consolidated reporting. You should also consider question 3 in this case.
   
   If the answer is no, it is better to keep these three apps as separate apps on the Countly side, too, since they don’t share a common user identifier.

3. Do you need to have different teams accessing these applications?
   
   If the answer is yes, regardless of your answer to question 2, you should go with three separate applications on the Countly side since you will want to control access to these apps on a granular level.

Apart from the above questions and consideration points, we recommend having the test, production, and/or QA versions of your applications represented as separate apps on the Countly side to avoid cluttering the production app(s).

Remarks about custom user properties:

1. If a piece of information defines the user rather than an action, it is generally recommended to store this information as a custom user property. A good custom user property example is “Account Type,” which defines the type of account a user holds and makes the entire Countly dataset segmentable using the account type.
2. However, you have to be mindful that there is a default limit of custom user properties per application, which is 20. This limit is adjustable from global or application-level settings, but the reason this default limit exists is primarily that the custom user properties get stored together with all the data (sessions, events, views, crashes, etc.)  originating from a user as a historical snapshot, and might cause performance degradation.
3. If you find the need to store an identifier as part of the custom property key, such as “Apr Balance,” where the “Apr” part has variability, you need to be careful about deleting/unsetting these properties once you don’t need them anymore.
4. Countly SDKs have functions and methods for setting and altering custom user properties, but you can also use the Countly API for the same purpose. A common use case is feeding custom user properties from the server side into your internal customer information storage (such as a CRM).

Customer Paths of Interest

Define the questions and then plan the data to answer them. As such, it is crucial to define important customer touchpoints and paths inside your digital products before creating your events, funnels, and cohorts.

One way to approach this is to think of funnel reports you would want to analyze. This exercise will help you break customer journeys into smaller pieces, which will be your starting point for creating your events and the basis of your behavioral cohorts.

Imagine a simple customer onboarding process where the customer goes through:

1. Filling in personal details.
2. Confirming their identity via a document upload.
3. Confirming their mobile number via entering an SMS code.
4. Reviewing the information and finalizing the onboarding.

For this process, we would like to answer the following questions:

1. How many customers get stuck in each step? What is the overall completion rate?
   The product team will assess the health of each step and overall process health.
   
2. Which customers got stuck in steps 2 or 3?
   The support team will proactively reach out to customers to offer help.
   
3. Which customers got stuck in step 4?
   The success team will proactively reach out to customers to learn why they didn’t go through with the process.
   
4. How long does it take to complete document upload/verification and mobile number confirmation steps?
   The engineering team will look for and test alternative solutions.
   
5. What’s the rate of failed SMS verification attempts?
   The product and engineering team will consider replacing the SMS verification with another method or choosing a different provider.
6. How many customers go back to editing information from the review stage? And which information do they edit?
   The product and UX team will consider adjusting the steps or their order.

Defining customer paths of interest and then diving into the questions are instrumental for your data planning as well as your data exploration and acting on data efforts later on.

Events / Segments

In Countly, events are used as the basic tracking block

Tracking everything you possibly can or tracking very little is equally bad. An ideal strategy, as mentioned in the Defining Customers Paths of Interest section, is collecting questions from various departments in your organization and then constructing your events and segments. 

Some common focus areas of different departments include:

• The product team will want to check feature usage, and they’ll need multiple events that show how users interact with various application features.
  
  
• The customer experience & success team will want to understand paths users go through (such as during onboarding) and get stuck in, and will need customized events as milestone indicators.
  
  
• The engineering team will want to get transactions & statutes that are created after users' interaction with the UI layer; thus, they will need events or event segments that they can take advantage of.
  
  
• CXOs and managers will want to see higher-level metrics or KPIs; thus, this higher-level data should exist either as dedicated events or individual ones to be used while constructing complex metrics using Formulas.

In its most complex form (there can be additional segments), an event's object representation looks like below:

{
    "key": "Journey",
    "count": 1,
    "sum": 100,
    "dur": 3600,
    "segmentation": {
        "Route Type": "Fastest"
    }
}

The only mandatory fields are key and count, which are set when you call the recordEvent function in any given SDK. Optional sum property is valuable when you would like to store an extra numerical value for an event. In the above example, we used it to store kilometers for a journey. Duration property represented as dur can be explicitly set, or you can take advantage of the timed event concept available in most SDKs.

Segments are properties that add further detail and meaning to an event. Segments are important since most of the time, you aren't only interested in how many times some general action happened but also will have the need to dig deeper and filter certain cases or group occurrences by different nuances of the action.

From our event sample above, thanks to the Route Type event segment, you can not only see overall journeys taking place but also see how many of the journeys were planned with the fastest, shortest, or eco route types offered in the app. Furthermore, in plugins like Cohorts, Funnels, Drill, and Formulas, these event segments will be available for use cases such as:

• Filter events where Route Type = Eco using Drill
  
  
• Construct 3 different funnels where the final step is the Journey event in all but filtered to be Route Type = Eco, Route Type = Fastest, and Route Type = Shortest.
  
  
• Create a behavioral cohort of users who did have a Journey with Route Type = Eco at least 2 times in the last 30 days (these are our eco-friendly personas which we can target using remote config and automated push notifications).
  
  
• Construct 2 formulas in which you calculate the average kilometres driven per journey for Route Type = Shortest and Route Type = Fastest.

As you can tell from the above reporting examples, event, and event segment selection is an important part of your success in data exploration and acting on data with Countly.

Additional Optional Features To Integrate Into Your Product

Page Views / Views

Countly has built-in support for automatic (page) view tracking in most of its SDKs. For each view tracked, Countly also records metrics such as time spent, landings, exits, bounces, and average scroll. The availability of these metrics is SDK and platform-dependent. For information on view reporting, please check out the Views and Heatmaps article in the Countly Help Center.

We don’t recommend enabling view tracking by default in all cases. Views are helpful if they contain essential milestone indicators of the customer journey, but we have observed that’s not always the case. Views might end up damaging the clarity of reporting and ease of use of connected capabilities such as Funnels and Cohorts. Furthermore, views have to be supported by events and event segments for Customer Path of Interest in order for you to be able to dig into the customer journey and to build cohorts of customers with wanted and unwanted activity.

Think of an example scenario where your customer is going through an order process. In this process, there are four views your customer needs to go through:

1. View Cart / Proceed to Checkout.
2. Shipping Address.
3. Payment Details / Confirmation.
4. Result.

You can very well build a funnel using these four views since the first view indicates the milestone your customer enters the funnel, and the fourth step is the completion/conversion point. But your reporting abilities won’t go beyond reporting users who got stuck in one of these holistic milestones. Countly is designed to help you achieve more than that.

By adding these three simple events to your tracking strategy:

1. New shipping address
   1. City and Country as segments.
   2. Result as a segment to indicate failure/success.
2. New payment method
   1. Card type as a segment.
   2. Result as a segment to indicate failure/success.
3. Purchase from category
   1. Category as a segment.
   2. Count property to represent the number of items purchased from the category.
   3. Sum property to represent purchase amount from the category.

And storing these two custom properties in the user profile:

1. Total Purchase Count.
2. Total Purchase Amount.

You can:

• Build more detailed versions of your funnel that incorporate adding shipping details and a payment method during the process.
• Report on funnel completion rate per purchase categories to discover commonalities in customer behavior.
• Create a cohort of customers who have more than one purchase from a specific category within the last 7 days, which you can dig into commonalities of and also use as a target for your push notifications, surveys, and personalization via remote configuration.
• Create a cohort of customers who have a failed shipping address adding attempt (or a payment method) and don’t have a successful go within the last day. These customers can be fed into an external system via Hooks to let your support agents be proactive, supporting high-value customers.
• Report on categories your top customers based on total purchase count and total purchase amount are shopping from, a metric your CRM might be providing to you, but this time, having this part of your reporting capabilities so that your analytics data is much more impactful across departments within your organization.

As we tried to illustrate in the above example, with the addition of just 3 events and 2 custom user properties, your analytics capabilities go well beyond high-level, view-based KPIs. We strongly urge you to evaluate using view reporting in conjunction with other rich data types Countly provides.

Crashes / Errors

Countly provides crash analytics capabilities in most of its mobile, web, and desktop SDKs. Together with the stack trace, device-related information such as operating system, device manufacturer, state of the device information at the time of crash such as free RAM, free disk space, and other pieces of information such as custom key/value pairs to enrich the crash data are available together with this data point. A full list of metrics collected automatically and via manual instruction can be found in the Crashes article in the Countly Help Center.

Countly treats the crash data point in two main ways:

1. As a way to help engineering teams understand and resolve application issues quickly. To expand on this further Countly provides: 
   1. Symbolication/de-obfuscation capabilities for iOS and Android.
   2. A two-way JIRA integration.
   3. A customizable crash grouping mechanism.
   4. Alerting on new crash occurrences or increases in the number of crashes.
2. As an activity in the customer journey, just like an event or a view, to help product, customer success, support, and data teams to:
   1. View crashes as part of the customer activity timeline/journey in the user profile.
   2. Use the crash data point while building funnels, cohorts, and Drill queries.
   3. Act on the crash data point in features such as push notifications and remote configuration.

As technical as it sounds, the crash data point is not just a metric for technical teams; it is an integral part of a happy customer journey; thus, all teams in your organization should approach this metric within the tie-it-all-together context of Countly.

Performance Traces

Countly has a Performance Monitoring plugin that helps you analyze network request-related performance metrics and rendering, start, and load-related profiling in your mobile and web applications. For the purposes of the Performance Monitoring plugin, we refer to the data point generated as a performance trace. 

Countly SDKs have different support levels for Performance Monitoring. In the Web SDK, you have automatic network and page load time traces, whereas in the iOS and Android SDKs, you have the automatic app start time tracing but manual network traces. Please check the documentation of the SDKs you are planning to take advantage of to see the level of support they provide for Performance Monitoring. 

Similar to crashes, we see performance traces as health indicators of your customer journey; thus, they should not be considered a metric reserved for technical teams.

Form Tracking (Web Only)

Countly Web SDK provides a built-in capability to automatically capture form submissions as an event named formSubmit. Automatic form submission tracking is enabled with a one-line configuration on the SDK initialization stage.

Automatic form tracking will track all HTML form fields in all forms on all pages except for passwords and hidden fields. These form fields will be recorded as event segments together with the formSubmit event. You can configure the SDK to track hidden inputs by adding a flag to your one-line configuration. If you want only certain forms under a specific parent node to be tracked, you can pass the parent node as the second parameter (as an HTML object) to the one-line configuration.

Link Clicks (Web Only)

Countly Web SDK provides a built-in capability to automatically capture link clicks as an event named linkClick. Automatic link click tracking is enabled with a one-line configuration on the SDK initialization stage.

When automatic link tracking is enabled by default, all links on all pages will be tracked. However, you can provide a second parameter to the initialization (as an HTML object) to track only link clicks within a given parent node. Together with the linkClick event, SDK will automatically capture the text, ID, and URL attributes of the link as event segments.

In high-traffic deployments, automatic link click tracking should be used with caution since it might create a substantial volume of data points.

Clicks and Scrolls for Heatmaps (Web Only)

Countly provides in-page click and scroll heatmap capabilities for web applications via the Web SDK. Click and scroll tracking for heatmap purposes are enabled via two separate one-line configurations on the SDK initialization stage, which can be found here and here.