AMP's client ID currently has these behaviors:

• On the publisher origin, the "scope" parameter is used as a cookie name stored on the client.
• On an AMP cache, the "scope" is used as part of a hash to compute a client ID based on a single stored value.
• In an AMP viewer, the "scope" is used as part of a hash to compute a client ID based on a single stored value.

This issue proposes to enable specifications of 2 (or possibly 3) scopes. In the case where 2 scopes are supported, one scope would be for the origin case (i.e. the cookie name) and the other would be for the cache/viewer cases. In the 3 scope case, then we'd support differentiated scopes across all 3 scenarios listed above.

Proposed markup is a substitution function such as:

CLIENT_ID(CONTEXT_SCOPE('origin-cookie','off-origin-scope-name'),'amp-user-notification-name')

Design discussion:

• 2 scopes or 3? There doesn't seem to be long-term value in differentiating the viewer and cache cases, so I propose 2, as illustrated in the above example.
• Name. Above CONTEXT_SCOPE is proposed. What should we call the function?

Note: amp-user-notification element ID is an optional 2nd parameter to CLIENT_ID. Thus, we use a nested function syntax to achieve this.