In digital advertising, machine learning (ML) is indispensable for delivering optimal performance to advertisers and serving relevant ads to users. It enables precise audience targeting, budget optimization, and goal achievement. In today's competitive digital environment, ML-driven advertising strategies are vital for maximizing ROI, fostering business growth, and maintaining a competitive edge.

Now, the challenges presented by the integration of a new paradigm, such as the Protected Audience API (PAAPI), require a redesign of the ML systems that support our bidder, known as BidIQ.

Within the BidIQ team, one of our core responsibilities is building and maintaining pricing and pacing systems. In the pricing domain, one of our goals is to evaluate each bid opportunity with our ML systems to determine the probability of an event (clicks, conversions, etc.) and adjust the bid price accordingly to deliver the best possible performance for our clients and campaigns.

In order to place a bid on a user within the context of PAAPI, certain steps involving different types of information at different times must be met. This contrasts significantly with the current state, where we receive a bid opportunity request, match it server-side with previously stored data, evaluate all relevant features through our ML pipeline, and respond with a single candidate based on our criteria.

The Impact of Multi-Tower Model Design

Given the implications of PAAPI, we believe a multi-tower model design is a strong approach, as it respects users’ privacy while utilizing the available data on each phase.

A multi-tower structure uses different "towers" as models instead of a single, monolithic model to solve a problem. Each tower is focused on capturing specific data aspects at different moments, preserving performance and interpretability.

In the context of PAAPI, with limited data access and specific time constraints, we have to meet different phases in order to place a bid..

The main phases identified are:

• Interest Group join: Triggers when a user is browsing an advertiser’s site

• Contextual Request: A server to server request with contextual data, like publisher domain and user topics from the Topics API

• KV Service (TEE): At bidding time we evaluate segments, advertiser ads, and provide other related data

• On device auction: Our custom bidding logic has to decide a bid price for the auction based on certain criteria and available data in the browser.

In this scenario, the multi-tower approach involves constructing a distinct 'tower' for each phase. Each tower processes data—user insights, contextual data, and advertiser information—and generates encoded feature vectors encapsulating the essential information from their respective phases. These vectors are then transmitted to the browser, allowing for server-side computation and reducing the computational burden and data processing required during the browser auction.

Upon receiving these feature vectors and evaluating new data that’s available only at bid time, we can compute the probability of an event when the on-device auction runs. Our custom bidding logic will optimize for the goals of our advertisers, leveraging the towers to make informed bidding decisions.

The multi-tower model design enables efficient data utilization and privacy preservation, reducing the computational impact to the browser in the on-device auction.

Bidding and Auction Services (B&A)

In order to maintain data privacy, there is a proposal for moving the bidding auction from the browser (on-device auction) to a trusted execution environment (TEE) on cloud servers. This relocation limits network access and prevents external logging by adtech participants. 

There are some advantages to this move for members of the adtech ecosystem. For browsers, it means handling less bidding data and processing requirements, which reduces  latency. For adtech companies, it opens possibilities for larger models with proprietary code, providing differentiated performance. 

However, this transition also presents some challenges. Shifting to bidding within a TEE may limit flexibility in the types of machine learning models adtech companies could run. Since the code bidding execution is the same for everyone (known as Roma), there's a risk of all models becoming the same . As a result, data quality would become  the primary factor distinguishing which company has the best performance.

Moreover, transitioning to server-side bidding entails increased infrastructure costs and complexity: debugging and testing become even more challenging, and the responsibility for maintaining and operating the infrastructure remains unclear.

Overall, transitioning to B&A offers enhanced data privacy and performance benefits, but requires careful consideration of trade-offs and challenges, including limitations in model flexibility and operational complexities.

Conclusion

As we explore the multi-tower approach and the potential transition to B&A, it's evident that both situations offer unique opportunities and challenges.

While the multi-tower model design could efficiently handle data and time constraints, maintaining good performance levels, the move to B&A promises performance benefits but presents operational complexities. Nevertheless, with careful consideration and strategic implementation, we can navigate these options effectively, ensuring optimal performance while respecting user privacy.

Ultimately, the path forward will require thoughtful decision-making to strike the right balance between efficiency, privacy, and operational feasibility.

Agustin Recouso is an Engineer at NextRoll.