Skip to content
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

Feedback on native rendering proposal #94

Open
omriariav opened this issue Mar 6, 2024 · 1 comment
Open

Feedback on native rendering proposal #94

omriariav opened this issue Mar 6, 2024 · 1 comment
Assignees

Comments

@omriariav
Copy link

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"):

  • 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.

@omriariav
Copy link
Author

omriariav commented Mar 13, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants