Postbacks

A postback is a way to notify partner about a target action being performed by a user (for example an install stemming from their campaign). These notifications are usually done in the form of HTTP requests.

For most integrated partners we've already configured postbacks — all you need to do is set the sending mode (see the Sending postback section).

However, sometimes ready-made postbacks are not enough:

  • When you add a new partner
  • When you need to send postbacks to your own or third-party analytics system

In these cases, you can create additional postbacks and use them just like the regular ones.

Add postback

Before you read on, ask your partner for documentation or a description of postback requirements.

  1. Select the Campaigns > Partners menu.
  2. In the list, find the partner you want and click on its title or logo.
  3. Go to the Postbacks tab and press the Add button.
  4. Fill out the form:
    • Account * — the new postback will be added to the selected account. For details, see the Account section. Note:
      • If you have only one account, it'll be selected by default.
      • If you are adding a postback for an integrated partner, you can choose any account. We recommend that you contact our support team before you do this. In most cases, integrated partners already have all the necessary postbacks and you don't need to add anything.
      • If you are adding a postback for a new partner, the account to which the partner belongs will be selected automatically.
    • Title * — postback name that will be shown in all future reports.
    • We recommend you standardize the naming scheme. This will make it easier to navigate if postbacks stack up. For example:
      Partner name | install

    • Event * — an install, reattribution or in-app event that triggers a postback. The list of supported events is provided below.
    • URL template * — a template of the URL where the postback will be sent to (HTTP request). Postback parameters are based on standard GET-parameters http://site.com?myparam={myparam}&idfa={mt_idfa}. You can input the parameters directly to the URL or use a parameter kit for URL templates. See details in the section below.

    * — required fields.

  5. Press the Add button.

Now you can set up postbacks for all partner campaigns and add additional postbacks to a specific campaign.

URL template

A URL template is a regular URL that uses so-called macros (a special variable that will be automatically replaced with actual values before a postback is sents to an integrated partner).

To create a URL template:

  1. Type in the base URL in the URL template field type a base part of the URL (until the question mark):
    http://site.com/postback/
  2. Press the Add params button.
  3. Add all the parameters specified in the partner documentation.
    For each parameter:
    1. Specify a Name — this field will match the variable in the GET query.
    2. Select a Param type:
      • Constant – a specific value, sent to the partner without changes.
      • Parameter from a Click URL – if additional GET-parameters are added to the ad click-link, they can be used when sending postbacks. In the "value" field, specify the parameter name from the Click URL.
      • myTracker macros – data that is already in myTracker: device IDs, event parameters, user info. For a complete list, see the section myTracker macros.
      • mt_event_name — the event name. Most relevant for postbacks on custom events.
      • mtpp_* — campaign parameters. See the section Campaign params.
    3. Press the  Add button to the right. As a result, a new parameter will appear in the URL template field, and you will see a new line for adding the next parameter.
  4. Before saving the form, make sure that the URL template contains all the necessary parameters. Don’t forget to press the Add button to the right of the last parameter for which you specified the name and type. Until you press the button, the parameter won't be added to the URL template.

  5. Press the  Add button.

Supported events

You can send postbacks for the following events:

  • Installs
  • Re-engagement
  • Re-install
  • First payment LT/CA
  • Payment LT/CA
  • First Registration LT
  • Registration LT/CA
  • First authorization LT
  • Authorization LT/CA
  • Custom event LT/CA

For a mobile app, you can send any postbacks listed. For web apps, you only need re-engagement, registration, and authorization events.

Installs

An Install event is logged when a user first installs and launches an app with an embedded myTracker SDK

An Install event occurs regardless of a Launch, but if the user never launches the app, the SDK will not be able to send the install data to the server. Hence, myTracker will not register an install

Unique event: happens on a device only once.

Use case: for most CPI partners, install postback is a must for integration.

Re-engagement

Re-engagement occurs when a user launches the app or visits the website after being passive during an "Inactivity window" (30 days by default).

The order of actions leading up to re-engagement (in the context, of mobile devices tracking).

  1. A user installs an app on a device. At this point, the "time of last activity" matches the "time of install".
  2. (optional) The user launches the app. With each launch, the "last activity time" is updated - it becomes the same as the last launch time.
  3. More than 30 days have passed since the "last activity" (30 days - customisable value). It's called the "Inactivity window", set for each app). There were no launches during that time.
  4. The user launches the app → myTracker logs re-engagement.

Non unique event: сan happen on a device multiple times.

Use case: re-engagement postbacks are needed if you are running a remarketing campaign to connect with people who previously interacted with your app.

Re-install

A re-install means a user installed a mobile app again after removing it and being "dormant" during the "Inactivity window" (30 days by default)

The order of actions, leading up to re-installing:

  1. A user installs an app on a device. At this point, the time of "last activity" matches the "time of installation".
  2. (optional) The user launches the app. With each launch, the "last activity time" is updated - it becomes the same as the last launch time.
  3. The user uninstalls the app.
  4. More than 30 days have passed since the "last activity" (30 days - customisable value). It's called the "Inactivity window" and is set for each app). There were no launches during that time.
  5. The user re-installs (and launches) the app → myTracker logs re-install. A Re-install event occurs regardless of a Launch has followed. But if the user never launches the app, the SDK will not be able to send the re-install data to the server.

Non unique event: сan happen on a device multiple times.

Use case: re-install postbacks are needed if you are running a remarketing campaign to connect with people who previously interacted with your app.

First payment LT/CA

First payment LT is the first payment in the entire lifetime of a user/device.
First payment CA is the first payment since the last attribution (install, re-engagement or re-install of an app).

An LT event is unique.
An CA event is not unique: it сan happen multiple times over the lifetime of a device (but only once per attribution).

Use case: postbacks on the first payment can be used in campaigns based on the CPA model, where the target event is "turning the user into a paying". They can also be used in combination with regular Install postbacks to inform a partner about the quality of the audience they bring in (provided the partner supports campaign optimization).

The LT version of events should be utilized in user acquisition campaigns, the CA version - in remarketing campaigns.

Payment LT/CA

Payment LT — any payment.
Payment CA — a payment within the current attribution period (postbacks on the current campaign will stop if reattribution is logged).

Both these Events are not unique, and сan happen multiple times over the lifetime of a user/device

Use case: postbacks on the payment can be used in campaigns based on the "percentage of income" model. They can also be used in combination with regular Install postbacks to inform the partner about the quality of the audience they are brought in (if the partner supports campaign optimization).

The LT version of the event should be utilized in user acquisition campaigns, the CA version - in remarketing campaigns.

First registration LT

First registration LT is the first registration in the entire lifetime of a device.

This postback relates to Event LT metrics named mt_registration.
Note it is postbacks on a device event, not users. It means that if a user has multiple accounts in the app, only one registration will be the first.

Unique event: happens on a device only once.

Use case: postbacks on the first registration can be used in campaigns based on the CPA model, where the target event is "the user registration". They can also be used in combination with regular Install postbacks to inform a partner about the quality of the audience they bring in (provided the partner supports campaign optimization).

Registration LT/CA

Registration LT — any registration on the device.
Registration CA — a registration within the current attribution period (postbacks on the current campaign will stop if reattribution is logged).

This postback relates to Event LT metrics named mt_registration.
Note it is postbacks on a device event, not users.

Both these Events are not unique, and сan happen multiple times over the lifetime of a device. For instance, two users or one user under different accounts can register on the same device.

Use case: postbacks on the registration can be used in combination with regular Install postbacks to inform the partner about the quality of the audience they are brought in (if the partner supports campaign optimization).

The LT version of the event should be utilized in user acquisition campaigns, the CA version - in remarketing campaigns.

First authorization LT

First authorization LT is the first authorization in the entire lifetime of a device.

This postback relates to Event LT metrics named mt_login.
Note it is postbacks on a device event, not users. It means that if a user has already authorized on other devices, authorization on a new one still is considered the first.

Unique event: happens on a device only once.

Use case: postbacks on the first authorization can be used in campaigns based on the CPA model, where the target event is "the user authorization". They can also be used in combination with regular Install postbacks to inform a partner about the quality of the audience they bring in (provided the partner supports campaign optimization).

Authorization LT/CA

Authorization LT — any authorization on the device.
Authorization CA — an authorization within the current attribution period (postbacks on the current campaign will stop if reattribution is logged).

This postback relates to Event LT metrics named mt_login.
Note it is postbacks on a device event, not users.

Both these Events are not unique, and сan happen multiple times over the lifetime of a device.

Use case: postbacks on the authorization can be used in combination with regular Install postbacks to inform the partner about the quality of the audience they are brought in (if the partner supports campaign optimization).

The LT version of the event should be utilized in user acquisition campaigns, the CA version - in remarketing campaigns.

Custom event LT/CA

These are events that are specific to an app. For example, adding to basket, test drive, and so on App developer set the names for custom events and their parameters by themselves, except for events that are pre-configured in the myTracker SDK (registration, login, invite, and levelling up). Learn more for iOS | Android | Unity | Web

Uniqueness

You (your programmers) control the uniqueness of events. Depending on the logic you’ve used for an event, it can be either unique (for example, completing a game tutorial) or repeatable (adding to basket).

Difference between LT and CA

The difference between the LT and CA versions is exactly the same as for other events. LT events happen over the entire lifetime of an audience, and they are not affected by reattribution. CA events can only happen during the current attribution: from the moment of attribution (install, first visit, re-engagement or re-install) to the next reattribution (re-install of the app or re-engagement).

Use case

How you use these depends on the kind of an event and the thinking behind it. The main principles are the same as for the other events:

  • CPA campaigns (replaсing or supplementing the regular install postbacks).
  • The LT version for regular campaigns, CA - for remarketing campaigns.

Custom events are also work well for remarketing lists (for partners that support them, like Google Ads).

LT and CA events: which to choose

Rule of thumb

If you are not running remarketing campaigns, use LT events only:

  • Install
  • First payment LT
  • Payment LT
  • First Registration LT
  • Registration LT
  • First authorization LT
  • Authorization LT
  • Custom event LT

The reverse is also true. For remarketing campaigns you should use CA events:

  • Re-engagement
  • Re-install
  • First payment CA
  • Payment CA
  • Registration CA
  • Authorization CA
  • Custom event CA

Similarity to reports

If you have already figured out the LT (LifeTime) and CA (Current Attribution) report metrics, then understanding the postback events algorithm will be a breeze. The same logic applies.

For example, if you enable the "Payment LT" postback, the number of sent postbacks will be equal to the value of the "Transactions LT" metric in reports. And if you enable the "Payment CA" postback, the number of sent postbacks will match the value of "Transactions CA" metric.

What are LT and CA

Life Time (LT) events and report metrics represent the entire life of a device/user, starting with the first interaction with an app (install or website visit) and until the "death" of the device. Intermediate reattribution does not affect them in any way.

Current Attribution (CA) events and report metrics exist in the context of a single attribution: from the moment of attribution (install, first visit, re-engagement or re-install) to the next reattribution (re-install or re-engagement). What happens outside the current attribution does not affect CA events in any way.

If you still have questions, please contact our support team