Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: aps integration with regards to size mismatch (#140)
## Description The current APS integration does not work correctly if using the GAM size mapping feature. This is because while GAM accepts the size mapping feature, and will request the designated sizes at the designated breakpoints, the current APS integration simply uses the size array of the unit, which includes _all_ potential sizes of the unit. You can see this where the apsSlot is defined in the defineSlots() function. This can result in a request for a size that the unit is not currently set up to display. For example a leaderboard unit may be a 320x100 on mobile, a 728x90 on tablet, and a 970x250 on desktop. All of the sizes exist in the "size" array of the unit. That unit may also contain a GAM size mapping definition that states that the 320x100 can only be requested on mobile, 728x90 on tablet, and a 970x250 on desktop. The APS call, however, will simply include all 3 of those sizes for every request. This can cause breakage on the site as the creative delivered will likely be larger than the size of the ad unit / placeholder. This will also hurt viewability metrics (a 728x90 on mobile won't be fully viewable, etc). Amazon has a newer method of integration called "simplerGPT" which does utilize GAM size mapping definitions. In fact you do not need to define any slot for APS, it will just use the GPT definition. You can read about this method [here](https://ams.amazon.com/webpublisher/uam/docs/reference/googletag-sizemapping.html). I added a simple check for the presence of "simplerGPT" in the config that if present, will utilize the gpt slot definition for the APS calls, instead of the APS unit that is defined. I've defaulted to the older method to avoid any breakage. Testing this I'm able to verify that APS is being called for the correct sizes at the configured breakpoints, versus the older method which requests all listed sizes. --------- Co-authored-by: Travis Czerw <[email protected]>
- Loading branch information