Intent to implement: Client identifiers in AMP

[cramforce]

The following doc proposes a concrete mechanism for producing "client identifiers" for AMP documents which can be used by AMP Analytics (See #871) for use cases such as distinguishing users.

The proposed mechanism provides a unified solution for the following 3 scenarios:

1. document loaded from publisher page
2. document loaded from AMP cache
3. document loaded through AMP viewer

It does not, however, treat users that are active across these as the same.

For details see
https://docs.google.com/document/d/1f7z3X2GM_ASb3ZCI_7tngglxwS6WoWi1EB3aKzdf6vo/edit

[cramforce]

Implemented all except bullet 3.

[bmuller]

The Google doc says:

This document deals with the question how advanced analytics can be supported inside of AMP files and in particular how a notion of a user or a session can be established.

What follows, however, doesn't include any discussion of "sessions" (nor could I find any other mention of "sessions" in any of the docs). Are sessions something the publishers/analytics providers will need to infer based on timestamps, or are there plans to support a session identifier as well?

[rudygalfi]

@bmuller The way I've usually seen sessions defined is by looking at timestamps and choosing some period of time to elapse before a new session is established.

Do you have some specific definition or instrumentation you're interested in to either directly define a session or to be able to do so on the data processing side?

[bmuller]

@rudygalfi it would be useful if there was some way to get an identifier for the client session (for instance, browser session based on a session cookie, or some concept of app session if in a viewer).

[cramforce]

There is a related bug on low entropy page view ids. This together with a
client id and engagement instrumentation should be sufficient to compute
most concepts of sessions. AMP itself doesn't have an opinion about that,
but analytics providers and other users might, so details are delegated to
that layer.
On Nov 22, 2015 1:37 PM, "Brian Muller" notifications@github.com wrote:

@rudygalfi https://github.com/rudygalfi it would be useful if there was
some way to get an identifier for the client session (for instance, browser
session based on a session cookie, or some concept of app session if in a
viewer).

—
Reply to this email directly or view it on GitHub
#961 (comment).

[bmuller]

@cramforce What would be nice is an understanding of session based on the context of the app displaying the AMP content. Simply using time between interactions is a poor way to understand a user's activities when the underlying application knows about it's own use (so why not expose that?). Delegating to the "analytics provider" layer means a less accurate understanding than is possible to provide. Session information is something we get on the web (with session cookies), and it would be nice to get that for AMP pages as well.

[cramforce]

Did you check out the page view id? Sorry, on phone. Don't have a link
handy. I think this will be trivial to implement on the analytics side
without hard coding anything on the framework side.
On Nov 23, 2015 12:49 PM, "Brian Muller" notifications@github.com wrote:

@cramforce https://github.com/cramforce What would be nice is an
understanding of session based on the context of the app displaying the AMP
content. Simply using time between interactions is a poor way to understand
a user's activities when the underlying application knows about it's own
use (so why not expose that?). Delegating to the "analytics provider" layer
means a less accurate understanding than is possible to provide. Session
information is something we get on the web (with session cookies), and it
would be nice to get that for AMP pages as well.

—
Reply to this email directly or view it on GitHub
#961 (comment).

[rudygalfi]

@cramforce is indicating #969

[bmuller]

Thanks @cramforce / @rudygalfi - but (as far as I can tell) I don't think a page view id would help in understanding what constitutes a session. I think there's a misunderstanding of what I'm asking for so here's an example:

On the web, when a user opens their browser and clicks a link to one of our sites, a session cookie is set (which goes away when the browser is closed). If the user comes back later for a second view in the same browser session (i.e., the browser has stayed open between views), we know that the browser has been continuously open for both the initial view and the second view based on the value of that cookie. These two views could occur seconds or hours apart - so merely looking at time doesn't help - but the presence and value of the session cookie can tell us that it was the same browser session.

We'd like the same thing for AMP pages (but instead of just the case of a browser, we could be talking about a mobile app that is capable of displaying AMP pages, etc). We'd like to know if two views occur in the same app session (where, say, backgrounding the app would count as a new session, for instance). This isn't something that can be determined based solely on time (again, the views could occur minutes or hours apart) and it's not something (as far as I can tell) that we could glean from page view ids.

I hope this is more clear - please let me know if there's anything else I can provide to help.

[cramforce]

We could in theory provide a low entropy id with the lifetime of a session
cookie. Please file a separate issue and make an extensive case for it
including laying out alternatives. We currently set 0 cookies. Adding one
will need to have a very good case.
On Nov 24, 2015 10:36 AM, "Brian Muller" notifications@github.com wrote:

Thanks @cramforce https://github.com/cramforce / @rudygalfi
https://github.com/rudygalfi - but (as far as I can tell) I don't think
a page view id would help in understanding what constitutes a session. I
think there's a misunderstanding of what I'm asking for so here's an
example:

On the web, when a user opens their browser and clicks a link to one of
our sites, a session cookie is set (which goes away when the browser is
closed). If the user comes back later for a second view in the same browser
session (i.e., the browser has stayed open between views), we know that the
browser has been continuously open for both the initial view and the second
view based on the value of that cookie. These two views could occur seconds
or hours apart - so merely looking at time doesn't help - but the presence
and value of the session cookie can tell us that it was the same browser
session.

We'd like the same thing for AMP pages (but instead of just the case of a
browser, we could be talking about a mobile app that is capable of
displaying AMP pages, etc). We'd like to know if two views occur in the
same app session (where, say, backgrounding the app would count as a new
session, for instance). This isn't something that can be determined based
solely on time (again, the views could occur minutes or hours apart) and
it's not something (as far as I can tell) that we could glean from page
view ids.

I hope this is more clear - please let me know if there's anything else I
can provide to help.

—
Reply to this email directly or view it on GitHub
#961 (comment).

[dvoytenko]

I don't think session cookies would work very well in the webview case. I think we still need to consider doing this via local storage, but perhaps enable viewer to consult us on what is the session.

[cramforce]

The concept asked for here is not known by the viewer. Still like to
understand what is interesting about session cookies. Browser lifetimes can
be months. They provide very little semantics.
On Nov 24, 2015 12:01 PM, "Dima Voytenko" notifications@github.com wrote:

I don't think session cookies would work very well in the webview case. I
think we still need to consider doing this via local storage, but perhaps
enable viewer to consult us on what is the session.

—
Reply to this email directly or view it on GitHub
#961 (comment).

[rudygalfi]

Is there anything else that needs to be resolved from this or can it be closed?

[cramforce]

We need to finish a few optional user-notification connections. CC @erwinmombay

[wupengFEX]

@cramforce , I have two questions to ask:

1. Under server type, how to ensure the unique of client identify. if local storage, when clear it, how to match the client identify with publisher's database?
2. For paid pages,Whether to consider strong login or not. if clear local storage, other paid pages can be read,I think this is not a reasonable design!

[cramforce]

@wupengFEX When a user is logged in, you never need to use the client id (can always just use a cookie). If a user deletes localStorage, there won't be a way to match it back. That is working as intended, as the user chose to delete it.

[wupengFEX]

@cramforce Thanks very much for your reply, i know login state, But If amp can't match it back, then it can't associate the old records to the new value, How to inform the publisher to delete the data which marked with previous clientId in the database, such as pingback data.