This changelog is the source of truth for all changes to the Marketplace that affect people publishing apps.
Posts are made in the Marketplace announcements category of the developer community when the changelog is updated. Subscribe to the Marketplace announcements category to get notifications.
Beginning on 15th May 2024, we will update our marketplace reports to use the invoice issuance date as the sale date, aligning it with the sale date used by our finance systems. This change is designed to benefit Atlassian Marketplace Partners by resolving inconsistencies between marketplace and remittance reports and enhancing clarity. Please note that this change will not impact historical transactions or alter our current payment process.
For more details, please refer to https://atlassianpartners.atlassian.net/wiki/spaces/news/blog/2024/04/12/453771297/Reports+Alignment+of+Sale+Date+Across+Marketplace+and+Finance+Systems
We are excited to announce the first set of improvements since our initial communication on the work we are doing for the technical foundations of Marketplace!
We are happy to introduce the enhanced distributions (active installation and user counts) data. We have made improvements to the way we provide and calculate the distributions (installation and user counts) for various aggregations. Alongside that, we have considerably decreased the latency from one week to one day for this data which will now be accessible via the existing partner metrics API (currently also being used for retrieving MRR/ARR).
Not only that, we have implemented specific improvements to effectively monitor and correct failures, thereby enhancing its reliability. Similar to distributions, download counts will be served via the existing partner metrics API.
To learn more about these enhancements and how to make requests, please refer to the quick reference guide.
Partners had requested to know which customers are receiving dual licensing support. As part of that, a new field "reason" has been introduced in our APIs to provide insights specifically when discounts are applied due to DUAL_LICENSING. This field is displayed when the discount reason is DUAL_LICENSING.
The newly introduced field information will be accessible through the following Marketplace APIs./vendors/{vendorId}/reporting/sales/transactions/vendors/{vendorId}/reporting/sales/transactions/export/vendors/{vendorId}/reporting/sales/transactions/async/export/{exportId}
Please refer to more details on how the API response and CSV files will reflect this change.
API response with new fields
1
2
3
4
5
6
7
8
9
10
11
"discounts": [
{
"type": "XXX",
"amount": "XXX",
"reason": "DUAL_LICENSING" <-- Reason field shown only if reason is DUAL_LICENSING
},
{
"type": "XXX",
"amount": "XXX" <-- Reason field not shown as reason is not DUAL_LICENSING
}
]CSV response with new columns
We have expanded the transaction csv export file by incorporating four new columns: loyaltyDiscountReason, marketplacePromotionDiscountReason, expertDiscountReason, and manualDiscountReason. If the discount amount is greater than 0 and the reason for the discount is a dual license, these columns will contain DUAL_LICENSING.
loyaltyDiscountAmount | loyaltyDiscountReason | marketplacePromotionDiscountAmount | marketplacePromotionDiscountCode | marketplacePromotionDiscountReason | expertDiscountAmount | expertDiscountReason | manualDiscountAmount | manualDiscountReason |
|---|---|---|---|---|---|---|---|---|
XXX | DUAL LICENSING | XXX |
| DUAL LICENSING | XXX | DUAL LICENSING | XXX | DUAL LICENSING |
Our new finance ERP platform, Oracle Fusion, will undergo scheduled periodic updates, causing approximately a 9-hour maintenance downtime that will impact our internal data pipelines. Once the update is completed, our internal data pipelines will resume and it will take about 3 additional hours to reinstate unprocessed transactions in Marketplace reports and APIs.
We anticipate that Marketplace reports and APIs will be affected on the following upcoming date and time.
May 17th 2024 7 p.m PST to May 18th 7 a.m PST
For more details, please refer to this blog: https://atlassianpartners.atlassian.net/wiki/spaces/news/blog/2023/12/21/379453986/Important+Notice+Scheduled+Oracle+Fusion+Maintenance+Impacting+Marketplace+Reports+and+APIs
EDIT, 13-May-2024: This RFC is now closed.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-46-app-editions-for-marketplace/79452/25.
The new categories and keywords, as part of the new store experience, will start rolling out end of April. In order for customers to discover your apps via the new categories and keywords, please be sure to tag your apps accordingly as soon as possible.
You can tag your apps to the new categories and keywords in your App Details page. For more information, please visit this link.
We will be extending the Jira Work Management list view to Jira Software projects. This view will be accessible via the side navigation but will sit outside the board context. The list view will sit alongside other lists we have available in the platform – such as the “Issues” view.
This new view will make it easier for our users to view all tasks across their Jira Software project and make quick and easy edits as they plan, refine and track their project tasks.
For more information, visit the Quick Reference Guide.
As of this week, some Cloud customers will be able to set up and enable app access rules under data security policies. The feature will be slowly rolled out to customers over the coming week.
Customer outreach for this feature will be high-touch at first to give Marketplace Partners more time to update apps, but we plan to do a larger announcement toward the middle of 2024 (calendar year). You can read more about the rollout plan here.
We highly recommend testing out the feature and considering adjusting your app to warn users when it’s impacted by an app access rule.
Prepare for this change by reading more about the app access rule API here for Jira and here for Confluence.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party access to certain content in select spaces.
Marketplace team has released an enhancement to the improved marketing attribution data feature. Partners can now track the exposure of app requesters who initiate evaluations for installed apps.
This involves presenting the activities of all the app's requesters (if any) for which the evaluation is generated. Partners can leverage these activities to comprehend the channels through which a user was exposed to the app prior to making a request. This capability will be particularly beneficial for marketing campaigns targeting app users rather than administrators.
Partners can access this data via the new asynchronous APIs for improved marketing attribution. There will now be two new fields present in this data:
userType: The type of user performing the activity. It can have two values i.e admin and requester
userId: One way hashed value to uniquely identify the user (and thus group the set of activities performed by them)
For more details on how to use this data, visit the updated quick reference guide here.
EDIT, 13-Apr-2024: This RFC is now closed.
A new RFC is ready for review at [Marketplace Store Revamp |Marketplace Store Revamp |smart-link].
We are pleased to announce the general availability of improved marketing attribution for partners!
The Atlassian Marketplace provides marketing attribution data to partners in our reports. This data is based on the last touch model. Even though this model is straightforward, it sometimes oversimplifies the path to conversion, neglecting the impact of other marketing channels and touch-points contributing to the overall journey. Partners would like the ability to use advanced attribution models to identify the various touch-points a customer took before installing the app. We have also noticed over time that:
Evaluations have been misattributed to Atlassian-run campaigns in some cases, even when Atlassian campaigns were not the actual last touch point.
Evaluations have not been attributed to partner campaigns because that is not the last touch before installation
Partners can't use attribution models according to their own needs (such as first touch, time based etc.)
To address these issues, we have revised our approach to marketing attribution. We have enhanced our logic to specifically consider user activities related to the app for which the evaluation is created. Partners will now experience improved data quality, particularly for the campaigns they run. Additionally, instead of last touch, we now provide all the relevant user activities (related to the app discovery) from the last 30 days, along with a timestamp to be used as a weighing mechanism.
Partner can retrieve this data by making the following API calls:
https://marketplace.atlassian.com/rest/2/vendors/{vendorId}/reporting/marketing-attribution/async/export - Initiate a POST request to export all marketing attribution data. For more information, you can visit this link.
https://marketplace.atlassian.com/rest/2/vendors/{vendorId}/reporting/async/export/{exportId}/status - Get status for async export marketing attribution request. For more information, you can visit this link.
https://marketplace.atlassian.com/rest/2/vendors/{vendorId}/reporting/async/export/{exportId} - Download async export marketing attribution. For more information, you can visit this link.
For more information, visit the QRG.
In the coming 2 weeks, all Cloud customers will be able to set up and enable app access rules under data security policies. Customer outreach for this feature will be high-touch at first to give partners more time to update apps.
Many app components will display proactive warnings letting customers know that the app has been blocked by their admin. However, if an app relies on data from restricted spaces or projects, user experience may be impacted in other spaces where the app is not blocked. This may confuse end users or present them with incorrect data if the app is not adjusted to account for the impacts of app blocking.
For this reason, we highly recommend testing out the feature and considering adjusting your app to warn users when it’s impacted by an app access rule.
Prepare for this change by reading more about the app access rule API here for Jira and here for Confluence.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party access to certain content in select spaces.
EDIT, 8-Apr-2024: This RFC is now closed.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-42-deprecation-of-mirroring-third-party-dependencies-via-packages-atlassian-com/78360.
Starting at the end of March 2024, all Cloud customers will be able to set up and enable app access rules for Jira and Confluence under data security policies. This change will give customers an important new control to protect data while benefiting from Marketplace apps.
Customer outreach for this feature will be high-touch at first to give partners more time to update apps.
Many app components will display proactive warnings letting customers know that the app has been blocked by their admin. However, if an app relies on data from restricted spaces or projects, user experience may be impacted in other spaces (ex: search features or workspace modules) where the app is not blocked. This may confuse end users or present them with incorrect data if the app is not adjusted to account for the impacts of app blocking.
For this reason, we highly recommend testing out the feature and adjusting your app if necessary to warn users when it’s impacted by an app access rule.
Prepare for this change by reading more about how applying an app access rule to your app affects the behaviour of product REST APIs it calls here for Jira and here for Confluence.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party access to certain content in select spaces.
On Mar 4, 2024, we announced the release of XSS mitigation for partner reports provided by Marketplace.
After receiving some partner feedback, we have decided to roll back this change. We will reevaluate our approach and explore a more agreeable solution.
We would like to extend our apologies for any inconvenience the change (XSS mitigation in transactions report) may have caused. We recognize the impact of this change on some of our partners (who are mitigating at their end) and have therefore taken a decision to reevaluate our approach.
Rate this page: