• Overall description
• The logic behind status schemes
• An example
• IF CONDITION block
• THEN (action) block
• Important clarifications

Overall description

Postback processing rules module inside the tracker consists of a group of (status schemes). Each status scheme can be used for specific campaigns and affiliate networks and includes groups of (сonversion status values). Conversion status groups consist of if - then - else condition groups.

For example, E-commerce scheme (the template can be loaded)

On the screenshot below it is applied to all the campaigns in the tracker and consists of three status conversion groups (lead, sale, reject):

In it's turn, each group of conversion statuses consists of a group of if - then - else modules, you you can see a setting consisting of a single "lead" status (several statuses can be used divided by a comma in this group) on a screenshot below:

The logic behind the status schemes

• Status scheme work is initiated by a correct postback.

• Status scheme works only with the data of a single specific click, that had a postback sent to it.

• Every incoming postback goes through an apply for filter on a campaign level. The check is initiated whether the campaign (for the click that belongs to this campaign and had a postback) is a part of any status scheme.

• If the campaign is a part of one or several status schemes, a consecutive check of the status of the conversion against conversion status values of these status schemes is initiated. The check is done top-to-bottom whether the value inside cnv_status or cnv_status2 against a group of conversion status values.

• If the conversion status corresponds to any value of the conversion status values group, then a cycle of comparisons starts that checks if a click corresponds to any value of the if conditions in a specific group of conversion status values.

• In case the if conditions check was successful, then actions of the corresponding condition are executed and the cycle of the status schemes for this particular conversion is finished.

• In case the if conditions check fails, one of the chosen else actions is executed and the cycle of the status schemes for this particular conversion is finished.

Example

Let's assume that a click exists in the tracker clickid=cisfebmvgfgew, that already had a postback with cnv_status=lead and now another postback comes https://domain.com/click?cnv_id=cisfebmvgfgew&cnv_status=reject

Tracker has two status schemes setup (E-commerce and Subscription):

As these two status schemes are applied for all the campaigns of the tracker, a check is initiated to find matching conversion status (reject) against conversion status values in both of the schemes starting with the first (topmost) scheme.

In our example, reject satisfies (E-commerce) scheme, that's why the check against the second (Subscription) scheme is not happening.

Getting into the conversion status values = reject funnel is followed by corresponding if conditions. We got two in our case: the former status of the click was either sale or lead.

As the former status happens to be lead, a corresponding action of the then block will be executed.

This concludes the processing of the postback and no other actions are happening.

In case none of the conditions were met, the postback in our example would have been ignored according to the selected else condition which would end the processing of the postback.

IF CONDITION block

Conditions in this block can:

• Be absent (meaning that this block will be applied to for all the clicks that matched by the conversion status and by condition of being a part of the campaign)

• Info about the state of the click can be used as a condition at the moment of the arriving of the postback. The condition in the example below is as follows: the value of the status of the conversion for the click = lead. Meaning that if the postback comes for a click that already has a lead status conversion - this condition would be fulfilled.

In the example below, if a postback comes for a click that already has event1=5 and event2=6, the condition would be fulfilled.

• The info from the incoming postback can be used as a condition. If the incoming postback consists a payout of more than "2", the condition below would be fulfilled.

• Logical OR can be used between the conditions. Logical AND and OR work exactly like in boolean algebra (AND is processed first, proceeded by OR).

THEN (action) block

Inside the then block three types of actions can be executed (addition, subtraction, install) with three types of the attributes of the click (events, payout, status of conversion if any). Moreover, inside the then block, an outgoing s2 postback can be set up. The actions inside the then block are executed one-by-one - top to bottom.

Numbers as well as a list of tokens can be used as values inside the then block:

• {payout} - the value of the payout from the postback link.

• {event_N} - the value of the corresponding event from the postback link.

• payout - the current value of the payout on a click at the moment of postback coming to the tracker.

• event_N - the current value of the corresponding event on a click at the moment of postback coming to the tracker.

Important mentions

Postback processing rules module was created in order to allow maximum flexibility in setting up schemes and process postbacks. Such flexibility, however, can result in collisions due to lack of attention. And in order to avoid it, you need to keep in mind this:

• Statuses inside the conversion status values must be unique. Meaning that every status must be a part of only one status schema and of only one group of conversion status values.

• All actions of the then block are executed consecutively top to bottom.

• Every incoming postback (even inside the logic of status schemes) always changes the value of Conversion (from 0 to 1, unless it gets into an else ignore postback clause), payout (if stated) and events (if stated). Thus, when making a then block, you need to carefully watch the logic that you apply. In case of E-commerce, for example, these values sometimes need to be reset:

• In order to avoid confusion, you need to watch carefully so that the numbers of events inside the incoming postbacks are different from the event numbers that are used inside the status schemes.

• In order to avoid confusion, you need to watch carefully so that events that are used inside the status schemes are not updated in any other place. It would be best to have a separate group of events only to be used for status schemes.