mileRtdProvider initial commit#14636
Conversation
|
Why is prebid involved? Why don't you just have your script call the gam set targeting API? |
We hook on Prebid's As a RTD module it makes it easier for the publishers to integrate this functionality to their stack. |
|
@codex is this module affecting the bid request or processing the bid response in any meaningful way or are they just using this module to send data to gam |
|
Codex couldn't complete this request. Try again later. |
jdcauley
left a comment
There was a problem hiding this comment.
A few observations after reviewing the implementation against the patterns used by the other ~51 RTD modules in this repo.
The main concern is the isFlooringEnforcedForAuction gate — this module only applies targeting when floor enforcement is active. Across the entire RTD module ecosystem, no other module gates behavior on enforceJS or enforcements, and only one (oxxionRtdProvider) even references floorData at all. This makes the module look purpose-built to influence floor pricing rather than provide general real-time targeting data.
Suggested changes:
-
Remove the floor enforcement gate. If the targeting data is genuinely useful for ad serving, it should apply regardless of floor state. This is the most important change to address the architectural concern.
-
Consider using
getTargetingData()instead of directslot.setTargeting()on GPT. Only 2-3 modules out of 51 directly manipulate GPT slots; the standard pattern (used by ~13 modules) is to return targeting through Prebid'sgetTargetingData()interface. This makes targeting transparent to publishers and other modules. -
If the event hooks (
onAuctionInitEvent/onBidResponseEvent) are needed overgetTargetingData(), document why. These hooks are rare (2-3 modules each), so clarifying what they provide that the standard interface doesn't would help reviewers.
| if (targetingValue != null) { | ||
| slot.setTargeting(TARGETING_KEY, targetingValue); | ||
| } | ||
| }); |
There was a problem hiding this comment.
Only 2-3 out of 51 RTD modules directly manipulate GPT slots. The more common pattern (~13 modules) is to implement getTargetingData() on the submodule, which returns targeting through Prebid's pipeline and makes it visible to publishers.
Suggestion: consider replacing setSlotTargeting with a getTargetingData() implementation on the submodule definition. This would also eliminate the direct googletag dependency.
There was a problem hiding this comment.
This is a great point, we should put this in our cove review guidelines and open an issue to fix the 2-3 you mention
There was a problem hiding this comment.
Hi, the intent of our RTD module is to influence GAM pricing rules and we wish to do it by passing relevant targeting to the ad server(GAM). We agree with your assessment about floor enforcement gate and we have removed it.
However we require the use of setTargeting to ensure that the GAM targeting happens timely. getTargetingData on the other hand is triggered at auctionEnd which can be too late for the targeting keys to be passed to GAM because of failSafe timeouts that most publishers implement. We would want our targeting to be triggered at auctionInit and bidResponse which is not possible with your suggested method.
We also found out this GPT setTargeting pattern being used by other RTD modules, some examples of which are as below:
relevadRtdProvider
sirDataRtdProvider
Please review and let us know how to proceed, thanks.
There was a problem hiding this comment.
this is the main hang up at the moment, i've opened an issue to fix those two.
This is interesting: "getTargetingData on the other hand is triggered at auctionEnd which can be too late for the targeting keys to be passed to GAM because of failSafe timeouts that most publishers implement. " and we'll talk about it in the next PMC
There was a problem hiding this comment.
i closed that pr, great point
There was a problem hiding this comment.
@mohanjpAtmd please proceed with using our methods, we're picking up #14706 (comment) right away to solve the issue you identified
There was a problem hiding this comment.
@mohanjpAtmd there's a pr on the board to solve the issue you flagged about targeting; we welcome your feedback
There was a problem hiding this comment.
Hi @patmmccann, with this change we are able to use adUnit.adserverTargeting to set the targeting at auctionInit at ad unit level. However we also need to be able to set targeting at bidResponse event. Which utility function do you suggest we use for this?
There was a problem hiding this comment.
Hi @patmmccann On testing this again we are now able to verify that adUnit.adserverTargeting approach works for us in setting the targeting on auctionInit and bidResponse events and these targetings are getting passed even when the failsafe timeout triggers before the Prebid's auctionEnd.
The change to use adUnit.adserverTargeting is committed to this branch. Please review and let us know how we can proceed.
|
Whoa there partner! This project is migrating to typescript. Consider changing the new JS files to TS, with well-defined types for what interacts with the prebid public API (for example: bid params and configuration). Thanks!
|
Pull Request Test Coverage Report for Build 23860972488Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
| const slotElementId = slot.getSlotElementId?.(); | ||
| const adUnitPath = slot.getAdUnitPath?.(); |
There was a problem hiding this comment.
I recommend using isAdunitCodeMatchingSlot to keep it consistent with how the rest of prebid decides how to match ad units with GPT slots.
There was a problem hiding this comment.
hi @dgirardi we need the actual slotElementId and adUnitPath values, not just checking if they match. We use them to retrieve the targetingValue as shown in line number 151.
patmmccann
left a comment
There was a problem hiding this comment.
should be ready to use our methods with the failsafe timeout concern fixed
Type of change
Description of change
New RTD module for Mile Tech(Automatad). This module hooks on Prebid's lifecycle events like onAuctionInitEvent and onBidResponseEvent which RTD core module provides and adds ad server targeting as key values based on an external loaded JS which provides the values.
Configuration
Use the RTD module with provider name
mile:Params
runtimeScriptUrl(optional): URL of runtime script to load.runtimeGlobalName(optional): global object name exposinggetMileTargetingByAdUnit; defaults tomileRtdRuntime.