Exchain Analytics Adapter #12161
Exchain Analytics Adapter #12161
Conversation
|
This module should not use |
|
@ChrisHuie Renamed |
|
@ChrisHuie There is failed test on safari. But it looks like flaky test. It pass locally. Can we rerun it? |
|
Appears to be a resubmission of #12018 ; neither of these are analytics modules as neither calls register analytics |
|
The tid is the correct solution to this problem and this project has done a lot of work to make them reliable. We've modified many bid adapters to ensure the tid is always the same in every request eg #9969 #9073 and a variety of other pr's. If you see two different tids go out on the same impression please file a bug report. |
| } | ||
| }; | ||
|
|
||
| adapterManager.registerAnalyticsAdapter({ |
There was a problem hiding this comment.
This seems to call register analytics adapter but doesn't do any analytics, why isn't this an rtd module?
| import { MODULE_TYPE_ANALYTICS } from '../src/activities/modules.js'; | ||
|
|
||
| export const MODULE_NAME = 'ExchainAnalyticsAdapter'; | ||
| const EXCHAIN_PREBID_GVL_ID = 6969 |
There was a problem hiding this comment.
I didn't find any documentation about logic of getting this ID. Where I can find it?
There was a problem hiding this comment.
well this module appears to be vendorless #11536 ?
| onBidCatch: function(bids) { | ||
| bids.forEach(bid => { | ||
| bid.ortb2Imp.ext.tid = this.generateUUID(); | ||
| }); |
There was a problem hiding this comment.
This is already filled in by prebid core using nearly identical logic
|
Wherre do you work? If you're a prebid member, I suggest we chat in committee |
|
It appears you work at startupsoft in lviv. If your client company is a member, we'd be happy for you to join our meeting as their guest to discuss this pr. For now, it seems you are attempting to implement something that is already part of prebid.js and publishers could replicate simply by setting enableTids: true |
|
Hi Pat Mccann. 'Slonafanya' is an employee of a developer contracted to our very early stage start up: Exchain Pte Ltd. My name is Patrick Looram and I am one of Exchain's co-founders. We are not members of prebid.org (yet) but were wondering if we can arrange a short call with you to get your advice on the best way to get our module approved. We are wondering, for example, if we submit it as a Custom Targeting Module it will be simpler to get approval? We are working with some large publisher groups on several products that are based on sending our own unique ID in their bid_requests. The publishers have asked us to explore implementation via a prebid.module as this will simplify adoption for them. So this process is new to us. There are number of reasons why our products will not work using either of the tid parameters. We will be happy to explain on a call if that can be arranged. |
|
Dear Mr @patmmccann , do you require anything else from me on a technical level before you are in a position to reply to Mr @plooram message? |
|
Hi @patmmccann and @lksharma, We see that this PR is still showing an Open status and that all checks have been passed. Is there anyway we can have a short discussion to understand what we can do to gain merger approval on this request or a modified one? Thanks for your time. |
|
Hi, I do not see any path to merging this module. It appears to be an antipattern. |
|
Hi @plooram ; there is no path to merge on this module without a defense of it in committee. As you are not members, there is no one to defend it. |
Module:
ExchainAnalyticsAdapterThe use case for the Exchain IOID is to allow a means for DSPs, exchanges and other adtech platform operators to deduplicate bid requests across multiple supply paths. Our module will create unique, standardized IDs for each Impression Opportunity that will remain persistent throughout the Impression Opportunity journey (ad request - bid request - bid response - win notification...)
We have looked into using Transaction IDs (3.2.2 Object: Source: tid and 3.2.4. Impression: Ext: tid) for this purpose and adtech platforms report that it is not reliably useful for deduplication purposes: TIDs are typically populated by SSPs so the same impression opportunity will have different TIDs when it arrives at the DSP from more than one SSP/Supply path. If/when a publisher populates a prebid ad request with a Transaction ID there is no standardization across publishers so different Impression Opportunities can have identical Transaction IDs.
When subsequent SSPs or exchanges receive the ad request, they may regenerate or modify the Transaction ID to ensure uniqueness within their systems and for their own tracking purposes. This then means that the DSP will receive different Transaction IDs for the same Impression Opportunity rendering deduplication based on Transaction ID meaningless.
The Exchain IOID will solve the growing bidstream bloat problem that all platforms are attempting to address with somewhat indiscriminate throttling based on a wide range of imperfect probabilistic methodologies. The Exchain IOID will also benefit publishers by creating a higher probability that their ad requests will not be throttled and therefore seen more often by more buyers
Type of change
contact email: [email protected]