Proposed by
...
...
Closing date
...
...
Status
...
| Status | ||||
|---|---|---|---|---|
|
...
Related Documents
/wiki/spaces/IN/pages/4152033328
Table of contents
| Table of Contents |
|---|
Summary of changes
Introducing:
an ERROR EVENT with the following properties:
Path
Error Code
Response Title
Response Description
in accordance with the new User Interface Event Catalogue and pass it to mParticle
and standardized ERROR KEYS passed on within the
propertyStatus colour Blue title error code create and maintain documentation on
providing a description mapping, explaining what the meaning of the error and what it is cause by.Status colour Blue title error codes
in order to provide our stakeholders with a deeper understanding of corresponding root causes as well as actionable steps to mitigate them.
- Supported by Walker-Sperber, Ian
- Supported by Pierzynski, Augusto
- Supported by Melo De Ornelas, Teodoro
- Supported by Carrington, Maria
- Supported by Rodrigues da Silva, Manuel
- Supported by Hainzenreder, Diego
- Reviewed by Fernandez Pranno, Marco Manuel
- Reviewed by Busana, Marcelo (Deactivated)
- Reviewed by Benet, Anton
- Reviewed by Lopes da Costa, Valentina
- Reviewed by Fisher, Luke
- Reviewed by Zaharia, Raluca (Deactivated)
- Reviewed by Yildirim, Semih
- Reviewed by Silva, Carlos
- Reviewed by Klein, Simon (Deactivated)
- Reviewed by Watanabe, Adolfo
Context
The way our platform issues are currently surfaced in Amplitude is by capturing error modal events. This solution itself is problematic by its nature as we tend to focus only on the modal appearance, lacking any insight into the actual root cause of the issue.
Those modals constitute a front-end representation of both: frontend and backend errors, that may be triggered by a variety of causes: misconfigurations, RBI’s implementation, partners' integration or user caused errors.
Therefore, unfortunately today there’s not a clear path to understand the origin of the fluctuations in error modals, which are currently an indication of issues and friction points that our users experience on our platform.
Problem Statement
Today there’s not an easy way to identify root cases of the error modal deviations visible in Amplitude, which are monitored by our Franchisees and internal stakeholders.
As an example we may take the Cart Error and Payment Error Modals investigated by the Fulfillment Team. The team gratuitously added useful insights into the Root Cause column per each modal type.
| Info |
|---|
Please note that this level of granularity is not meant to be exhaustive but will offer a more descriptive level understanding of where the problem originates from. Today, this information is not accessible in Amplitude. |
Example:
...
Cart Errors Modal
...
Title
...
Messages
...
Root Causes
...
Cart error: order could not be completed
...
Restaurant is Unavailable
...
Your order could not be completed
...
When a non-delivery order pricing fails (i.e PRICE_ERROR) or Cart item(s) become unavailable
| Status | ||||
|---|---|---|---|---|
|
Occurrences:* 1,640
...
We apologize for any inconvenience, but this restaurant had to be abruptly closed due to technical issues and is currently unavailable.
...
| Status | ||||
|---|---|---|---|---|
|
...
Please try again later + other server pricing error messages
...
When the message body translation is not found. (Both delivery & non delivery)
| Status | ||||
|---|---|---|---|---|
|
Occurrences:* 5
...
Oops. Looks like something went wrong.
...
We won’t be able to complete this transaction. Check with your card provider for details.
...
| Status | ||||
|---|---|---|---|---|
|
...
Sorry, your location can’t accept deliveries at this time.
...
We apologize for any inconvenience, but this restaurant had to be abruptly closed due to technical issues and is currently unavailable.
When a delivery order pricing fails (i.e PRICE_ERROR, QUOTE_ERROR, QUOTE_UNAVAILABLE) or Cart item(s) become unavailable
| Status | ||||
|---|---|---|---|---|
|
...
Source:
Intent
Therefore, we’d like to propose a protocol to pass on the first layer of granularity (as in the example above) to mParticle (ultimately for the use in Amplitude) to serve as an immediate insight into the causes of the deviations. Proposed error codes are not supposed to be exhaustive; a deeper level of granularity explaining the exact root cause of the issue should be surfaced internally via appropriate DataDog dashboards. Hence, the objective of this document is to receive an approval for creating error events enriched by error code property based on standardized alphanumeric and pass them to mParticle in order to be surfaced and used in Amplitude.
Proposal
General Process:
Introduce a new ERROR EVENT with the following properties:
Path
Error Code
Response Title
Response Description
in accordance with the new User Interface Event Catalogue and pass it to mParticle
Create a mapping of Errors Codes and pass it on within the Error Code property of the ERROR EVENT
Error codes must have alpha-numerical format for scalability and security reasons.
They must follow a pre-determined schema specific to an area within a platform such as Loyalty, Checkout etc. Examples:
”CHECKOUT.PRICE_ERROR”
“CO.PRICE_ERROR”
CO.123
61230 (“checkout errors are in format 6xxxx”)
Error keys will be passed in one property of ERROR CODE
it had been agreed that we may group by a domain using a the following function available in Amplitude “containing:XXX”
Create a documentation providing an explanation of each of the error keys, potential actionable steps and location of DD Dashboard for further granularity. The DD dashboards should remain for the internal use only and not disclosed to out clients.
| Info |
|---|
This step does not include DD dashboard adjustments or creation; it’ll be addressed as a separate step in the process. |
Example:
...
Path
...
Error code
...
Response Title
...
Response Description
...
Root Cause
...
Actionable steps
...
Further Granularity Dashboard (DD)
...
/cart
| Status | ||||
|---|---|---|---|---|
|
...
Please update your account phone number to continue
...
We are unable to confirm your phone number. Please confirm your phone number is correct or try a different one.
...
When delivery quote failed while selecting a delivery address with graphql error message ‘invalid phone number
...
User should verify their phone number
...
<placeholder>
Initial Phase Proposal:
As a Proof of Concept, we propose to start with cart and payment error modals.
| Info |
|---|
As a premise we need to make sure we don't unnecessarily distinguish/create multiple errors surfacing the same problem only because we have multiple modal types triggered by that same issue. |
Alternatives considered
Labeled Error code Mapping
The use of labeled error codes for example
| Status | ||||
|---|---|---|---|---|
|
Out of scope:
Improvement of the user messaging or inclusion of the error keys (potential separate initiative)
Next Steps
Propose an actual error keys table focused on cart & payment in a form of an RFC.
If X RFC is accepted test within cart & payments domain
If successful apply the process across the entire platform
Process on documentation maintenance should be further discussed and agreed on
Provide adequate granularity in the DD dashboard to assure a sufficient level of pragmatism. For example an internal stakeholder should be able to tell whether the issue had been caused by a partner, misconfiguration or an internal technical issue to be able to report the matter to an appropriate party
To provide a holistic picture; surface errors occurring on the FE that are currently not tracked in DD
Timing
RFC should be implemented as an initiative in Q3, 2024.
Next steps
...
Refer to /wiki/spaces/IN/pages/4550328658