Daniel, we recognise that there are issues in this area of app lifecycle management.
Data Retention
Track storage and move data across products | Atlassian Support discusses data retention in general, from Atlassian’s perspective:
After you have been unsubscribed, Atlassian retains your data for 15 days (for evaluation sites) or 60 days (for paid subscription sites).
So, based on that, I would recommend the approach:
/uninstall with a delay
I would recommend the delay be 60 days for paid apps. Free apps could probably go with 15 days but 60 days there too, may be prudent. Whatever you choose, this should be made clear to customers when they install your app.
Instance Deletion
Currently instance deletion does not send uninstall events to installed apps. We know this is an issue in the Connect framework. This is primarily due to historical architectural reasons. The Connect framework runs as a plugin with the Jira/Confluence product instance. Normally prior to deletion an instance is suspended. It is no longer running due to conditions such as non-payment. The site may be reinstated during this period, once payment is successful, for example, so the site’s state (including addons installed) is preserved.
When a site transitions from suspended to deleted, we do not reactivate the site prior to deletion. As a result the Connect framework is not active to uninstall the site’s current apps.
We are moving to a more centralised model of app installation tracking, where the uninstall actions will not require the site to be active to deliver these events. When this change is made, site deletion will be able to internally trigger app uninstalls. We are not there today and I do not have a timeframe to give you for when this change will occur.
So in lieu of an event sent at the time of instance deletion, I would recommend the polling for access approach. I recommend the data retention times would start at the point you decide a site has been deleted.
How could an app achieve this? All apps are different so we can’t give a definitive statement about how to implement this data expiry. The following approach is one possibility:
Each tenant record could be tagged with a last-accessed data, which is updated whenever there is an interaction with the instance. All instances with no active interaction in the last week would be polled. Polling would recur at regular intervals (daily or weekly, say). At 60 days since last active date, the site would be considered as deleted. At 120 days the instance’s record could be removed.