Guidance required - how to enforce 'publisher blocking' (filters) rules when running native advertising in PAAPI with multisellers

[omriariav]

Hi all,

We are in the middle of our live testing with the PAAPI.

Unlike display advertising, native advertising has several parts: title, description, image URL, and sometimes also a call to action.

Publishers who utilize native advertising want to block ads based on matching text patterns. For example, publisher A does not want to show ads with the string ‘foo' in the title.

These rules use different matching text patterns within the title, description, and the image URL.

The number of blocking rules is very large. On average, one publisher can have hundreds of blocking rules, defined at the site level or for all of the sites that they manage in the native advertising platform.

We are seeking guidance on a potential implementation that takes into account situations where the native advertising platform is using 3rd party sellers in addition to being a buyer and a seller (code on page as the SSP, and DSP from its direct demand)

We thought of the following options:

Option A - per auction blocking:

• Taking all of the publisher blocking rules from the floor price auction (context)
• Build it into the ‘auctionConfig’
• Pass it to the scoreAd
• Reduce the desirability value

Pro: everything is done by the client (more privacy, I guess) Cons: Possible latency, difficulties when using component auctions

B - Blocking using Trusted Server:

• By using the domain/publisher ID (context) - use the real-time call in directFromSellerSignals during the scoreAd process
• Match blocking rules in the Sellet trusted server, adhering to the TEE requirements
• Once we meet at least one blocking rule is met, reduce/use the desirability / allowComponentAuction values
• Report it either via reportResult() or by using the Private Reporting API

Pro: less latency/load Con: We can update the publishers rules in the TE environment per TEE requirements only (not in real time)

Can you please advise on the above flows? Can you offer alternatives/tips for this native advertising use case?

Thank you!

[michaelkleber]

Yup, you've already described the two possibilities that I would have recommended. Option A seems better if the bocking rules can be expressed in a relatively compact way, and can become unwieldy if the rule set is very large. Option B helps with that, and indeed the reason we include the publisher domain in the trusted server request is exactly to enable that flow.

Can you explain more about the "Con" you listed for blocking inside the Trusted Server? I don't see a fundamental reason that a server running inside a TEE should have more difficulty with receiving real-time updates of publisher rules, compared to a server running in any other environment.

[omriariav]

Thanks, @michaelkleber, for the reply.

I am still ramping up my knowledge of TEE running in a secured cloud environment. I was unsure if we could update our seller TS in real-time with all the publishers' blocking rules adhering to the TEE design. Please let me look into that. Can you please direct me to the relevant area in the documentation?

[michaelkleber]

Sure!

1. The overall repository with our Key/Value service built for running inside a TEE is https://github.com/privacysandbox/protected-auction-key-value-service

2. For your use case, the essential business logic — taking the publisher controls for this domain and applying them to these specific ads — would be implemented in a User-Defined Function, or UDF. (Here the word "user" means "the ad tech using the K/V server", not "the person who is going to see the ad".) UDFs are explained in one section of the K/V Trust Model document but then have a whole explainer of their own, over at https://github.com/privacysandbox/protected-auction-services-docs/blob/main/key_value_service_user_defined_functions.md

I hope these do a good job addressing your needs!

[omriariav]

Thanks, @michaelkleber we'll take a look and revert if needed.

[eysegal]

@michaelkleber as a seller, do you have an idea on how can we get the ad's creative (title, thumbnail)? If we're not also the buyer of course.

[michaelkleber]

I assume you're still asking about things at scoring time (e.g. applying publisher blocks).

We built Protected Audience on the assumption that the way sellers would learn about the creative was based on the renderURL supplied by the buyer. Check out https://github.com/WICG/turtledove/issues/792 and all the references to "creative scanning", which are about the seller doing some sort of out-of-band fetch of buyers' render URLs so that they know what the contents of each ad is.

[eysegal]

Thanks @michaelkleber - so which of the alternatives there is going to be implemented? Pass the metadata (title, thumbnail, description) to the seller Trusted Server or have a designated endpoint that would inform us on a creative, which we'll later validate in the the seller Trusted Server?

[michaelkleber]

Discussion is ongoing, and that issue is the place to contribute to it if you have opinions :-)