Technology at Criteo is shaped by the engineers, researchers, and communities who build, experiment, learn, and share every day.

tech.criteo.com brings more of that work together in one place. It is a dedicated destination for exploring technical articles, engineering stories, research, career journeys, and insights from across Criteo Tech.

The site also makes it easier to discover the wider Criteo Tech ecosystem, with links to key initiatives and resources such as the Criteo AI Lab and our Open Source projects.

This is only the beginning. Over time, the website will feature more of the people and activities behind our technical community — including events, talks and recaps, Tech Ambassador stories, and other ways Criteos contribute to technology inside and outside the company.

Whether you already follow our work or are discovering Criteo Tech for the first time, we invite you to explore tech.criteo.com and see what our teams are building, researching, and sharing.

Criteo Tech | Engineering, AI & Research

Introducing Criteo Tech was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

For many years now, we have been computing the global carbon footprint of the Criteo Bare-Metal Infrastructure thanks to the plethora of data we have at the data-center-level — yearly electricity consumption, PUE, the carbon impact of manufacturing the servers, …

This was enough for some time as it allowed us to monitor our impact and work on achieving our SBTi commitments. But as awareness grows, people and teams start asking questions to understand the impact of their applications and their share within the global picture.

Due to the lack of more granular data, questions like “ What is the footprint of this specific server in this location?” become harder to answer, and questions like “What is the impact of my application in a specific data center?” even harder.

This is the story of how we reduced that gap at Criteo: from an end user’s genuine question about application emissions to Dashboards and a Web UI where anyone can explore the daily embodied & usage emissions of every physical asset across our fleet.

Since the application impact can be derived as a share of the underlying assets it uses, the first step was to compute the impact of those physical assets and make the result available for exploration.

From data centers to physical assets

Our initial sustainability work focused on facilities: how much electricity each data center uses, how efficient the cooling is, how much carbon is associated with the local grid, and what the manufacturing impact is of all the physical assets. This was good enough for Sustainability reporting and high‑level decisions.

But things are moving forward and we needed to strengthen our approach and methodology:

• New regulations and voluntary frameworks were asking for more granular, auditable data.
• Internally, the infrastructure and product teams wanted to compare hardware options and locations based on carbon impact in addition to price.
• With AI workloads growing, we were about to deploy new, very carbon‑intensive hardware (GPUs) and needed a way to measure their specific impact.
• Reduce the infrastructure impact: to identify the levers and make some carbon savings

We realized that in order to make meaningful decisions, we had to compute the carbon impact at a more granular level: instead of “X tons of CO₂eq per datacenter per year,” we wanted “Y kgCO₂eq per server per day.”

To do so, we set ourselves a goal:

Compute the daily carbon footprint of every physical asset in our datacenter (server, PDU, rack, network gear), split into embodied and usage emissions, and let our users explore the data in the tools they already use.

Agreeing on what we actually measure

Before we could write a single line of code, we had to answer a deceptively simple question:

“What should be accounted for in the carbon footprint of a server (or any other physical asset)?”

We worked with our partner Hubblo, a consulting firm specializing in the environmental impact of digital technologies, and converged on a model with two complementary parts, mirroring how finance views CAPEX vs OPEX: in our case, embodied and usage impacts.

Embodied impact: before the asset is installed, and once it is decommissioned

The Embodied Impact is the part we often forget; it includes:

• Extracting raw materials and manufacturing boards, chips, and chassis.
• Assembling and shipping the assets.
• Treating the hardware at its end‑of‑life.

We treat embodied emissions like amortized CAPEX in finance: i.e. we amortize the embodied impact over a standard six‑year lifetime to obtain a daily embodied impact of the asset.

There are three components to this:

Manufacturing

• Vendor ‑ or database‑provided — emission factors for servers, racks, PDUs, and network gear.
• Amortized over a six-year period: Daily manufacturing impact = (hardware manufacturing emission factor) / (365 × 6)

Hosting & technical environment

• A generic factor from ADEME’s Cloud & Datacenters PCR that represents the impact of the building and its technical environment (beyond electricity).

Transportation

• Standardized intensities per ton-kilometer for the typical lanes between suppliers, staging locations, and data centers.
• Also amortized over a six-year period.

Once we have all three, we can compute the daily embodied impact of the asset:

Daily embodied emissions
= Daily manufacturing + Daily hosting & technical environment + Daily transportation.

Usage impact: what happens once the asset is powered on

The Usage Impact covers everything that happens during the life of the asset. For this, we take into account:

• Its own electricity consumption.
• The overhead of keeping it alive: cooling, power distribution, UPS, etc., captured via the data center’s PUE.

Conceptually, the formula is pretty simple:

Daily usage emissions
= PUE × Electricity Emission Factor (kgCO₂e/kWh) × Power consumption over the last 24h (kWh).

In other words, consider how much energy the asset uses, adjust for the efficiency of the building, and multiply by how carbon‑intensive the local grid is on that day.

Putting it all together

Once we agreed on this split, two things became clear:

• We couldn’t simply rely on static theoretical power usage values, we needed real measurements from the assets.
• For our engineers and auditors to trust the numbers, our assumptions had to be transparent and auditable.

From whiteboard to pipeline

The first tangible step of the project was not a dashboard; it was a whiteboard covered in arrows between data sources.

We identified five families of inputs:

1. Inventory & flavors — what assets do we have, where are they, and which hardware profile (or “flavor”) do they belong to?
2. Power metrics — how much power each asset actually consumed over the last 24 hours?
3. Data‑center metrics — PUE and location‑specific electricity emission factors.
4. Hardware emission factors — manufacturing and end‑of‑life footprint of servers and other assets.
5. Transport data — how hardware moves from its manufacturing location to its destination data center, and relocation over its lifetime.

Some of these already existed in our production systems; some lived in Excel sheets or PDF files; others were lost in emails from our vendors; and the rest were missing and had to be requested from our partners.

Normalizing carbon data

We started by building a data service to gather, ingest and normalize all carbon‑related numbers:

• Emission factors
• Transportation footprints
• Real-time power usage of each physical asset
• …

Everything is stored in a database with explicit owners and update processes, so that, for example, the Hardware team can refresh a set of emission factors without touching the rest of the pipeline.

Values change over time, for example, the manufacturing of the same hardware model can evolve and become more efficient; the data service had to handle all of that.

This service became the single source of truth for anything that might appear in a carbon computation.

Daily computation and persistence

With emission factors under control, we can now focus on the daily computation. The shape of the job is deliberately simple:

For each day and each physical asset:

• Extract the power consumption on that day.
• Retrieve the relevant PUE and electricity emission factor for its data center.
• Fetch its manufacturing and transport emission factors, in addition to the generic hosting factor.

Compute:

• Daily embodied emissions.
• Daily usage emissions.
• Total daily carbon impact.

Store results in a database with one row per asset per day.

From there, everything else is “just” data visualization and analysis.

Living with imperfect data

As expected with initial iterations, early runs of the pipeline surfaced all the usual data quality issues:

• Assets with no real-time power consumption metrics.
• Hardware models with unknown manufacturing emissions.
• Assets relocation that were never marked as such.
• …

Instead of waiting for perfect data, which will never happen, we decided to work on a methodology to estimate reasonable replacement values; we would rather have good-enough well-documented numbers than nothing.

Power usage: a ladder of fallbacks

Usually, when real-time power usage metrics are unavailable, they are lost for good for that period of time; for this reason, we use a ladder of fallback heuristics:

1. Use real‑time power consumption metrics when available
2. Otherwise,

• An asset that is shut down uses no power.
• Estimate the power usage from similar assets doing the same thing, in the same location.
• Fall back on the theoretical power consumption of the hardware model, provided by the manufacturer.
• Estimate the power usage from all assets of the same type (i.e. servers, PDUs…) in the same location.

Each time we move down the ladder, we increase uncertainty — but we are explicit about it and have the metrics to monitor coverage and evolution over time.

Embodied emissions: borrowing from neighbors

The issues are much easier to handle for manufacturing and transportation given that missing past data is not lost forever, although they can change over time,

• Use vendor‑provided values or our partners’ values, when available.
• Otherwise, borrow values from similar assets deployed in the same location to keep transport distances realistic.
• Any remaining gaps are temporarily set to 0, clearly flagged as such — an incentive to liaise with our providers to gather the real data instead of ignoring the problem.

Once the real values are retrieved, we update our metrics database and restart the computation to refine the numbers.

This may sound rough around the edges, but it has the advantage of computing a value for every single physical asset, and making our numbers traceable: when someone challenges a number we publish, we can walk them back through the exact assumptions behind the computation.

Visualization dashboards

Once the database started filling up with results, we moved on to the fun part: exploring them.

With different users and different needs, some interested in digging into the details while others focused on more global views, we built different visualizations that let us answer questions we could not answer before this initiative:

• What is the carbon impact of this specific server in this location on a given date?
• What is the average daily usage impact of this type of server models in a specific year?
• What is the yearly carbon impact in this location (i.e. the sum of all assets in that location)?
• What is the total monthly embodied impact of all network gear on a given month?
• How does the carbon impact of this database evolve over time?
• How much carbon impact did we save by migrating to the newer generation of server models?
• How is the carbon impact distributed across the different types of assets (servers, network gear, etc.)?
• …

All these questions, and many more, become easy to answer and let internal users of Criteo’s infrastructure explore data independently and incorporate the results into workload-sizing and deployment decisions.

What the numbers changed for us

First of all, when we sum everything, we get back to the global carbon footprint of the Criteo Bare-Metal Infrastructure we were previously manually computing, but we now have much more detail, and the conversations shifted from theory to very concrete trade‑offs when we started exploring the results.

Usage dominates, but embodied emissions are important

It comes as no surprise that usage emissions are the largest slice of our footprint: Electricity and PUE still matter a lot.

However, the dashboards make something else visible: for certain fleets — especially those using recent hardware models and high‑end GPU servers — embodied emissions are significant.

This has practical consequences:

• We pay very close attention to how well these GPU servers are actually used, not just how many we have.
• We ensure we continue using server models that can safely run for another year or two before replacing them with newer generations.

Geographic location matters

Comparing the same hardware model across different locations highlights how grid mix and facility design interact:

• The same hardware in two regions can have very different usage emissions, purely due to electricity mix.
• High‑density sites with better PUE can offset a part of that, but not all.

This feeds directly into capacity planning and site‑selection discussions: we can now consider both the carbon impact and the financial cost when considering moving workloads from one location to another.

Server models are not made equal

Analysis of the carbon impact of different hardware models shows:

• A couple of large, general‑purpose CPU fleets dominate total emissions because there are a lot of them, and they run all the time.
• Some GPU and storage models have the highest per‑server daily impact.

This leads to more nuanced conversations:

• if you optimize and reduce this particular fleet, here’s how much carbon you can realistically save
• if you migrate to a different hardware model, here’s how the carbon impact will change
• if you pick this specific server model for your fleet, here’s how much carbon impact to expect

The wider picture

We are taking a complementary angle on the infrastructure side:

• Grounding our calculations in recognized methodologies (GHG Protocol, ADEME’s Cloud & Datacenters PCR).
• Treating upstream emissions (manufacturing, buildings, transport) as first‑class citizens, not a footnote to electricity.
• Making the results available and usable by our engineers, not just sustainability specialists.

Our hope is that, as more actors share their methods and data, we can converge on standards that make hardware and site choices comparable across the industry.

What next?

We are quite happy with this first iteration, yet we already know how to improve on this:

Refine data

• Use daily electricity emission factors instead of annual averages.
• Integrate relocation emissions directly into the embodied impact of assets.

Broaden the scope

• As stated above, we can now compute the carbon impact of each individual asset we have in our infrastructure
• The next step would be to compute the impact of each application, each product, each user…
• To do so, we will rely on the redistribution framework we already have in place to propagate the monetary cost of these physical assets to their users, and their users’ users…
• The idea is that the cost is first allocated to its direct clients, such as technology clusters, whose cost is then redistributed to the services and applications running on those clusters according to their resource consumption, and this logic continues up the stack until we reach the production and clients.
• Our goal for carbon is to reuse the same framework so that carbon emissions follow the same allocation paths.
• This will let us compute the carbon cost of each layer, each service, each application, each product, each user.

Closing the loop

Remember that original question — “ What is the footprint of this specific server in this location? “

It now has a concrete answer.

More importantly, it unlocks new kinds of discussions inside Criteo:

• SREs and hardware engineers discussing the carbon impact of hardware models in the same breath as reliability and cost.
• Product teams asking for carbon estimations (in addition to cost estimations) to feed into their own roadmaps.
• Sustainability work that is embedded in everyday infrastructure decisions based on realtime carbon impact, not just in yearly reports.

There is a lot still to improve in our data and our methodology, but one thing is clear: once you can see the carbon footprint day by day, site by site, it becomes much harder to ignore — and much easier to act on.

Originally published at https://tech.criteo.com on September 16, 2026.

How Criteo Measures Bare-Metal Infrastructure Carbon was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Criteo, retail media is about helping brands reach shoppers directly on retailers’ property, right at the digital shelf where purchase decisions are made. Through CMAX, our unified retail media platform, we connect advertisers to retailers’ audiences with Sponsored Products that appear alongside native results in onsite search and browsing experiences.

In this context, the core problem we address is balancing two imperatives: delivering strong performance for advertisers while preserving a high‑quality, trustworthy shopping experience for retailers and their customers, as we define more precisely in our notions of semantic relevance and outcome‑based relevance below. We solve this by using our proprietary deep learning models to ensure that Sponsored Products not only perform, but also accurately reflect each user’s intent and each retailer’s catalog.

Criteo Boosts Ad Performance with Latest AI Advancements

In this article, we align with the accuracy and outcome‑based relevance framework introduced in our blog post on agentic recommendation systems, “Leveraging Commerce Data for Outcome-Based Relevancy in Agentic Recommendation Systems”:

• accuracy or “semantic relevance” captures how well a product’s content matches the user’s query
• “outcome‑based relevance” measures whether recommendations actually satisfy user needs as evidenced by real commerce signals such as clicks and purchases

Leveraging Commerce Data for Outcome-Based Relevancy in Agentic Recommendation Systems

Building on Criteo’s ongoing investment in AI‑driven retail media, we have therefore focused on strengthening the accuracy engine behind Sponsored Products.

Advertising on retailer’s property comes with unique constraints. Unlike off-site advertising, where ads are displayed beyond the retailer’s own digital properties, for example, on external websites, search platforms, or social media, and optimization primarily targets performance metrics (e.g., click-through rate), onsite Sponsored Products must satisfy strict accuracy requirements to preserve the quality of the shopping experience. For instance, if a shopper searches for “red dress,” the ads shown alongside search results must be tightly aligned with that intent: different brands, styles, lengths, or sizes of red dresses are acceptable, but different-colored dresses, such as a yellow dress, as well as unrelated products like jeans, shoes, or handbags, are not.

Ads are displayed alongside organic results in response to explicit user queries, making relevance to search intent non-negotiable. An inaccurate ad is not just inefficient: it creates annoyance and cognitive friction for shoppers, undermines the perceived quality of the retailer’s search results, and ultimately harms Criteo’s reputation with retailers by degrading the overall shopping experience.

To address this challenge, we have leveraged the latest advances in Language Modeling to deepen our understanding of search intent and product semantics. In our Agentic Recommendation Service blog post, we showed that outcome-based relevancy improves by 60% when fine‑tuned on commerce data. This builds on top of years of experience gained by optimizing search models to deliver optimal Retail Media experience to retailers, brands, and consumers. By combining our unique commerce data with these latest advances in language models, we ensure that Sponsored Products deliver strong performance while meeting the high bar of accuracy required in retail media.

Introducing our Contrastive Language Embedding for Product Retrieval model

Criteo’s retail media ecosystem operates at a truly global scale. We power Sponsored Products across multiple continents, languages, and retail verticals — from home improvement to fashion and consumer electronics. Our systems must understand billions of products across diverse catalogs, each shaped by local consumer behavior, regulatory environments, and cultural nuance.

Semantic understanding in this context is far from trivial. A simple query can carry very different meanings depending on geography or vertical. “Chips,” for example, refers to crisps in the US, but to fries in the UK; “biscuits” are soft, savory rolls in the US but sweet, crunchy cookies in Europe; and “Apple” may denote a smartphone brand in consumer electronics or a piece of fruit in grocery. These nuances are not edge cases; they are daily realities at a global scale.

As a result, we need a system capable of handling multiple languages while capturing cultural subtleties, domain-specific vocabulary, and local shopping intent. At the same time, it must operate reliably across billions of product listings and millions of daily queries without compromising latency.

To address these challenges, we developed CLEPR (Contrastive Language Embedding for Product Retrieval), a deep learning model designed to measure and optimize the semantic relevance between search keywords and product offerings.

While Large Language Models (LLMs) are powerful, they are not yet practical as the primary retrieval engine in our setting. On-site Sponsored Products must respond in a few tens of milliseconds and score billions of keyword–product pairs per day. Running an LLM at that frequency would be prohibitively expensive and too slow for real‑time retail search. Our CLEPR two-tower architecture addresses both problems at once. Similar to the DeepKNN system described in “Optimizing Advertising Performance with Advanced Machine Learning and Vector Database Technology” these vector representations place related items close together in a shared space, enabling fast similarity scoring with low latency and predictable costs at Criteo scale.

Optimizing Advertising Performance with Advanced Machine Learning and Vector Database Technology | Criteo

We first experimented with CLIP, which was the most popular text–image encoder at the time. While CLIP’s text encoder could theoretically represent keywords to retrieve products, this method is less ideal: keywords, typically broad and concise, differ significantly from the detailed and descriptive product titles and descriptions CLIP was trained on. Concretely, CLEPR is a two-tower neural network architecture featuring two specialized encoders: one for search keywords and another for products. Using contrastive learning, CLEPR learns to map semantically similar keywords and products into nearby points in a shared embedding space, enabling us to compute relevance scores that capture the true intent behind user searches.

Training CLEPR: overcoming data sparsity and quality challenges

Ideally, we would train CLEPR directly on organic search clicks: when a user searches for “running shoes” and then clicks a specific product page, this search‑to‑product interaction provides noisy but powerful evidence that the query and product are relevant to each other. By mining millions of such organic search‑to‑click events on retailers’ e‑commerce platforms, one could automatically build positive (keyword, product) training pairs without any manual labeling.

In practice, however, we do not collect these search‑to‑click events explicitly. We only see search events and product page visits as separate log events. To approximate the ideal signal, we reconstruct pseudo “organic clicks” by stitching together consecutive search events and subsequent product page views within the same session, using simple heuristics based on temporal proximity and session information. This reconstruction lets us train at scale on a natural behavioral signal, but it also makes the data inherently imperfect.

Once these heuristic search‑to‑product pairs are built, CLEPR learns to pull matched keyword–product pairs closer in a shared embedding space through contrastive learning.

However, even after reconstruction, this click-based training signal remains imperfect. In particular, it can produce false positives where a product is clicked after a query, but the click does not actually reflect the user’s search intent. To limit this noisy traffic, we apply strict data‑quality filters. We retain only keyword–product pairs with high exclusivity scores (where a keyword consistently leads to clicks on the same product across sessions) and enforce hard thresholds on minimum volume and recency of interactions. These safeguards do not fix issues such as relevant products that are never clicked, but they substantially reduce spurious positive pairs and focus training on the most reliable keyword–product relationships.

Even with these filtering strategies, an important concern remains: a model trained on click data may learn to reproduce behavioral biases rather than true semantic relevance. Clicks are biased by search result positioning, product popularity, and user behavior patterns that don’t necessarily reflect semantic relevance. For this reason, we adopt a contrastive learning objective: instead of predicting clicks directly, the model learns to bring embeddings of matched keyword–product pairs closer together while pushing apart mismatched pairs within the same batch. This relative training signal encourages the model to capture discriminative semantic structure rather than absolute click propensity. For example, even if a keyword–product pair appears with 10,000 clicks in the training data, we only count it once, preventing popularity bias and keeping the focus on semantic meaning. To obtain an accurate measure of model quality, we evaluate CLEPR on human-labeled keyword-product pairs, where annotators provide explicit relevance judgments. These annotations serve as ground truth, allowing us to measure whether CLEPR genuinely understands relevance beyond the patterns in click data. CLEPR’s contrastive learning approach, trained purely on filtered click data, must learn rich semantic representations that generalize to these human-judged examples — a true test of whether the model has captured meaningful relevance signals rather than simply overfitting to click biases.

CLEPR in production: bringing semantic guardrails to ranking at scale

Deploying CLEPR in our ranking pipeline brought semantic relevance directly into production. Acting as a guardrail, CLEPR ensures that candidate products meet a minimum relevance threshold before performance optimization, reducing mismatches between search intent and ad placement.

We followed a deliberately careful, experimentation‑driven path to get there. CLEPR was first introduced behind strict safeguards, with successive A/B tests and phased rollouts to validate every change before expanding its impact. At each step, we closely monitored both semantic and outcome-based relevance, only scaling up when experiments demonstrated clear, consistent gains.

Operating CLEPR at the Criteo scale also required solving non‑trivial ML engineering challenges.

On the inference side, we must continuously re‑embed a catalog of about 2B products whenever product content changes, and still score over 10 billion keyword–product pairs per day across languages, verticals, and retailers. This calls for highly optimized offline inference pipelines and infrastructure that can run massive batches of CLEPR forward passes in a reasonable time, while keeping latency low and costs predictable.

Training at this scale introduces its own constraints. To keep up with the volume and diversity of training data, we rely on Distributed Data Parallel (DDP) training with Ray over a multi‑GPU cluster, allowing us to efficiently ingest billions of keyword–product pairs, stabilize optimization, and iterate quickly on new CLEPR versions.

After deployment, we saw a +6% increase in Click-Through Rate (CTR) and a sharp drop in relevance issues. CLEPR proves that embedding semantic understanding into production not only improves shopper trust but also drives measurable engagement gains.

What’s next? Powering AI-Native Commerce

By embedding CLEPR scores as features in our ad ranking and filtering pipelines, we create strong relevancy guardrails that improve user experience, increase ad engagement, and help advertisers reach the right audiences with the right products.

Building on this foundation, we are now extending CLEPR’s semantic intelligence into AI-native shopping experiences. In this context, we are exploring multimodality, where CLEPR can jointly leverage text, image, and other signals, and how it can best interoperate with Criteo’s Foundation Models to inject richer commerce knowledge into AI-native journeys.

Next, we’re extending this semantic intelligence into AI‑native shopping experiences. Building on Criteo’s agentic commerce vision described in Sherry Smith’s blogpost, “Why retail media rises in an agentic commerce era” (Why retail media rises in an agentic commerce era | Criteo we are designing conversational shopping assistants on retailers’ properties, where commerce shifts from keywords to rich, natural‑language interactions. CLEPR ensures products surfaced in these experiences are tightly aligned with what shoppers actually mean.

Why retail media rises in an agentic commerce era | Criteo

At the same time, our Agentic Commerce Recommendation Service connects AI shopping assistants directly to merchant inventory through Criteo’s commerce intelligence. CLEPR translates open-ended queries into transaction-ready recommendations grounded in real shopping signals — not just catalog metadata.

As commerce shifts from keywords to conversations, CLEPR is evolving from a ranking feature into a foundational semantic layer for AI-driven discovery.

Introducing CLEPR, our model for semantic understanding was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The 14th International Conference on Learning Representations (ICLR 2026) was held from April 23 to 27, 2026, at the Riocentro Convention and Event Center in Rio de Janeiro, Brazil. It was the first time the conference made its way to South America. As one of the three flagship venues in machine learning, ICLR gathers each year several thousand researchers and practitioners from academia and industry around the latest advances in representation learning.

This edition was particularly vibrant, with a strong emphasis on reasoning and agentic LLMs, world models, multimodal foundation models, diffusion-based generation, and modern 3D and 4D scene representations. The setting itself, sitting between the conference center, the beach, and the Pão de Açúcar, added a uniquely warm and collaborative atmosphere to the technical program.

Our Contributions

Contextual Multi-Armed Bandits with Minimum Aggregated Revenue Constraints

Authors: Ahmed Ben Yahmed, Marc Abeille, Hafedh El Ferchichi, Vianney Perchet.

Our paper addresses an open question in the literature on the exploration–exploitation dilemma for contextual bandits with minimum revenue guarantees, where the learner must simultaneously maximize cumulative reward and ensure a minimum aggregated revenue for each arm across contexts. Prior work shows that in the non-contextual case, multi-armed bandits with revenue constraints can achieve fast rates for both regret and constraint violation; however, in the contextual case, existing methods rely predominantly on primal-dual approaches that yield only √T guarantees on both metrics. We establish a sharper trade-off between regret and constraint violation through two algorithms, OLP and OPLP, which target two opposite points on the Pareto frontier, one prioritizing regret, the other prioritizing constraint satisfaction. Our results are essentially tight, matching the lower bounds we derive.

Main takeaways

• Pareto trade-off: OLP achieves polylogarithmic regret with O(√T) constraint violation, while OPLP flips this, polylogarithmic constraint violation with O(√T) regret, giving practitioners two operating points on the performance/constraint-satisfaction frontier.
• Novel gap notion: We define the sub-optimality gap ρ* via the LP’s active constraint set rather than reward differences, providing a refined complexity measure that generalizes naturally to other globally-constrained bandit problems.
• Lower bound rules out free exploration: We establish a matching Ω(√T) lower bound, and prove that whenever K > 2 and |C| > 1, the optimal allocation assigns zero probability to at least one (arm, context) pair. This refutes the “free exploration” property exploited in non-contextual settings (Baudry et al., 2024), restoring the classical exploration-exploitation tradeoff.

Contextual Multi-Armed Bandits with Minimum Aggregated Revenue...

Fused-Planes: Why Train a Thousand Tri-Planes When You Can Share?

Authors: Karim Kassab*, Antoine Schnepf*, Jean-Yves Franceschi, Laurent Caraffa, Flavian Vasile, Jeremie Mary, Andrew Comport†, Valérie Gouet-Brunet† (*,† equal contribution).

Tri-Planar NeRFs have become the go-to representation for large-scale 3D modeling, as their 2D planar structure makes them directly compatible with standard image-based architectures. Yet, the prerequisite step of training a Tri-Plane per object is computationally wasteful: each scene is fit in isolation, ignoring the rich structural similarities that exist within an object class. Our paper, Fused-Planes, addresses exactly this inefficiency.

We introduce a novel planar representation that decomposes each object into two complementary components: a micro plane that captures object-specific details, and a macro plane obtained as a learned linear combination over a small set of globally shared base planes.

Main takeaways

• State-of-the-art efficiency among planar representations: 7.2× faster training and 3.2× lower per-object memory footprint than Tri-Planes, while improving rendering quality.
• Ultra-lightweight variant (Fused-Planes-ULW): 1875× smaller per-object footprint than Tri-Planes, with only minor quality degradation, opening the door to truly large-scale Tri-Plane datasets.
• Design insight: the latent space and the micro/macro decomposition are both essential. Each in isolation underperforms; together, they provide a framework with similar or better quality than Tri-Planes.

Fused-Planes

On the Impact of the Utility in Semivalue-based Data Valuation

Authors: Mélissa Tamine, Benjamin Heymann, Maxime Vono, Patrick Loiseau

Our paper studies a practical but often overlooked question in semivalue-based data valuation: how much do the resulting data rankings depend on the utility function chosen by the practitioner? In data valuation, each data point is assigned a score reflecting its contribution to a downstream task. These scores are then typically used to rank examples, for instance, to remove harmful samples, select a smaller training subset, or reason about the contribution of different data providers.

The issue is that semivalue-based methods, such as Data Shapley, Beta Shapley, or Data Banzhaf, do not produce values in isolation: they depend on a utility function. If small changes in the utility lead to completely different rankings of the data points, then the valuation is hard to interpret and may not be reliable enough for downstream decisions.

We address this problem by introducing a geometric view of utility dependence. For a fixed semivalue, we embed each data point into a low-dimensional space, which we call the dataset’s spatial signature. In this space, choosing a utility corresponds to choosing a direction, and the value of a data point is obtained by projecting its embedding onto that direction. Therefore, changing the utility becomes a geometric rotation, and robustness becomes the question: how far can we rotate the utility direction before the ranking of data points changes significantly?

Building on this representation, we define a robustness metric that quantifies how stable the data-value ranking is under changes in the utility. Empirically, we show that this robustness metric agrees with classical rank-correlation analyses: when rankings under different utilities have low Kendall or Spearman correlation, our robustness score is also low. We also observe that Banzhaf often yields more robust rankings than Shapley or Beta Shapley, and we provide geometric and analytical insight into why this happens.

Main takeaways

• Data valuation should not be used blindly. Even when the valuation method is fixed, changing the utility function can substantially change the ranking of data points.
• Robustness to utility choice is a necessary diagnostic. Before using data values for cleaning, subset selection, or partner-level compensation, practitioners should check whether the ranking is stable or mostly an artifact of the chosen metric.
• The spatial signature gives an interpretable geometric picture. It turns utility dependence into a projection problem: data points are embedded in a space, utilities are directions, and rankings are induced by projections.
• The proposed robustness metric makes this diagnostic operational. It yields a normalized score between 0 and 1, making it easy to identify contexts where semivalue-based data valuation is reliable and those where it is too sensitive to trust.
• Banzhaf appears more robust in many settings. Across several datasets and utility families, Banzhaf often yields more stable rankings, which can be explained by the greater collinearity among its spatial signatures.

On the Impact of the Utility in Semivalue-based Data Valuation

Papers Highlighted By The Team

Can Small Training Runs Reliably Guide Data Curation? Rethinking Proxy-Model Practice?

Authors: Jiachen T. Wang, Tong Wu, Kaifeng Lyu, James Zou, Dawn Song, Ruoxi Jia, Prateek Mittal

This paper studies a very practical question in large-scale model training: can small proxy models reliably guide data curation decisions for larger target models? In many industrial and frontier AI pipelines, data teams cannot train a full-scale model for every candidate data recipe (i.e., candidate training datasets resulting from different data curation choices). Instead, they train smaller proxy models on different curated datasets, compare their validation performance, and use this comparison to decide which data recipe should be used at scale.

The paper argues that the standard proxy-model protocol has a subtle but important flaw. Most proxy experiments train all candidate datasets with the same fixed hyperparameters, often in the name of fairness. However, in realistic large-scale training, the final model is not trained with a fixed generic configuration: hyperparameters are tuned for the selected dataset. Therefore, the right objective is not to find the dataset that performs best under one arbitrary proxy configuration, but the dataset that performs best after data-specific hyperparameter tuning. The authors show that proxy rankings can be fragile: even small changes in learning rate can flip the relative ranking of data recipes. This means that a data recipe that looks best under one proxy configuration may not be the one with the best potential after tuning at the target scale. To address this, they propose a simple patch: train proxy models with tiny learning rates. Their intuition is that, in this regime, training dynamics are dominated by first-order gradient alignment between the training data and the validation distribution, while higher-order effects that can scramble rankings are reduced.

Empirically, they evaluate 23 data recipes covering domain composition, filtering, deduplication, and major pretraining corpora across the GPT-2, Pythia, and OPT model families, ranging from 70M to 1B parameters. The results are strong: using tiny learning rates significantly improves the agreement between proxy-model rankings and tuned target-model rankings.

Main takeaways

• Proxy-model data curation is not automatically reliable. Small training runs can give misleading recommendations if the proxy configuration is fixed arbitrarily.
• Fair fixed hyperparameters can be unfair to datasets. Different data recipes may require different optimal learning rates or training configurations, so comparing them under a single fixed setup can favor the dataset that happens to match it.
• Learning rate is a major source of ranking instability. Small changes in learning rate can change which data recipe appears best, even at the same proxy scale.
• Tiny learning rates provide a simple, practical fix. Training proxy models with learning rates one or two orders of magnitude below standard choices makes rankings more stable and more transferable to tuned larger models.
• This is highly relevant for data-centric AI at scale. The paper gives a concrete warning: when using small models to guide expensive data decisions, the evaluation protocol matters as much as the data recipe itself.

Can Small Training Runs Reliably Guide Data Curation? Rethinking Proxy-Model Practice

Convergence of an Actor-Critic Gradient Flow for Entropy-Regularised MDPs in General Spaces

Authors: Denis Zorba, David Šiška, Lukasz Szpruch.

This paper proves the stability and global convergence of a two-timescale actor-critic gradient flow for infinite-horizon, entropy-regularised Markov Decision Processes (MDPs) with continuous (Polish) state and action spaces under linear function approximation. The critic is updated via Temporal Difference (TD) learning on a faster timescale, while the actor is updated via Policy Mirror Descent, which in the continuous-time limit becomes an approximate Fisher–Rao gradient flow. The key technical challenge is that in general action spaces the KL divergence is unbounded (unlike the finite-action case where it is bounded by log|A|), making finite-time blow-up a real risk. The authors develop a Lyapunov-based framework combining convex analysis over both Euclidean and measure spaces to rule this out and establish exponential convergence to the optimal regularised value function.

Main takeaways

• Timescale separation is essential: The critic must run on a faster timescale than the actor for both stability and convergence; the authors show ηₜ = η₀·exp(k₁t) suffices.
• Entropy regularisation is necessary, not optional: In general action spaces, the KL term in standard mirror-descent bounds is typically infinite without regularisation, since optimal unregularised policies are mixtures of Diracs. Regularisation forces the optimal policy to have full support, making the analysis tractable.
• Convergence rate: The actor-critic flow achieves exponential convergence to the optimal regularised policy for all discount factors γ ∈ (0,1), up to an error term that decays exponentially when the critic runs sufficiently fast.
• Stability result: Under mild assumptions, KL(πₜ(·|s)|µ)² grows at most as a₁·exp(a₂t), preventing finite-time blow-up of either the policy or the critic parameters.

Convergence of actor-critic for entropy regularised MDPs in general action spaces

Best-of-N through the Smoothing Lens: KL Divergence and Regret Analysis

Authors: Gholamali Aminian, Idan Shenfeld, Amir R. Asadi, Ahmad Beirami, Youssef Mroueh

This paper provides a theoretical analysis of Soft Best-of-N (SBoN), a smoothed variant of Best-of-N (BoN) sampling for LLM alignment. Instead of deterministically picking the highest proxy-reward response from N samples, SBoN samples probabilistically via a softmax with inverse temperature β (recovering BoN as β → ∞, and the reference policy as β → 0). The authors derive finite-sample upper bounds on KL divergence between SBoN and the reference policy, and both upper and lower bounds on the regret gap versus the optimal policy. A novel tilted error metric ε_β,r is introduced to track reward misspecification, interpolating between MSE and L∞ error.

Main takeaways

• Smoothing mitigates reward hacking: When the proxy-reward model is weak, BoN overoptimizes as N grows, while SBoN’s stochasticity guards against this failure.
• Optimal finite β exists: Under overoptimization, there is a sweet spot β* where SBoN provably achieves a tighter regret bound than BoN.
• Improved theory: Unlike Huang et al. (2025), the BoN regret bound here stays finite when overoptimization vanishes, and the framework uses calibrated rewards.
• Empirical validation: Experiments with Olmo-2 1B on the Attaq harmfulness dataset confirm that SBoN outperforms BoN when paired with weak proxy reward models (Beaver 7B, Tulu-v2.5), while both perform similarly with a strong reward model (ArmoRM 8B).
• Practical edge: SBoN matches the performance of more complex methods like InferenceTimePessimism while requiring only a single hyperparameter.

Best-of-N through the Smoothing Lens: KL Divergence and Regret Analysis

Depth Anything 3: Recovering the Visual Space from Any Views

Authors: Haotong Lin*, Sili Chen*, Jun Hao Liew*, Donny Y. Chen*, Zhenyu Li, Yang Zhao, Sida Peng, Hengkai Guo, Xiaowei Zhou, Guang Shi, Jiashi Feng, Bingyi Kang*†.

Depth Anything 3 (DA3) pursues a minimal modeling strategy for 3D visual perception. Stepping back from task-specific designs (monocular depth, SfM, MVS, SLAM), the authors ask two central questions: is a single set of prediction targets enough, and is a plain transformer enough?

The paper answers yes to both. DA3 predicts geometry from any number of input views, with or without known camera poses, using a plain pretrained DINO backbone (no architectural specialization) and a single depth-ray prediction target that sidesteps the orthogonality constraints of rotation matrices by representing camera pose implicitly through a per-pixel ray map. Multi-view consistency is obtained through an input-adaptive cross-view self-attention mechanism, and diverse training data is unified via a teacher-student paradigm in which a synthetic-data-trained monocular teacher generates high-quality pseudo-depth labels for real-world captures.

On the paper’s newly proposed visual geometry benchmark, DA3 sets a new state of the art, improving over VGGT in camera pose accuracy and in geometric accuracy, while also surpassing Depth Anything 2 on monocular depth. The paper further introduces a feed-forward novel view synthesis (FF-NVS) benchmark and reports two findings: (i) fine-tuning DA3 with an additional DPT head for FF-NVS substantially outperforms highly specialized task-specific models, and (ii) enhanced geometric reconstruction capability directly correlates with improved FF-NVS performance, establishing DA3 as a strong backbone for this task.

Depth Anything 3: Recovering the Visual Space from Any Views

Sharp Monocular View Synthesis in Less Than a Second

Authors: Lars Mescheder, Wei Dong, Shiwei Li, Xuyang Bai, Marcel Santos, Peiyun Hu, Bruno Lecouat, Mingmin Zhen, Amaël Delaunoy, Tian Fang, Yanghai Tsin, Stephan R. Richter, Vladlen Koltun.

SHARP (Single-image High-Accuracy Real-time Parallax) addresses photorealistic view synthesis from a single image. The paper targets three problems: sub-second synthesis on a standard GPU, real-time photorealistic rendering from nearby views, and a metric 3D representation with absolute scale that can be coupled to a physical headset. Given an input image, SHARP regresses a high-resolution 3D Gaussian representation (around 1.2M Gaussians, parameterized over a 768×768 grid with two layers) via a single feed-forward pass.

The architecture consists of four learnable modules: a pretrained Depth Pro encoder, a depth decoder that outputs two distinct depth layers, a learned depth adjustment module, and a Gaussian decoder, and is trained end-to-end for view synthesis fidelity. Two additional contributions are emphasized: a carefully designed loss configuration that prioritizes view synthesis quality while suppressing common artifacts, and the depth adjustment module, which resolves depth ambiguities during training and is identified by the authors as a fundamental challenge for regression-based view synthesis.

Across multiple held-out datasets in the zero-shot regime, SHARP reduces LPIPS and DISTS relative to the strongest prior method, synthesizes three orders of magnitude faster than that baseline (and two to three orders of magnitude faster than diffusion-based systems more broadly), and supports rendering at more than 100 FPS on a standard GPU.

SHARP

Lyra: Generative 3D Scene Reconstruction via Video Diffusion Model Self‑Distillation

Authors: Sherwin Bahmani, Tianchang Shen, Jiawei Ren, Jiahui Huang, Yifeng Jiang, Haithem Turki, Andrea Tagliasacchi, David Lindell, Zan Gojcic, Sanja Fidler, Huan Ling, Jun Gao and Xuanchi Ren.

Lyra addresses the challenge of generating realistic 3D scenes from very limited input. Traditional 3D reconstruction methods usually require many camera views and precise camera positions, while video diffusion models can generate realistic videos but do not produce explicit 3D structures.

The main idea behind Lyra is to transfer the 3D understanding learned by a video diffusion model into a 3D Gaussian Splatting (3DGS) representation using a teacher–student training setup. Instead of relying on real multi-view datasets, the model is trained entirely on synthetic views generated by the diffusion model itself.

One of the most interesting aspects of Lyra is its flexibility: it can generate 3D scenes from a text prompt, a single image, or even a short video, and it also supports dynamic scene generation over time. The paper reports state-of-the-art performance on both static and dynamic 3D scene generation tasks.

Lyra: Generative 3D Scene Reconstruction via Video Diffusion Model Self-Distillation

EA3D: Event‑Augmented 3D Diffusion for Generalizable Novel View Synthesis

Authors: Wangbo Yu, Chaoran Feng, Jianing Li, Aofan Zhang, Zhenyu Tang, Mingyi Guo, Wei Zhang, Zhengyu Ma, Li Yuan and Yonghong Tian.

EA3D focuses on generating new camera views in challenging situations with fast camera motion, where traditional NeRF and 3D Gaussian Splatting methods often fail because they rely on sparse RGB images.

The paper combines standard RGB frames with data from event cameras, which capture rapid brightness changes and motion information much more effectively. Instead of optimizing each scene independently, EA3D uses a diffusion-based framework that learns to combine appearance information from RGB images with geometric information extracted from event streams.

A key contribution is the EA-Renderer, which builds 3D scene features from both RGB and event data, allowing the model to generate realistic and temporally consistent novel views. The authors also introduce a new large-scale dataset, Event-DL3DV, designed specifically for this task.

What is particularly interesting is that EA3D achieves strong generalization across different scenes while handling difficult motion conditions much better than previous approaches.

EA3D: Event-Augmented 3D Diffusion for Generalizable Novel View...

What Stood Out at ICLR 2026: Criteo Papers and Research Highlights was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our previous post, we explained the Engineering Program Manager role at Criteo at a high level: EPMs sit at the intersection of business ambition, technical reality, and execution, helping complex cross-team initiatives move from intent to delivery. But if you are considering this role, that high-level description is only the beginning. The more interesting question is: what does the role actually feel like in practice?

For us, the answer comes down to one simple idea: an EPM drives projects to completion in complex environments.

That means aligning people who do not naturally work together, maintaining momentum over time, and ensuring the work converges toward a coherent outcome. A big part of the role is spotting inconsistencies early, whether they are in priorities, understanding, ownership, or execution, and addressing them before they slow everything down. And underneath all of that, there is one principle that matters especially: transparency. Because consistency across teams only happens when people have access to the same information, the same context, and the same reality.

To illustrate that, we will use two very different examples:

• Audience Agent, a product-facing initiative with high ambiguity, fast iteration, and many cross-functional dependencies
• Dallas datacenter migration, a large infrastructure transformation with strict operational constraints and a strong need for sequencing, risk visibility, and production safety

On the surface, they have very little in common. One is a product-facing initiative in an emerging space, with fast learning cycles and evolving technical approaches. The other is a large infrastructure transformation, with strict operational constraints and a strong need for sequencing, readiness, and production safety. Through these two examples, we’ll look at how projects with very different dynamics and constraints still rely on the EPM role in similar ways: creating clarity, enabling collaboration, and helping teams move forward together.

Audience Agent: bringing structure to an emerging space

The Audience Agent project explored a new way of interacting with customer audience insights and segmentation data, using emerging agent-like systems to make complex workflows more intuitive and automated. The goal was to empower clients with an AI-driven experience that makes audience building smarter, faster, and more streamlined — enabling marketers to explore insights, create segments, and manage audiences through more natural and efficient interactions. More details are available in this article Introducing Agentic Audiences, and in the product demo showcasing how the agent works in practice.

From the start, there were strong product signals. We had clear use cases and a good understanding of user needs. But on the execution side, much more was still open. Some of the features had never been built at Criteo before, there were no established internal guidelines for this kind of agentic experience, and the technical approach was still evolving.

So the project started with a familiar EPM challenge: clear intent, but high uncertainty.

Our ambition was not to wait until everything was perfectly defined. It was to deliver fast, learn fast, iterate, and keep moving.

Bringing structure without losing flexibility

One of the most important things an EPM does is turn fuzzy ideas into a delivery shape that teams can actually work with. On this project, which started with a kickoff bringing together all the key stakeholders. This was not just about reviewing requirements. It was about creating shared clarity on how we would work together, what we were trying to achieve first, and where we needed to stay flexible. From there, we structured the project into three milestones. The first two had clear goals and deliverables. The third was intentionally left more open. That was a deliberate choice: we wanted to reach an MVP within the quarter, while also keeping room to adapt based on feedback and learning.

That balance matters a lot in EPM work.

Structure is necessary, but over-structuring too early can slow a project down instead of helping it.

Making a cross-functional team work as one team

Another key challenge was that success depended on close collaboration across domains that do not always work tightly together. The project brought together contributors from backend, frontend, testing, UX, AI research, AI platform, agentic core, and product. Each group had its own expertise, constraints, and perspective. None of them alone could make the project successful.

This is exactly where the EPM role becomes very concrete.

The EPM job was not to replace the expertise of those teams. It was to create the conditions for that expertise to come together effectively: making sure the right people were involved at the right time, that dependencies were visible, that the work was framed in a way people could act on, and that decisions did not get lost in the gaps between teams.

What the role looked like in practice

On a project like this, the day-to-day work of an EPM is rarely one thing. It is a mix of structuring, facilitating, connecting, challenging, and adjusting.

That meant:

• framing the work and the milestones
• collecting needs across teams
• identifying the right contributors
• aligning stakeholders around a shared delivery plan
• putting in place the right artifacts, rituals, and tracking
• keeping the broader stakeholder group informed
• surfacing cross-team impacts early
• spotting inconsistencies across workstreams
• challenging priorities when needed
• unblocking collaboration issues
• protecting momentum over time

For the Audience Agent project, we set up a dedicated cross-functional squad composed of people from different teams. While they worked almost exclusively on this scope, they still belonged to and participated in the dynamics of their respective teams. We also used a cadence that matched the project’s needs: squad stand-ups twice a week, deep dives on specific topics, and a weekly sync with a broader group of stakeholders.

That cadence was chosen to match the project’s level of dependency, urgency, and ambiguity, not to follow a supposedly “correct” process..

This is another important part of the EPM role at Criteo: we create structure, but we do not force a one-size-fits-all model. In the broader EPM role, the goal is to support ways of working that serve the teams and the program, not the other way around.

Launch is not the finish line

We reached the initial goal of delivering an MVP within the quarter. But on this kind of project, launch is not the end. It is the start of the next cycle.

From there, the work continued through iteration: incorporating user feedback, refining priorities, and building on what the first milestones had taught us.

That is part of what makes projects like this so interesting for an EPM. You are operating in an environment with high ambiguity, strong dependencies, and fast learning loops. The role is not just to keep a plan on track. It is to help the project keep making coherent progress as reality evolves.

Adapting the level of involvement

One aspect of the role that is often underestimated is how much you need to adapt your level of involvement.

Sometimes you are deeply embedded with the team, helping structure discussions and move decisions forward. Sometimes you step back and simply monitor progress. Sometimes you only intervene when something starts to drift.

The goal is not to be everywhere but to step in where and when it matters most.

That is also why the role is hard to reduce to a checklist. EPM work is contextual. It depends on the maturity of the teams, the shape of the project, the level of ambiguity, and where the biggest delivery risk sits at a given moment.

Dallas datacenter migration: making a complex infrastructure transformation deliver safely

If Audience Agent shows the EPM role in a fast-moving product and innovation space, the Dallas datacenter migration shows the same role in a completely different context: infrastructure transformation at scale.

Criteo operates and manages its own on-premises infrastructure across multiple datacenters in Europe, Asia, and America. In that context, this project is about moving out of the current Dallas datacenter and opening a new Dallas setup aligned with newer Criteo standards for architecture, resiliency, power efficiency, network access, and new server generations, while keeping production stable during the transition. This is not a simple move. It is a real infrastructure evolution: opening the new room, opening the new network hub, interconnecting the environments, migrating workloads, and eventually vacating the legacy site.

Why is such a delivery challenge

What makes this project particularly interesting is that complexity is everywhere, but not always in the same form as on a product-focused project.

Here, complexity comes from architecture choices, migration patterns, operational safety, procurement and readiness dependencies, and the sheer number of teams that need to move in the right order.

The migration approach itself is designed to reduce disruption. Instead of doing a large, customer-visible traffic cutover, the setup keeps the carrier hotel as the stable connection point, and allows work to be shifted server by server gradually into the new environment, making it transparent for clients (both internal and external).

At the same time, the project introduces updated network standards and new server generations to improve resilience, reduce power and space usage, and prepare for future infrastructure needs.

And all of this needs to happen without disturbing production in the current datacenter, and it must be completed and stabilized well before the end-of-year peak season.

What the EPM adds in practice

On this kind of initiative, the EPM does not replace technical ownership. The technical decisions stay in the experts’ hands. The role of the EPM is to create the conditions for successful delivery: ensuring the project progresses against the agreed planning, making dependencies visible as early as possible, identifying and communicating that risks along with mitigation plans, and keeping teams aligned throughout a long and complex execution path.

A lot of that work is almost invisible when things go well.

But behind that apparent continuity, there is a lot of coordination:

• defining what “done” means at each stage
• aligning multiple technical roadmaps
• sequencing readiness and migration activities
• making small but critical dependencies visible early
• clarifying which workloads can move transparently and which require more preparation
• maintaining visibility on the critical path
• communicating risks and mitigation actions clearly
• keeping stakeholders aligned without centralizing every technical conversation

This project also shows something important about EPM work: shared clarity is already a delivery enabler.

When many teams, dependencies, and risks have to move together, progress does not happen automatically. It needs structure, visibility, and continuous alignment.

Two very different projects, one same role

At first glance, these two projects do not look similar at all. One is about experimenting with a new user-facing agent experience in a fast-moving environment. The other is about evolving physical infrastructure and migration architecture without disturbing production. One needs flexibility to learn and iterate quickly. The other needs sequencing, readiness management, and careful operational control. And yet, despite these differences, the core expectations of the EPM role remain remarkably similar.

In both projects, the value of the EPM is to make delivery possible across complexity.

That means:

• creating structure without removing flexibility
• making dependencies visible before they become blockers
• maintaining transparency across teams
• adapting the level of involvement to what the project needs
• creating momentum and making experts makes the best technical decisions

This is also fully aligned with how we describe the EPM role at Criteo more broadly: EPMs help turn fuzzy ideas into scoped programs, surface dependencies and risks early, communicate progress transparently, and lead through influence rather than through formal authority.

EPMs do not replace technical ownership. They create the conditions for expert teams to deliver together.

What this means if you are considering the role

For us, this is one of the most rewarding things about being an EPM at Criteo. You are not there to be in the spotlight. You are there to help complex things actually happen.

You work close enough to the technical side to understand the real constraints, and close enough to the broader program view to keep the whole system moving coherently. That position is demanding because ambiguity, dependencies, and trade-offs are constant. But it is also what makes the role so engaging.

If you enjoy turning messy situations into actionable plans, helping teams align without flattening their expertise, and driving progress in environments where many things are moving at once, then this role can be a very good fit.

Because in the end, whether the project is innovative, operational, product-facing, or deeply infrastructural, the heart of the job stays the same: turning complexity into alignment, and alignment into execution.

If this article inspires you and sounds like the kind of challenge you’d enjoy, keep an eye on EPM opportunities on our careers page 👇

Your next adventure awaits!

What the EPM Role Looks Like in Practice at Criteo was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

From April 22 to 24, we were back on site at Devoxx France with a booth and two talks from our Tech Ambassadors, Estelle Thou and William Montaz. This year’s edition had a great atmosphere, strong turnout, and one very clear trend: AI was everywhere, with sessions on LLMs and agentic systems filling up fast and driving conversations across the venue.

Between talks, our booth gave us plenty of chances to talk about what makes Criteo unique, share some of the AI initiatives happening in our tech teams, and connect with other engineers and curious attendees from very different backgrounds.

Criteo Talks

Maternité dans la tech: Du témoignage à l’action

Estelle Thou, one of our Software Engineers, talked about concrete strategies to better recruit and retain women in tech, drawing on the experience of maternity leave: safe spaces, HR support, mentoring, inclusive communication, adaptation of the return to work, and levers for improvement, aimed at managers, HR, and developers for greater inclusion.

Production Troubleshooting: boostez vos skills, une étude de cas

William Montaz, Senior Staff SRE, walked attendees through a real-world incident involving Spark jobs corrupting data. The session explored a rigorous technical investigation method: formulating and testing hypotheses, avoiding bias, and distinguishing between correlation and root cause. The goal was to learn how to effectively diagnose any complex incident, even in uncertain environments.

Talks that stood out to our team

Stop à la dette documentaire: Industrialisez vos ADRs et READMEs avec Spec-kit

Speakers: Alexandre Guillemot, Tech Lead at WeScale, and Axel Chauvin, Senior Engineer at WeScale.

This session looked at documentation debt through a very practical lens: ADRs and project documentation should be part of the regular development workflow, not something left for the end. The spec-driven approach presented with Spec-kit was especially interesting, from specification and planning to tasks and implementation, with AI helping generate artifacts while developers remain responsible for reviewing and validating them. Another strong idea was the use of CI agents to check architecture rules, required ADRs, and consistency between code and documentation, with a scoring mechanism that can even reject a pull request when the ADR is missing or unrelated to the change.

Understanding Prompt Injection: Techniques, Challenges, and Advanced Escalation

Speaker: Brian Vermeer, Staff Developer Advocate at Snyk.

Brian framed prompt injection less as traditional hacking and more as social engineering for LLMs. Through live demos, he walked through prompt leakage, structured output abuse, role-playing, multi-turn manipulation, payload splitting, obfuscation, delimiter confusion, and link smuggling, showing that newer models are not automatically safer and that combining simple techniques can still bypass guardrails or expose sensitive data. One of the clearest takeaways was the need to be careful when AI agents have access to broad tools, chat history, or sensitive context.

Shall we play a Game? LLM Security in Practice

Speakers: Joseph Katsioloudes and Xavier René-Corail, GitHub Security Lab.

This workshop explored how to trick LLMs into revealing information they should not disclose, starting with a simple chatbot and ending with a more agentic setup based on GitHub Security Lab’s Secure Code Game. What made it memorable was how concrete it felt: some classic tricks are now blocked by major providers, but other manipulations still work, even on the latest models. The conclusion was both simple and important: prompt injection cannot be fully prevented, so the rest of the application has to be designed with that reality in mind.

⚠️ This is the workshop from Devcon Spring 2026

L’ampoule qui en savait trop: voyage au cœur de la sécurité des objets connectés

Speaker: Paul Pinault, Rtone.

What started with a simple ESP32 lightbulb demo quickly became a deep dive into the hidden complexity of modern connected devices. The talk showed how compliance, secure updates, certificate chains, real-time clocks, and long-term support requirements turn a seemingly simple IoT product into a much larger engineering challenge, especially under European regulations such as the Radio Equipment Directive and the Cyber Resilience Act. It was a great reminder that while talking to the device may take only a few lines of code, building a secure and compliant connected product is something else entirely.

7 ans au pays de Kafka

Speakers: Fabien Alberi and Valérie Servaire, Michelin.

This was an impressive look at how Michelin built and scaled its Kafka infrastructure over seven years, from factory floors to web and client-facing services. The session walked through the architecture journey from initial requirements to real-world design and showed how they achieved smooth, reliable streaming at scale.

Les design patterns agentiques dont vous êtes le héros

Speaker: Guillaume Laforge, Google.

Guillaume offered a hands-on exploration of multi-agent systems that went beyond basic demos. The session focused on coordination strategies, routing mechanisms, and swarm-style collaboration, using LangChain4j and ADK for Java to show how scalable and resilient agent-based architectures can be designed and integrated in practice.

Docker Compose votre Dev Toolkit pour AI & Cloud

Speakers: Nicolas De Loof and Guillaume Lours, Docker.

This talk focused on the latest Docker Compose updates for LLM-based applications. The demos showed how to define models, connect to external resources through providers, and offload GPU workloads with Docker Offload, all within a more streamlined workflow that brings code, models, and execution closer together for modern AI projects.

Apprendre à notre IA à apprendre

Speaker: Stéphane Philippart, OVHcloud

Stéphane Philippart brought useful clarity to the vocabulary around AI agents, covering concepts such as RAG, MCP, tooling, and agents. The key idea was to separate the reasoning engine from the runtime: the LLM acts as the brain, while the agent runtime handles state, memory, and tooling so the brain can interact with the real world. It was a strong reminder that most of the real implementation work for developers still lives in the runtime layer.

Standards et agents IA: un tour d’horizon de MCP, A2A, ADK et plus encore

Speakers: Guillaume Laforge and Emmanuel Bernard.

Several attendees highlighted this session, and the common thread in their notes was clear: AI agents are moving from standalone tools to connected systems built on shared protocols. MCP was presented as the standard way to connect agents to tools and external systems, A2A as the communication layer between agents, and ACP as a structured messaging protocol, all pointing toward a more interoperable ecosystem. Frameworks such as LangChain4j and Quarkus were also highlighted as the scaffolding that helps teams implement these ideas without getting lost in protocol boilerplate.

L’Agentic Coding, nouveau territoire du Platform Engineering

Speakers: Yankı Sesyılmaz and Julien Tanay, Doctolib.

This was another talk that came back in several recaps, and for good reason. Through Doctolib’s experience, it showed what happens when agentic coding becomes a real internal platform used by hundreds of engineers: spec-driven development, shared skills and plugins, telemetry, governance, and strong onboarding all matter as much as the models themselves. One takeaway stood out especially well: in such a fast-moving ecosystem, success is not just about building features, but about knowing what to standardize, what to govern, and sometimes what not to build at all.

PostgreSQL Analytics: It’s a Trap!

Speaker: Lætitia Avrot, Docker.

Lætitia challenged the familiar idea that PostgreSQL is only for transactional workloads and should be abandoned for analytics. A big part of the talk was about benchmark bias, especially vendor-created benchmarks that are designed to favor the engine they promote while ignoring general-purpose scenarios where PostgreSQL performs very well. Her conclusion was refreshingly pragmatic: the best engine for your data is often the one you already know how to run well.

Sous le capot d’une base de données analytique

Speaker: Sylvain Wallez, Elastic.

This session offered a deep dive into what really happens inside a query engine, using Elasticsearch and ES|QL as reference points. The talk walked through the full pipeline from parsing to logical planning, optimization, physical planning, and distributed execution, with a strong focus on predicate pushdown, vectorized execution, and static rule-based optimizations that reduce compute and data movement. One particularly interesting point was that the engine does not score multiple query plans against each other, but instead relies on deterministic rules to produce a single optimized plan.

Another World, une belle leçon d’architecture logicielle

Speaker: Olivier Poncet.

This talk revisited the architecture of Another World, the 1991 game created by Éric Chahi, and showed just how modern some of its design choices still feel today. The most striking example was the use of a custom virtual machine and instruction set, a concept that still echoes in today’s software world through technologies such as the JVM, .NET, and Docker. The session also covered compression, rendering, and sound, while reminding the audience that all of this came from one person working far outside the usual norms of the time.

De zéro à des milliards de traces, le tracing distribué chez Winamax

Speakers: Anthony Maffert and Nicolas Fidel, Winamax.

This session explored Winamax’s observability journey, from trace production to indexing, storage, and search, with open-source technologies such as OpenTelemetry, Quickwit, and Jaeger. The talk was also notable for its scale: 100% of the system is instrumented, an internal tracing SDK helps standardize implementation across hundreds of repositories, and daily trace volume reaches around 50 terabytes. For teams working on large, interconnected systems, it felt very relevant and easy to map to challenges we know well ourselves.

Devoxx France 2026 reminded us once again why this conference matters so much to our team. It gave us space to share what we do at Criteo, reconnect with the wider tech community, and come back with ideas that feel immediately relevant to the way we build, scale, and think about software today. From agentic platforms and AI security to documentation, streaming, observability, and database architecture, the event was full of strong conversations and practical lessons.

Most of all, we are leaving this edition grateful for the people we met, the talks we attended, and the energy around the booth throughout the event. We are already looking forward to the next one.

Check all the recordings from the conference here 👇

Devoxx France videos

Our Experience at Devoxx France 2026 was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Public orators have played a major role in spreading knowledge and driving progress since the early days of oratory in Ancient Greece. I’ve always been fascinated by speakers’ unique ability to catch an entire audience’s attention and how they turn messages into valuable takeaways that stick with you long after their speech is done.

If there’s one thing I’ve learned throughout my journey as a tech speaker is that knowledge doesn’t just depend on the message you want to deliver; Knowledge happens when you get people to hear it. This is even more true in today’s world. Current society is marked by constant information, and the rise of AI is accelerating and reshaping the way we gain knowledge. In a world where accessing knowledge has never been easier, we might question how relevant speakers still are…

But that’s the trick, isn’t it? We’re surrounded by this ocean of noise everywhere we go, so if you don’t want your message to get lost, you need the right voice to carry it. That’s the reason for this article on why tech speakers are still relevant today to drive progress in tech — and beyond.

Stage one: Powering through

They say that any time you learn something new, you go through the same process; a learning curve consisting of 4 distinctive stages:

1. Stage 1: You don’t know that you don’t know it, meaning that you’re still unaware of your own biases, triggers, and blockers. So, your only option is to power through.
2. Stage 2: You know that you didn’t know it. You become aware of those limitations.
3. Stage 3: You know that you know it. That’s when learning happens. You gain experience and start to improve.
4. Stage 4: You no longer know that you know it. You now have integrated the right reflexes, and you do them automatically without even thinking about it. Now, you’re ready to get the point of all this.

So, let’s rewind the tape to stage one, when I first stepped into the tech speakers’ game. During a work visit in Paris, I met Kini, our Head of Developer Relations, who emphasized how important it was to have tech experts spread knowledge and make our community more visible in and out of Criteo. He was talking about diverse ways in which we could all contribute, like writing tech articles, hosting meetups, and giving public talks. Back then, I remember thinking, “I don’t know who will accept such a challenge…”

A few months later, Voxxed Days 2025 came and, as we wanted to make ourselves known in Bucharest, one of our Dev Leads, Benjamin Degerbaix, agreed to give a talk on stage. He still needed someone else up there with him though, so, despite my insecurities, I volunteered. The goal was to introduce attendees to the world of Adtech, how we work at Criteo, and how we manage super busy times like Black Fridays from a technical standpoint. Even though I had worked on the content repeatedly with Benjamin and practiced it with Kini’s support, I felt like a total mess up there. My voice was trembling, and I couldn’t bring myself to breathe better. I remember I constantly ran out of air. But I went on, with my eyes fixed on the audience. There, I spotted familiar faces smiling back at me, which helped me to power through.

Their encouragement made a real difference for me; yet another example of how much community matters for your own growth.

Stage two: Becoming aware

Going down from there, I realized how poorly my voice sounded and how hard it was for me to breathe peacefully when fear stroke. There was only room for improvement from that point on.

I felt like I had just climbed a mountain. Was it worth it? Oh, absolutely! The view from the top was just breathtaking. We always want to master things, but there is real room to grow further when switching back to a beginner’s mind. You must accept that learning those things doesn’t happen overnight; You grow into them.

Lesson learned: No matter how much you stumble along the way or how much you need to learn still, learning always makes things more exciting — at least, for me.

Stage three: Growing into it

If public speaking might feel like an innate skill in some people, it’s like any other skill. You can learn it, nurture it, and finally master it.

That was my mindset when I agreed, later on, to join my colleague Catalin Stan on stage at Devcon to discuss developer environments from a DevOps versus Developer perspective. This time, I didn’t hesitate. I think I was rid of the fear of the unknown also. I know what troubled me the first time was my breathing patterns, and this time, I knew what I was getting myself into, so I practiced being mindful of my breathing while speaking. I found abdominal breathing to be the key here! It’s no mystery, but we’re so disconnected sometimes that breathing can end up feeling like rocket science.

Devcon was an upgrade compared to my first time on stage at VoxxedDays. I could feel it the way I spoke and how naturally I moved on stage. As I said, you grow into those things.

Stage four: Getting the point

Soon after Devcon, I was asked to present again, but this time internationally for Codemotion Madrid. This turned out to be a huge step forward for me. Why? Well, for starters, I was to be alone on stage for the first time. The talk would be longer too (45 minutes just for myself versus 30 minutes shared with a co-speaker) and there would be no familiar faces in the audience.

The talk was about the architecture of the AdTech ecosystem. I was very nervous to be alone on stage, but then it hit me: I could draw from my previous experiences. I then remembered that it’s fine and actually relevant to take breaks between sentences. It allows the information to sink in and your audience can follow your thought process more naturally. I remember placing my bottle of water on the side to remind me of that. I went on stage and did my thing. It was only after finishing my talk that I realized it: not once had I run out of air. Shoutout to me! I was now rid of my own technical difficulties and had just reached the 4th stage of learning: managing to control my breath while speaking, without thinking about it.

The room was full, and many participants showed curiosity about digital advertising. I then realized something: I had successfully delivered my message to a wide and diverse international audience. I got the global picture then: Developing those individual skills had boosted my personal growth but, more importantly, allowed me to contribute to boosting collective tech growth. At the end of the day, it was all about sharing knowledge and learning to do it with my own personal touch.

Circling back to the beginning of the article, why attend in-person conferences in a world where knowledge is accessible everywhere? Why learn to go on stage if everything can be done online?

I guess my answer lies in the power in real interactions. Sharing ideas, stories, and experiences firsthand brings (and will still bring tomorrow) real added value that can’t be found elsewhere. AI may be reshaping many things, but there is nothing like connecting in-person with people who share your interests, passions, and objectives. This thing, right there, that’s the human factor, and it cannot be replaced.

Are tech speakers still relevant in the AI era? was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you run a large production footprint in Google Cloud, changing a VM family is never just a hardware refresh. In our case, HAProxy sits on a critical path of the platform, serving as part of the traffic layer that hundreds of downstream systems quietly depend on every day. That means even a seemingly straightforward migration from one instance type to another has to be treated as a reliability exercise first and an infrastructure optimization second.

We decided to migrate our HAProxy fleet from N2D to C4D, not because the old setup was failing, but because at our scale, “good enough” is rarely the end of the story. With hundreds of VMs in production, small improvements in per-instance efficiency, network handling or latency behavior can compound into meaningful operational gains. At the same time, even a minor regression can have an outsized blast radius. This made the migration worth doing, but only with careful validation and a clear understanding of what success would actually mean.

What made this project especially interesting is that the value was not limited to raw benchmark improvements. We expected some performance benefits from moving to a newer instance family, but along the way we also found several less obvious advantages: better operational headroom, more predictable behavior under load, and benefits that only become visible when you operate proxy infrastructure at scale. This article is about that migration, how we approached it, and what we learned beyond the usual “new machine type is faster” narrative.

“Even a seemingly straightforward migration from one instance type to another has to be treated as a reliability exercise first and an infrastructure optimization second”

HAPROXY SETUP

In our platform, HAProxy is a core part of the traffic layer sitting between upstream traffic sources and a large pool of backend services in Google Cloud. It is not just a simple proxy tier: it serves millions of requests per second overall, with individual instances commonly handling around 100k–200k QPS. At that scale, even small changes in instance behavior can have a visible impact on latency, resilience and how well the platform absorbs traffic spikes or infrastructure events.

One of the main reasons this layer matters so much for us is that it gives us more flexibility than relying only on Google Cloud Load Balancing. It is also significantly less expensive, which is important when you run a fleet of this size. But the biggest advantage is control: with HAProxy, we can tune traffic distribution much more precisely and align balancing behavior with how our backend fleet actually behaves in production.

That flexibility is especially valuable in our environment because a large part of our backend fleet runs on Spot VMs and those machines are not homogeneous. We use different instance types and sizes depending on availability, price and what capacity we can actually get in each region. As a result, backend capacity is not a flat pool of interchangeable nodes: some machines are stronger than others and the fleet composition can change quickly when Spot capacity becomes constrained.

This is where HAProxy gives us an advantage beyond cloud load balancing. Instead of treating every backend as equal, we can assign different balancing weights and distribute traffic according to the real serving capacity of each machine. To make those weights meaningful, we use our own internal performance measurements for the instance types we run rather than relying only on specs. That becomes especially useful during Spot shortages, when we need to replace one machine family with another and keep the service stable while the backend mix is changing.

PLATFORM COMPARISON

N2D and C4D are not just two price points in the same catalog, they come from different product generations and were introduced for different goals. N2D was introduced as Google Cloud’s AMD-based general-purpose family, aimed at giving customers a lower-cost alternative for common compute workloads while still supporting large VM sizes and flexible memory ratios. The Milan-based version of N2D was announced in September 2021 as an update to the earlier N2D generation, bringing 3rd Gen AMD EPYC Milan into that same cost-oriented family. Google documents N2D as a general-purpose series with up to 224 vCPUs and up to 896 GB of memory.

C4D was introduced much later, in June 2025, for a different purpose. Google presents it as a high-performance VM family for demanding business workloads, built on 5th Gen AMD EPYC Turin and Google’s Titanium platform. In this context, Titanium matters as much as the CPU generation itself: Google describes it as dedicated offload hardware for networking, storage and virtualization, which reduces hypervisor overhead on host CPUs and is meant to deliver more predictable performance. Google also positions C4D above prior generations in raw capability, advertising up to 80% higher web-serving throughput and up to 30% better general compute performance versus the previous generation. C4D VMs: Unparalleled performance for business workloads | Google Cloud Blog

For us, the architectural difference mattered less as a marketing distinction and more as an operational one. N2D was built to be a strong price-performance general-purpose option, which is exactly why it had been the default choice for years. C4D, by contrast, was launched for workloads where higher and more stable performance is worth paying for. That makes the comparison less about “old versus new” and more about whether a general-purpose Milan platform is good enough for the job, or whether a Turin + Titanium platform gives enough additional throughput and consistency to justify its higher cost.

NOISY NEIGHBOR

In cloud environments, the noisy-neighbor effect is the name for performance interference caused by resource sharing on the same physical host. Even with virtualization and tenant isolation, not every underlying resource is perfectly dedicated. Different workloads can still compete for shared CPU caches, memory bandwidth, NUMA-local resources, interrupt handling capacity, NIC queues, storage paths and hypervisor attention. This usually does not appear as a hard failure. More often, it shows up as lower consistency: jitter, uneven latency and visible differences between instances that look identical on paper.

Our measurements are consistent with that kind of effect on N2D and it is especially visible for a latency-sensitive tier such as HAProxy. In practice, we observed performance differences of around 20% between nominally identical machines and performance on the same machine could also vary over time. For a high-QPS proxy layer, that means you cannot safely size the fleet around the average machine in the pool. Operationally, you have to orient load toward the weakest machines, because they define the safe capacity limit. That reduces usable headroom per instance and forces you to run more machines overall than you would need on a more stable platform.

For example, in the test below, we sent the maximum possible request volume to both the N2D servers and C2D, the previous generation of AMD instances that already provided much more stable performance. The difference was visible immediately. N2D performance fluctuated significantly throughout the day, even under the same test conditions, while C2D remained much more consistent over time.

“Operationally, you have to orient load toward the weakest machines, because they define the safe capacity limit”

We do not observe the same behavior on C4D, and that is not surprising. Google explicitly presents C4D as a platform designed for stronger consistency, describing it as aligned with the underlying NUMA architecture to provide optimal, reliable, and consistent performance. In practice, C4D combines a newer Turin-generation CPU, higher memory bandwidth, and a more advanced platform stack, which likely reduces transient contention enough that it no longer becomes visible in our HAProxy workload. So while noisy-neighbor effects are theoretically possible on any shared platform, in our case, they are clearly visible on N2D and effectively negligible on C4D.

SECRET SAUCE

One of the most valuable outcomes of this migration was that it improved much more than raw instance performance. During a broader HAProxy configuration optimization initiative, we had already learned that for this type of workload, hardware and network driver behavior matter almost as much as the proxy configuration itself. In a system serving traffic over Ethernet at very high rates, some share of CPU is always spent on IRQ processing. One of the first optimizations we applied was to dedicate a subset of cores to IRQ handling only. That helped, but it also made it clear that the default networking settings provided by the platform are designed for general-purpose workloads, not for a proxy layer operating at our scale.

A particularly useful optimization was reducing how frequently the system switches between kernel space and user space by increasing NIC interrupt coalescing values. In practice, this meant allowing the kernel to batch work more aggressively instead of interrupting the CPU as often. The change was simple:

ethtool -C ens3 rx-usecs 256 tx-usecs 256
# instead of the default 20 / 50

Our preliminary investigation showed that this could increase ICMP response latency by around 0.512 microseconds, which was negligible for our use case, while reducing the user-space share of CPU load quite significantly. In other words, the machines became not just faster, but calmer: less CPU time was wasted on constant interruption and context switching and more of it was available for actual HAProxy work.

The non-obvious advantage was that this optimization turned out to depend not only on HAProxy tuning, but also on the NIC implementation and queue format exposed by the instance family. Older environments gave us either legacy VirtIO networking or an older generation of gVNIC behavior. Newer machines, by contrast, came with gVNIC by default and more importantly, with a more modern queue model that exposed more granular driver controls. That difference mattered because the rx-usecs setting is supported only when the NIC and driver stack expose the right capabilities. In our older fleet, that path was effectively blocked even when gVNIC was enabled.

The reason it failed on N2D was not that the idea was wrong, but that the platform simply did not support the level of NIC tuning we needed. On N2D, the gVNIC driver runs with the older GQI QPL queue format:

sudo dmesg | grep gve
[    4.388590] gve 0000:00:04.0: Driver is running with GQI QPL queue format.

That queue format does not support reading or changing coalescing parameters through ethtool, which meant we could not tune rx-usecs and tx-usecs there. On more modern instances, the driver uses DQO RDA instead:

sudo dmesg | grep gve
[    2.224848] gve 0000:00:03.0: Driver is running with DQO RDA queue format.

“The machines became not just faster, but calmer: less CPU time was wasted on constant interruption and context switching and more of it was available for actual HAProxy work”

That newer mode allows tuning of network parameters and in practice it gave us a meaningful extra lever for optimization. Once we could actually apply those settings, we saw the soft-IRQ portion of CPU load drop by roughly 10%. This was one of the clearest examples of a non-obvious migration benefit: the gain was not just that the newer instances were faster, but that they unlocked a class of low-level network tuning that had simply not been available to us before.

At the same time, this is only one part of a much broader story. We have done a long and detailed body of work on adapting HAProxy to cloud environments and that topic deserves a dedicated article of its own. Much of this initiative has been driven by our SRE professionals, Dmytro Hopkalo and Damien Claisse, who have invested significant effort into understanding and improving HAProxy behavior under real cloud constraints. They will be writing a separate article focused specifically on HAProxy setup and cloud adaptation shortly after this one.

AND HOW IT GOES

We approached the migration conservatively. Our HAProxy fleet is managed through Google Instance Groups, so instead of doing a big-bang replacement, we migrated environments gradually, moving traffic from N2D-based groups to C4D-based groups step by step. After each change, we let the environment run for several days and watched the metrics that actually mattered for this layer: latency, CPU behavior, stability during peaks and the overall predictability of the fleet. For a proxy tier on the critical path, that kind of slow validation under real traffic was far more important than any synthetic benchmark.

On paper, the economics looked challenging. We use highcpu shapes for HAProxy, but the C4D equivalents come with much more memory than N2D. For example, n2d-highcpu-16 has 16 GB RAM, while c4d-highcpu-16 has about 30 GB. So part of the C4D premium was not just newer CPUs, but also paying for memory we did not necessarily need in the same ratio. In our case, the closest C4D equivalent ended up being about 88% more expensive per instance than N2D. That meant the migration only made sense if the performance gain was significant enough to let us run materially fewer resources.

Some Cost Optimization Examples

In production, that is exactly what happened. Because C4D gave us more usable performance per machine, more stable behavior, and better tuning options, we were able to right-size environments much more aggressively using c4d-highcpu-4, c4d-highcpu-8, and c4d-highcpu-16 according to real traffic patterns. We also moved to HyperDisk Balanced, which improved I/O behavior and simplified the platform. Above are the results for some environments in Japan and the Netherlands, where we achieved a significant reduction in vCPUs and instance cost. Overall, the effective savings were around 50%, despite C4D being substantially more expensive per instance on paper.

Just as importantly, we achieved all of this with zero downtime. The migration was completed without service interruption, which is exactly the standard you want for a high-QPS HAProxy layer. The only serious complication was capacity availability: during Black Friday 2025, we had difficulties with provisioning of C4D highcpu instances in the Netherlands for almost two months. That was a useful reminder that infrastructure migrations are not only about performance and cost. They also depend on regional capacity and keeping a realistic fallback plan. Looking back, the migration was worth it not because one benchmark was higher, but because the new platform changed the operational profile of the fleet: fewer vCPUs, fewer instances, lower cost, better tuning control and more predictable performance.

How We Cut HAProxy Fleet GCP Cost in Half by Moving from N2D to C4D was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

From ideation to outcome, this is the story of a privacy-preserving research project. It tells how research can generate innovations but also joy and despair.

Early 2024: The “Hammer” Phase

Two research leads who pioneered Criteo’s early privacy initiatives, as part of the Criteo multi-year research program, introduced me to a challenge born from the Privacy Sandbox era: Learning from Label Proportions (LLP). The data was no longer granular; we were looking at “bags” of samples where only the aggregate label distributions were known.

I let the problem sit. Research often begins with a subtle, subconscious “incubation” phase. This is where the mental load of the unknown begins to take its toll. In my case, but I know I am not alone, the problem starts to consume your brain. It follows you home, sitting at the dinner table and echoing through your sets at the gym. It even finds its way into your dreams, playing out in abstract logic. Eventually, this constant mental churn led to a breakthrough. I convinced myself this was a Domain Adaptation (one of my favorite research topics) problem in disguise that could be addressed using my favorite mathematical tool.

As the saying goes, when you have a hammer, everything looks like a nail, and my favorite mathematical tool was the only hammer I liked to use.

Research Lesson #1: The Tool Trap.

We often default to our favorite methods because they feel safe. The difficulty lies in staying objective enough to realize when your favorite tool is actually a distraction.

October 2024: The “False Peak”

I began generating “synthetic” samples to start working on the problem. On toy datasets, the results were staggering. Mood: Indestructible!

I onboarded two other researchers on the problem, with whom I already had successful research stories, and moved to real-world benchmarks and stress-tested the model on problems considered hard by Google fellows. It outperformed the state-of-the-art (SOTA) in nearly every category. We felt like world champions, and an ICML 2025 submission was a no-brainer… or so we thought.

January — March 2025: The Reality Check

We submitted the paper, complete with a new algorithm and what we believed was foundational theory. Then came the “silence”, two months of forced patience to let our brains muse on other problems while the work sat in the hands of reviewers.

Then came the day of the reviews. We were overconfident, eager to see just how enthusiastic the reviewers would be. You know the feeling: refreshing the webpage every minute, heart rate climbing with every click.

The reviews showed up. They weren’t glowing; they were lukewarm.

The crushing blow came from a single comment: a reviewer pointed to a 2019 paper we had completely overlooked. At first glance, it felt like the classic “reviewer-wants-to-be-cited” situation, a common hurdle in the peer-review process. Yet I rushed to re-implement the paper, as performance is everything, praying it was a false alarm or a niche case. It wasn’t. Their performance was better than ours. The “novelty” and performance we felt so proud of were suddenly under threat.

Mood: Rock bottom.

Research Lesson #2: The Hidden Literature.

Research is difficult because you aren’t just racing against the present;
you’re racing against every paper ever written. Missing one citation can invalidate months of work.

April 2025: The Valley of Despair

The rejection was official. It stung, but it was fair: the competition’s performance was simply superior. In a single review cycle, we went from feeling like world champions to local league players.

To make matters worse, the ground shifted beneath us: Google announced it was pivoting away from the Privacy Sandbox. The emotional toll was too high and our motivation evaporated. We lacked the energy to pivot and the time to reflect, so we did what many researchers do when the light fades: we put the project in a drawer.

Research Lesson #3: The Psychological Toll.

This is the hardest part of research: the “Dead End” phase. It requires immense emotional resilience to watch your work be rejected and your project’s relevance questioned simultaneously.

Sometimes, “putting it on pause” isn’t giving up; it’s necessary maintenance for your brain.

Research Lesson #4: Strategic Patience.

Sometimes, the best thing you can do for a project is to stop working on it. Burnout kills creativity; distance creates perspective.

November — December 2025: The Transcendent Simplicity

Dust settled. The relentless pressure to “publish or perish” for the ICML cycle had faded, and another successful privacy project gave us the breathing room and the energy to open the drawer again.

Then, it happened. Out of the quiet churn of dozens of trials and errors, and the solitary musings of a researcher staring at mountains of experiments, came a spark. A new way to refine the method, one that actually simplified the entire architecture.

The results were undeniable: we had achieved state-of-the-art performance. Again.

Research Lesson #5: Order from Chaos.

The difficulty of research is that you must navigate through extreme complexity to find simplicity. You have to be willing to be wrong, to be rejected, and to wait, just to find that one elegant truth that was hiding in the noise all along.

In December, as we sat down to write the paper, the true “Epiphany” arrived. The new algorithm fit perfectly into a beautiful mathematical framework, one that made the entire approach feel flawless. There were no longer any “black box” components or parts justified by sloppy rationales. The pieces didn’t just fit; they belonged together. It was no longer a collection of ideas; it was a cohesive truth.

As it turns out, performance isn’t everything. Mathematical beauty counts.

Research Lesson #6: Writing is Reasoning.

The “write-up” isn’t just a report; it is the final, most rigorous stage of discovery. Moving from a mental sketch to a formal paper acts as a cognitive filter, exposing “hand-wavy” logic and forcing messy architectures into elegant frameworks. You don’t write to record an epiphany, you write to invite one.

January 2026: The Seoul Cycle

The dust from the previous year’s rejection has been recycled into fuel. We’ve just hit “Submit” for ICML 2026 in Seoul. The paper is unrecognizable from the 2025 version; the new algorithm is more efficient, the math is rigorous, and we’ve proactively addressed that 2019 competitor in the related work.
Current mood status: Cautiously Zen.

But the difficulty of research doesn’t end at the submission button. Now begins the “Black Box” phase. Between now and the April 30 notification date, the work is out of our hands. We will likely face a tough rebuttal period in late March, where we’ll have one week to defend our work against “Reviewer 2”, who might still argue that the problem is irrelevant because the Privacy Sandbox was dropped.

Research Lesson #7: The Zen of Detachment.

You have to care enough about the work to spend a year perfecting it, but be detached enough to realize that a conference decision isn’t about you
personally. Research is a marathon where the finish line (the conference in Seoul) is fixed, but the path is paved with “Weak Rejects” that you have to flip into “Accepts” through sheer persistence.

So What May Happen Next?

• The Best Case: The epiphany holds up. Reviewers recognize the elegance of the mathematical framework, and by July 2026, we will be presenting our work at the COEX Center in Seoul, contributing a definitive solution to the LLP problem.
• The Reality Check: We might get “lukewarm” scores again. If so, the next step isn’t to give up as we did in April 2025, but to use the rebuttal phase to educate the reviewers on why this simplified framework is actually a fundamental shift in the field.
• The Pivot: Regardless of the ICML outcome, the “epiphany” has given the work a life of its own. Even if the Privacy Sandbox is gone, the math behind learning from aggregated data is universal, it’s the future of medical data, financial privacy, and beyond.

The Final Word: The Pulse of Discovery

In the end, this is the heartbeat of research. It is a cycle that demands you find the courage to begin confident and joyful, the resilience to endure the despair of being “scooped” or rejected, and the clarity to see that a failed submission is often just the “incubation” for a greater idea. Of course, we must also accept the truth that, sometimes, the drawer stays closed.

Whether the notification on April 30th is an “Accept” or a “Reject,” the outcome has already been won. We traded the overconfidence of the “world champion” for the quiet certainty of the architect of a novel framework. We found the beauty in the math, and that is a victory that no reviewer can take away. Furthermore, the algorithm we built will serve as a keystone when the industry shifts again, placing Criteo in a formidable position for whatever comes next in privacy.

Research is a rollercoaster, but it’s a ride worth taking.

The Math Behind the Epiphany

The core challenge of Learning from Label Proportions is that the labels are hidden inside “bags”. Our breakthrough came from a simple intuition: if we introduced a small set of samples, anchors, with known labels, they could act as a compass for guiding the model to identify categories within the rest of the data, only based on proportions.

We framed this as a Domain Adaptation problem. We treated the anchor samples with known labels as a “source” and the unlabeled bags as the “target”. The goal was to align the features of the unlabeled data within those bags with the known behavior of our anchors.

To make this alignment happen, we used Optimal Transport. Think of it as a mathematically disciplined way of moving points in space. Instead of letting the model guess, we used an iterative process to “move” samples toward their most likely counterparts. This was the “hammer” I loved to use, and it provided a crucial guarantee: the math ensured that the majority of our samples were being pulled toward the correct regions of the feature space, rather than drifting aimlessly. It turned a guessing game into a precise geometric migration.

The final, “beautiful” framework emerged as a single, unified optimization problem. It doesn’t just move the data; it jointly learns the model parameters while migrating the anchor samples toward their final goal in one seamless mathematical motion.

Check the paper 👉 Particle Flow for Learning from Label Proportion.

The Grind Behind the Epiphany: A Short Story of a Research Project was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Criteo, Engineering Program Managers (EPMs) sit at the heart of our most complex, cross-team initiatives. We connect business ambition with technical reality, helping engineering teams ship impactful products at scale. In this article, three EPMs share what the role really looks like, why we love it, and how your career can grow in this path.

If you ask ten people what an EPM does, you’ll probably get ten different answers… So let us explain our vision of the EPM role: what we do (and don’t), why so many of us love this job, and how the role can evolve over time.

What is an EPM at Criteo?

At Criteo, we’ve been working hard to define this role more clearly. In this section, we’ll explain who we are, how we work, and what we are actually doing.

Who are we?

EPMs are part of Criteo Technology, led by the CTO. They are embedded in engineering domains (e.g., Infra/Platform, Security, Product functional areas such as campaign management or audience) or transversal programs (e.g., AI, agentic commerce). Our main goal is to deliver our projects efficiently, and to do so, we must facilitate and work in close partnership with:

• Product Managers (PMs) — who translate an idea into a product vision.
• Engineering Managers (EMG) / Dev Leads/Devs — who own the technical strategy, the product building.
• other EPMs — who own how it all comes together and actually ship
• Functional teams (Legal, Sales, Finance, …)- Who support our client operations (rollout strategy, sales enablement, compliance, data analysis…)

A simple way to think about it: EPM is the heartbeat of a program, connecting tissue between business intent, technical reality, and execution at scale.

How do we work?

We use a shared mission statement for the EPM team at Criteo:

Our mission is to drive valuable outcomes from complex engineering projects and programs, and improve the delivery of R&D, while supporting Product and Engineering.

This is a catchy phrase, but in practice, this means:

• Turning fuzzy ideas into scoped, phased programs that teams can execute
• Making sure dependencies, risks, and trade‑offs are surfaced and handled early
• Ensuring delivery flows are as simple and efficient as possible (reducing friction, hand‑offs, and noise)
• Measuring and communicating outcomes, not just activity (e.g., revenue impact, time saved, quality improvements)

In our role, we consistently keep 3 pillars in mind:

Projects / Delivery — Making sure complex initiatives are correctly shipped by:

• Clarifying scope, dependencies, and success criteria.
• Designing the delivery plan: phasing, milestones, critical path, anticipating challenges and risks early, and preparing mitigation plans.
• Coordinating execution across teams, managing constraints (time, resources, scope), and adapting plans as reality changes constantly.
• Communicating progress, risks, and changes with as much transparency as possible.

Best Practices & Processes — Acting as “guardians of the temple” for key R&D processes with a pragmatic approach by:

• Supporting and improving rituals like project kick‑offs, technical architecture validation, and quarterly preparation/planning.
• Helping teams pick and evolve ways of working (Scrum, Kanban, hybrid) that actually serve them, rather than forcing a one‑size‑fits‑all model.
• Continuously refining our operating model: processes should serve the teams, not the other way around.

Influence and collaboration — Aligning all the stakeholders to move in the same direction by:

• Providing a neutral, program‑first view when priorities collide.
• Sometimes, saying “not yet” or “not this” (always backed by actual capacity and risk data) when everything can’t fit at once.
• Keeping alignment across Product, Tech, and Go‑to‑Market so that increased velocity doesn’t just produce more chaos.

What concretely do we do(n’t)

People we work with often mix up what we do and what we don’t do. Let us clarify what people think we do and what we actually do.

🚩️ “EPMs manage people.”
✅ We lead through influence and partner with managers. BUT EMG/Devleads are managing the people.

🚩️ “EPMs write code and define technical architectures.”
✅ We take part in technical discussions and ask probing questions (sometimes “annoying” but always necessary) to strengthen the shared understanding between Product and Engineering and to ensure consistency at the company level. We don’t write production code, but we do speak the engineers’ language: most EPMs have an engineering background (though it’s not mandatory), which allows us to challenge plans and identify risks. BUT, development teams own the technical decisions, and Product Managers own the product features.

🚩️ “EPMs are like Scrum masters, they plan and organize our teamwork”.
✅ Teams can use Scrum or Kanban, and some ceremonies overlap. BUT we focus on end‑to‑end program outcomes, not on running every daily for a single squad.

🚩️ “EPMs prioritize for the company.”
✅ We frame trade‑offs, expose dependencies, and highlight constraints. We often challenge prioritization or roadmap assumptions when they clash with capacity or reality. BUT PMs and Dev Leads own their roadmaps and the final calls.

🚩️ “EPMs defend only R&D or product interests.”
✅ We must take a step back and see the big picture outside of Product or R&D point of view to deliver the best possible outcomes for Criteo.

🚩️ “EPMs must be in all the decision meetings, and everything must be validated by us.”
✅ We don’t want all information and decisions to be funneled “through the EPM.” We push for open channels and direct conversations between the people who actually do the work.

Why we love our job

Given all this complexity and ambiguity, why do people stay in EPM roles and genuinely enjoy them?

One of the main reasons is the diversity. No two programs look the same. When you take a look at the different projects the 3 of us have been working on, those are completely different with different technical topics, product and business goals, and stakeholders:

• Criteo GO: Our new self-service platform that enables small businesses to launch and optimize effective digital ad campaigns in minutes.
• Audience Agent: A new way of interacting with audience data, leveraging emerging agentic systems to make complex workflows more intuitive and automated — Which we’ll deep-dive in another post.
• Datacenter migration: The opening of a new air-cooled datacenter room in Dallas, aligned with updated DC standards, improves efficiency and paves the way for advanced technologies such as densified infrastructure. We’ll explore this topic in a future post.

Another reason is the dynamism and the daily challenges. We never get bored. We’re often brought in when everything is moving at once (priorities, constraints, and expectations) and there’s no obvious path forward, which is exactly what makes the work engaging. If we can give you examples, we have to:

• Deal with ambiguity: We’re often pulled in when something is clearly important, but nobody has yet turned it into a clear objective, scope, and plan. Our job is to take that fuzzy idea and work with stakeholders to turn it into something concrete that teams can actually build and deliver.
• Manage the constraints: Capacity versus ambition, tech debt, compliance, client commitments, market windows. Quarter preparation at Criteo, deciding what actually fits in the next quarter, can be a roller coaster. It is essentially a structured conversation about finding the right balance between trade‑offs.
• Lead through influence, no formal authority: We don’t manage people, and we don’t sign off on roadmaps. Instead, we help shape how programs are defined, sliced, and delivered, and we’re expected to speak up when something needs to be reshaped or even stopped.

And finally, we love our job also because of Criteo’s culture: a collaborative, supportive, and learning-oriented environment where we get to work with smart people who are willing to share, challenge, and grow together.

What can I become when I grow old?

Who becomes an EPM?

Whether you started as an engineer, a PM, or a project/program manager is finally secondary. The specific path you took matters less than the skills and mindset you bring.

What really makes someone effective as an EPM at Criteo is a mix of:

• Systems thinking: being comfortable with complexity, dependencies, and trade-offs.
• Structured communication: turning messy reality into clear narratives and actionable plans.
• Bias to action: driving progress instead of staying on the sidelines.
• Resilience and curiosity: sticking with tough problems and wanting to understand how things really work.
• Technical knowledge: understanding engineering concepts well enough to follow technical discussions, challenge plans, and spot risks.

What can I do then?

Once you’re in the role, the natural next question is: what does growth look like if I stay an EPM? Or should I try something else? The good news is that both scenarios are possible.

Growing within the EPM path

If you choose to stay in the EPM craft, you can build a long, rich career without changing jobs entirely — your scope, impact, and challenges simply grow over time. Instead of running a single project in one product area, you gradually move to larger, more complex programs and portfolios that span multiple teams and connect to company-level priorities, not just one product.

As you progress, the challenges also evolve:

• Functional and technical: deeper product and tech topics, more complex systems, tougher trade-offs.
• Operational: heavier coordination, higher stakes, more critical communication and reporting, especially on initiatives closely followed by leadership.

With seniority, we’ll also expect you to share your experience by mentoring other EPMs and ICs, and by supporting EMGs/Devleads on program practices.

Moving beyond EPM

And if, at some point, you want to move beyond the EPM role itself, the skills you’ve built can easily be reused in several roles:

• Product Management. If you’re drawn toward owning the “why” and “what” — problem definition, value, customer outcomes — your EPM background in execution and cross‑team alignment is a strong foundation.
• Engineering Management / Tech Leadership. If you want to lead teams directly and own technical direction, you already understand capacity, dependencies, risk, and how to make complex work deliverable.
• Org / Strategy / Business Ops. If you love planning, prioritization, and portfolio‑level thinking, there are paths into roles focused on how we invest, how we plan across time horizons, and how we evolve our operating model.
• Domain leadership. Some EPMs go deep into a space (e.g., infra, AI, security, data, commerce experiences) and evolve into leaders whose job mixes domain strategy with strong program orchestration.

The point isn’t that EPM is “just a stepping stone”. It’s that:

Being an EPM builds a rare mix of strategic thinking, execution craft, and cross‑functional influence that keeps a lot of doors open. You can stay and deepen your craft, or you can pivot when the right opportunity appears — without starting from scratch.

If we had to summarize in short words, we are not always in the spotlight, but if you look behind most large, cross‑team successes in Product & Technology, you’ll usually find an EPM somewhere in the middle asking the awkward questions, mapping the dependencies, making risks visible, nudging decisions forward, and quietly making sure the whole thing actually works. And for those of us who love seeing the whole system, connecting dots, and getting things done and done right, then this job is made for you.

The three of us who worked on this article genuinely love what we do. Even if the day‑to‑day isn’t always easy, we feel we’re in a unique position: close enough to the functional side of Criteo to understand the business, and close enough to the technical side to enjoy the engineering challenges that come with it. We rarely get bored, and we have the chance to work with great teams in a great atmosphere.

If this article inspires you and sounds like the kind of challenge you’d enjoy, keep an eye on EPM opportunities on our careers page 👇

Your next adventure awaits!

At the Heart of Delivery: What Engineering Program Managers Do at Criteo was originally published in Criteo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.