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 ERROR CODE property

• create and maintain documentation on ERROR CODES providing a description mapping, explaining what the meaning of the error and what it is cause by.

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.

Example:

Source:

https://rbictg.atlassian.net/wiki/spaces/TRX/pages/4423811195/Understanding+Cart+and+Payment+Errors#Errors-modal-table

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:

1. 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

2. Create a mapping of Errors Codes and pass it on within the Error Code property of the ERROR EVENT

   1. Error codes must have alpha-numerical format for scalability and security reasons.

   2. 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”)

   3. Error keys will be passed in one property of ERROR CODE

      1. it had been agreed that we may group by a domain using a the following function available in Amplitude “containing:XXX”

3. 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.

Example:

Initial Phase Proposal:

As a Proof of Concept, we propose to start with cart and payment error modals.

Alternatives considered

Labeled Error code Mapping

The use of labeled error codes for example PRICE_ERROR was rejected due to security and inhibited scalability cross-platform.

Out of scope:

• Improvement of the user messaging or inclusion of the error keys (potential separate initiative)

Next Steps

1. Propose an actual error keys table focused on cart & payment in a form of an RFC.

2. If X RFC is accepted test within cart & payments domain

3. If successful apply the process across the entire platform

4. Process on documentation maintenance should be further discussed and agreed on

5. 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

6. 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