Skip to main content
Deutsch Français Nederlands

Implementation of Revenue Share Tracking

  • Updated

Revenue Share is a compensation model within affiliate marketing where the payment to publishers (affiliates) is based on a recurring amount or percentage of the revenue they generate. This model is ideal in sectors where customer value varies over time or where retention (customer retention) is important. Think of campaigns in the dating and finance industries, where subscriptions and contracts run for longer periods and can be cancelled in between, or games of chance where a portion of the provider's profit is shared with the publisher over a longer period.

Because Revenue Share pays out at different times over a longer period, a server-side solution is always needed for tracking.

Note: More information about the parameters, DCI, and how to call them can be found in the article on Server Side Tracking.

When to use Revenue Share?

This model is suitable when an advertiser aims for a long-term customer relationship and recognises that affiliates play a crucial role in attracting long-term valuable customers. It offers the ability to pay out commissions to publishers over a longer period, for example based on retention.

The difference with standard Server Side Tracking

In standard server-side tracking, a transaction is directly linked to a publisher's click, but the link between customer and publisher is not permanently stored.

Revenue Share Tracking differs in this respect, as it focuses on measuring ongoing customer relationships. For ongoing (retention) commissions, it is crucial that transactions can still be correctly linked to the right publisher after a longer period, even if the original click information is no longer available. Therefore, we permanently link a customer account in Revenue Share campaigns to a publisher from the affiliate programme.

Note: This article requires a higher level of technical expertise than pixel tracking. For pixel-based solutions, please read: Implementing the conversion pixel.

Implementation Instructions

  1. Using the Daisycon Click Identifier (DCI) and registering customer accounts
    • In the first tracking call (/at/), a unique customer ID and the DCI are stored. The DCI is the 'Daisycon Click Identifier', Daisycon's unique identifier for a click.
    • Example: 
      https://jdt8.net/at/?ci=[CAMPAIGN_ID]&at=[UNIQUE_CUSTOMER_REFERENCE]&dci=[DCI]&pn=[DESCRIPTION]
    • Here the customer number (at) is linked to an affiliate via the DCI.
  2. Registering Revenue Share Transactions
    • For the second call (/rs/), the same customer number (at) is used. The DCI is no longer needed here because the link between customer and affiliate was already established in the /at call.
    • Example: 
      https://jdt8.net/rs/?ci=[CAMPAIGN_ID]&at=[UNIQUE_CUSTOMER_REFERENCE]&a=[TRANSACTION_AMOUNT]&cur=[CURRENCY_CODE]&pn=[DESCRIPTION]
    • The unique customer reference (at) is the same as a previously registered customer number (with /at/). This way, we find the right publisher for the commission without DCI or click information.
  3. Dashboard and Statistics
    • Revenue share transactions are tracked separately in the Daisycon dashboard under 'revenue share statistics'.
    • Revenue share transactions are typically converted 1-to-1 into Daisycon transactions.
    • In certain sectors, multiple transactions can be collected and periodically settled in one transaction. If this is necessary, contact your campaign manager or startup specialist.

Conclusion

This approach ensures accurate and long-term measurement of customer value in affiliate programmes at Daisycon. By using the Daisycon Click Identifier (DCI) at the initial link and tracking transactions based on the customer number, attribution remains correct even if the click data disappears over time and the relationship with the customer continues.

Related articles