Compute affiliate commissions based on conversions value

[mbroinizi]

We run a business based on affiliate sites, this use case may not be feasible by using only the Conversion Measurement API due to the limit on data that can be sent in a conversion. Here is an example:

Affiliate site “affiliate-A.com” becomes part of the affiliate network of “ad-tech.com”, it will receive a commission based on sells originated by ads shown in “affiliate-A.com”.

A cellphone vendor “cellphone.com” decides to offer its products through the affiliate program of “ad-tech.com” by creating a series of campaigns and ads of different products through the “ad-tech.com” platform, including a 10% commision for a cellphone ads campaign.

In order to show ads, “affiliate-A.com” installs a script of “ad-tech.com” on its site, so when a page is loaded an ad-request is sent to “ad-tech.com” to retrieve and show an ad.

An ad from “cellphone.com” is returned and displays a cellphone that costs $500. The user browsing “affiliate-A.com” clicks on the ad and is directed to “cellphone.com”, the user decides not to buy the phone, but a new cable for his own phone instead, costing $20. In the checkout page of “cellphone.com”, a conversion is triggered to “ad-tech.com” telling which product, and by which value, was bought by the user.

Nowadays, based on 3rd-party cookies, the script from “ad-tech.com” in ”affiliate-A.com” (cross-site) creates a cookie in “ad-tech.com” domain allowing to track the user when the conversion pixel to “ad-tech.com” is triggered, the conversion pixel also includes detailed data regarding the conversion, such as product ids and values, allowing the computation of the commission, for instance, in the previous example that $2 must be paid to “affiliate-A.com” due to a $20 spent on a cable the user decided to buy after click on a cellphone ad.

However, due to the limits on data that can be sent back in the Conversion Measurement API (3 bits for conversion does not allow granular price tracking), in such scenario, the conversion would be linked to the cellphone ad, which might generate a commission of $50 (10% of the cost of the cellphone advertised) for a transaction of only $20.

I believe that an alternative approach would be to provide aggregated data regarding transactions from different users, for instance, if “ad-tech.com” can receive an aggregate report containing tuples “affiliate-site, campaign-id, sum(amount spent)” it would be enough to address this scenario. Based on the key “campaign-id” we could retrieve the rate (%) of commission defined for the campaign created by the advertiser (advertisers and campaigns may have different commission rates), apply it to total “sum(amount spent)” and pay this amount of commission to “affiliate-site” identified by this key.

[csharrison]

I believe that an alternative approach would be to provide aggregated data regarding transactions from different users, for instance, if “ad-tech.com” can receive an aggregate report containing tuples “affiliate-site, campaign-id, sum(amount spent)” it would be enough to address this scenario. Based on the key “campaign-id” we could retrieve the rate (%) of commission defined for the campaign created by the advertiser (advertisers and campaigns may have different commission rates), apply it to total “sum(amount spent)” and pay this amount of commission to “affiliate-site” identified by this key.

This sounds right to me, this is very similar to the use-cases the aggregate reports in our API (see https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md) is designed to address (i.e. tracking the sum of purchase values for a given campaign). Let us know if there is anything in that proposal that is missing to address the use-case as you see it.