User matching

User matching is the practice of linking one company's identifier for a person or device to another company's identifier, so bid requests, audiences and conversions can be joined across systems.

The OpenRTB 2.6 specification treats user matching, user syncing and cookie matching as other names for cookie syncing. Its Appendix C, added in release 2.6-202409 on 23 September 2024, explains the match table. The exchange usually holds it and puts the DSP's own ID for the user in the buyeruid field of each bid request (IAB Tech Lab, OpenRTB 2.6, Appendix C).

Matching now goes well beyond cookies. The same release added inserter, matcher and mm to the extended ID (eids) object, so a request can say who matched an ID and how. The AdCOM list of ID match methods has five values after "unknown" (IAB Tech Lab, AdCOM 1.0). They are no match, browser cookie sync, authenticated (a login or hashed email), observed first-party ID, and inference from signals such as IP address.

Buyers use these values to weigh an ID. An authenticated match is usually more reliable than an inferred one, and some buyers price them differently.

Example: An SSP matches a reader's hashed email to an identity provider's ID and adds it to the request as "eids": [{"source": "id-provider.example", "matcher": "ssp.example", "mm": 3, "uids": [{"id": "a7Fq...", "atype": 3}]}]. The mm value 3 tells the DSP the match came from authentication, and atype 3 marks a person-based ID.

Related terms: cookie sync, identity resolution, hashed email, RampID, UID2, bid request.

Authoritative source: IAB Tech Lab, OpenRTB 2.6, Appendix C "Cookie Based ID Syncing" and section 3.2.27 "Object: EID" (accessed 9 November 2026).

Read the full guide: Prebid Server cookie sync and user matching explained.