登录

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 postbacks section).

However, sometimes ready-made postbacks are not enough:

  • When you add a new partner that MyTracker does not yet support
  • When you want to send postbacks to your own or third-party analytics system

If the available postbacks are not enough for your tasks, please contact support.

Postbacks are not yet available for VK Mini Apps. Learn more

Supported events

You can send postbacks for the following events:

  • Installs
  • New user
  • Re-engagement
  • Re-install
  • First purchase
  • Purchase
  • First custom revenue
  • Custom revenue
  • First Registration
  • Registration
  • First authorization
  • Authorization
  • Custom event

For a mobile app, you can send any postbacks listed. For web apps, only new users, re-engagements, registrations, authorizations, custom revenue are valid.

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.

New user

New user is an authorized user who appeared in the project for the first time. The "New user" event occurs when MyTracker logged the first event with the user ID.

The first event can be not only registration, but authorization, payment, etc. This is possible if the user registered in the application before the app developer connected the MyTracker SDK and configured the user ID transfer.

Unique event: happens only once.

Use case: postbacks are needed if you are optimizing the user engagement campaigns. Postbacks show the actual number of new customers, who may have installed the app on multiple devices or switched mobile and web platforms. Learn more

Re-engagement

Re-engagement is the activity before which a user has not interacted with the app within the "Inactivity window" (by default, 30 days).

Activity involves a registration, authorization, launch, website visit, in-app impression, or payment

You can send re-engagement postbacks by device and user:

  • Re-engagementd is a notification of re-installs and re-engagement on a device.
  • Re-engagementu is a notification of returning registered users to your project. Learn more

As an example, consider the order of actions leading up to the mobile re-engagementd:

  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 an app, registers, authorizes, visits a website, views an advertising in an app, or makes the payment. With each of such user's actions, the "last activity time" is updated and matches the time of the last user's action.
  3. More than 30 days have passed since the "last activity" (30 days is the customisable value. It's called the "Inactivity window", set for each app). MyTracker has recorded no user's actions during that time.
  4. MyTracker records activity → 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 purchase

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

First attribution 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 purchase 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).

Use Events in new user acquisition campaigns, the CA events — in remarketing campaigns.

Purchase

Purchase — any purchase.
Purchase CA — a purchase 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 purchase 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).

Use Events in new user acquisition campaigns, the CA events — in remarketing campaigns.

First custom revenue

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

First attribution 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 custom revenue 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 and Registration postbacks to inform a partner about the quality of the audience they bring in (provided the partner supports campaign optimization).

Use Events in new user acquisition campaigns, the CA events — in remarketing campaigns.

Custom revenue

Custom revenue — any custom revenue.
Custom revenue CA — a custom revenue 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 custom revenue can be used in campaigns based on the "percentage of income" model. They can also be used in combination with regular Install and Registration postbacks to inform the partner about the quality of the audience they are brought in (if the partner supports campaign optimization).

Use Events in new user acquisition campaigns, the CA events — in remarketing campaigns.

First registration

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

This postback relates to Event Flow 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

Registration — 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 Flow 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).

Use Events in new user acquisition campaigns, the CA events — in remarketing campaigns.

First authorization

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

This postback relates to Event Flow 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

Authorization — 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 Flow 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).

Use Events in new user acquisition campaigns, the CA events — in remarketing campaigns.

Custom event

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 | Flutter | React Native | 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 Event and CA event

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 first attribution event 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).

Events and CA events: which to choose

Events are sent according to the first attribution. That means that these events are attributed to the traffic source that led to the device's first appearance (the first time app install or the first time site visit).

CA events are sent in the current attribution. That means that for sites the traffic source is determined the by last-visit model use, and for apps it includes reattribution.

Use Events if you are focused on attracting new audience which have not interacted with your app or site before.

Similarity to reports

If you have already figured out the Flow 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 "Custom event" postback, the number of sent postbacks will be equal to the value of the "Events" metric in reports. And if you enable the "Custom event CA" postback, the number of sent postbacks will match the value of "Events CA" metric.

If you still have questions, please contact our support team.

Was this article helpful?
    Sorry, the translation has not been completed yet