-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Slot-Size macro replacement on render_url #311
Comments
+1 We also have the same issue. We currently bypassed this by injecting the width and height on our own with Javascript during rendering. It works because stuff is still rendered the iframe but it won't work with the fenced frame implementation.
EDIT: |
I’m sorry, I haven’t looked in to the capabilities of fenced frames yet. Is it possible to get access to its dimension attributes via JS or CSS from inside as in regular iframe? If this is possible, why wouldn’t you implement responsiveness from the inside of the ad document? |
The fenced frame is able to access its own dimensions as a regular iframe. |
OK. Indeed. If the size is available from inside the fenced frame we could migrate the logic client side with JS/CSS in the long run. |
I know this doesn't answer your question, but is it possible to use responsive techniques for asset selection and layout to enable a single |
This doesn't fit our current use-case and it would require significant re-work throughout our ad-stack in order for something like this to work. Currently we depend on the creative size to be present in the url in order to know which version of the creative to return. |
If nothing else, @tylerdev0, you could have each view URL include "&dim=unknown", and in response to seeing such a URL you could serve a piece of JS which measured the width and height of the window it was in, and then navigated itself to the same URL with the dimensions filled in properly. This would of course take one extra round-trip between the browser and the server, so I see the efficiency gain from including the size via macro expansion. But if the goal is a proof-of-concept working within the currently-running system, it seems like this would get you there, right? |
@michaelkleber That is an interesting idea; I think we could test something like this for the purposes of the origin trial. |
@shivanigithub What would be the JS APIs to retrieve the width and height from inside a fenced frame ? I tried |
@fhoering Both document.documentElement.clientWidth and window.innerWidth are returning non-0 values for me inside a fenced frame. Can you check that the FF is created and navigated successfully: the required Chrome flags are enabled: FencedFrames and PrivacySandboxAdsAPIsOverride and the document loaded inside the FF has the correct supports-loading-mode:fenced-frame response header? |
@fhoering Followed this up further within the team (cc @gtanzer ) and it seems there is a time lag between the creation of the FF element and the point at which innerWidth starts returning the actual size (this may not be fenced frames specific though). Once the fenced frame document is rendered on the screen, the APIs should reflect the actual size. Any time lag because of this will be hopefully resolved with the proposal in #312 |
OK. Thanks for having a look @shivanigithub I tried again with some real ad and the script below in latest Chrome Beta. It actually seems to work.
The rendering seems not be be exactly the same however iframe vs fencedframe. I there a way to deactivate the border and scroll ? |
Yes, you can add
|
I have been working on a Fledge implementation and have come across an issue regarding support for ads with multiple options for dimensions.
For a given ad, we may have multiple different creative dimensions that we support. For example we may have a separate creative for each of the following dimensions:
[[160, 600], [245, 250], [300, 250], [300, 600], ...]
We refer to these as "responsive ads" and this allows us to place a bid for a single ad and adapt the creative response based on the slot-size which was communicated through the bid request.
In the current Fledge spec, the
render_url
for an ad that is included in an interest group is a static url with no support for macro replacement. This means that in order for us to support multiple sizes we must include multiple copies of the same ad within an interest group and our bidding function must manually filter the list of ads to find ads whose creative dimensions match the slot-size.This duplication of every single ad to include all of the sizes which it supports will eventually become un-scalable for our needs. As an example if we wish to include 100 ads in an interest group, and we must include 15 copies of each ad (one for each dimension we support) it would require us to insert 1,500 ads in an interest group. Not only does this add bloat to the interest group object stored in the browser, but it also impacts the latency of our bidding function as it must perform manual filtering for the slot size.
In addition to impacting the size of the interest group and the performance of the bidding function, this also impacts k-anonymity of our ads in a negative way. Each distinct creative size would be subject to k-anonymity independently even though they are effectively the same ad. For less common slot sizes it would become difficult to meet k-anonymity if we treat each creative dimension as its own ad.
Would it be possible for the render_url to support a macro for the slot height and width so that we can respond with an appropriately sized creative. For example the render_url could be formatted as:
https://cdn.com/url-of-winning-creative.html?size={%SLOT_HEIGHT%}x{%SLOT_WIDTH$}
The exact formatting doesn't really matter as long as there is some method to communicate the slot size at the time of the creative request.
The slot dimensions are already communicated via the contextual request so this should not have any impact on privacy. Slot sizes are fairly standard and determined by the publisher so there should be no risk of this macro leaking any information that could be used by sellers to learn information about the user.
The text was updated successfully, but these errors were encountered: