Add UMA metric for "View Original" link clicks in distilled page viewer.

Add UMA metric for "View Original" link clicks in distilled page viewer.

Committed: https://crrev.com/8250a63d859fb8f4395be9452e691be7756569cf
Cr-Commit-Position: refs/heads/master@{#294089}

[Yaron, 2014-08-22 23:45:43]

Since we don't have bindings (and don't want them), it seems the simplest way is
to use the image trick to send a beacon back to chrome to record a metric.

[nyquist, 2014-08-25 01:13:03]

lgtm

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
File components/dom_distiller/content/dom_distiller_viewer_source.cc (right):

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/dom_distiller_viewer_source.cc:290:
content::RecordAction(base::UserMetricsAction("DomDistiller_ViewOriginal"));
Would this ever be needed on iOS? I.e., should it live in viewer.[cc|h]?
I'm guessing it's easier to just copy-paste this string if that's the case?

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
File components/dom_distiller/content/resources/dom_distiller_viewer.js (right):

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/resources/dom_distiller_viewer.js:72: img.src =
"/vieworiginal";
Would this ever show up as an ugly visual artifact for the user?

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/resources/dom_distiller_viewer.js:73:
document.body.appendChild(img);
Since the click will navigate away, could there be any timing-related issue
here, in which we would miss this beacon?

[Yaron, 2014-08-25 19:41:23]

thanks.
+jwd for metrics OWNERS

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
File components/dom_distiller/content/dom_distiller_viewer_source.cc (right):

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/dom_distiller_viewer_source.cc:290:
content::RecordAction(base::UserMetricsAction("DomDistiller_ViewOriginal"));
On 2014/08/25 01:13:03, nyquist wrote:
> Would this ever be needed on iOS? I.e., should it live in viewer.[cc|h]?
> I'm guessing it's easier to just copy-paste this string if that's the case?

I think this is simple enough to leave.

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
File components/dom_distiller/content/resources/dom_distiller_viewer.js (right):

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/resources/dom_distiller_viewer.js:72: img.src =
"/vieworiginal";
On 2014/08/25 01:13:03, nyquist wrote:
> Would this ever show up as an ugly visual artifact for the user?

Hmm. I suppose it's possible. Added display:none.

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/resources/dom_distiller_viewer.js:73:
document.body.appendChild(img);
On 2014/08/25 01:13:03, nyquist wrote:
> Since the click will navigate away, could there be any timing-related issue
> here, in which we would miss this beacon?

I don't think so. Remember that the backend is always running in chrome, it's
not tied to the webpage itself being live. Adding the element to the dom should
kick off the "network" request at that moment and we'll handle it.

[nyquist, 2014-08-25 20:09:19]

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
File components/dom_distiller/content/resources/dom_distiller_viewer.js (right):

https://codereview.chromium.org/502653002/diff/1/components/dom_distiller/con...
components/dom_distiller/content/resources/dom_distiller_viewer.js:73:
document.body.appendChild(img);
On 2014/08/25 19:41:23, Yaron wrote:
> On 2014/08/25 01:13:03, nyquist wrote:
> > Since the click will navigate away, could there be any timing-related issue
> > here, in which we would miss this beacon?
> 
> I don't think so. Remember that the backend is always running in chrome, it's
> not tied to the webpage itself being live. Adding the element to the dom
should
> kick off the "network" request at that moment and we'll handle it.

Right, I think I was just concerned that the network stack would cancel
outstanding requests when you navigated away from the current page. If that is
the case, and the request for /vieworiginal hasn't hit the backend yet, we would
miss it.

But anyway, sounds good to me.

[jwd, 2014-08-26 15:51:47]

jwd@chromium.org changed reviewers:
+ isherman@chromium.org

[jwd, 2014-08-26 15:51:48]

+Ilya, who you'll need for review anyways.

Similar comment to what Ilya said on the other CL, maybe you'd be better served
by a histogram that tracks the number of times this link was shown with the
number of times it was clicked.

[Yaron, 2014-08-26 17:03:45]

On 2014/08/26 15:51:48, Jesse Doherty wrote:
> +Ilya, who you'll need for review anyways.
> 
> Similar comment to what Ilya said on the other CL, maybe you'd be better
served
> by a histogram that tracks the number of times this link was shown with the
> number of times it was clicked.

The link will always be shown on the distilled page. We anticipate low usage but
it's an indicator of usage and whether we believe the user was satisfied. I
would expect to use invocations of the menu item/button (user actions to get to
this page) as a baseline for comparison. I think this one is fine as is because
it's actually non-trivial to compute non-invocations (i.e. all navigations, tab
closes, back button etc which aren't clicking this link)

[jwd, 2014-08-26 19:01:42]

On 2014/08/26 17:03:45, Yaron wrote:
> On 2014/08/26 15:51:48, Jesse Doherty wrote:
> > +Ilya, who you'll need for review anyways.
> > 
> > Similar comment to what Ilya said on the other CL, maybe you'd be better
> served
> > by a histogram that tracks the number of times this link was shown with the
> > number of times it was clicked.
> 
> The link will always be shown on the distilled page. We anticipate low usage
but
> it's an indicator of usage and whether we believe the user was satisfied. I
> would expect to use invocations of the menu item/button (user actions to get
to
> this page) as a baseline for comparison. I think this one is fine as is
because
> it's actually non-trivial to compute non-invocations (i.e. all navigations,
tab
> closes, back button etc which aren't clicking this link)

I was thinking of having a histogram that recorded when a distilled page was
shown and when the link was clicked.

So the distilled page is viewed based on a user action (this menu item/button
you refer to)? 

I do think you will find it a bit cumbersome to rely on two different counts
when doing your analysis.

[Yaron, 2014-08-27 20:59:09]

On 2014/08/26 19:01:42, Jesse Doherty wrote:
> On 2014/08/26 17:03:45, Yaron wrote:
> > On 2014/08/26 15:51:48, Jesse Doherty wrote:
> > > +Ilya, who you'll need for review anyways.
> > > 
> > > Similar comment to what Ilya said on the other CL, maybe you'd be better
> > served
> > > by a histogram that tracks the number of times this link was shown with
the
> > > number of times it was clicked.
> > 
> > The link will always be shown on the distilled page. We anticipate low usage
> but
> > it's an indicator of usage and whether we believe the user was satisfied. I
> > would expect to use invocations of the menu item/button (user actions to get
> to
> > this page) as a baseline for comparison. I think this one is fine as is
> because
> > it's actually non-trivial to compute non-invocations (i.e. all navigations,
> tab
> > closes, back button etc which aren't clicking this link)
> 
> I was thinking of having a histogram that recorded when a distilled page was
> shown and when the link was clicked.

Can you elaborate? So when a distilled page is shown, trigger one bucket. When
the link is clicked record another bucket? I have a hard time groking how that
helps because you have the same user session potentially in multiple buckets
which seems confusing to represent as a histogram.
> 
> So the distilled page is viewed based on a user action (this menu item/button
> you refer to)? 

Yes
> 
> I do think you will find it a bit cumbersome to rely on two different counts
> when doing your analysis.

I know the dremel incantation to split a metric by field trial so I'm not too
worried about it. I think looking at view original counts / distilled page
counts is fairly straightforward.

If I'm missing something, please let me know. It's just not clear (yet) to me
why it'd be better.

[Ilya Sherman, 2014-08-27 22:02:03]

The advantage of using an enumerated histogram is that it allows you to
conveniently see all of the related events in a single place.  I'll send you a
link to an example, offline.

However, if you prefer using user actions and Dremel, that's fine too.  LGTM if
you prefer that approach.

[jwd, 2014-08-28 21:10:50]

lgtm

[Yaron, 2014-09-10 02:09:45]

The CQ bit was checked by yfriedman@chromium.org

[commit-bot: I haz the power, 2014-09-10 02:21:20]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/yfriedman@chromium.org/502653002/40001

[commit-bot: I haz the power, 2014-09-10 03:25:49]

Committed patchset #3 (id:40001) as ac6f7d8e541def08d133e77ad22b8a9509d61fd5

[commit-bot: I haz the power, 2014-09-10 03:58:42]

Patchset 3 (id:??) landed as
https://crrev.com/8250a63d859fb8f4395be9452e691be7756569cf
Cr-Commit-Position: refs/heads/master@{#294089}