Time to read: 10 min.
The article covers the following topics:
- Why is it important to choose the correct Payout?
- How does the conversion choose an appropriate Payout?
- Particular cases
Why is it important to choose the correct Payout?
When the conversion is being registered, it is checking the offer and its Payouts to choose one of them (or the only one existent) and to place the needed values to Statistics.
Payout in the offer contains the following fields: Offers - > Edit button - > Payouts.
All these fields are shown in the Statistics tab, Conversion slice:
or on the Conversion view page (click the Conversion ID link):
So if the offer contains several Payouts, the system needs to choose the right one. Data in 'Payouts', 'Revenue', 'Currency', 'Goal' fields/columns depends on which Payout was chosen.
How does the conversion choose an appropriate Payout?
Four criterion influence the Payout selection:
- Existence of personal Payout for the Affiliate whom this very conversion belongs to.
- Goal value
- Other fields (county, cities, devices, OS, sub1-sub8)
The first criterion is the main one, and others are applied after this criterion will be checked.
Existence of personal Payout
The general principle is: if there is a personal Payout for the Affiliate whom this conversion belongs to, and other criterion are met, the conversion will be registered under this personal Payout as Approved. If there is no personal Payout - the system will check all general ones.
Personal Payout is always primary to be selected if the system chooses between two similar Payouts: the general one and the personal one (other criterion are met in both ones).
This criterion is the first one applied to the conversion when the system selects the appropriate Payout.
Selection by Goal
Firstly, we recommend reading the article on Goal tracking.
Once the conversion is being registered, it looks at Goal value the Advertiser sent via &goal= parameter. If there is no such a parameter - the Goal value '1' will be placed by default. Then the system compares conversion's Goal value with the Goal values presented in personal Payouts (if any)/in general Payouts (if there are no personal ones).
Selection by other fields
The general principle is the same as Selection by Goal has:
Once the conversion is registered, it looks at country, city, device, OS, and values from sub1-sub8 parameters. Then the system compares conversion's those values with the values presented in personal Payouts (if any)/in general Payouts (if there are no personal ones).
The difference between Goal value criterion and these fields criterion is the following:
1) System checks all above-mentioned fields at once. If at least one of them is not met, the system will check other Payouts presented in the offer according to the Existence of personal Payouts criterion.
2) 'Goal value' field can't be empty, but 'Country', 'Cities', 'Devices', 'OS', and 'Sub1-Sub8' fields can be. It means: if the field is empty in the Payout, it will allow all countries, cities, devices, OS, and values in Sub1-Sub8 parameters.
Selection by weights
Sometimes one conversion can have several appropriate Payouts:
1) When there are several appropriate personal Payouts, where both criterion of Goal values and other fields are met.
2) When there are several general Payouts, where both criterion of Goal values and other fields are met. No personal Payouts for the particular Affiliate exist.
In this case, the system should choose only one Payout. Weights are points that are scored for the particular field in Payout. The more points the Payout has in general, the higher chance of its choosing by the system.
If, after weights checking, there are still the same appropriate Payouts, the random one will be chosen.
Case No. 1: Conversion came with the goal '2'. The following Payouts are presented. Why there are 0 in Revenue and Payouts in the Conversion?
Zero conversion came with the Goal value '2', that's why it was registered under the second general Payout. Other criteria are met in both Payouts.
Case No. 2: Conversion came from Russia. The following Payouts are presented. Why has the system chosen the general Payout, despite there is the personal one from the affiliate, whom the conversion belongs to?
The conversion came not from Belarus. The system found the needed personal Payout, but it also checked other criterion. In this case, the conversion came from another country; that's why the system denied the personal Payout and went to check the general one. Goals are the same, so the conversion was registered under the general Payout.
Payouts selection in the case of Probabilistic Attribution
The process of payouts selection in this situation is almost similar to a usual process, but with several peculiarities.
The first step the system makes is checking whether there is a personal payout. The scheme on this step is absolutely the same.
The second step is to check the goal value. Once again: this stage is performed in the same way.
The third step is checking values for other fields like Countries, Cities, Devices, OSes, and Sub-values. When coming to this stage, the system requires the usage of specific parameters:
Let’s imagine there are the following settings:
If the postback contains parameters &country= and &platform=, then the system will read the values passed in these parameters. If the values meet the settings above, the system will select this payout. If the postback doesn’t have those parameters, the system will read values as ‘All countries’ and ‘All OSes’, which means the payout is wrong, and the system will start looking for another one.
In this case, the system will start looking for other payouts anyway, because the postback doesn’t have information about devices and sub8 values due to the lack of relevant parameters. It is perceived automatically as ‘All devices’ and ‘All sub8 values’.
That’s why we highly recommend not to use restrictions in other fields (‘Cities’, ‘Devices’, other subs). The system will always perceive information from each postback as ‘All cities’, ‘All devices’, and all sub-values regardless of which parameters you use in the very postback link.
Here you can read more information about Probabilistic Attribution.
The fourth step is comparing weights. This stage is performed like it is done in case of usual integration (not Probabilistic Attribution).
The following articles can be helpful:
Should you have any further doubts or questions on S2S integration or Pixel integraion, feel free to address them to Affise Support Team via email@example.com or your internal live-chat as long as to contact your dedicated Account Manager.
Written by Lizaveta Talkachova