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.