Data API

Server API integration manual

Request format

The request should be sent to: https://api.devtodev.com/stat/v1/?api=ak-cDNRQl0Lypq4AOUrx8aGGMnmJT1FSebd where:

  • api - individual devtodev API app key, which can be found on the page of app integration;

  • v1 - the current version of the API aggregator.

All the transferred data must be in UTF8 encoding.

Contents must be sent as POST in gzip. The archive must contain JSON with one or more events for one or several users.

The size of a package can't exсeed 1 MB before compression. Packages that exсeed this size can't be processed.

If there are several events they must be formed inside a user object by type (name).

{

    "abcd1234abcd" : {              // Main identifier (device or user ID)
        "prev" : "asdf2345234asdf", // Previous main identifier (device or user ID)
                                    // in case it has been changed 
        "userId":"",                // Additional identifier (it is used if there is an identifier
                                    // that is different from the main identifier.
                                    // For example, a cross-platform user identifier)
        "prevUserId":"";            // Previous additional identifier in case it has been changed
        "sc" :[                     // Event name
            {},                     // Parameters of the first event
            {},                     // Parameters of the second event

        ],
        "gs" :[                     // Event name 
            {}                      // Event parameters
        ],

    },
    "1234abc1234" : {               // Unique user ID
        "userID":"",                // Additional identifier (it is used if there is an identifier
                                    // that is different from the main identifier.
        "sc" :[                     // Event name
            {},                     // Parameters of the first event
            {},                     // Parameters of the second event

        ],
        "gs" :[                     // Event name 
            {}                      // Event parameters
        ],
    },
}

Response format

HTTP Code

State

413

Wrong size of the data package (exceeds the maximum)

400

API key is absent

401

Wrong API key

403

Administrative restrictions on data received from a client

400

The error of data unpacking

{

"error_message":"Wrong GZIP format"

}

400

The error of JSON format

{

"error_message":"Wrong JSON format"

}

200

Package is received

200

The package is received, but there are errors found during the validation of events syntax.

The errors found are specified in an answer in the following format:

1.

{ "errors": { "rg": { "expected": "[timestamp]", "received": [ "[timestamps]", "[timestaTTmp]" ] } } } The message indicates that there have been received fields listed under the tag "received", but there are no fields that are listed under the tag "expected" among them. Such an event will not be processed.

2.

{ "errors": { "rg": { "expected": "[timestamp]", "useless": [ "[timestamps]", "[timestaTTmp]" ] } } }

The message indicates that there have been received extra fields listed under the tag "useless", however, fields listed under the tag "expected" are enough. Such an event will be processed.

The list of events

Information about a source of user appearance

(traffic source, referral) It is used when it is necessary to track data about a source of user appearance. The event is sent when an app is first launched by a user if a user came from a tracked source. Maximum of the fields from the following accessible data must be transferred.

Information about a user

It is not sent in case there is some data missing. The event can't be submitted as a package.

Information about an app

The recommended interval of sending is not more than once per 24h.

Information about a device

The recommended interval of sending is not more than once per 24h. Information is the most relevant for mobile devices.

Session

In case it is possible to fix the length of a session, it is sent during the end of a session or during the next session. If there is no such possibility, send the date of the start of a session, the length of a session must be placed in the middle in case it is known. The absence of a parameter of a session's length makes it impossible to count some metrics.

Real Payment

In case you transfer data related to several transactions, group them by item name.

Onboarding (tutorial) steps

The event allows to learn how a user goes through a tutorial. The event is created after every completed step.

Use the following constants for basic actions:

In all other cases use the number of steps above 0.

Custom event

If it is necessary to count events that are absent from the main types of events, use user events. An event must have a unique name and can include up to 20 parameters. You can use up to 300 unique names.

New level

This event is for games only.

Allows you to analyze players' distribution by game levels. The event is created when a player moves to the next level. In order to track the average state of game currency accounts, the amount of spendings and earnings of a currency, the amount of a game currency bought while completing a level, you can also send this data in this event.

Virtual Currency Payment

This event is for games only.

It is used to track the ways in which an in-game currency is spent and the popularity of in-game items.

In case one item is sold in several currencies, a purchase is divided into several events, the amount of which corresponds to the number of currencies. Wherein the number of items is specified only in one event.

Progression event

This event is for games only.

First of all, the event is used for games with short locations (game levels) that are completed during one game session. The event allows to gather data about the success in location completion and receive statistics by parameters that are changeable during location completion.

Ad impression

The event is used for individual tracking of ad revenue.

Do not use 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:

Connection to social networks

Allows you to track existing connections to social networks.

Constants that are supported by the system:

EN

Evernote

RT

Reddit

FB

Facebook

RR

Renren

GM

Google Mail

TB

Tumblr

GP

Google+

TW

Twitter

IN

LinkedIn

VK

VK

OK

Odnoklassniki

VB

Viber

PI

Pinterest

WP

WhatsApp

QQ

Qzone

Publication in social networks

Allows you to track publications in social networks. It also allows you to analyze viral channels to optimize marketing efficiency.

It is sent after a publication has been approved by a social network.

We recommend to specify actions that encourage to make a publication as a reason:

For example:

  • Start playing

  • New level reached

  • New building

  • New ability

  • Quest completed

  • New item

  • Collection completed

  • Invitation

  • Asking for help

  • New Record

  • Achievement

  • URL sharing

  • Recommendation

  • Review

and so on...

Clearing user data

The "Wipe" function can help when you test your app and/or when you need to clear user data as a part of the gameplay.

By default, when you send an event without any parameters, a user-specified will be "forgotten". We will keep user data in the database, but you won’t be able to find them by their main identifier. Respectively, the following event batch with the same identifier will result in creating a new user. Also, in certain circumstances, you can’t just ‘forget’ some of the users. Therefore, we have provided several flags that might be helpful.

Tracking state (GDPR)

Limiting the processing of user data. The right to erasure.

This event is implemented in accordance with the GDPR requirements.

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 "ts" event with the parameter "isTrackingAllowed": 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 listed as an impersonal unit in previously aggregated metrics.

When sending a true value, the permission to block data collection is removed.

An example of a package

'POST' https://api.devtodev.com/stat/v1/?api=ak-npADyEmjxc0usQR52k6it38zUPSloGT7 with gzipped body:

Utility for testing

A utility for sending packets

https://www.devtodev.com/upload/files/devtodevapitester.jar

An example of sending to PHP

An example of the implementation of a request to PHP with the use of Curl. The sending of real payment.

Last updated

Was this helpful?