How to connect mobile analytics with push notifications and not go bankrupt

When launching an app, teams usually integrate a similar stack of mobile analytics tools: Amplitude, Firebase, MixPanel, AppsFlyer, Adjust, among others. These tools are used to track product and business metrics such as: the number of installations, churn, engagement, and conversions. 

The question that emerges from this data is: how can an app influence these metrics? 

One of the most popular and effective ways is to use personalized, user-relevant push notifications. Most app teams realize this fact, however, in reality, it’s difficult to implement. 

So, what is the problem and how can it be resolved?

In order to send relevant push notifications at the right time, you need:

• To collect detailed data about user actions on the app screens and be able to reconstruct sequences of actions and characteristics of those actions.
  For example, in an e-com application, we need not only log the funnel “main screen -> catalog -> item -> add to cart -> successful order”, but also understand what category the product belongs to.
• A system for sending push notifications (a customer engagement or “push” platform), which will send out push messages, and track if they are delivered and opened by the users. 
• A complete picture of what push notifications, and what texts we send to users between or during their app sessions. This will improve the quality of the user experience within the app.

A major challenge for the market is that mobile analytics products can collect detailed, granular analytics, and offer advanced segmentation to send the most relevant, targeted push notifications, yet push notifications platforms can't use most of this information. 

Why does this happen?

1. Push platforms have their own data transfer protocol

And because of this, push platforms are unable to transmit the same number of events as what mobile analytics systems can process. This means that a push tool needs to pass only the most relevant information about user behavior, otherwise it will no longer be economically viable due to high costs. 

A few examples of the challenges companies face: 

• One of the leading customer engagement platforms on the market offers users only three event fields on which the app will perform segmentation. To put this into context, the bare minimum required for targeting in any app is the ability to specify the country, and language of a user. This leaves only one remaining field, and  seriously limits what companies can do: for example, an e-commerce store with hundreds of SKUs would have to select only one item for targeting. 
• Another widely used push platform, facilitates sampling based on only one value and metric. For example, a retail app might choose to send push notifications to its customers who bought sneakers at a price lower or higher than the target value. Sampling based on a specific range, when the value of the item is in the interval, is not possible. So creating a push mailing list for users who purchased an item priced between $20 and $40 is not possible.
• The pricing model of most market solutions depends not only on the number of data and values transmitted, but also on the number of events. For small applications that have already created a large number of analytics events, it is usually too expensive to send this data to the push platform, even though there is still a low number of data points. The customer has to analyze data of the same users in two different systems to send a push notification, and then pay for each separately. The cost of maintaining an analytics system and customer engagement platform for startups and middle enterprises in this configuration is often higher than the added value from Revenue and Retention. 

2. Limited analytical functionality of push platforms

The system of push platforms is not designed for analytics, because its core goal is sending notifications. As a result, clients have no capability to look at data analysis from different angles. This requires exporting information to an analytics system, which is a lengthy, expensive, and sometimes impossible process. 

For example: even the lowest tier Amplitude plan includes a desired and popular functionality - funnel visualization. This allows you to track how unique users navigate through different screens of the app after they clicked on push notifications, and what conversions it had at each step. Push platforms can provide information on segments and metrics, but they don't allow you to track how sending a notification affected a user's journey through the funnel. 

In essence, the most basic plan of a mobile analytics system offers more analytical capabilities than a whole module in a push platform. At the same time, industry users have become used to the core capabilities of analytical tools, and expect similar functionality from push notifications platforms. The lack of familiar visualization, dashboards, and metrics presents new challenges for the decision-making manager: he needs to export data and transfer it to the analytics system, hire an analyst, or look for other alternatives. The specialist has to learn how to work with two systems at once to understand both of their functionalities and limitations. This increases the workload on the team and seriously delays the decision-making process.

3. Push platform is an additional toolkit, which is another SDK

An SDK always adds weight to an application and affects its speed. Because of this, when marketers send a request to the development team to integrate additional SDKs, the IT specialists must first research the product. Even if marketers are familiar with the tool, analyzing it in the context of a specific project takes time, which development teams usually don't have. This generally results in the implementation of the new SDK-based solution being placed into the queue of prioritization of the product team, which creates a delay in the process. 

Additionally, the SDK also affects the crash rate and non-response rate (ANR) of the app, which in turn impacts the position of the app in the Google Store. The app's ranking in the Store can drop by several dozen points just because a new SDK has been installed. This is why many gaming apps try to avoid implementing push platforms. 

Finally, apps usually start developing a push marketing strategy at some point after the initial app's release. The SDK is implemented in a new app version, and the push module starts working only for the users who have installed the latest update. As a result, the part of the audience that needs activation the most is left out simply because they are less likely to download the update. 

Alternative approaches to push notifications

Proprietary backend and analytics systems

When applications "outgrow" industry standard analytics systems, they generally want to have a more customized solution for their needs, get away from the extra costs that are characteristic of popular products on the market, and pay more attention to their data security. In pursuing this, they build their own data warehouses, event collectors and other tools, i.e. they create their own data management system, including the management of push campaigns. 

To do this, the company involves a separate team of data engineers and other specialists. In parallel, the team develops a system for sending pushes that can integrate with the analytics system and retrieve all the necessary data and segments from it. 

Pros:

1. Control. The company manages data independently and builds all processes for itself, from the moment  a user clicks on a specific element to its appearance in the analytics system and the way push notifications are delivered.
2. Scalability. The system will evolve with the company, and all the expertise required to scale it will remain within the team. 
3. Customization. There are many types of push notifications, and not all of them are necessary for every application. The company can program their own set of push notifications and embed only what the business needs in the backend. 
4. Cost efficiency. There is no need to overpay for features that you do not use. The main costs are usually the hardware part and the developer's time.

‍

Cons:

1. Long and expensive development cycle. Even if the company hires an experienced team of 5-6 people who have already created a similar product, it will take at least half a year to build the analytical system with the push platform. It will take another few months to implement all other required functionality, and you also need to invest a lot of resources in the development process at the first project stages.
2. Poor interface. Custom development often lacks a clean, clear user interface that is intuitive and easy to use. The company has to hire skilled professionals who can understand how to work with an unfamiliar product, which is a big disadvantage in the hiring process, and even a highly experienced marketer will need to be trained on how to use the custom system. 
3. Ongoing support. The company becomes hostage to its own in-house systems. If Apple introduces any new updates related to push notifications (such as notification tagging), the app team needs to incorporate them into their platform. The modification process is continuous, which means that the development team will always have to keep this task in their pipelines. Using existing customer engagement products solves this problem since they handle all of the updates themselves.

It is important to add and understand that in recent years it has become easier to develop in-house analytical systems. There are more and more services like Snowball on the market, that provide development components, and allow you to build a fully functional solution on Amazon infrastructure within six months, using a team of 5-6 people. So, creating your own products are gradually becoming more accessible, even to small and medium enterprise companies.

Intelligent integration with push platforms and analytical systems 

At nGrow.ai we use a different method - suitable for companies with any analytics system and push notifications technology stack. We integrate with all popular analytics platforms and build our own push notifications management system, incorporating machine learning on top. Over the past year and a half, we have learned how to connect to the most popular market tools, and have closed the gap between analytics, push notifications and reporting. 

This means that:

• The cost of launching personalized, highly relevant push campaigns is much lower compared to deploying engagement and analytics platforms.
• You can transmit all necessary app events and data points to the push notifications platform. Our mobile analytics systems guarantee data delivery, consistency and versioning of data.
• You can monitor granular charts with information on funnels, conversions, and user retention right in the Amplitude interface (or other system familiar to marketers). 
• You are guaranteed to get access to the most complete information on user actions and their metrics. Any funnel or rule you can create in Firebase/Amplitude can also be used in nGrow. 
• You don't need to integrate additional SDKs, compromising the performance of the entire application. Your already installed analytics system is enough to start working.

Our solution does not involve custom development, and can be integrated within just one week. Our approach allows you to take advantage of advanced mobile analytics systems and ensures connectivity between all components. 

Conclusion

Google and Apple’s operating systems have dictated that mobile applications have to be as contextual as possible with respect to user behavior, and  send only relevant messages at the appropriate time. The old approach to user engagement with its lack of data and "clumsy" rules no longer works, and doesn't guarantee good ROI because development and support are expensive.

nGrow provides no-code functionality for push notifications to work on top of data from mobile analytics systems, meaning you can easily achieve an ROI of thousands of percent, in the shortest time possible.