RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
Summary of Project:
Today, it takes about 3-4 hours for us to share evaluation (app trial) data with Atlassian Marketplace Partners. We have heard and understand this data is critical to partners for multiple reasons, including creating a smooth user onboarding experience. To address this issue, we plan to provide evaluation data in near real-time to the partners.
- Publish : 17 August 2023
- Discuss until: 4 September 2023
- Resolve by: 18 September 2023
Context
Atlassian’s Marketplace provides partners with reporting data which they use for running and scaling their business. This data includes details of the evaluations being done on their apps. As told by our partners, one of the use cases of this evaluation data is to provide onboarding details and run drip campaigns for their app to the customers evaluating it. Some of our partners also integrate this data with CRM systems to not only make faster decisions about their business but also provide a customised experience to their customers.
Problem
Providing data for evaluations takes about 3-4 hours to process and share the data with our partners. This is because we combine data from different internal sources that are processed at different rates (some slower than others causing latencies). Ultimately, this delay prevents partners from engaging with the customers in a timely manner after the license is created.
In addition to that, we are using a flat data structure. This implies that if the data in any field undergoes changes, we need to modify the data of all licenses showing that field. What this means is that the next time partners try to retrieve license data, they will be retrieving all the historical data that got modified because of that field. However, an update in some of the fields can act as noise and does not necessarily mean that the partners need to take any action. This task can consume a lot of time and can be a futile effort for our partners.
With our current way of exposing data, it is not possible for us to solve the above problems, particularly with near real-time data.
Impact of the problem on our partners
As a result of the delay in obtaining the data, partners have missed a few opportunities. One particular opportunity is to offer a seamless onboarding experience for their apps. The initial interaction with users can directly impact revenue by ensuring engagement, increasing awareness about the apps for customers, and thereby improving chances of conversion. Therefore, it is essential to engage and educate users while reducing the time required to deliver value to customers.
As quoted by one of our partners, a customer may install the app on a Friday at 2 p.m. and, because of the current delay in partners receiving the data, the customer might not receive the onboarding emails until Monday of the following week. In some cases, this is resulting in customers installing and then uninstalling the app due to not having the correct onboarding information.
Our objective is to increase the speed at which Partners receive evaluation data, which can help them reduce the time to first contact with customers who start a trial of their app. This has the potential to improve customer satisfaction and increase trial conversion rates. Additionally, we aim to enhance the way we distribute data and provide our partners with more flexibility in accessing the data.
Proposed Solution
Partners will be able to access evaluation data with improved latency (we are targeting a delay of less than 10 minutes compared to the current 3-4 hour timeframe).
The approach we are taking for this is to move to expose licenses as separate data entities. Data entities are defined as fundamental building blocks. In this context, we have Entitlement, Subscription, Contact and other entities.
Data will be exposed to the partners directly after a few minutes of the license being created. Partners can query and combine the data for these entities, based on their use case, via a graphQL API.
Please note - The images within the table below are presented separately due to technical constraints. Clicking on each image will open some parts of the table individually.
Disclaimer: The data entities and the fields associated with them are tentative and subject to changes. It does not represent the final version and is provided for illustrative purposes only.
To help you understand how our proposed solution will work, we have recorded a working demo for our partners.
Potential Impact of the Proposed Changes
Improved latency - The evaluation data will now be provided with improved latency, allowing partners to start their onboarding activities within 10 minutes of a customer beginning an evaluation. This is about a 95% reduction in the current delay. This improvement will provide an opportunity to educate and convert customers who may otherwise uninstall the app due to delays in obtaining onboarding details or other important information.
Improved data retrieval flexibility - Instead of utilizing an API to obtain all license fields which may not be necessary, partners now have the flexibility to retrieve data based on their specific requirements. Partners can choose to combine data from various entities to obtain only desirable data that would be most advantageous to them.
Moving to graphQL - In order to make data retrieval easier using entities, we will start exposing graphQL API. This is a change from the current way of reporting data via REST endpoints. We are moving towards graphQL because of the increased flexibility it can provide for retrieving data. Using GraphQL, partners can retrieve only the fields they need. It is possible to introduce new entities without any disruption. Partners can choose to use the entities at their own pace without their existing queries failing due to the introduction of new entities.
Once we release this functionality, partners will be provided with adequate documentation on all the entities, their significance, the fields that are a part of each entity, the relationships between the different entities which can be used to stitch them together and examples.
Future Iteration
For now, we plan to start with exposing APIs. In the future, in addition to APIs, we plan on introducing a push-based model so that the partners can receive the updates seamlessly.
Additionally, we will also be exploring how we can improve the quality of the data we provide to the partners.
Asks
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:
- What do you think about using separated data entities to retrieve the desired data? We want to consider if partners find this kind of architecture flexible and useful
- Although the data entities provided above are not finalised, do you feel these data entities and the fields associated with them are sufficient for your reporting and campaign use cases?
- How do you feel about the problem we are trying to solve and any suggestions for us on this RFC?
We appreciate your time and expertise in providing feedback on these specific points outlined in the RFC. Your insights will play a significant role in shaping our decision-making process. When we close this RFC, we will inform you of our plans to incorporate your feedback by posting in this thread. At any point, if you feel that you would like to have a 1:1 with us to provide further feedback, ask additional questions or face trouble in understanding the RFC, feel free to raise a request to setup some time.
)