Affiliate Postbacks

  Affiliate postbacks are an essential component for transmitting data about generated conversions, leads, and commissions to third-party affiliate systems. This article covers the fundamentals of setting up affiliate postbacks, their principles, and examples of configurations for networks and operators.

In this article

• What is an Affiliate Postback?
• List of available Macros
• Example of Postback Setup for Keitaro in Scaleo for an iGaming Vertical Case.
• Example of Postback Setup for Operators

An affiliate postback (or callback) is a mechanism used in affiliate marketing to automatically send conversion data (such as sales, registrations, or leads) from the advertiser back to the affiliate network or the affiliate's tracking system. It enables precise tracking of user actions generated through affiliate links and is a critical tool for evaluating the performance of marketing campaigns.

How Does an Affiliate Postback Work in general?

1. Click on an Affiliate Link: When a user clicks on the affiliate link, a unique identifier (Click ID) is created and stored in the affiliate network's system.
2. Conversion Event: If the user completes a desired action (such as a purchase or sign-up), the advertiser’s system records the conversion.
3. Postback Trigger: Once the conversion is recorded, the advertiser sends the conversion data (Click ID, conversion value, and other details) via a postback URL to the affiliate network or webmaster.
4. Data Matching and Attribution: The affiliate system matches the Click ID with previous click data, validates the conversion, and credits the affiliate with their commission.

Benefits of Using Postbacks:

• Accuracy: Postbacks provide precise tracking information, bypassing browser limitations and user behavior issues.
• Security: They often include security tokens to prevent conversion fraud.
• Flexibility: Postbacks can carry various parameters such as revenue, demographics, and detailed conversion information.

Types of Postbacks:

1. Global Postback: Used across all affiliates and offers, applied universally whenever a conversion occurs.
2. Individual, Specific or Local Postback: Customized for a specific affiliate or offer, providing greater control over data handling.

As a manager to manage Affiliate Postbacks, go to Affiliates > Postbacks. The full list of available postbacks is available there. If necessary, you can filter them by status, affiliate, offer, and level. To edit a postback, select it in the list and click on the Edit button. To add a new postback, click "Add Postback".

When adding a postback in this menu, the following options are displayed for configuration:

1. Select Status: Active/Inactive. Select the Active status to make the postback available immediately or pick Inactive to disable the postback.
2. Select Level: In Scaleo for managers available four types of Affiliate Postbacks for setup:
   Global (Affiliate) — the postback will be executed for all Offers run by the Affiliate. It will work with all Goals except the CPC (cost-per-click) type as there are no conversions generated for CPC Goals in Scaleo.
   Specific — the postback will be executed for the selected Offer only. If the Goal is not specified, the postback will be executed for all Goals in that Offer.
   Global (Offer) - the postback will be executed for all the Affiliates for the selected Offer and Goal type.
   All Affiliates and All Offers - the postback will be executed for all Offers run by all Affiliates. This is convenient when it's needed to add a single postback for all Offers and all Affiliates on the platform. It's also worth noting that this postback will not be visible to Affiliates in their postback settings on the platform.
3. Select Conversion Status: All/Approved/Pending/Rejected/Trash. Postback will be executed only for the conversions with the selected status.
4. Select Method: Postback (Cookieless)/HTML Pixel (Cookie-Based). Please learn more about them in the Attribution Methods guide.

Let's explore how affiliate postbacks function using the example of two Scaleo platforms: Demo and Beta.

Scenario:

1. On the Demo platform, a private offer is created and made accessible to a specific affiliate, who will promote this offer using the Beta platform.

2. On the Beta platform, a corresponding offer is also created. The tracking link provided by the Demo platform is added as the landing page on the Beta platform. This ensures that when traffic flows from the Beta platform to the Demo platform, the necessary tracking and postback communication occurs.

https://demo.scaletrk.com/click?o=776&a=6771&aff_click_id={click_id}&sub_id1={sub_id1}&aff_param1={aff_param1}&custom1={sub_id2_hash}

3. Formatting the parameters is essential to ensure that the postbacks function correctly across the two platforms. As with any system, it's critical to pass key identifiers like the click ID (or user identifier). When a conversion occurs, the postback will return the correct data only if the right value is passed in the correct parameter.

Let's break down the tracking link parameters for the Demo platform that are set as the landing on the Beta platform:

    aff_click_id:
    This parameter is crucial because it stores the Click ID from the Beta platform on the Demo platform. When the affiliate postback triggers a conversion, it uses this value to send the correct click ID back to the Beta platform. This ensures accurate tracking and attribution of the conversion.

    sub_id1:
    This is an additional parameter used in the example to pass the source (such as traffic source or referrer) to the advertiser. It helps provide more detailed information for campaign analytics.

    aff_param1:
    This parameter is used to pass the campaign ID from the Beta platform to the Demo platform and eventually to the advertiser’s side. It helps in identifying which campaign generated the conversion.

    custom1:
    This is another additional parameter used to pass the hashed marker of the Beta platform to the advertiser’s side. This hashed value can represent some unique identifier, such as a user or session marker, making it useful for tracking purposes without exposing sensitive data.

In summary, these parameters allow for accurate tracking, ensuring that data such as the click ID, source, campaign, and any additional markers are passed between the Beta and Demo platforms and the advertiser. This setup is essential for maintaining data integrity and ensuring proper postback functioning for affiliates.

4. To ensure that the Beta platform's click ID is captured on the Demo platform, it is stored in the parameter aff_click_id. This parameter is specifically designed in Scaleo to store and pass the affiliate’s click ID. When the conversion is generated on the Demo platform, this aff_click_id is used in the postback sent to the Beta platform, ensuring the right click ID is attributed to the affiliate.

Key points:

• Postback accuracy depends on the click ID, which serves as the primary identifier for conversions.
• By using aff_click_id, both platforms can share user and click data without discrepancies, ensuring that each platform correctly tracks conversions and commissions.

This method is essential in multi-platform affiliate tracking, ensuring smooth and transparent communication between the advertiser’s and affiliate’s tracking systems.

Now let's move on to configuring affiliate postbacks on the Demo platform. In this offer, there are two main actions that will trigger conversions: Registration and First Deposit.

Postback for Registration:

For the registration event, we will set up a standard postback that only triggers when the status is marked as Approved. This ensures that the conversion is recorded only after a verified registration takes place.

https://beta1.scaletrk.com/track/conv?click_id={aff_click_id}&token=dbeaecd3&goal_alias=reg

Postback for First Deposit:

For the deposit event, we will configure an ultimate postback. The reason for this is that the deposit event typically requires confirmation from the advertiser’s side, and the status of the conversion might change depending on their decision. This postback will be set to trigger on all statuses (Pending, Approved, Declined, etc.), ensuring that we receive all updates regarding the conversion status for this event type.

https://beta1.scaletrk.com/track/conv-addchange?click_id={aff_click_id}&conv_status={conv_status}&token=dbeaecd3&goal_alias=dep

The ultimate postback helps by continuously tracking status changes, making sure that any updates, such as reversals or confirmations, are correctly reflected on the affiliate side.

For more detailed information on how ultimate postbacks work and their benefits, you can refer to this article.

The affiliate postbacks have been set up, so let's move on to testing.

To generate clicks, we will follow the tracking link from the Beta platform. Once the clicks are recorded, we'll check the data stored on the Demo platform. The next step involves manually sending postbacks to generate conversions on the Demo platform, which in turn will trigger the affiliate postbacks.

https://beta1.scaletrk.com/click?o=226&a=1&sub_id1=BETA&sub_id2=DEMO&aff_param1=SCALEO

This testing ensures that the affiliate postbacks are functioning correctly, passing necessary click IDs and conversion statuses from one platform to another.

Check Generated Clicks in Demo Platform Logs:

Navigate to the logs on the Demo platform and verify that the clicks from the Beta platform have been recorded correctly. Pay attention to the specific parameters like aff_click_id, sub_id1, and other custom parameters to ensure the click tracking is accurate.

Review Advertiser Postbacks on Demo Platform:

Examine the postback logs for the advertiser on the Demo platform to ensure that postbacks were received successfully after conversions were generated. These postbacks should reflect the correct data for actions such as registration or deposit.

Verify Affiliate Postbacks for Related Events:

Check the affiliate postbacks for the corresponding events (registration, deposit) to ensure they are firing as expected. For each conversion, ensure that the affiliate postbacks are sent back to the Beta platform with the proper click ID (aff_click_id) and status information. Also, confirm the accuracy of the affiliate's custom parameters and macros used, such as {aff_click_id} and {conv_status}.

This thorough check guarantees that the entire flow, from click generation to affiliate postbacks, works seamlessly across both platforms.

We changed the statuses of the deposits: one was set to Rejected, and the other to Approved. Therefore, in the Affiliate Postback Logs, we will see a total of six postbacks:

1. Two postbacks for the registration event conversions.
2. Two postbacks for the deposit event conversions.
3. Two additional postbacks for the update of the deposit statuses—one for the rejected deposit and one for the approved deposit.

This reflects both the initial conversions and the updates to the statuses of the deposits, ensuring that all related events are recorded and sent back to the affiliate platform correctly.

Now let's check the postback logs on the Beta platform to ensure that all conversions were properly received and updated as expected according to our scenario:

1. Confirm that both conversion events for registration and deposit have been logged as expected.
2. Check that the statuses of the deposits—one as Rejected and the other as Approved—are reflected in the logs, confirming that the updates were applied correctly.
3. Verify that there are no discrepancies or missing postbacks, which would confirm that the postback integration between the Beta and Demo platforms is functioning as intended.

By verifying these steps, we ensure that the process of sending, receiving, and updating postbacks has worked seamlessly, adhering to the affiliate tracking setup we configured.

We have successfully configured affiliate postbacks and verified the data flow for conversions between the Beta and Demo platforms. The setup included generating clicks on the Beta platform, transmitting them to the Demo platform via tracking links, and recording click and conversion data appropriately.

We also tested the functionality by triggering various conversion events, such as registrations and deposits, and confirmed that both standard and ultimate postbacks were processed correctly. Updates to the deposit statuses were accurately reflected on both platforms, demonstrating that the integration is working as intended. This comprehensive test verifies that all conversions and status updates are properly transmitted between the platforms, ensuring a reliable affiliate postback setup.

Macro	Description
{aff_click_id}	Affiliate Click ID. Unique ID for every click sent from Affiliate.
{offer_id}	Offer’s ID in platform
{affiliate_id}	ID of Affiliate promoting the offer.
{sub_id1}	Affiliate Sub ID 1 specified in the tracking link.
{sub_id2}	Affiliate Sub ID 2 specified in the tracking link.
{sub_id3}	Affiliate Sub ID 3 specified in the tracking link.
{sub_id4}	Affiliate Sub ID 4 specified in the tracking link.
{sub_id5}	Affiliate Sub ID 5 specified in the tracking link.
{aff_param1}	Affiliate additional parameter 1 specified in the tracking link.
{aff_param2}	Affiliate additional parameter 2 specified in the tracking link.
{aff_param3}	Affiliate additional parameter 3 specified in the tracking link.
{aff_param4}	Affiliate additional parameter 4 specified in the tracking link.
{aff_param5}	Affiliate additional parameter 5 specified in the tracking link.
{link_id}	Offer additional link specified in the tracking link.
{deep_link}	Hyperlink used to direct users to a specific page, section, or content within a website or mobile application, rather than simply taking them to the homepage or general landing page.
{creative_id}	Offer Creative ID used.
{goal_id}	Offer’s goal ID in platform.
{goal_name}	Offer’s goal name in platform.
{goal_alias}	Offer’s goal alias in platform.
{offer_name}	Offer’s name in platform.
{offer_currency}	Selected offer's currency.
{adv_order_id}	Advertiser's order ID specified upon the conversion.
{adv_user_id}	Advertiser's user ID specified upon the conversion. Player ID/Trader ID specified upon the commission.
{adv_param1}	Advertiser additional parameter 1 specified upon the conversion.
{adv_param2}	Advertiser additional parameter 2 specified upon the conversion.
{adv_param3}	Advertiser additional parameter 3 specified upon the conversion.
{adv_param4}	Advertiser additional parameter 4 specified upon the conversion.
{adv_param5}	Advertiser additional parameter 5 specified upon the conversion.
{amount}	Sale amount/Deposit amount on Advertiser side.
{payout}	Value of Afiliate's payout/commission
{conv_status}	Conversion status (approved / pending / rejected / trash).
{transaction_id}	Transaction ID. Unique ID for every transaction in platform.
{ip}	IP address that started the click session.
{user_agent}	User's agent string determined at the time of click.
{device_type}	User's device string determined at the time of click.
{device_os}	User's OS string determined at the time of click.
{connection_type}	User's connection type string determined at the time of click.
{mobile_operator}	User's mobile operator string determined at the time of click.
{geo_country_code}	User's country code determined at the time of click.
{geo_country}	User's country determined at the time of click.
{geo_region}	User's region determined at the time of click.
{geo_city}	User's city determined at the time of click.
{idfa}	Apple iOS Advertising Identifier (IDFA).
{gaid}	Google Android Advertising Identifier (GAID).

Setting up a postback from Scaleo to Keitaro involves ensuring proper tracking of conversions through a multi-layer system, involving the affiliate tracker (Keitaro), the affiliate network (Scaleo), and the advertiser. Here's a detailed breakdown of how this works:

Traffic Flow:

1. Traffic Direction: The traffic originates from the Keitaro tracker, where all the clicks from your traffic sources are first sent.
2. Forwarding to Scaleo: From Keitaro, traffic is directed to Scaleo, the affiliate network, which then redirects the user to the advertiser's landing page.
3. Conversion Postback Flow: When a user completes a target action (e.g., registration), the advertiser sends a postback to Scaleo. Scaleo then generates an affiliate conversion postback and sends the conversion data back to Keitaro, marking a successful event in the Keitaro system.

Key Differences Between Keitaro and Scaleo:

• Keitaro (SUBID): Keitaro tracks clicks and conversions using a parameter called SUBID.
• Scaleo (Click ID): Scaleo, like many affiliate networks, tracks conversions using Click ID.

To ensure the systems communicate effectively, the affiliate needs to pass the SUBID from Keitaro into Scaleo’s aff_click_id parameter. This allows Scaleo to identify which click to credit when the conversion happens.

Generating and Passing the Correct Parameters:

• Affiliate Link in Scaleo: The affiliate will generate a tracking link within Scaleo, which they will use as the destination offer URL in their Keitaro campaign.

Example Scaleo tracking link: https://demo.scaletrk.com/click?o=776&a=2&aff_click_id={subid}

• Here, {subid} is a Keitaro macro that dynamically passes the SUBID into Scaleo’s aff_click_id parameter. This ensures that the Keitaro SUBID is recorded in Scaleo as the aff_click_id, allowing for correct postback functionality.
• Setting up the Campaign in Keitaro: The affiliate creates a campaign in Keitaro and adds the Scaleo tracking link as the destination URL in a flow. This ensures that the traffic flows from Keitaro to Scaleo, with the necessary tracking parameters passed correctly.

Postback Structure:

Advertiser to Scaleo: When a conversion occurs, the advertiser sends a postback to Scaleo, typically passing conversion details such as registration or purchase data.

Scaleo to Keitaro: Scaleo then triggers an affiliate postback, which includes the aff_click_id (Keitaro SUBID) in the postback URL, sending the conversion event back to Keitaro.

Here are examples of common affiliate postbacks that Keitaro users typically add in Scaleo for the iGaming vertical. In such offers, there are generally two main goals: registration and deposit.

1. Postback for Registration

This postback gets triggered when a user registers on the platform. In this case, the postback in Keitaro might look like this: https://keitaro-traffic.io/2d63972/postback?subid={aff_click_id}&status=lead

• subid: This is a required Keitaro parameter that tracks conversions based on clicks. In this setup, the subid will be populated with the aff_click_id using the macro {aff_click_id} because when the click was generated, the subid from Keitaro was passed and stored in Scaleo's aff_click_id parameter.

2. Postback for Deposit

For the deposit, which is often considered a sale or action that generates revenue, the Keitaro postback might look like this: https://keitaro-traffic.io/2d63972/postback?subid={aff_click_id}&status=sale&payout={payout}

• subid: Again, this is the mandatory parameter that will be passed with the aff_click_id macro.
• payout: This is the payout or commission earned, passed via the {payout} macro from Scaleo.

Key Notes:

• subid is a crucial parameter for Keitaro, and changing its name or structure would break the tracking flow.
• The macro {aff_click_id} is critical because it ensures that Keitaro's subid value (from the original click) is correctly tracked and linked when a conversion happens in Scaleo.

Conclusion:

This setup ensures that conversions generated by Keitaro traffic, tracked through Scaleo, are accurately recorded in both systems. By properly configuring the postback and tracking parameters, affiliates can ensure they receive credit for all valid conversions, and data flows seamlessly between the advertiser, Scaleo, and Keitaro.

Operator platforms work with affiliates through various commission models, such as CPA (Cost Per Acquisition), RevShare (Revenue Share), and CPL (Cost Per Lead). These platforms typically offer fewer goal types for setting up affiliate postbacks. Let's go through each type of goal and when to use them in postback settings:

1. CPA (Cost Per Acquisition): This goal type corresponds to CPA commission models, which means the postback should trigger only when the affiliate earns a CPA commission. Use this goal type when the operator pays the affiliate based on specific actions, such as a user acquisition.
2. CPL (Cost Per Lead): Similar to CPA, this goal type corresponds to CPL commissions. The postback should be triggered when the affiliate is paid for a lead generation, such as when a user fills out a form.
3. REG (Registration): This goal type is used when an affiliate wants to receive data each time a player completes registration at the online casino. Affiliates commonly use this to track registrations without waiting for other actions like deposits.
4. DEP (Deposit): This goal type is set when the affiliate wants to receive data every time their referred player makes a deposit in the online casino. This is often used for revenue tracking.
5. RevShare (Revenue Share): This goal type is tied to RevShare commission models, where affiliates earn a percentage of the revenue generated by their referred players. The postback should trigger only when a RevShare commission is credited to the affiliate.

Example of Affiliate Postbacks on an Operator Demo Platform:

The affiliate on the operator platform could have four different postbacks set up:

• For Registration: To get player information whenever they complete the registration at the online casino.
• For Deposit: To get player data every time a deposit is made.
• For CPA Commission Events: To receive notifications when CPA commissions are credited.
• For RevShare Commission Events: To receive updates when RevShare commissions are credited.

These postbacks ensure that the affiliate receives detailed and relevant information for tracking conversions and commissions according to the specific commission models they are working with.

In conclusion, setting up postbacks on operator platforms for affiliates involves defining the correct goal types based on the commission models used by the operator. The most common goals include CPA, CPL, Registration (REG), Deposit (DEP), and RevShare, each corresponding to specific events or payouts. Affiliates need to ensure their postback configurations align with the operator’s commission structure to accurately track conversions, registrations, and revenue-generating actions.

For affiliates working in verticals like iGaming, this setup ensures they receive timely and relevant data, helping them monitor player activities and commissions. Properly configuring postbacks enhances transparency and helps avoid issues like missed conversions or inaccurate reporting, ensuring a smooth flow of information between affiliates and operators.