Cookie Matching

Cookie matching allows MGID (SSP) and a Partner (DSP) to associate their user identifiers. This enables MGID to pass both the MGID user ID and the Partner's user ID in a Bid Request when the user has been successfully matched.

How Cookie Matching Works

MGID and the Partner use their own user identifiers. Cookie matching creates a mapping between these identifiers.

For a successfully matched user, MGID sends both identifiers in the OpenRTB Bid Request:

user.id — the MGID user ID (SSP ID)
user.buyeruid — the Partner's user ID (DSP ID)

For a user who has not been matched yet, only the MGID user ID is available in the Bid Request.

The matching process is based on redirects between MGID and the Partner. Depending on which platform initiates the sync and where the mapping is stored, there are four possible integration scenarios.

Cookie Matching Scenarios

1. MGID initiates the sync, and MGID (both) stores the mapping

In this scenario, the Partner provides MGID with a user synchronization URL. The Partner's sync endpoint must accept the MGID user ID and redirect the request back to the MGID sync endpoint.

MGID expects:

The Partner's cookie sync URL.
The Partner's user ID to be passed to the MGID sync endpoint.

Example:

https://partnerURL.com/sync?gdpr={GDPR}&gdpr_consent={GDPR_CONSENT}&gpp=${GPP_STRING}&gpp_sid=${GPP_SID}&redirect_url=https://cm.mgid.com/m?cdsp=123456&c={user.id}

The flow is: MGID → Partner → MGID

The Partner stores the mapping between the MGID user ID and the Partner user ID.

2. MGID initiates the sync, and only the Partner stores the mapping

In this scenario, MGID initiates the synchronization by calling the Partner's sync URL.

MGID passes its user ID to the Partner using the user_id parameter.

Example:

https://partnerURL.com/sync?user_id={muidn}&gdpr={GDPR}&gdpr_consent={GDPR_CONSENT}&gpp=${GPP_STRING}&gpp_sid=${GPP_SID}

The Partner is responsible for storing the mapping between the MGID user ID and the Partner user ID.

The flow is: MGID → Partner

3. Partner initiates the sync, and MGID stores the mapping

In this scenario, the Partner initiates the synchronization by calling the MGID sync endpoint.

The Partner should provide:

its own user ID using the {user.id} macro;
its redirect URL using the adu parameter.

Example:

https://cm.mgid.com/m?cdsp=123456&c={user.id}&gdpr={GDPR}&gdpr_consent={GDPR_consent_string}&gpp=${GPP_STRING}&gpp_sid=${GPP_SID}&adu=https://partnerRedirectUR.com/sync?user_id={muidn}

The flow is: Partner → MGID → Partner

MGID stores the mapping between the MGID user ID and the Partner user ID.

Macros and Parameters

Parameter / Macro	Description
{GDPR}	0 if the user is not subject to GDPR; 1 if the user is subject to GDPR.
{GDPR_CONSENT} / {GDPR_consent_string}	IAB consent string when the request is subject to GDPR.
${GPP_STRING} / ${GPP_SID}	GPP consent string and the corresponding GPP section IDs when applicable.
{user.id}	Platform-specific user identifier. In the Partner context, this represents the Partner's user ID.
{muidn}	MGID-specific user identifier.

Result in Bid Requests

Once the user IDs have been successfully matched, MGID includes both identifiers in the Bid Request:

user.id - MGID user ID
user.buyeruid - Partner/DSP user ID

If no matching record exists, MGID sends only user.id.

Choosing the Integration Scenario

The appropriate scenario depends on:

which platform initiates the synchronization;
whether MGID stores the user ID mapping;
whether the Partner stores the user ID mapping.

If you are unsure which scenario is applicable to your integration, contact your MGID technical representative before implementing the sync.