I2I: Error trigger in amp-analytics #6415

Closed
lannka opened this Issue Nov 30, 2016 · 12 comments

Comments

@lannka
Collaborator

lannka commented Nov 30, 2016

This is for publisher to report client errors (maybe limited for user() error) to a specified analytics platform or their own server, so that they can get their problem noticed and fixed.

Google Webmaster can potentially be one of the pre-configured destinations.

Syntax
Pub configs custom event and error trigger just like other triggers:

<amp-analytics>
<script type="application/json">
{
  "requests": {
    "error": "https://example.com/report-error?name=${errorName}&message=${errorMessage}"
  },
  "triggers": {
    "Error" {
      "on": "error", // new proposed trigger type
      "request": "error",
    }
  }
}
</script>
</amp-analytics>

Example change in error logger
All client errors will be piped to specified destinations like this:

// in user() logger impl:
...
errorTrackersFor(doc).then(trackers => {
  trackers.forEach(tracker => {
     tracker.trackError(tag, message);
  });
});
...

@dvoytenko @avimehta @ericlindley-g @rudygalfi

@dvoytenko

This comment has been minimized.

Show comment
Hide comment
@dvoytenko

dvoytenko Dec 1, 2016

Collaborator

SGTM. Couple of notes:

  1. It should definitely be only user errors.
  2. We can start with GA error protocol and configure it for correct error reporting. That will help us validate this approach.
  3. Not sure about special services for tracking. Generally, that sounds like a good idea, however, we currently don't have ampdoc in any of those API and thus it'd be a challenge to refactor. Ideas welcome. But we could also start with the single-doc environment for POC and go from there.
Collaborator

dvoytenko commented Dec 1, 2016

SGTM. Couple of notes:

  1. It should definitely be only user errors.
  2. We can start with GA error protocol and configure it for correct error reporting. That will help us validate this approach.
  3. Not sure about special services for tracking. Generally, that sounds like a good idea, however, we currently don't have ampdoc in any of those API and thus it'd be a challenge to refactor. Ideas welcome. But we could also start with the single-doc environment for POC and go from there.
@ericlindley-g

This comment has been minimized.

Show comment
Hide comment
@ericlindley-g

ericlindley-g Dec 11, 2016

Collaborator

SGTM too — @rudygalfi , do you have any thoughts from an Analytics perspective? One question I had is if enough = providers have the tools to receive errors and surface meaningful reports to users. Seems like GA has this covered, but I'm not sure what the coverage looks like across other analytics providers. ( @lannka, you may already know the answer to this ?)

Context: This project is part of the effort to make sure publishers have the tools to ensure high-quality content on their AMPs.

Collaborator

ericlindley-g commented Dec 11, 2016

SGTM too — @rudygalfi , do you have any thoughts from an Analytics perspective? One question I had is if enough = providers have the tools to receive errors and surface meaningful reports to users. Seems like GA has this covered, but I'm not sure what the coverage looks like across other analytics providers. ( @lannka, you may already know the answer to this ?)

Context: This project is part of the effort to make sure publishers have the tools to ensure high-quality content on their AMPs.

@lannka

This comment has been minimized.

Show comment
Hide comment
@lannka

lannka Dec 12, 2016

Collaborator

Crash reports are available in most analytics platforms for native apps. I'm not sure about mobile web though.

But in anyway, publisher can still create custom events to track errors.

Collaborator

lannka commented Dec 12, 2016

Crash reports are available in most analytics platforms for native apps. I'm not sure about mobile web though.

But in anyway, publisher can still create custom events to track errors.

@adelinamart

This comment has been minimized.

Show comment
Hide comment
@adelinamart

adelinamart Feb 6, 2017

Collaborator

@ericlindley-g is this something it was prioritized for this year? or still at discussion level? Thanks.

Collaborator

adelinamart commented Feb 6, 2017

@ericlindley-g is this something it was prioritized for this year? or still at discussion level? Thanks.

@lannka

This comment has been minimized.

Show comment
Hide comment
@lannka

lannka Feb 6, 2017

Collaborator
Collaborator

lannka commented Feb 6, 2017

@adelinamart adelinamart modified the milestones: Prioritized FRs, New FRs Feb 6, 2017

@muxin muxin assigned muxin and unassigned ericlindley-g Feb 6, 2017

@rudygalfi rudygalfi added this to Sprint Candidate in Analytics Feb 8, 2017

@rudygalfi rudygalfi added the P2: Soon label Feb 8, 2017

@rudygalfi rudygalfi moved this from Sprint Candidate to Backlog in Analytics Feb 13, 2017

@lannka lannka moved this from Backlog to Sprint Candidate in Analytics Feb 24, 2017

@rudygalfi rudygalfi moved this from Sprint Candidate to Backlog in Analytics Feb 27, 2017

@rudygalfi rudygalfi moved this from Feature Backlog to Sprint Candidate in Analytics Jun 29, 2017

@lannka lannka assigned tiendt and unassigned muxin Jun 29, 2017

@rudygalfi rudygalfi moved this from Sprint Candidate to On Deck for Next Sprint in Analytics Jul 14, 2017

@lannka lannka moved this from On Deck for Next Sprint to In Progress This Sprint in Analytics Jul 28, 2017

@grantkemp

This comment has been minimized.

Show comment
Hide comment
@grantkemp

grantkemp Jul 31, 2017

As an idea - could this trigger for Amp validation errors as well? Then we can allow AMP to be self alerting and potentially self repairing. This can operate similarly to how tag manager works with Javascript error observing.

As an idea - could this trigger for Amp validation errors as well? Then we can allow AMP to be self alerting and potentially self repairing. This can operate similarly to how tag manager works with Javascript error observing.

@lannka

This comment has been minimized.

Show comment
Hide comment
Collaborator

lannka commented Jul 31, 2017

@grantkemp

This comment has been minimized.

Show comment
Hide comment
@grantkemp

grantkemp Jul 31, 2017

Hiya @lannka
nope, I am looking for the ability to push these errors into Analytics as events as we get the benefit of the following:
( Here is an example based on the AMP error logging - that is out of the box in GTM)

  • Pretty immediate notification of errors ( assuming user has alerting on their GA/ other logging tool)
  • Ability to track historically number of errors as a metric - and show improvement.
  • Ability to allow our developer team to self serve what pages are generating errors without needing to add any extra interfaces, marketing team member time, or systems. ( similar to how we diagnose JS errors via GTM/ GA)
  • no need to grant more access to Search Console. ( and teach people the interface)

Example from JS Tracking
image

Alternative Approach ( but less desirable )
Potentially surface AMP errors in Data Studio - but then we lose the alerting feature.
image

grantkemp commented Jul 31, 2017

Hiya @lannka
nope, I am looking for the ability to push these errors into Analytics as events as we get the benefit of the following:
( Here is an example based on the AMP error logging - that is out of the box in GTM)

  • Pretty immediate notification of errors ( assuming user has alerting on their GA/ other logging tool)
  • Ability to track historically number of errors as a metric - and show improvement.
  • Ability to allow our developer team to self serve what pages are generating errors without needing to add any extra interfaces, marketing team member time, or systems. ( similar to how we diagnose JS errors via GTM/ GA)
  • no need to grant more access to Search Console. ( and teach people the interface)

Example from JS Tracking
image

Alternative Approach ( but less desirable )
Potentially surface AMP errors in Data Studio - but then we lose the alerting feature.
image

@lannka

This comment has been minimized.

Show comment
Hide comment
@lannka

lannka Aug 11, 2017

Collaborator

@grantkemp AMP validation is happened at page indexing time, so it's not a client runtime error. We have no way to send those errors to Google Analytics.

Collaborator

lannka commented Aug 11, 2017

@grantkemp AMP validation is happened at page indexing time, so it's not a client runtime error. We have no way to send those errors to Google Analytics.

@lannka

This comment has been minimized.

Show comment
Hide comment
@lannka

lannka Aug 11, 2017

Collaborator

This work is fully broken down to sub tasks for better tracking. Closing this now.

Collaborator

lannka commented Aug 11, 2017

This work is fully broken down to sub tasks for better tracking. Closing this now.

@ericlindley-g

This comment has been minimized.

Show comment
Hide comment
@ericlindley-g

ericlindley-g Oct 26, 2017

Collaborator

@lannka, is the first iteration of the feature launched, or is it still pending completion of some of the sub-tasks?

Collaborator

ericlindley-g commented Oct 26, 2017

@lannka, is the first iteration of the feature launched, or is it still pending completion of some of the sub-tasks?

@rudygalfi

This comment has been minimized.

Show comment
Hide comment
@rudygalfi

rudygalfi Oct 26, 2017

Contributor

I think #10891 is still pending, but the feature is usable. The documentation calls out a known issue. @zhouyx Can you confirm?

Contributor

rudygalfi commented Oct 26, 2017

I think #10891 is still pending, but the feature is usable. The documentation calls out a known issue. @zhouyx Can you confirm?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment