PMP page is missing five attributes, the third-party cookie behaviour and the sharing flow

[jwrosewell]

The PMP page documents eight configuration attributes. The platform served from https://cloud.51degrees.com/api/v4/pmp reads thirteen. The five that are missing are the ones that turn on cross-site sharing, which is the behaviour a publisher is most likely to want and least likely to guess at.

Page: https://51degrees.com/documentation/4.5/_identifiers__p_m_p.html
Source: src/identifiers/pmp.md

How this was checked

The live platform bundle was fetched from https://cloud.51degrees.com/api/v4/pmp?resource=<a paid key> on 8 September 2026 (70,779 bytes) and every data- attribute in it was compared against the table in src/identifiers/pmp.md lines 37 to 44. Configuration attributes were separated from internal DOM markers by looking at how each is read: configuration is read off the script tag through the getValue accessors on the settings class, whereas data-card, data-section and data-action are markup hooks inside the rendered dialog and are correctly absent from the documentation.

Missing from the table

Attribute	Required	Default	What it does
data-network-name	No, but see below	none	Name of the group the visitor's choice would be shared with, shown to them in the sharing question, for example "Axel Springer".
data-network-logo	No	none	URL of the network's logo, shown alongside the network name.
data-use-third-party-cookies	No	on	Set to "false" to keep the choice to this site. Any other value, including the attribute being absent, leaves it on.
data-brand-icon	No	none	URL of the icon used on the floating button that reopens the notice. Distinct from data-brand-logo, which is the dialog header.
data-timeout	No	1500	Milliseconds allowed for the third-party cookie probe. Must be a positive whole number. Values above 4500 are capped at 4500, and a warning is logged in both cases.

The third-party cookie behaviour needs describing, not just listing

This is the part that would cost a publisher the most time, because the default is on but doing nothing has no effect.

Third-party cookies are enabled unless data-use-third-party-cookies is exactly "false". They only actually engage when data-network-name is also set. With the attribute absent and no network name the platform logs this and carries on with the choice kept to the one site:

Sharing a choice across sites needs 'data-network-name', the name of the group the visitor would be sharing it with, for example 'Axel Springer'. None was given, so the choice stays with this site. Add the attribute, or set 'data-use-third-party-cookies' to 'false' to ask for that on purpose.

So a publisher who reads the current page, deploys the eight documented attributes and expects the documented behaviour gets the single-site flow, which is correct, but has no way to discover from the documentation that a second flow exists.

The sharing flow is undocumented

When sharing is in play the visitor is asked a second question on its own card, after the preference question. The strings in the bundle are:

• "Checking whether this choice can be shared" while the probe runs
• "You can apply this choice to the other [networkName] websites, so you are not asked again on each one. You can change it later from any of them."
• buttons "All [networkName] sites" and "Only this site"

Section 60 of the page describes the numbered flow through to data-action-url and does not mention this step at all.

What would help

1. Add the five attributes to the table.
2. A section on third-party cookies covering: the default being on, the dependency on data-network-name, what the probe is doing and what data-timeout bounds, and what the visitor is actually asked.
3. Set out the distinct flows rather than one numbered list, because they differ in what the visitor sees and in what is stored:
   • third-party cookies unavailable or turned off, or no network name given
   • available, sharing offered, visitor accepts
   • available, sharing offered, visitor declines
   • a return visit in each of those cases, where the current page says steps 2 and 3 are skipped
4. State plainly what is stored and where in each case. The page currently documents the localStorage key for the single-site case, and the shared case needs the same treatment.

Note

The attribute names, defaults, limits and quoted strings are read from the served bundle rather than from memory, but the wording of any new documentation and the description of intended behaviour need a human review, particularly from whoever owns the PMP in the cloud repository, since the code is the only source consulted here and it may not reflect what the behaviour is meant to be.