Hi,

I've noticed that this demo https://fledge-multi-seller-with-gpt.glitch.me/ is not working anymore: the 'FLEDGE' ad is not displayed and the FLEDGE auction does not happen. Is something changed? About two or three weeks ago everything worked as expected

We're now testing Protected Audience API (PAAPI) on our websites. At the moment, we've split PAA-enabled inventory into two sets:

• on 50% of the inventory, PAAPI auction is initiated by the Google Ad Manager, and includes component auctions provided by the publisher
• on the remaining 50% of the inventory, PAAPI auction is initiated by the publisher, and runs partly in parallel to header bidding / adserver calls

This test setup is described in the following issue to WICG/Turtledove github:
WICG/turtledove#851

The purpose of this test is to ascertain both revenue and UX impact of sequential and parallel PAAPI setups.

However, validity of the test depends on executing both types of auctions with the same set of buyers. This is ensured for our partners (using the same component auction configs in publisher-initiated and Google-initiated top level auctions), but is there a additional 3rd party demand from Google Ads, that is used in Google-initiated top level auctions? If so, can You provide a Google component auction config we can use?

Hello,
When looking at the official protobuf, I see the new enum field auction_environment, which enables interest group bidding on the browser.
However, in the BidResponse, there is no field to be filled so we can indicate that we want to participate in the on-device auction. In the previously shared doc, such a field was called interest_group_bidding, but it is not in the current protobuf.
Could you clarify how a buyer should respond to participate in the FLEDGE auction?

I appreciate the effort to help solve f capping. I'm unsure on a few pts though. In the goals section you mention:

We would like to ensure that critical frequency capping use cases can be supported via RTB without relying on the presence of user identifiers in bid requests

And in the assumptions section you mention:

the exchange should be able to identify when an additional impression would violate the limits specified in the caps for a given user

then again in the assumptions section

The experiment assumes that exchanges have the means of identifying the same user across different sites or mobile apps in respective environments – for instance, by using a pseudonymous identifier based on a third-party cookie or a mobile device advertising identifier.

This mention of a cross domain user id, is that something that could be shared from the publishers to the exchange but not to DSPs? Is that the idea?

It seems like cross domain user ids in the ad request are ok, but not in the bid request?

Is this 100% of the 'Limited' or 'Enabled' labeled experiment arms in the Ad Manager, PAAPI column this graphic,

or 100% full bore all PA API equipped & enabled Chrome instances?

(excluding where user has disabled the feature or not permitted ads, &c).

Hi,

ROBIN describes a potential information flow between SSP and DSP during an interest group request. The specification of this request is taken from vanilla Turtledove.

PLTD extends the specification of interest group request by bringing product_ids into the picture. The exact details are not formalized yet, but the following excerpt summarizes the general idea:

In requests to ../.well-known/fetch-ads endpoint browser fetches ads for specified interest groups as previously. However, it also fetches the corresponding products' web_bundles - packages with assets necessary for rendering the product's presentation. This can be done in separate requests if needed.

PLTD is an extension of critical importance to us, and it seems that ROBIN can be easily adopted to work with it. As the explainer makes no mention of PLTD, however, I'd be grateful for your opinion, do you see any potential issues when it comes to adjusting ROBIN to PLTD?

Best regards,
Jonasz

The Dovekey explainer makes no mention of the outcome-based extension to Turtledove. In our view, from the perspective of bidding accuracy, the most valuable part of OBTD is the addition of userSignals (a piece of data stored privately in the browser and accessible only by the on-device bidding logic). I was wondering, what are your thoughts on adding it to Dovekey?

It is good to see GAM to start explaining how other exchanges will be able to test FLEDGE API when publisher is using GAM, as it was a request from the industry for a long time now. However, I am still unclear how this will work exactly.

The explainer mentions a new API part of GPT tag:
Slot.addComponentAuction(seller, AuctionConfig)

Other exchanges can submit their auction config through this API to GAM, which will in turn use those to populate the componentAuctions field of the top-level AuctionConfig.

Then, the explainer states:
"Ad Manager will compare the bids of all sellers and the best contextual ad selected via dynamic allocation, and will serve the ad with the highest bid."

This part isn't clear. How will Ad Manager "compare" the bids of all sellers and the best contextual ad, since all fledge related bids (both top level and component) are obfuscated and can only be evaluated within the fledge auction.

Will the contextual bids be passed into the top level fledge auction as component ads as well?

Regarding the Pre-bid IVT models, we highly value the ability to block traffic pre-bid, since not only can it guarantee that we don't spend budget on invalid traffic, but it also saves the resources to process this traffic.

We are concerned about the loss of some information available pre-bid and losing the ability to detect forms of IVT that are best detected pre-bid.

Interest groups seem like a good signal to distinguish human from non-human traffic based on their browsing behavior. We understand that a user not assigned to any interest group would not trigger any FLEDGE requests, which in itself should remove some forms of non-human traffic.

Besides, interest groups may be a good way to cluster together traffic from groups of bots designed to browse similar websites therefore generating similar browsing patterns. Therefore, interest groups could provide a good way to identify traffic from botnets leveraging browser-based automation frameworks or headless browsers. How does this proposal intend to filter out such traffic in the contextual FLEDGE request, if no interest-group data is passed? Would browser vendors be responsible for filtering out this traffic?

As for interest-group only requests, the main use cases for contextual data pre-bid are:

• Brand safety: ability to block unsafe publishers globally or for a set of advertisers that may not want their brand to show ads on them.
• For IVT, in particular app/domain spoofing: blocking traffic from untrusted publishers or from sellers not declared in a publisher's ads.txt/app-ads.txt

We understand that we would be able to apply those checks to the contextual request and pass the derived signals directly into the auction, however we would like to raise a few concerns:

• For the use cases listed above, there would need to be different types of flags: whether to participate in the auction or not, and possibly allowlists/blocklists of advertisers that may or may not want to serve ads based on language, publisher or content/category. Will those signals be standardized and will there be a list of acceptable fields that we can pass?
• This may lead to very long allowlists/blocklists to be passed in the auction, how can this proposal ensure this system scales and remains tractable and with acceptable latencies when having multiple buyers, each with potentially very long lists of blocked/allowed advertisers for the opportunity?
• If these signals are only used in the final on-device auction, will we be required to submit several bid responses on the interest-group only request in case one of them turns out to not be eligible?

Some thoughts & clarifications on the Google's FLoC experiment A/B experiment:

What is the all else equal?
In the FLoC group, what elements of identity are preserved in the experiment that would be lost in the full application of privacy sandbox. For instance, how did the experiment handle ad frequency capping?

Internal & external validity
The experiment operated on a sub-sub-sub set of Chrome's logged in users as I understand it. This would be useful to clarify and provide evidence of experimental internal validity. Also, given the narrow set of users who are included this raises concerns about external validity. For instance, the experiment somehow excluded users who were eligible for retargeting, so what share of users remained and how many of them had Google behavioral segments attached?

Comparing converions
Conversions vary in value. Google presented a single metric (cost per conversion) in evaluating the experiment. In Ravichandran's presentation, he explained that Google used some similarity metric to ensure comparability of the experimental outcomes. How was this done?

Marketplace spillovers
One challenge in evaluating the effectiveness of proposals is accounting for the general equilibrium effect where advertisers reallocate their budgets in or out of the market in response to the offering quality (see e.g. Blake and Coey (2014)). In this instance, were advertiser budgets able to move across groups or were they held equal (proportionately) across groups? How does this affect the interpretation of the findings?

The most robust and reliable signal we use today as a "ground truth" for qualifying traffic is sales conversions. A user generating credit card sales/transactions can reliably be considered valid human traffic.

Today, we can transfer the knowledge that a user is legitimate across partners.

This requires to have a stable cross-domain identity which is what this proposal aims to prevent in the first place.

Therefore, how does this proposal intend to address this use case and to detect invalid traffic at the application level?

The section about Post-bid IVT models suggests adding another trusted server for IVT detection providers and introducing the IVT trusted server API, which would be open only to a list of IVT detection providers controlled by the browsers.

How would companies that provide both ad buying and targeting technology and IVT detection/prevention solutions be treated in this regard? Would they still be able to access this server/query this API to run their post-bid IVT detection models over the decrypted events?

Referencing ads-privacy/trust-model/trust_techniques.md

First vs third-party servers

The entity that controls and runs the server will have considerable power over the servers.

If the entity has very strong incentives to uphold user privacy, for example, if it is a corporation whose public image is built on that, then the likelihood of the data being misused is lower.

The title of the paragraph is confusing. First vs third-party servers seem to have acquired a definite meaning in the context of a webpage displayed in a browser, and that meaning is irrelevant to the point being made here.

A couple suggestions of alternative titles:

• Server governance
• Operator incentives

Hi Google Chrome team,

During our recent meeting, you provided an explanation of the existing 3PC (Third-Party Cookies) depreciation timeline, which comprises the following phases:

January 2024:

• A gradual increase in Chrome traffic without 3PC, reaching 1%.
• Q1-Q2 2024: No further ramp-up is planned during this period due to ongoing market testing.
• H2 2024: The depreciation process will recommence, aiming to achieve 100% 3PC depreciation by the year's end.

As previously discussed, we wish to highlight the concerns expressed by Alliance digitale regarding the proposed depreciation in Q4 2024. These concerns are grounded in the following considerations:

• Q4 represents a significant and busy period of the year, during which many adtech companies suspend their production deployments to mitigate potential disruptions.
• The ramp-up process for publishers is expected to require a considerable amount of time, and the current timeline appears to be rather stringent.
• The market is undergoing a period of flux characterized by fluctuating budgets that may shift between the open web and other platforms, along with evolving competitive dynamics.

While we acknowledge the necessity of resuming the depreciation process after the conclusion of market testing, we would like to propose an adjustment to the plan as follows:

1. Implement a complete freeze in Q4 2024.
2. Gradually ramp up outside of Q4, for instance, at a rate of 1% per day.

This approach would serve to safeguard the activity of our members during the crucial year-end period, without compromising the overall completion of the 3PC depreciation plan.

Sincerely,
Alliance Digitale

Assuming the use of Coarse keys as a methodology for limiting the scale of the response in an augury bids object:

The current proposal would validate bids against the publisher rules at the SSP level, but the limitations of the coarse key method would seem to create limitations on how bid controls at the publisher level can propagate to DSPs.

At the point where the SSP sends the bid request to the DSP the available bid limits and controls established by the publisher would seem to be transmitted at a lower level of specificity, potentially making availability less clear and either raising the floor or lowering the ceiling through signal limitations against the intentions of publisher controls.

Am I correct that this could be an issue? If so I propose we discuss ways to retain precision in bid availability throughout the system while still accomplishing the other goals involved.

As noted in the WICG Fledge call today, we are trying to understand how Prebid.js will function in Fledge. The biggest unknown is how the publisher's ad server (most often GAM) intends to function in Fledge. In the present world, the final ad selection happens inside of GAM using proxy line items to represent Prebid.js demand. In Fledge, the browser will run the final ad selection process and this necessitates the consolidation of all demand in the Fledge Auction. This is made somewhat easier by the introduction of Component Auctions, which allow each partner to run their own Interest Group auction. However, several challenges remain to be solved regarding the uber auction. Those are:

1. Who owns and configures the uber auction?
2. Inputs are necessary for the uber auction

Who owns and configures the uber auction?

The uber auction code needs to be publisher configurable (to meet their business use cases) while also being a standard that different partners can integrate with. There are compelling arguments for making this code open-source and consortium owned (explored in brief here). Prebid.js has evolved as a solution that allows competitors to work together in a standardized way on the publisher's behalf and this seems like a good model to continue.

Inputs necessary for the uber auction

The uber auction requires several things:

1. AuctionConfig for every component auction.
2. The maximum contextual bid price (and potentially priority).

The need for component auction AuctionConfigs is self explanatory. The maximum contextual bid price is necessary to allow the uber auction to determine if any of the component auctions performed better than the contextual ad selection process.

Needed from GAM/GPT

AuctionConfig

If GPT were to provide a mechanism by which an AuctionConfig object could be retrieved, it could be added as a component auction of the uber auction for the ad slot.

Bid/Price Signal

All the Prebid.js SSPs currently provide a price signal that is used by Prebid.js to determine the contextual winner. Something similar would be needed from GPT in order to determine what the price to beat is for the Fledge auction.

In short, it would be great to work with the GAM team to devise a solution that enables publishers to easily integrate Fledge demand in the future.

cc @jeffkaufman @sbelov @brodrigu @jonasz @fbastello

Further Reading
An overview of our current thinking can be found here. A partial sequence diagram that prompted this issue:

We'd like to understand how Google Ad Manager executes PAA auction - especially how winning bid value is sent to PAA (see https://support.google.com/admanager/answer/13627134?hl=en).

1. If Ad Manager passes ad creative and winning ad value (eCPM) to PAA, would it be possible to pass this value to the publisher’s ad selection logic (yield optimisation). It would enable the publisher to use Google Ad Manager in parallel with other demand sources (such as Header Bidding, publisher adserver, etc.). It would also guarantee equal position for all players.

2. If the Ad Manager does not pass ad value (eCPM), then how do You guarantee that the displayed ad, chosen between the Ad Manager and PAA, provides optimal revenue for the publisher?

Hi Google Ad team,

Thank you for providing us with detailed analysis and results of your testing on the Topics API.

To further understand the impact of the removal of 3PCs, could you also disclosed the raw data from your testing? More specifically, could you provide us with actual spend, impressions, clicks and conversions numbers, for each dimension from table on page 6?

For clarity, we would like to get metrics above for GAD, with and without AI-powered optimization, and for DV360, with and without AI-powered optimization, for both test and controls groups.

Thank you!

Alliance Digitale France

The recent Dovekey Auction explainer details a new flow where the contextual ad request is encrypted and sent to DoveKey which is then forwarded to the SSP.

However, in a typical page flow today, contextual bids are collected from an SSP and sent into the publishers Ad Server where they can be compared against direct sold campaigns.

Where would a Publisher's ad server fit in the Dovekey flow?

Robots often don't care about their personal privacy, but want their browser to be treated as if it were Chrome or some other popular brand. For example Googlebot, Baidu, Integral Ad Science, Page Speed Insights Bot. Publishers often like knowing how often these bots come to their page by querying logs for them. It seems a browser sub-brand field could solve this.

Similarly, Edge, Pinterest Webview, and Vivaldi browsers like to pretend to be Chrome, even while having a different feature set. Publishers often run queries to identify these users as having bad experiences in aggregate based on access log queries. This brand aliasing, 'you probably want to treat me as chrome but I am really Edge or Vivaldi' seems useful to preserve. An optional subbrand would seem to succeed in preserving this.

Hi,

In Dovekey the ability to bid accurately is severely limited by the necessity to materialize bids in the key value store. In fact, we don't see a way to implement a satisfactory system under such a limitation.

The bid value depends on many (more or less independent) factors, like interest_group, slot_id, number of recent ad impressions, time from the last visit to the advertiser's page, device type, and more. In real-life systems, the list of such signals can easily grow to over one hundred, each signal having between a few and a few hundred million values.

If we want to account for those signals, the key space very quickly grows well beyond what could be physically materialized in a key-value store. (The order of magnitude would be gigantic, our intuition is closer to 100^100 than to anything that can be managed in a physical system.)

I was wondering, have you considered a design where the bidder, during a single auction, can specify multiple keys, and combine the values into the final bid in a custom way? So instead of a single query with a long key:

let bid_value = dovekey.get('ig=WeReallyLikeShoes-athletic-shoes,slot_id=151513513,recent_impressions_1d=8,recent_impressions_5m=3,time_last_seen=17h,device_type=iphone7,...')

We would get

let bid_value = dovekey.get('ig=WeReallyLikeShoes-athletic-shoes,slot_id=151513513') * dovekey.get('recent_impressions_1d=8') * ...

That seems like a simple way to greatly optimize the size of the KV store, and to allow for more accurate bidding at the same time.

Of course the snippet above is just a discussion starter, the amount of browser-side flexibility for key construction and bid computation would require a more detailed discussion.

Best regards,
Jonasz

In the FLEDGE for RTB explainer, it suggests that exchanges could provide an API for creative submission to be scanned, and gives a simple example of how that might look.

For this purpose, consider the already existing OpenRTB Ad Management API, which could be improved as needed to support this scenario.

If a publisher chooses not to have a certain advertiser or piece of ad creative appear on their site, will they also be able to set an option similar to "mute this ad" to prevent it from appearing?

The current Dovekey proposal describes a contextual signal being returned by the SSP during the contextual ad request. Is this planned to be arbitrary and opaque in structure to the UA and KV server or is there likely to be some structure to it? What limits to the size might be applied?

Scaup mentions ATPs being able to send user profile data in an ad response to be used for training the ML model. Will it be possible to also send user profile data outside of an ad response based on specific events such as the user visiting an advertiser site, or conversion?

Hello everyone,

I had a question while reading through the specifications. Specifically regarding the part where DSPs and SSPs would bulk upload Key-Values to the KV server ahead of time.
The specification says:

From historical ad requests and tagging signals, along with information about previously missing keys that would need to be provided by the aggregate reporting API, the DSP can make an informed decision to predict which keys (contextual signals + ig_id) will provide maximum coverage. Once a key is identified, the DSP can compute the respective values, i.e., creative_id and bid, and then pass this key-value pair, along with the contextual ad request, to the SSP.

Given a contextual ad request, creative_id, and the bid, the SSP can apply publisher brand safety & ad quality checks, pricing rules to calculate publisher payout.

So my understanding from this, is that DSP will decide how to generate a CS (no pre-defined form). For example, if a DSP decides that its CS will contain domain, size and geo country information, it will generate a CS of the form "domain-size-geo". For ease of usage, the DSP may choose to use internal id to represent each dimension, so the CS could become something like "1234-5-67". The DSP then decides which IG campaign(s) is most likely to deliver on this CS. For example, IG1 for a bid of $10 for creative id 789.

The DSP will then provide the SSP with such CS / bid combination: [(1234-5-67,IG1),(10,789)]
As per the specifications, the SSP should then apply publisher brand safety, ad quality and pricing rules. However, how should the SSP decides which publisher to do that for? The DSP's CS has no meaning for the SSP, so it can't know in advance which publishers might be eligible for that CS/bid KV.
Should the SSP apply publisher brand safety, ad quality and pricing rules for each publisher he works with for that provided KV?

Thank you for your clarification and help on this.

On the Web Advertising BG call when Dovekey was first discussed, questions were raised about scalability. #14 discusses this as well.

One answer was that significant coverage can be attained with a more limited set of keys. Do you have any estimates for the scale a KV server would be expected to support? Are there any currently unstated non-monetary/cost reasons to limit it?

As per https://support.google.com/admanager/answer/13627134:

When the Protected Audience API (formerly known as FLEDGE) becomes generally available in Chrome, Ad Manager will begin gradually increasing the amount of traffic included in its testing. We'll monitor the impact to publisher revenue as we slowly increase the percentage of traffic, and will not ramp up further if there is a noticeable negative impact to publisher revenue. We expect that by the end of 2023, up to 10% of Chrome traffic will be enabled for Protected Audience API testing.

As noted #77 (comment), #65 (comment) and privacysandbox/privacy-sandbox-dev-support#110, with the GA release of PAAPI, it has become evident that there is a gap in how on-page Protected Audience auctionConfig, GPT setConfig and GAM's handling are interacting, making it extremely difficult to for buyers, sellers and publishers to begin integrating with PAAPI.

In short, there is no indication on-device available in JavaScript that an auctionConfig registered for a component auction will not be honoured by GAM -- neither before the display call for the ad slot is executed, nor after the slot has rendered -- runAdAuction simply isn't executed, and it's invisible as to why this is the case from the browser. In other words, it acts as though there are no IGs available for the user, but that simply isn't the case. At the moment, it appears quite random as to whether or or GAM will throttle PAAPI or not.

https://services.google.com/fb/forms/uastringformultisellertestsignup/ is the proposed workaround for local testing -- but if ad tech vendors are going to begin to start PA testing, we're going to need additional clarity and signalling regarding if and when a given slot is PAAPI-eligible in GAM during the ramp-up period.

Can GAM provide this much-needed clarity?

That is, how is a Dovekey server able to count that a particular browser instance has seen an ad too many times? It seems that browsers will be required to provide a strong signal, albeit an encrypted one, that distinguishes one browser from another.

There is a question on how we might trust one or both of the trusted MPC servers within the scaup proposals.

Could an ATP run an MPC server themselves (or contract a 3rd party to run one for them) and specify all their models should leverage their server of choice for at least one of the two MPC servers?

On Jan 25 Google published a blog post stating:

By creating simulations based on the principles defined in Chrome’s FLoC proposal, Google’s ads teams have tested this privacy-first alternative to third-party cookies. Results indicate that when it comes to generating interest-based audiences, FLoC can provide an effective replacement signal for third-party cookies. Our tests of FLoC to reach in-market and affinity Google Audiences show that advertisers can expect to see at least 95% of the conversions per dollar spent when compared to cookie-based advertising. The specific result depends on the strength of the clustering algorithm that FLoC uses and the type of audience being reached.

These results will be used by many in the industry -advertisers, publishers, ad tech providers- to define their strategy regarding the retirement of third-party cookies in Chrome. A FLOC 95% replacement of conversions per dollar spent may render all other alternatives useless, including TURTLEDOVE.

In order to fully understand the scope of these results, could you please publish the related study that led to this conclusion?

The scaup proposal details how an MPC powered ML model can be used to generate similar audience user-lists using user-profile data providing by ATPs, these users-lists are then used to assign TURTLEDOVE interest groups to the user/browser.

How does the browser/MPC know what the interest group is? Can the ATP provide a mapping of events / profile data that should correlate with an interest group?

Thank you for the proposal and the presentation during W3C meeting @gangwang-google !

One thing I am not sure to understand is, how does this proposal work with several Dovekey servers, as well as what is the relationship between the publisher and the dovekey server, if any?

Assuming there can be several dovekey servers, managed by different entities, how does the browser choose which ones to call on a given publisher's page?

Also, unsure how some of the feature described in the proposal would work with several dovekey servers.
For example, the "Precise and timely budget and pacing control" says that Dovekey server will be updated with impressions made on a given campaign, so it can apply filter in case the campaign is ahead of budget or behind. But how does that work if the same campaign gets delivered through different dovekey servers, managed by different entities? How does each Dovekey server knows how much of the budget was spent by the other dovekey servers?

Similar question to what you described during the call. You mentionned that a DSP wouldn't need to return all its conditional bids (ie: IG bids) all the time in bid response, since the Dovekey server would cache them. But how does the DSP knows which DoveKey server is initiating the auction, and whether that specific Dovekey server was sent the conditional bids from the DSP recently? Is there some protocol to pass the Dovekey Server identifier in bid requests, so DSPs know which DoveKey servers were sent the cached bids already?

Thank you for your help clarifying this part.

Julien

As I understand the TURTLEDOVE flow, an ad network would receive a contextless request that only includes an interest group. The ad network would respond with bid information, as well as the actual ad assets (represented as a Web Bundle.) That is cached by the browser, and used later when making a decision about displaying either a contextual ad and an interest group ad. As a list:

1. add to interest group
   a. advertiser calls TURTLEDOVE api in browser
   b. delay
2. request ad for interest
   a. browser makes contextless request bids from ad network
   b. ad network respond with interest group bids and and asset
3. ad serving on publisher page load
   a. request contextual ads from ad network
   b. find eligible cached interest group ads and bid data
   c. compute top bid value from bidding function between interest group ads and contextual ads
   d. display winning ad in fenced frame
4. report ad served via aggregate reporting API

Now, from the Augury explainer, as I understand the core difference is that step 2 is removed, and step 3 is slightly different:

1. same as above
2. skipped
3. ad serving on publisher page load
   a. request contextual ads and augury ads from ad network
   b. filter augury ads down to matches with interest groups in the browser
   c. compute top bid value from filtered augury bids and contextual ad
   d. display winning ad in fenced frame
4. same as above

The issue here is that because step 2 is skipped, the ad assets aren't cached and cannot be displayed in step 3c (for the Augury case.)

My initial understanding was that the asset would be fetched between 3c. and 3d., but this would present a timing attack. On today's W3C web-adv group, the suggestion was that the timing attack wouldn't be an issue because the assets would already be cached. I see two potential interpretations here, and both have issues:

• Step 2 isn't entirely skipped, and some request for assets for interest groups are made outside of the publisher page load.
  • Issue: Given that each interest group can have multiple campaigns and ad assets, each interest group could end up requiring a very large amount of cache space and user bandwidth, so that all (or most) possible combinations of (campaign, asset) are available later at step 3d. (This is not an issue in the original TURTLEDOVE case, because the interest group bid must make that selection at time of caching.)
• OR, at Step 3a, the ad network responds with not just bids, but with the full ad assets.
  • Issue: The current suggestion is that augury bids could number in hundreds or thousands. While the bandwidth and performance impact on just bids wouldn't be ruinous to user experience, including the assets for those thousands of augury bids would.

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.

Dear Google Ads team,

Google Analytics (GA) is de facto the standard web campaign attribution tool in the industry, used by marketers to measure the outcome of their campaigns, even for campaigns run outside of Google.

According to GA 4 documentation, GA can make use of "Google signals", defined as "data from users who are signed in to Google" for GA to "create[s] a single user journey from all the data associated with the same identity".

As this data is only available to Google, this may lead to the following issues:

Discrepancy in Results:

If GA and the other attribution methods, such as Privacy Sandbox Reporting API, provide different results, it may lead to misunderstandings and disputes between marketers and DSPs.

Campaign optimization:

DSPs may face challenges in optimizing for marketer goals if those GA is measuring those goals in a way that is not accessible to DSPs.

Cross-Site Identification Contradiction:

The use of login data from users signed into Chrome as a cross-site identifier in GA4 contradicts Chrome's efforts to deprecate cross-site user identification (3PC deprecation) and may be contradictory with Google commitments to the CMA.

Based on this, we have the following question: considering Google's focus on eliminating cross-site identifiers, is there a plan to review GA4 use of "Google signals"?

All the best

Alliance Digitale

Hey,

I don't see how can remarketing work if 3rd party cookies are depricated. Could someone explain?

Let us review this proposed solution to "privacy."

1. Eliminate 3rd party cookies
2. Continue to track and store personal data
3. Build an unsupervised model based on personal data
4. Group users together based on personal data
5. Create products based on personal data
6. Sell services and products with no personal data

In other words, let Google eliminate competition while continuing to infringe on privacy, collect and store private data. Then let Google create products based on private data to sell back to the market. This is not a solution to our privacy issue but rather an attempt to centralize and monopolize private data.

I'd like to know where and when user privacy is established and not just centralized on Googles servers?

Most of the IVT detection we do today is based on post-bid signals that feed more or less complex anomaly detection models. Information is processed by breaking down on one or more dimensions, to identify offenders that we want to block pre-bid and post-bid. The computation can be done in real-time or offline, depending on the complexity of the model.

We are concerned that the ASTRAPIA proposal in its current form will not cover those needs as it relies on the Aggregate Reporting API and the Conversion Measurement API for human analysis and post-bid models. We see this as presenting the following limitations:

• The latency of the data would not allow supporting IVT use cases, especially post-bid models, for which being able to react quickly to detected IVT is critical (typically within a few minutes).
• For example, some of our rules-based filtration models block traffic in real-time, i.e. typically with a 5-minute delay, e.g. detecting IP3 subnetworks going rogue and generating a spike in clicks.
• It is unclear whether the granularity would be sufficient to address IVT needs, in particular, whether we are able to access all the dimensions we rely on today (IP, User-Agent, other user and device-level identifiers), and the ability to cross several dimensions.
• Depending on the level of noise added, it could make it difficult to interpret the data, and in particular with conversions, which are a very robust signal that can often be considered as the "ground truth".
• Still, regarding conversions, the lack of flexibility around attribution models (up to the browser vendor if I am correct) will cause issues as this is a reliable signal to vet the quality of traffic. See related issue.

How does this proposal plan to address those limitations?

For an SSP that believes interest group-based ads are more likely to win auctions, should it have the option to opt out of returning an ad at all and instead only return a contextual signal? The ad returned by the KV server would be the only one downloaded.

One could imagine the SSP specifying a null interest group ID for ads that want to server based purely on the contextual signal. The initial contextual ad request could potentially also specify a fallback URL for the creative in the event that the KV server ends up not having a matching key.