Dovekey: multiple Dovekey servers

[jdelhommeau]

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

[gangwang-google]

Thank you for your questions.

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?

The diagrams in Section Simplification of the flow is a simplification of real world deployment. In real production, we could have multiple Dovekey servers certified by browser vendors. Then multiple SSPs and DSPs can be supported by the multiple Dovekey servers.

In this deployment scenario, assuming that publishers’ SSP adopts the proposed design, the Dovekey server is a technical detail to bring IG ads demand to publishers. If we do it right, publishers may not experience degradation in publisher controls or sell side functionality (e.g. deals), or significant IG ads revenue drop, or noticeable user experience degradation on publishers' site.

One objective of this design is to minimize publishers’ overall adoption cost. Let’s discuss the best way to achieve that.

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?

To set up a certified Dovekey server in production, browsers need to be configured to send ad requests to the Dovekey server, SSPs need to be configured to send conditional and unconditional bids to the same Dovekey server. Browser vendors and the ad tech industry may work together to flush out the deployment/configuration details.

For example, each browser may be configured to support a few Dovekey servers. The SSP’s ad tag can instruct the browser to send the Ad request (Step 1 in the diagram) to the preferred one among all configured Dovekey servers.

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?

If I understand it correctly, this seems to be a budget allocation problem, i.e. allocating budget across all sales channels, each of which has its own Dovekey server. Budget allocation problem is related to but distinct from the budget enforcement problem that the Dovekey Auction and Dovekey auction with secure 2PC explainers try to solve. Budget allocation is more at a higher (i.e. business) level, where budget reallocation is typically done with human intervention, at the frequency from a few times per day to once every few days. Budget enforcement is more at engineering level to prevent overspend or underspend, given an allocated budget. Budget enforcement (e.g. shutdown campaigns that are out of budget) or pacing adjustment is typically done automatically and frequently, e.g. once every 10 ~ 15 minutes.

Chrome aggregate measurement API may be an effective tool to assist budget allocation.

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?

The identity of the Dovekey server to initiate the auction may not be privacy sensitive. It seems reasonable to pass the ID of the Dovekey server downstream in the contextual ad request in Step 2 and Step 3.

[jdelhommeau]

thank you @gangwang-google .

In my case, I am not referring to budget allocation, but rather budget enforcement. Specifically, the way you described counters in Dovekey servers to allow the Dovekey server to block the campaign in case it spent all its budgets:

The counters effectively provide a filter for the Dovekey Server to apply based on whether a cached bid has run out of budget, or whether the cached bid is behind or ahead of its delivery goals specified by the DSPs

In realworld, as there will be several Dovekey servers, all running the same DSP campaign, a single Dovekey server wouldn't be able to have a full understanding of the campaign spend, since it would be split across all the Dovekey servers out there.
In your proposal, it seems to me that the mechanism you describe to support "Precise and timely budget and pacing control" can only work if there is a single DoveKey server in the world, having a full overview of the campaign realtime spend. As discussed above, that will not be the case.

Could you clarify the expected workflow, in case we have for example 5 Dovekey servers operating, each which are likely to be used on different sites by different SSPs, leading to a DSP running a campaign to send each Dovekey server with a conditional bid from that same campaign. How can the DSP keep track of the budget spent across each Dovekey server and not have Dovekey servers overspend?

[gangwang-google]

Hi @jdelhommeau,

To confirm, between

• budget enforcement within a single Dovekey server
• And budget allocation across multiple media types, DSPs, etc.

You see the need for budget enforcement across multiple Dovekey servers, on behalf of the same DSP for the same campaign. Is that an accurate summary?

If so, there are two possibilities that I can think of.

1. Treat this as a budget allocation problem, i.e. allow DSPs to periodically reallocate campaign budget across multiple Dovekey servers, based on the aggregate measurement API reports.
2. Add additional engineering solutions on top of the existing Dovekey auction with secure 2PC to synchronize multiple Dovekey servers. The synchronization logic will be in the log processor pool without increasing the ad serving latency.

#1 may be a sensible solution, especially at the initial deployment stage while we gain real experience to run those servers and understand the priority/feasibility for a more complex engineering solution, e.g. #2. What do you think?

[jdelhommeau]

Yes @gangwang-google , this is correct.

Lets assume a DSP is in charge of delivering a campaign C, with a budget of 1000$, over 10 days.

As different SSPs will use different DoveKey servers, and the DSP being connected to all those SSPs, the DSP will end up pushing the campaign C as conditionnal bid on the different DoveKey servers. The question is: how does the DSP can manage to respect its campaign's budget allocation and pacing across all those DoveKey servers?

Regarding #1, I haven't dug enough yet in the aggregate reporting API (definitely intend to), so unsure how it will work. What delay would the DSP have in getting delivery information? I think that today, DSPs manage pacing by allocating small budget for delivery every few minutes. (ie: spend 10$ in next 4 minutes, then wait until the end of the 4 minutes, then spend 10$ in next 4, etc.). Would that be doable here?
The question remains, how does the DSP split his budget across all DoveKey servers? That seems to bring lot of complexity on pacing enforcement, which is already not an easy problem to solve.

Regarding #2, I haven't looked at those proposal yet, but I think that syncronyzation across several DoveKey servers could be a solution indeed.

Another solution might be to change the impression counter in the on-device auction to update not just his DoveKey servers, but every DoveKey servers the browser can connect to. That way, all DoveKey servers will have an up to date budget in realtime, independantly of which DoveKey server delivers the campaign. What do you think?

[gangwang-google]

(ie: spend 10$ in next 4 minutes, then wait until the end of the 4 minutes, then spend 10$ in next 4, etc.)

IIUIC, this kind of pacing at minutes granularity is typically done automatically by algorithms. I added a paragraph in the Budget enforcement and pacing Section to discuss the application of PID controllers in the secure 2PC cluster to support the pacing.

Another solution might be to change the impression counter in the on-device auction to update not just his DoveKey servers, but every DoveKey servers the browser can connect to. That way, all DoveKey servers will have an up to date budget in realtime, independantly of which DoveKey server delivers the campaign. What do you think?

This suggestion may be quite intuitive. However, it may not fit into the current secure 2PC crypto design well, specifically the logging of auction results, as discussed in the impression notification section. To prevent any entity from learning the user’s interest group membership, the impression notification only carries the opaque auction_instance_id, which is totally meaningless for anyone but the original Dovekey server that conducted the auction.

Regarding #2, I haven't looked at those proposal yet, but I think that syncronyzation across several DoveKey servers could be a solution indeed.

If synchronization across several Dovekey servers is deemed necessary, Let's design the correct crypto protocol to do so.