Where to start

A tutorial is a very important part of any project because the first session lays the foundation for future retention and monetization indicators.

devtodev allows to analyze how users complete the tutorial, find bottlenecks, and measure the time it takes for users to complete the tutorial. These questions can be answered with the help of the Tutorial analysis report.

If users in your project become more experienced and raise their level

devtodev is an analytics system designed specifically for game projects. Many game projects have levels, which means that as users become more experienced, they gradually increase their level. In this case levels have a linear structure: the level N is followed by the level N+1.

When players move to the next level, you need to use the LevelUp event. All our reports, that are built by levels, are based on this event, e.g. Currency balances by level, Player levels, etc. Also, if your project has in-game currency, using the LevelUp event you can send information about the current amount of in-game currency players have. This data allows to evaluate the average amount of in-game currency that players have on a particular level.

For example, this is how the Player levels report looks like (see the pic below). It shows how users are distributed among levels, the percentage of users who remain on a particular level, the revenue of a particular level, etc.

If it is possible to pass / fail a level in your game

There are many projects (for example, Match-3 games), where players attempt to pass a level. Their attempts may be either successful or unsuccessful. In addition, during a certain attempt some numerical indicators can change: the number of stars, resources, in-game currency.

To analyze these attempts, we've created a basic Progression event. In the ProgressionEvent you send information about how players pass a particular game location, whether their attempt was successful, and how numerical indicators change.

Based on the ProgressionEvent, we build the Locations report, where all indicators are calculated by game locations, for successful and unsuccessful attempts.

If there is a virtual currency in your project

Many games, especially f2p, have in-game currency. Players can accumulate currency, or buy it for real money. They can then spend it on virtual goods. To work with virtual currency, devtodev has developed the following events:

• inAppPurchase – to send information about purchases made by players (please note that these are only purchases made with virtual currency, while information about purchases for real money is sent with the Payment event);

• currencyAccrual – to show information about movements of virtual currency (for example, if a player earns currency or receives it for some actions, you can use currencyAccrual to see this information).

All the game economy reports are based on these events.

With the help of the Currency Balances by Level tab in the Economy Balance report (this one also requires a LevelUp event), you can see how users spend, earn and accumulate currency on each game level.

The Top Purchases tab in the Economy Balance report allows you to analyze the structure of the consumer basket and identify items, which are the most popular among different categories of players.

devtodev is a universal analytics system with basic events structure designed specifically for game projects. However, there may be situations when your project requires events that are not provided by devtodev as basic. That's alright, such events can still be sent and analyzed in our system as custom events. It is possible to specify parameter values of custom events. Here are some examples of user actions that can be sent as custom events: when users open an in-game store, click on items, buy items. Based on these events, you can then build a funnel and see the conversion on each step.

Some limits for custom events:

1. The number of different event types sent from one project shouldn't exceed 300.

2. The event name must not exceed 72 characters.

3. One event can contain up to 20 parameters, each of them with unique names of up to 32 symbols.

4. Parameters can be string and numeric:

• the maximum length of parameter values is 255 characters;

• the number of string parameter values cannot exceed 50 000; when it exceeds 50 000, the further sending of information about the parameter and possibilities to work with it will be blocked;

Here is some expert advice to avoid problems with limits on custom events:

• there is no need to send user IDs in parameters (they are collected by default);

• do not send time in the timestamp format (it is also collected by default).

If you want to check transactions for validity

To exclude from statistics transactions made by cheaters, you can use devtodev Anti-cheat service. By using this method, you will be able to check payments for validity before sending them to devtodev. The verification process is the following:

1. When a user makes a transaction, the anti-cheat method must be called. The integration of this method is described in the documentation for a specific platform (the Anti-cheat methods section).

2. After this, the transaction will be checked for validity by devtodev.

3. If the transaction is not valid, the Payment event shouldn't be sent. If the transaction is valid, the Payment event should be sent and it will later get into statistics.

Here you'll find the principles of processing data about real payments, tips for the integration of the Payment event and anti-cheat methods used in devtodev.

Payment event integration

Gross metrics are one of the key indicators of the app’s performance. Therefore, it is important to approach the integration of the Payment event very seriously.

There are four parameters that are sent in the Payment event:

1. Transaction identifier

2. Item name

3. Item price in payment currency

4. Payment currency identifier.

Let’s look at each of the parameters and things to keep in mind when specifying their values while integrating devtodev SDK.

Transaction identifier

This is one of the transaction parameters where invalid values occur most often.

Here are the requirements for this parameter:

1. The transaction identifier is a string value of max 64 symbols. In case this limit is exceeded the value will be shortened to 64 symbols.

2. The transaction identifier must be unique. Data about the transaction with already registered identifier will be discarded by the system and not included in statistics.

3. We recommend using the identifier that has been assigned to the transaction by the payment system as the transaction identifier.

4. In case your app is designed for Apple (iPhone, iPad, iPhone+iPad, or Mac) or Android (Google Play) platforms, the use of the transaction identifier assigned by the app store is mandatory! Transaction identifiers that come from apps on these platforms are checked by devtodev for their compliance with the format used by these markets. This allows us to discard the most obvious cheat transactions. It is also important to know that users who made these transactions are marked as cheaters and all their subsequent transactions are not included in statistics (you can disable this verification process by contacting our managers).

Item name

The item name is a string value that shouldn’t exceed 255 symbols. One of the most common mistakes when specifying the value of this parameter is specifying the localized name of the item in multi-language apps, which leads to the appearance of many records that describe the same item in different reports (for example, Purchases by level). One way to avoid this situation is to specify the name of the item bundle as its name.

Item price and currency identifier

The item price and currency identifier are related parameters, so it makes sense to describe them in one section. The item price parameter contains the sum that a user paid for the item in a payment currency. The price is specified as a floating-point number. The currency identifier parameter must specify the currency as a three-letter code according to ISO 4217 standard (examples: USD, EUR, JPY, CNY, RUB).

When the Payment event reaches devtodev servers, before transaction data is saved, the sum is automatically converted to USD at the actual currency rate at that moment.

If after converting to USD the sum exceeds $1500, the transaction is considered invalid and is not counted in statistics as well (this verification can be disabled by contacting our managers). When the transaction is made with an in-game currency of social network, you first need to convert this currency to any real-world currency.

It is also important to remember that the sum of the purchase sent in the Payment event shows the actual sum that the user paid (this data is used to built Gross metrics). In order to see your net income (Revenue metrics), on the page with app settings in devtodev, you need to specify the coefficient of the part that you get after subtracting the percentage that goes to the platform or publisher. The coefficient can be specified as single or individual for each country (this increases the accuracy in case the part of the sum is spent on taxes and fees that are individual for each country).

Payment validation

Unfortunately, in some situations filling in the parameters of the Payment event is not enough for getting valid data in reports, since there can be cheat transactions. There are several ways to deal with this problem, but all of them are based either on preliminary verification of the transaction or detection of suspicious user actions.

To prevent cheat transactions from getting into the report, you need to either check the transaction in advance and, if the transaction turns out to be invalid, omit sending the Payment event, or mark the user/device as a cheater and exclude their further data from all reports. It is possible to combine both methods for greater reliability.

The process of detecting cheaters based on their behavior within apps depends on the specificity of a particular app. If you have implemented such an algorithm, you can mark suspicious users as cheaters to avoid getting data on their payments in reports. To do that, you just need to execute a method or mark users via API (“Information about a user” section).

One of the conditions for increasing the reliability of transaction verification is implementing it outside of the client app. You can create the system of verification and place it on your own servers or use our out-of-the-box solution - devtodev anti-cheat system.

devtodev anti-cheat allows to check the validity of transactions from the following app stores:

• iTunes

• Google Play Store

• Microsoft Store.

Validating App Store transactions

At the moment of transaction completion (for example, in the method - (void)paymentQueue:(SKPaymentQueue *) queue updatedTransactions:(NSArray *)

transactions at SKPaymentTransactionObserver class) call the method from the library devtodev.framework [DevToDevCheat verifyPaymentWithCompletion: (void (^)(ReceiptStatus status)) completion];

For example:

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions{
    for(SKPaymentTransaction *transaction in transactions){
        switch(transaction.transactionState){
            case SKPaymentTransactionStatePurchasing: 
                NSLog(@"Transaction state -> Purchasing");
                break;
            case SKPaymentTransactionStatePurchased:
                [DevToDevCheat verifyPaymentWithCompletion:^(ReceiptStatus status) {
                    switch (status) {
                        case ReceiptValid: 
                            NSLog(@"ReceiptValid"); 
                            break;
                        case ReceiptSandbox: 
                            NSLog(@"ReceiptSandbox"); 
                            break;
                        case ReceiptNotValid: 
                            NSLog(@"ReceiptNotValid"); 
                            break;
                        case ReceiptServerError: 
                            NSLog(@"ReceiptServerError"); 
                            break;
                        case ReceiptInternalError: 
                            NSLog(@"ReceiptInternalError"); 
                            break;
                    }
                }];
                [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
                NSLog(@"Transaction state -> Purchased");
                break;
            case SKPaymentTransactionStateRestored:
                NSLog(@"Transaction state -> Restored");
                [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
                break;
            case SKPaymentTransactionStateFailed:
                if(transaction.error.code == SKErrorPaymentCancelled){
                    NSLog(@"Transaction state -> Cancelled");
                }
                [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
                break;
            case SKPaymentTransactionStateDeferred:
                break;
        }
    }
}

Validating Google Play transactions

To verify the transaction made in Google Play you need:

1. Response data from an In-app Billing Version 5 purchase request. The validation process requires full values of the keys INAPP_PURCHASE_DATA и INAPP_DATA_SIGNATURE

2. Application's public key for licensing

Here's how to find your application's public key for licensing:

1. Go to the Google Play Console and sign in. Make sure that you sign in to the account from which the application you are licensing is published (or will be published).

2. In the application details page, locate the Services & APIs link and click on it.

3. In the Services & APIs page, locate the Licensing & In-App Billing section. Your public key for licensing is given in the Your License Key For This Application field.

The example of implementing transaction validation:

@Override
 protected void onActivityResult(int requestCode, int resultCode, Intent data) {
     if (requestCode == IN_APP_REQUEST_CODE) {
         String purchaseData = data.getStringExtra("INAPP_PURCHASE_DATA");
         String dataSignature = data.getStringExtra("INAPP_DATA_SIGNATURE");

         if (resultCode == RESULT_OK) {
            DevToDevCheat.verifyPayment(purchaseData, dataSignature, "APP_LICENSE_KEY", new OnVerifyListener() {
                @Override
                 public void onVerify(VerifyStatus verifyStatus) {
                     if (verifyStatus == VerifyStatus.Valid) {
                         //DevToDev.realPayment...
                     }
                 }
             });
         }
     }
 }```

Validating Microsoft Store transactions

The receipt is taken from the result of implementing the following method - RequestProductPurchaseAsync

PurchaseResults purchaseResult = await CurrentAppSimulator.RequestProductPurchaseAsync("some_product");

Cheat.VerifyReceipt(purchaseResult.ReceiptXml,
     (ReceiptVerificationStatus status) =>
     {
         if (status == ReceiptVerificationStatus.ReceiptValid)
         {
             // SDK.RealPayment ...
         }
     });

Recommended sequence of actions when working with transactions

1. Get response about a completed transaction from the payment system.

2. Either send data about the received transaction for verification by calling devtodev anti-cheat methods or use your own tools for transaction verification.

3. If the transaction has successfully passed verification, perform the Payment event.

4. If the transaction hasn’t passed verification, do not perform the Payment event and mark the user as a cheater.