Integrating Amplitude Analytics into iOS App: A Comprehensive Guide
Updated: October 26, 2024
7 min read
There are a million decisions one has to make when building a product. A proper analytics platform helps you understand what is good for your business and what is not. It uses data to give you a more accurate way of decision-making.
Amplitude is one of the most popular providers of product analytics. It dives deep into analyzing customer journeys, looking at hundreds of touchpoints and interactions to answer the key questions of your business, such as:
- What actions do my most valuable customers take?
- Who are the customers that churn?
- What are the characteristics of highly engaged users?
And, of course, some others.
What is ‘integrating’? Why do I need this in the first place?
As it stands today in the world of mobile apps, app developers have a huge gap between two crucial business concepts: economic rents and product analysis.
Normally, you can’t bind these two using standard methods, so it requires you to take a lot of actions until you can get the full picture of how certain users with different properties interact with your app over time.
Simply put, you need to properly adjust exports of in-app events to Amplitude. Ideally, you want to have all the necessary events exported and transformed into useful metrics. It’s quite complicated in the real world, though.
Events are tough to track and even tougher to bind. It takes a lot of time and a massive amount of code, but success is never guaranteed. We spent years in Adapty to create the necessary infrastructure and believe that our product would prove useful for many teams, but in this article, we will show what it takes to build such an export system on your own.
OK, so how do I receive subscription events?
Client events
Let’s try and trace the whole process of a hypothetical event, for example, when a user subscribes for the first time.
First, the client in the mobile app starts the transaction initialization process. Initialization is a process that is stretched out in time: the client starts, then our server gets the information about the transaction, our server sends notifications to Apple’s server, these two exchange information. If everything is OK, the client receives the receipt.
This receipt contains the original transaction ID and a bunch of meta info, such as the duration of the trial period or Product ID. Now you need this receipt to generate an event, like ‘Trial started’ or ‘Initial purchase’. You would want to enrich this event with properties that you extract from the receipt, but 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 example, Amplitude – that contains all these pieces of information. Linking all of this together remains the biggest problem.
Server-to-server notifications
Apart from client events that are sent directly from the app, there is a second source you should keep in mind.
Imagine a situation where a user had subscribed with auto-renewal, but then never opened the app afterward or 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.
The thing is that not every event is detected within the app, and the ones that are detected are sent only if the user launches the application. In such scenarios, 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, either.
First, you need to get a server of your own and support it. Then, you get a familiar problem: you have to match these notifications with users correctly and fill in the necessary properties. You have 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 Amplitude on your own
Frankly, the toughest part is over by now. On its developer’s website, Amplitude provides code on how to send data to the service.
import requests
headers = {
'Content-Type': 'application/json',
'Accept': '*/*'
}
r = requests.post('https://api2.amplitude.com/2/httpapi', params={
}, headers = headers)
print r.json()Well, that is basically it.
What it takes to make it with Adapty
Piece of cake, really.
Adapty already processes both client events and s2s-notifications correctly, so you don’t have to think about any of that. You also don’t need to implement custom server logic to process Apple subscription events or have your own server, just make sure to set up Subscription Status URL.
For the integration itself, what you need to do is:
- Copy Amplitude API key from project settings in Amplitude
- Paste the key into Adapty Integration settings and turn the integration on
- Use Adapty.updateProfile() method to set amplitudeDeviceId or amplitudeUserId. If not set up, Adapty uses your user ID (customerUserId) or if it’s a null – Adapty ID. Make sure that the user ID you use to send data to Amplitude from your app is the same one you send to Adapty.
You’re done!
Adapty gets you the full picture in minutes
Integrate Amplitude using Adapty with no headaches and start getting useful insights right away. With a 14-day trial, Adapty is certainly worth a try.
