Whether creating a new product or improving one already live, developers make thousands of decisions. A proper analytics platform helps you understand what is good for your business and what is not as it uses data to impact your decision trees positively.
Mixpanel is one of the most advanced analytics platforms for mobile & web. It helps businesses grow by understanding how their users behave and use their products by tracking actions people take rather than page views. It considers a plethora of interactions a user can make to provide essential information for your business, such as actions taken by the most profitable customers, reasons behind churn, bumps within your user flow, and others.
What do you mean by ‘integrating’? Is there any caveat behind it?
There is a problem in the world of mobile applications. First of all, there are economic rents that you as a developer extract from your app; after all, it is essential to thriving towards making your business as sustainable as possible. Think average revenue per user (ARPU) or monthly recurring revenue (MRR).
Second, there are improvements you can make for your product to improve these economic rents. Think flawed onboarding, non-relevant paywall screen, excessive promo push-notifications, or dozens of other things that might alienate your potential users or result in the churn of subscribed ones.
The problem is that developers don’t have the bridges they need to analyze their product: they can’t bind economic indicators and product flaws to get the complete picture. Analytics systems, such as Mixpanel, can’t do it on their own as well, so developers have to build their own tools to make 3rd-party analytics solutions work.
Basically, you need to adjust exports of in-app events to Mixpanel, and you would want to do it properly. Ideally, you wanna have all the necessary events exported and transformed into valuable metrics analysis of which can result in improved financial performance. Unfortunately, it’s quite complex in the real world.
Events are tough to track and even tougher to bind. It takes a lot of time and a massive amount of code; success is never guaranteed, however. In Adapty, we’ve spent years creating the necessary infrastructure and truly think that our product would be beneficial for many apps. Although in this article, we will show what it takes to build such an export system by yourself.
So how do I receive these subscription events?
Let’s imagine a hypothetical event and follow the whole process of tracing it – for example, when a user subscribes for the first time.
First, the client in the mobile app starts the transaction initialization. Initialization is an extended process: the client starts, then your server gets the information about the transaction, after which your server sends notifications to Apple’s server; these two exchange information. If everything goes smoothly, the client receives the receipt.
This receipt contains the original transaction ID and some meta info, like the duration of the trial or Product ID. Now you need this receipt to generate an event, such as ‘Trial started’ or ‘Initial purchase.’ You would want to enrich this event with properties that you extract from the receipt, but also, there is a lot of information that you don’t get from the receipt, such as e-mail, device, or IDFA.
It’s your analytics system – in this instance, Mixpanel – that contains all these pieces of information. Linking all of this together remains a major problem.
Besides client events sent directly from the app, there is another source of in-app events you should consider.
Imagine a situation where a user had subscribed with auto-renewal but then never opened the app afterward. Or, the user has unsubscribed and immediately deleted your application. In both cases, the app itself won’t be able to track any updates on the user’s status, and you, as a developer, won’t know if something has changed.
Not every event is detected in the app, and the ones that are could be sent only if the user launches the application. In scenarios where the user doesn’t use the app, the only way you can still obtain these updates on the user’s status is through server-to-server notifications, namely from Apple’s server to yours. Adjusting s2s-notifications properly isn’t easy, though.
First, you need to get a server of your own and support it. Then, you approach a common obstacle: you have to match these notifications with users correctly and fill in the necessary properties. You need to come up with a logic that matches s2s-notifications you receive from Apple with corresponding users: you need to save and store the info you get from the app itself so you can process s2s-notifications properly.
Integrating Mixpanel by yourself
Candidly, the toughest part is over by now. Mixpanel provides the code example on tracking events and recording revenue.
Well, that is pretty much it.
What it takes to make it with Adapty
Trust us, it’s child’s play.
Adapty already processes both client events and s2s-notifications correctly, so you don’t have to think about any of that. You don't have to implement custom server logic to process Apple subscription events or have your own server; just make sure to set up the Subscription Status URL.
For the integration itself, what you need to do is:
1. Copy Mixpanel token from project settings in Mixpanel
2. Paste the key into Adapty Integration settings and turn the integration on
- Use Adapty.updateProfile() method to set mixpanelUserId. If not set, Adapty uses your user ID (customerUserId) or if it's null Adapty ID. Make sure that the user id you use to send data to Mixpanel from your app is the same one you send to Adapty.
That's it :)
Complete the picture with Adapty
Integrate Mixpanel using Adapty in an hour with no pain and no bother and start building better products right away. Find out how people use your product, which users retain best, and where they drop off – nothing will stand in your way, as Adapty automatically maps properties to provide the most seamless experience possible.
With a 14-day trial, Adapty is worth a try.