Basic methods

Please take a look at our Expert tips before integrating the events.

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.

DTDAnalytics.realCurrencyPayment(orderId: "Order ID", 
                                 price: 12.5, 
                                 productId: "Product ID", 
                                 currencyCode: "USD")

By default (easy to change in the app’s settings) devtodev server invalidates transactions with previously-used identifiers. Besides, the server performs identifier checks by its outer appearance in order to avoid obvious fraud.

If you want to exclude fraud payments from your reports altogether, before creating ‘Real Currency Payment’ event, use devtodev anti-cheat feature.

Custom Events

If you want to track non-basic events, you can create custom events of your own. How you are going to apply them, depends solely on you.

Attention! We strongly recommend that you do not use custom event properties to transfer and store data that fits the definition of personal data!

DTDAnalytics.customEvent(eventName: "Event name")

If you want to pass custom parameters, use DTDCustomEventParameters class instance.

let parameters = DTDCustomEventParameters()
parameters.add(key: "key for string value", value: "string value")
parameters.add(key: "key for int value", value: 10)
parameters.add(key: "key for bool value", value: true)
parameters.add(key: "key for double value", value: 12.5)

DTDAnalytics.customEvent(eventName: "Event name", parameters: parameters)

The following data types can be passed using the DTDCustomEventParameters object:

devtodev supports no 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 in the parameters.

For example, if you need to track purchasing “Paper” and “Pen” items, then you don’t need to create two events with the names “Paper Purchase” and “Pen Purchase”. Create a “Purchase” event and add an “Item” parameter to it with the appropriate “Paper” or “Pen” value. 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 gets 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.

Subscriptions

The described method is available beginning with version 2.1.0!

Tracking of subscriptions is now available for Apple App Store and Google Play only.

Please note that in order to track subscriptions, you need to do the following:

  1. Call the subscriptionPayment method (described below)

To track your income from subscriptions, you need to call the following method at the moment of the subscription purchase even if the user signed up for a trial subscription: func subscriptionPayment(transaction: SKPaymentTransaction, product: SKProduct).

For example:

extension Purchases: SKPaymentTransactionObserver {
  func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {
    for transaction in transactions { 
      switch transaction.transactionState {
      case .purchased:
          // Your code ...
          if let product = products?[transaction.payment.productIdentifier] {
             DTDAnalytics.subscriptionPayment(transaction: transaction, product: product)
          }
      case .restored:
          // Your code ...
      case .failed:
          // Your code ...
      default:
          // Your code ...
      }
    }
  }
}

Further user actions - renewal, unsubscription, etc. are tracked by using the data received from AppStore in the server-server format. You will need the corresponding setting for it.

Also, if you want to track changes in the status of the subscriptions purchased before devtodev SDK 2.0 integration, you need to transfer your history of previously purchased subscriptions to devtodev.

The SDK monitors the need for historical data to avoid sending out excessive queries to App Store. Use the DTDAnalytics.isRestoreTransactionHistoryRequiredmethod to check whether or not there is a need in sending out the information about the previously purchased subscriptions to devtodev. The method returns BOOL value.

An example of a purchase history query with verification of the need for it:

DTDAnalytics.isRestoreTransactionHistoryRequired { isNeedRestore in
  if isNeedRestore {
    DispatchQueue.main.async {
      SKPaymentQueue.default().restoreCompletedTransactions()
    }
  }
}

Use the DTDAnalytics.subscriptionHistory method to transfer the list of previously purchased subscriptions received from App Store.

If your project accounts users by user ID (not by device ID) and the device is used by more than one user, you need to filter the transaction history so that it will contain only those transactions that belong to the active user. Otherwise, subscriptions of all device users will be attributed to the user who was the first to launch the app after the integration of subscription tracking.

extension Purchases: SKPaymentTransactionObserver {
  func paymentQueueRestoreCompletedTransactionsFinished(_ queue: SKPaymentQueue) {
    // Your code ...
    let restoredTransactions = queue.transactions.filter { $0.transactionState == .restored }
    DTDAnalytics.subscriptionHistory(transactions: restoredTransactions)
  }
}

To recover the purchase history, the user should be logged in with his Apple ID. Be mindful of this before starting the recovering process.

Onboarding (tutorial)

The event allows you to track tutorial completion and identify the stages where you lose new users.

We recommend tracking the starting point (value -1) before beginning the first tutorial stage, then passing the counting number of every completed stage after its completion (integers larger than 0), and at the end, marking the moment of the last tutorial stage completion (value -2).

If your app has an option of skipping the tutorial and the user has used it, then it’s necessary to send a refusal value (value 0) only.

DTDAnalytics.tutorial(step: 1)

The method takes on the step value with an integer type.

Level up

This event is for games only. It is worthwhile to integrate this event into a game type project, as specified in the application settings. In projects with the “app” type, game events will not be tracked and displayed in the interface, even if they are integrated. You can verify and change the project type in Settings → General settings.

The event allows you to analyze the distribution of players over different game levels, monitor the in-game currency balance by levels. You can find more information about the right moment to use LevelUp event here.

The event should be dispatched right after the level-up. The number of the level reached is passed to the level parameter.

DTDAnalytics.levelUp(level: 2)

To monitor the average account balance of in-game currency by the end of each level, dispatch in-game currencies (resources) names and their amounts to the method signature:

let balance: [String: Int] = ["Currency name 1": 100, "Currency name 2": 10]
DTDAnalytics.levelUp(level: 2, balances: balance)

Attention! The number of tracked in-game currencies or resources (their unique names) should not exceed 30 at all times.