Leveraging LDP for High-Trust OpenSearch UBI

I’m speaking at OpenSearchCon North America 2026 in San Jose, September 22 to 24. My talk is Leveraging LDP for High-Trust OpenSearch UBI, and it’s about a tension that anyone who works on search eventually runs into. The behavioral data that makes search better is also the data your users are most sensitive about.

The short version of UBI

OpenSearch User Behavior Insights , or UBI, is a standard way to capture what users actually do with your search: the queries they type, the results that came back, and the events that follow, like clicks and purchases. The key idea is a shared identifier that ties every event back to the query and the ranked result that produced it. That connected data is what powers learning to rank, A/B testing, and honest relevance measurement. I wrote a longer introduction to UBI .

The catch is right there in the value proposition. To learn from behavior, you have to collect behavior, and behavior is personal. What someone searches for can reveal their health, their finances, their politics, or their plans. Capturing that stream, tying it to a session, and storing it in an index is exactly the kind of data collection that makes privacy teams nervous, and rightly so. It’s the same concern that drives my work at Philterd on Phileas , an open-source engine for finding and redacting sensitive information before it lands somewhere it shouldn’t.

The short version of LDP

Local differential privacy , or LDP, is a way out of that bind. It’s a formal, mathematical definition of privacy, but the intuition is simple: instead of sending true data to a server and trusting the server to protect it, each user’s data is randomized on the client, before it ever leaves their device.

The classic illustration is randomized response. Suppose you want to know how many people did something sensitive. You ask each person to flip a coin in private. On heads, they answer honestly. On tails, they flip again and answer yes or no based on that flip. Any individual can now plausibly deny their answer, because the noise could explain it. But across thousands of people, the coin flips are predictable, so you can subtract them out and recover an accurate count. You learn the aggregate without ever learning any individual’s truth.

That’s the whole trick, and it’s why LDP is a high-trust design. You aren’t asking users to trust that you’ll guard their raw behavior, because you never receive their raw behavior in the first place. The privacy guarantee holds even if the server is compromised, subpoenaed, or simply careless.

Putting them together

The talk is about what happens when you apply LDP to UBI. On its own, UBI collects true signals. Layer LDP on top, and each client perturbs its own events before they’re reported, so the data that lands in OpenSearch is noisy at the individual level but statistically faithful in aggregate. You still get the counts that drive relevance work, which queries underperform, which results get clicked, whether a ranking change actually helped, without holding a database of exactly what each person did.

There are real trade-offs to work through. Noise costs you some precision, so there’s a privacy-versus-accuracy dial to set. Some UBI use cases survive aggregation cleanly while others lean on session-level chains that are harder to preserve under LDP.

Come to the talk

If you’re at OpenSearchCon North America 2026 in San Jose, come find out how far you can push relevance while promising your users that you’re genuinely not watching them. I’ll walk through UBI, LDP, and the practical mechanics of combining the two, along with the trade-offs you’ll want to reason about before turning it on. The talk includes a Jupyter notebook that walks through real code, so you can see LDP applied to UBI data end to end rather than just on a slide. I’ll add that notebook code to this post after the conference, so check back if you want to work through it yourself.

If you can’t make it but want to talk through high-trust search data, please reach out.