User messages and Multiple Customer Management (MCM)

This article explains how user messages work with MCM delegation types and describes how child publishers can control which account manages their messaging.

Note: If you're a legacy user of Scaled Partner Management (SPM) , and you haven't updated your tagging setup to MCM, we can't guarantee user messaging will work as described.

Messages and MCM delegation types

Manage Account

For Manage Account (MA), the parent publisher should configure all messaging within the child publisher’s account. Messages will then serve through the child's ad tag.

Manage Inventory

For Manage Inventory (MI), a site with MI parents will have ad tags for:

The child's ad unit(s)
Up to 15 MI parents' ad unit(s).

If multiple accounts among the child or parent(s) publish user messages to a domain, by default Privacy & messaging will arbitrarily select one of the accountsand display that account's messaging for the domain. Account selection will be consistent for any given set of accounts publishing to the domain, but may change if the set of accounts changes.

Example

Imagine that child A has parent X and parent Y, and all 3 have published user messages on the domain example.com . Privacy & messaging will arbitrarily pick one of: child A, parent X or parent Y. Let's say, it's parent X. In this case:

We will serve the user messages of all types that parent X has configured for all users that visit example.com .
If parent X only has a European regulations message published, then none of child A or parent Y's messages of any type (GDPR, US states, ad blocking recovery, etc.) will show.
Parent X will be used for all messaging unless a new MI parent publishes user message(s) on example.com .
For example, if child A later adds parent Z and parent Z publishes a message on example.com , Privacy & messaging may arbitrarily pick a different account to start displaying their messages on the domain.

How child publishers can control which account manages their messaging

If you're a child publisher who wants more control over which account manages your messaging, you can retag your site to explicitly choose the account. There are two ways you can do this, either:

Deploy the ad blocking recovery tag on your site . You do this because the account that generates the ad blocking recovery tag will always manage user messaging.
Note: We don't support deploying ad blocking recovery tags on the same site from multiple accounts. Doing so will lead to undefined behavior.

Or
Append the ?network-code=<account_network_code> query parameter to the ad tag you placed in the document header. When this query parameter is set, we will always deploy user messaging for the account with the specified network code.
Example of the tag with the query parameter
<script async src=".../gpt.js?network-code=<account_network_code>"> </script>

You can also use the network code to configure other features like header bidding trafficking . If you have multiple gpt.js tags, on your page, ensure the network code is appended to each tag.

Note:It's important that MI children explicitly discuss with their MI parent(s) who is responsible for managing user messaging for their site(s), so that only one account publishes messages to the domain and manages all messaging.

Offerwall (Beta) publishers

This information only applies to publishers participating in the Offerwall Beta program . Please note the following:

Manage Account parents

Rewarded ads should work without any additional configuration. The MCM parent should publish the Offerwall through the child account and use the child's ad unit.
Third-party integration payments (for example, Supertab ) are not currently supported.

If a publisher using Offerwall with Supertab becomes a Manage Account child, payments will still go to the child, regardless of the parent/child agreement.

Manage Inventory parents

Rewarded ads should work without any additional configuration. The MCM parent should select one of their own ad units for rewarded serving, and publish the Offerwall to their child MCM sites.

Was this helpful?

How can we improve it?