{"id":2021,"date":"2026-09-11T10:36:53","date_gmt":"2026-09-11T10:36:53","guid":{"rendered":"https:\/\/cms.research.wpp.com\/?post_type=research_feed&p=2021"},"modified":"2026-09-11T11:49:52","modified_gmt":"2026-09-11T11:49:52","slug":"embedding-alignment-for-profile-matching","status":"publish","type":"research_feed","link":"https:\/\/cms.research.wpp.com\/?research_feed=embedding-alignment-for-profile-matching","title":{"rendered":"Embedding Alignment for Profile Matching\u00a0"},"content":{"rendered":"
Can two companies collaborate on audience sizing and enrichment without sharing raw customer data, and without having to use the same AI embedding model? In this initial phase, we tested whether independent customer embedding spaces can be aligned using a geometric transformation guided by a small sample of shared customer profiles. We found that models built on similar foundations align almost seamlessly, and even entirely different models reliably place customers into their correct behavioural neighbourhoods for effective audience discovery. Furthermore, this alignment remains robust even with very few shared customer records. These findings prove that cross-model audience matching is viable in practice, establishing a strong foundation for our next goal: aligning spaces without needing any shared customers at all.<\/p>\n
<\/p>\n
The Problem<\/h2>\n
Consider two large B2C companies: a global e-commerce platform and a major telecom provider. Both have millions of customers and very rich data, such as purchase and web traffic history. If those two datasets could be joined, each company would learn from the other and greatly expand its understanding of its customer base. They could use this to improve their offerings, their marketing, and their personalisation features.<\/p>\n
But such a join is simply not possible, due to privacy laws and other applicable regulations. The raw data cannot be moved, and it cannot be shared with anyone.<\/p>\n
One AI-based “join” approach that has been gaining popularity is to use semantic embeddings: each customer profile is encoded by an embedding model (typically LLM-based), which converts it into a vector of a few hundred floating-point numbers. These numbers act as the coordinates of the profile in a semantic space. Similar customers are mapped to nearby points within that space; dissimilar customers are mapped to distant ones.<\/p>\n
Suppose both companies apply this process, converting their millions of customer profiles into millions of embedding vectors. Company A can then send the embedding of a customer as a query to Company B, which uses a vector index to quickly identify and count similar customers on its side. It can respond with just the count (audience sizing) or with aggregate descriptive labels that characterise the query user’s neighbours (audience enrichment). All without either side ever sharing raw customer data. Right?<\/p>\n
Not quite.<\/strong> There are at least two problems to worry about.<\/p>\n
First, an embedding is an obfuscated version of a customer profile, but it is not necessarily a safe one. Both directions of the exchange can leak. Every query embedding A sends reveals information about A’s own customer, and the counts and labels B returns can be probed by adversarially designed queries to reconstruct parts of B’s space, potentially exposing real customer data.<\/p>\n
Second, the query-based approach only works if both partners use the same encoder, the same profile-to-embedding converter. If they do not, we are comparing apples and oranges: the two semantic spaces are unrelated, and the notion of a “neighbour” across them is meaningless. In practice, the data of each partner is likely to have a different schema that will require a different encoder. For instance, the purchase history of a user has different columns than their web traffic history. Even if we assumed that both sides have the same type of data, there is no guarantee that they will choose the same encoder.<\/p>\n
In this blog post, we describe the first phase of our research on the second problem: methods for aligning spaces produced by different encoders. The first problem (adversarial embedding-based attacks) is on our roadmap and will be tackled next.<\/p>\n
Starting in Easy Mode<\/h3>\n
Before complicating the problem, we must first establish whether such an embeddings-based alignment is viable under ideal conditions. To this end, in this opening phase of our research, we make three simplifying assumptions:<\/p>\n
\n
\u25b8<\/span>Identical Feature Structure. <\/strong>Each of the two partners holds the exact same underlying dataset (identical feature columns and distributions).<\/li>\n
\u25b8<\/span>Pretrained Embedding Encoders. <\/strong>To generate embeddings, we assume that each side represents tabular rows as text strings and encodes them using off-the-shelf text-encoder models. In real-world enterprise deployments, a partner may opt for specialised, custom encoders.<\/li>\n
\u25b8<\/span>Anchor Points. <\/strong>We assume knowledge that a specific set of records exists on both sides (i.e. a set of shared users with accounts on both the e-commerce platform and the telecom vendor). We refer to these as \u201canchors\u201d. These anchors guide our alignment algorithm, allowing us to benchmark how cleanly we can rotate one embedding space into another. In practice, there is no guarantee that such anchors will exist or will be known to exist.<\/li>\n<\/ul>\n
We are fully aware that we cannot rely on these three assumptions when dealing with real data partners. Still, we use them to create an idealised setting that allows us to test the feasibility of different methods: if a method can\u2019t work in this simplest of settings, then it will immediately collapse once even one of our three assumptions is removed.<\/p>\n
Methodology<\/h2>\n
Dataset Source<\/h3>\n
To simulate a real-world scenario under the above assumptions, we take a starting dataset and copy it into two identical chunks, representing \u201cPartner 1\u201d and \u201cPartner 2\u201d.<\/p>\n
![\"\"](\"https:\/\/cms.research.wpp.com\/wp-content\/uploads\/2026\/09\/before_alignment-1-scaled.png\")