Access service issues events for major states in the access flow. These events can be reported through the analytics configuration by using triggers.
See amp-analytics.md for details on amp-analytics configuration.
The access-authorization-received
event is issued when the Authorization endpoint has succeeded. Use these configurations to fire a request for this event.
"triggers": {
"accessAuthorizationReceived": {
"on": "access-authorization-received",
"request": "event"
}
}
The access-authorization-failed
event is issued when the Authorization endpoint has failed. Use these configurations to fire a request for this event.
"triggers": {
"accessAuthorizationFailed": {
"on": "access-authorization-failed",
"request": "event"
}
}
The access-viewed
event is issued when the access system considers the page viewed and right before pingback is sent. Use these configurations to fire a request for this event.
"triggers": {
"accessViewed": {
"on": "access-viewed",
"request": "event"
}
}
The access-pingback-sent
event is issued when the Pingback endpoint has succeeded. Use these configurations to fire a request for this event.
"triggers": {
"accessPingbackSent": {
"on": "access-pingback-sent",
"request": "event"
}
}
The access-pingback-failed
event is issued when the Pingback endpoint has failed. Use these configurations to fire a request for this event.
"triggers": {
"accessPingbackFailed": {
"on": "access-pingback-failed",
"request": "event"
}
}
The access-login[-type]-started
event is issued right before the Login dialog has been opened. Use these configurations to fire a request for this event.
When only one Login URL is configured, the event is access-login-started
. When multiple Login URLs are configured, the event is access-login-type-started
, e.g. "access-login-signup-started".
"triggers": {
"accessLoginStarted": {
"on": "access-login-started",
"request": "event"
}
}
The access-login[-type]-success
event is issued when Login dialog has succeeded. Use these configurations to fire a request for this event.
When only one Login URL is configured, the event is access-login-success
. When multiple Login URLs are configured, the event is access-login-type-success
, e.g. "access-login-signup-success".
"triggers": {
"accessLoginSuccess": {
"on": "access-login-success",
"request": "event"
}
}
The access-login[-type]-rejected
event is issued when Login dialog has been rejected by the user. Use these configurations to fire a request for this event.
When only one Login URL is configured, the event is access-login-rejected
. When multiple Login URLs are configured, the event is access-login-type-rejected
, e.g. "access-login-signup-rejected".
"triggers": {
"accessLoginRejected": {
"on": "access-login-rejected",
"request": "event"
}
}
The access-login[-type]-failed
event is issued when Login dialog has failed due to an unknown reason. Use these configurations to fire a request for this event.
When only one Login URL is configured, the event is access-login[-type]-failed
. When multiple Login URLs are configured, the event is access-login-type-failed
, e.g. "access-login-signup-failed".
"triggers": {
"accessLoginFailed": {
"on": "access-login-failed",
"request": "event"
}
}
Access contributes the following URL substitutions to the amp-var-substitutions.md.
The ACCESS_READER_ID
variable is substituted with the Reader ID used for access operations. This is a sensitive ID and care should be taken in sharing it. Please ensure that any data you pass to a third party complies with its terms of service.
The AUTHDATA(field)
variable is substituted with the value of the field in the authorization response. The nested fields are allowed, such as AUTHDATA(nested.field)
.
This variable will wait until authorization is complete before being available.
Data contained in AUTHDATA
may be sensitive and care should be taken in sharing it. Please ensure that any data you pass to a third party complies with its terms of service.