Data API 2.0
If, for some reason, you cannot use the devtodev SDK, or some events cannot be tracked on the client side, you can use the devtodev data API. Using the API, you can send a set of events that almost completely replicates the capabilities of the SDK. However, you will need to independently prepare data about the device/user and also independently track the start and duration of sessions.
Request format
URL:
https://api.devtodev.com/v2/analytics/report?appId=sampleApplicationId
POST data is received by the server in compressed or text form, depending on the value of the "Content-type" field in the HTTP header.
All the transferred data must be in UTF8 encoding.
The archive must contain JSON with one or more events for one or several users.
The packet size cannot exceed 2 MB in its uncompressed state. Packages that exсeed this size can't be processed.
Headers:
Example POST Data:
The reports object contains:
Each packet consists of the following fields:
Response
The server responds with code 200 if everything is OK.
Service Events
Device Info
Contains information about the user's device. It must be sent as the first event when a new user is created. Additionally, it is desirable to send an event at the beginning of each session.
Example
Session Start
Sends information about the start of a new session.
Example
User Engagement
Sends information about the duration of user activity. This can be either the full length of the session or a part of the user's session while the application was in focus.
Example
Setting User Tracking Status (GDPR)
This event denies/allows tracking of user data and also implements the right to be forgotten in accordance with the requirements of the GDPR.
A developer must use this event in case a user doesn’t want their data to be sent and processed in the devtodev system.
When calling the event with the parameter "trackingAllowed": false, it is a command to the server to delete all user’s personal data that has been collected by devtodev from this app and a command to block the collection of any data of this user in future.
The user will remain in the devtodev system only as an impersonal unit in the previously aggregated metrics.
If it is set to “true”, tracking can be enabled again. In this case, the user will be considered new.
Example
Alive
Service event. Not obligatory. Ping event for the server. It is required to correctly display a player online if more than 5 minutes have passed since his last sent event.
Example
User properties
People
Each devtodev project can have up to 30 custom user properties.
Attention! We strongly recommend that you do not use these properties to transfer and store data that fits the definition of personal data!
Predefined user properties (in addition to 30 custom user properties).
Example
Basic Events
Custom Event
If you want to track non-basic events (below), you can create custom events of your own. How you are going to apply them, depends solely on you.
devtodev supports not more than 300 custom event names in a single project. Events that exceed the limit of custom event names will be discarded. Try to integrate the tracked actions by type to the event name level, and move the characteristic tags to the parameters.
For example, if you need to track purchases of “Paper” and “Pen” items, you don’t need to create two events with the names “Paper Purchase” and “Pen Purchase”. Instead. create a single “Purchase” event and add an “Item” parameter with the appropriate value of “Paper” or “Pen”. This way, you can use just one event to track many items.
For a string parameter, you can use no more than 50,000 unique values for the entire history of events. If the number of unique values exceeds the limit, the parameter gets locked by the system and is discarded from the received data. Therefore, we don’t recommend using highly variable parameters like user IDs or time as string values (moreover, they are automatically added to the event).
We strongly recommend that you do not change the data type passed in the same parameter. If you change the data type in a parameter, it will be duplicated with the same name, which may cause issues while processing reports.
We strongly recommend that you do not use custom event properties to transfer and store data that fits the definition of personal data!
Example
Real Payment
To track payments in a real currency, dispatch this event right after the system validates that the payment went through successfully. The event is fundamental and mandatory for all the app metrics related to monetization.
By default (easy to change in the app’s settings), the devtodev server invalidates transactions with previously-used identifiers. Additionally, the server performs identifier checks based on their outer appearance in order to avoid obvious fraud.
Example
Onboarding (tutorial)
Tracks the progress of the user's initial training (tutorial). The event is used to build a funnel through which users go through learning stages (steps). Each step is represented by an integer greater than 0. If you plan to add additional intermediate learning steps, you can number the steps initially, for example, in increments of 10. Additionally, three constants are used to describe the start of training, successful completion of training, and skipping the entire training process.
Recommended sequence for dispatching events:
Training started (-1).
Sequential sending of events at the entrance to the next learning step (1...N).
Completion of training after passing the last step of training (-2).
he tutorial skip logic assumes that a single event with a value of 0 is sent, replacing the entire sequence described above.
Example
Virtual Currency Payment
This event is for games only.
Pass this event after every purchase if you want to track in-app (virtual) currency spends and items’ popularity. You can apply this event to both games and any apps with virtual currency.
Example
Currency Accrual
This event is for games only.
The event involves the accumulation of in-game currency or resources. It contains data on the amount of in-game currency earned or purchased by the user. It is highly undesirable to send this data transactionally. Instead, please send aggregated data for a specific period, such as 5-10 minutes. Additionally, the accumulation of data must be interrupted, and an event should be sent if the user's level has changed.
Attention! The total number of tracked unique resources (virtual currencies) cannot exceed 30 items throughout the project's lifespan.
Furthermore, apart from grouping by type (earned/purchased), there is also a grouping by the source of income.
Current Balance
This event is for games only.
This event is used to generate a preset game report called Economy Balance (currency balance with grouping by days). This report shows the approximate amount of virtual currency on users' hands, which is useful for planning and checking the results of campaigns aimed at removing excess virtual currency from the application.
This event should not be sent more than once per day for a user.
Example
Level Up
This event is for games only.
Leveling up the user (player). The event is triggered when the user reaches a new level. In addition o the achieved level number, you can also include data on the balance of virtual currencies or resources at the time the new level was reached, as well as the total amount of currencies or resources spent, earned and purchased by the user during the previous level progression.
Attention! The total number of tracked unique resources (virtual currencies) cannot exceed 30 items throughout the entire life of the project.
Example
Progression Event
This event is for games only.
First of all, the progression event is used in games with short (within one game session) areas/game levels, for example, match 3 games. You can use the event to collect data on how well or how fast users complete levels, how difficult it is for them, how many resources they gained or spent, and other relevant parameters.
parameters object:
Example
All events generated during the passage of the location are recommended to be marked with the key "inProgress," the value of which indicates the name of the location (Progression event name).
Example
Secondary Events
Referral
Tracking the source of the application installation. Sent once per user. Does not need to be sent if ad trackers such as AppsFlyer are integrated in the project settings or the devtodev custom postback API is used.
Example
Ad Impression
The event is used for individual tracking of ad revenue on user devices. This method is used if there are CPI data available on the client device (they can be obtained from the ad network SDK).
Do not apply this event if you use ad networks that utilize the server-server protocol for sending ad revenue data (ironSource, AppLovin MAX, and Fyber networks) and you already set up this method of data collection because if you use both data sources, your revenue data may be duplicated.
Example
Social Connect
The event tracks the user's connection to a social network. It is sent at the moment when the application receives information about the successful authorization of the user on the social network.
Example
Preset social network codes
Social Post
The event tracks the user's posts on the social network. It is dispatched when a success report is received from the network, if possible.
Example
Example
An example of a package describing a single session of a single user.
Note: devtodev does not accept data that is older than 7 days and data that is more than 3 hours in the future. If you want to use this example, you will need to edit the timestamp parameters.
Last updated