You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I represent Taboola, a leading native advertising vendor. We want to provide the following feedback regarding the native use case.
Taboola works with publishers who place our JS code directly on their pages. We use CSS inheritance to get the look and feel. You can see this in action in the following URL. We try to avoid adding custom CSS rules from our side and rely on the website's look and feel set up.
In the first proposal ("Seller Specific RenderUrl"):
The renderUrl makes a request to the Seller’s Rendering Service that returns an HTML file with the relevant styles. The thing is that it's impossible and not feasible for Taboola to store each publisher's style rules. We think this assumption is based on publishers using GAM templates, where the look and feel are pre-defined. We suggest that the rendering service send the ad assets via postMessage (title, image, description, and call to action) to the parent, where our code on the page will render the ad utilizing the CSS inheritance availability. To ensure privacy, we can use SafeFrame techniques to control what goes in/from the parent.
When it comes to supporting component auction - in the native context, to ensure look & feel - the styles will need to propagate inside the auction - either by CSS inheritance, as it will be impossible for component seller to get the styles, or for the top level seller (us) to pass them forward
The second proposal ("RenderURL with Seller Rendering Macro") has the same issue. We don't see how the Seller Rendering Service URL can return HTML with the look and feel of the parent.
We understand avoiding making dramatic changes in the PAAPI at this point, but we recommend taking a more holistic approach to native advertising. For example, forcing publishers' rules on titles/descriptions (which are not relevant in the display) or returning multiple results in an auction as the number of placements we have on the below article asset is endless compared to the display (see here).
Happy to hear your thoughts and expand engagement on this matter.
The text was updated successfully, but these errors were encountered:
@timphsieh-google@sbelov
regarding the redirect -> putting aside the look and feel challenge (CSS inheritance) - it can pose high infra costs and latency. Having the ability to replace the domain can help.
Hi -
Thank you, @timphsieh-google and @sbelov, for sharing your proposal.
I represent Taboola, a leading native advertising vendor. We want to provide the following feedback regarding the native use case.
Taboola works with publishers who place our JS code directly on their pages. We use CSS inheritance to get the look and feel. You can see this in action in the following URL. We try to avoid adding custom CSS rules from our side and rely on the website's look and feel set up.
In the first proposal ("Seller Specific RenderUrl"):
renderUrl
makes a request to theSeller’s Rendering Service
that returns an HTML file with the relevant styles. The thing is that it's impossible and not feasible for Taboola to store each publisher's style rules. We think this assumption is based on publishers using GAM templates, where the look and feel are pre-defined. We suggest that the rendering service send the ad assets viapostMessage
(title, image, description, and call to action) to the parent, where our code on the page will render the ad utilizing the CSS inheritance availability. To ensure privacy, we can use SafeFrame techniques to control what goes in/from the parent.The second proposal ("RenderURL with Seller Rendering Macro") has the same issue. We don't see how the
Seller Rendering Service URL
can return HTML with the look and feel of the parent.We understand avoiding making dramatic changes in the PAAPI at this point, but we recommend taking a more holistic approach to native advertising. For example, forcing publishers' rules on titles/descriptions (which are not relevant in the display) or returning multiple results in an auction as the number of placements we have on the below article asset is endless compared to the display (see here).
Happy to hear your thoughts and expand engagement on this matter.
The text was updated successfully, but these errors were encountered: