MGID Cookie Matching Guide for SSPs

How Cookie Matching Works

Cookie Matching Scenarios

Inverse Mode

Macros and Parameters

Result in Bid Requests

Choosing the Integration Scenario

Cookie matching allows MGID (DSP) and a Partner (SSP) to associate their user identifiers. This enables the Partner to pass both the Partner's user ID and the MGID user ID in an OpenRTB 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, the Partner includes both identifiers in the OpenRTB Bid Request sent to MGID:

• `user.id` - the Partner's user ID (SSP ID).
• `user.buyeruid` -  the MGID user ID (DSP ID).

For a user who has not been matched yet, only the Partner's 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 different integration scenarios.

Cookie Matching Scenarios

1. MGID initiates the sync, and both MGID and the Partner store the mapping

The Partner provides MGID with a user synchronization URL. MGID initiates the synchronization by calling the Partner's sync endpoint.

The Partner's sync endpoint must accept the MGID user ID and redirect the request back to the MGID sync endpoint.

MGID expects:

1. The Partner's cookie sync URL.
2. The Partner's user ID to be passed back 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.

Both MGID and the Partner store the mapping between their user IDs.

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

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.

Only the Partner stores the mapping.

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

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 Partner user ID and the MGID user ID.

Inverse Mode

The `mode=inverse` parameter defines the direction in which the user ID mapping is stored.

In the regular mode, the mapping is stored as: muidn = externalID

Here, `muidn` is the MGID user ID and `externalID` is the Partner's user ID.

With `mode=inverse`, the mapping is stored in the opposite direction: externalID = muidn

The Partner's user ID is therefore used as the key to find the corresponding MGID user ID.

When to use mode=inverse

Use `mode=inverse` when the integration requires MGID to find its own `muidn` using the Partner's `externalID`.

This is typically relevant when MGID stores the mapping and later needs to resolve an MGID user ID based on an ID provided by the Partner, for example in traffic acquisition scenarios.

For example:

Partner externalID: abc123
MGID muidn: 987654

• Regular mapping: 987654 - abc123

• Inverse mapping: abc123 - 987654

The inverse mapping allows MGID to receive the Partner's `externalID` and resolve it to the corresponding `muidn`.

When mode=inverse is not required

Traffic acquisition by itself does not mean that `mode=inverse` should be used.

If the Partner initiates the request and already provides the MGID user ID in `user.buyeruid`, there is no need to use `inverse` just to obtain the `muidn` — the MGID user ID is already available in the Bid Request.

`mode=inverse` is relevant when:

1. MGID needs to store the mapping.
2. The Partner's `externalID` is available.
3. MGID needs to use that `externalID` later to find the corresponding `muidn`.

Does MGID need to find its `muidn` by the Partner's `externalID` later?

If yes, use `mode=inverse`. If the `muidn` is already provided in `user.buyeruid` and no lookup by `externalID` is required, `mode=inverse` is not needed.

Macros and Parameters

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

user.id - Partner/SSP user ID