Weekly conversion report with expanded trigger_data to satisfy CPA and affiliation attribution

[onetag-dev]

Allowing advertisers to pay for outcomes, like in CPA affiliation agreements, is a key element to grow traction in digital advertising. In return, advertisers and affiliation platforms need access to granular reporting based on Order IDs or Customer IDs that triggered the conversions.

In the context of event-level attribution reports, the trigger_data field currently supports only 3 bits of information, or as indicated here, it will be possible to increase its cardinality but at the expense of increasing noise. We need to support a use case where the advertiser, within the conversion pixel, inserts an identifier into the trigger_data field, ideally being able to utilize all 64 bits, which is not for tracking purposes but is necessary for matching with external CRM data and enabling the advertiser to verify the quality of conversions. We are aware that the choice of 3 bits is linked to privacy concerns as indicated here, and the issue is related to the association between the bits of information on the ad side and the conversion side. The current choice is to limit the bits on the conversion side: what we would like is the ability to fully leverage the bits on the conversion side (trigger_data) and instead limit the bits on the ad side (source_event_id). The noise introduced by the Phase 2 mechanism (Full Flexible Event-Level) is too high to functionally meet such a use case.

Here we have considered event-level reports, but the industry use case can also be fulfilled with offline periodic reports; there is no strict requirement for them to be real-time.

Available for further clarification, thank you in advance.

[jolynyao]

Hello - thanks for raising this! A few questions on the billing use cases:

• Is the primary use-case affiliate marketing, or are there any other conversion-based billing use cases you support?
• For limiting bits on the ad side, is that because you only need to identify the affiliate marketer or platform? Do you need campaign-level or anything more granular? (to put it more directly, does the advertiser pay the same amount per conversion to the affiliate platform regardless of where the ad was served?)
• How much does noise impact billing use-cases? I imagine that billing per conversion is already somewhat lossy today (more so than billing per click/impression at least).
• Reporting frequency - is this primarily used for monthly billing? Are there requirements that a monthly bill for the prior month is received at day 1 of the new month, or is there any room to introduce a small delay there (e.g. for conversions that happened close to midnight of the prior month)? How does this work with attribution windows?
• How is this currently done on other browsers without 3PCs?

[onetag-dev]

Hello - thanks for raising this! A few questions on the billing use cases:

• Is the primary use-case affiliate marketing, or are there any other conversion-based billing use cases you support?
• For limiting bits on the ad side, is that because you only need to identify the affiliate marketer or platform? Do you need campaign-level or anything more granular? (to put it more directly, does the advertiser pay the same amount per conversion to the affiliate platform regardless of where the ad was served?)
• How much does noise impact billing use-cases? I imagine that billing per conversion is already somewhat lossy today (more so than billing per click/impression at least).
• Reporting frequency - is this primarily used for monthly billing? Are there requirements that a monthly bill for the prior month is received at day 1 of the new month, or is there any room to introduce a small delay there (e.g. for conversions that happened close to midnight of the prior month)? How does this work with attribution windows?
• How is this currently done on other browsers without 3PCs?

Hello, we will proceed to respond point by point:

• The primary use-case is any conversion-based billing that can apply to affiliate marketing but also programmatic advertising.
• The amount paid could vary based on the marketer/platform used, although in our opinion 4 bits should be enough to allow up to 16 values
• Billing per conversion should be more precise than clicks/impressions since the amount paid is significantly higher (some industries can pay up to 500$ per conversion). This means noise would need to be closer to zero to avoid overpaying marketers/platforms that didn't actually drive the conversion.
• Weekly frequency would be ideal
  • Introducing a delay should be perfectly okay.
  • Re: attribution windows, what issues do you see? Since the report is based on the time of each conversion, it should allow the lookback window to go back in time accordingly.
• Other browsers without 3PCs only recently introduced attribution features that also need improvement.

Thank you

[jolynyao]

Thanks (and apologies for the delay)! For affiliate marketing - my understanding is that affiliate marketing attribution is purely click-through conversions (and therefore can be measured via link decoration and first-party cookies). Is that correct?

[onetag-dev]

Hi @jolynyao, thank you for your response. Actually, it's not correct, as within the affiliate marketing realm, there's also the possibility of attributing a post-view conversion, and the industry requires the capability to support this use case, hence our initial request. Do you consider our initial proposal valid (i.e. to fully leverage the bits on the conversion side and instead limit the bits on the ad side), or do you have any alternative approaches in mind to handle these scenarios? Thanks again for the support.

[jolynyao]

Gotcha, I think I misunderstood the use case here (was thinking of affiliate marketing as the case where an advertiser has an affiliation agreement with a 3P to drive leads to their site). Is your use case primarily programmatic advertising where the advertiser is paying an adtech platform per conversion rather than per click (CPC billing) or impression (CPM billing)?

Is billing generally based on one conversion per click/impression? Or would the advertiser ever pay more for multiple conversions that were attributed to the same click/impression?

The reason I ask is that you may be able to use aggregate reporting to do this (and it's easier if you assume one conversion per click/impression), by setting the source-side aggregate key to the 4 bits needed and the trigger-side aggregate key to the conversion ID.