Time to read: 10 min.
The article covers the following topics:
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):
❗ Also, there is a case with the CPC or CPM type of payment: the payout is checked for a click or an impression. If there is no appropriate payout, no cost is assigned to the click or the impression.
So if there are several payouts in the offer, it is crucial to select the appropriate one.
How does the conversion/click/impression choose an appropriate Payout?
Four criteria influence the Payout selection:
Existence of personal Payout for the Affiliate whom this very conversion/click/impression belongs to.
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/click/impression belongs to, and other criteria are met, the conversion will be registered under this personal Payout as Approved or the cost will be assigned to the click/impression. If there is no personal Payout - the system will check all general ones.
Personal Payout is always primary to be chosen if the choice is between two similar Payouts: the general one and the personal one (other criteria are met in both ones).
This criterion is the first one applied to the conversion/click/impression when the system is selecting the appropriate Payout.
Selection by Goal
This criterion is used only for conversions.
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 criterion is used for conversions/clicks/impressions.
The general principle is the same as Selection by Goal has.
Once the conversion is registered or a click/impression came, it looks at country, city, device, OS, and values from sub1-sub8 parameters. Then the system compares conversion/click/impression'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 criteria and these fields' criteria 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 criteria.
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/click/impression can have several appropriate Payouts:
1) When there are several appropriate personal Payouts, where both criteria of Goal values and other fields are met.
2) When there are several general Payouts, where both criteria 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 a 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, still there are the same appropriate Payouts, the random one will be chosen.
❗ Don't confuse Payouts weights and Additional URLs' weights. It is two different options, which are not correlated with each other.
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 criteria. 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) because 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.