My AppsLive demoNewsArticles

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")
Parameter
Type
Restrictions
Description

orderId

string

from 1 to 65 symbols

A unique transaction ID. Use transactionIdentifier property value in SKPaymentTransaction object in a complete transaction receipt.

currencyCode

string

precisely 3 symbols

price

double

from Double.min to Double.max

The item price in the transaction currency.

productId

string

from 1 to 255 symbols

Item name. We recommend using a bundle or names in the same language.

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)
Parameter
Type
Restrictions
Description

eventName

string

from 1 to 72 symbols

Custom event name.

parameters

DTDCustomEventParameters

key - from 1 to 32 symbols

value - see below

Custom event parameters.

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

Type
Restrictions

int

from Int64.min to Int64.max

string

from 1 to 255 symbols

bool

true/false

double

from Double.min to Double.max

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)

  2. Configure data transfer from the App Store Connect

  3. Configure integration in the devtodev application settings.

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.

Value
Meaning

0

The user skipped the tutorial

-1

The value defines the beginning of the tutorial

1..int

Counting number of completed tutorial stage

-2

The value defines the completion of the tutorial