Retention Days
Overview
This page covers information about Retention Days and how to configure them for a client.
Prerequisites
- Access to the client-configurations folder on hv-central-config.
Purpose & use case
Who is this for? GTM teams, developers, support teams.
When should this be used? When a client wants to extend or decrease the data retention period on HV's end.
What is "Retention Days"?
This is the number of days data is stored for a transaction ID on our end. Default: 14 days.
A transaction expires at:
(date transaction was created OR date of last successfully-processed FT call) + N days
- "Date transaction was created" is the first API call ever made for that transaction.
- "Date of last successfully-processed FT call" is the date a successful FT call was processed.
- "Successful" means an FT call was made with any status and was successfully processed by the backend, with the status updated.
Sample scenarios
Scenario 1
- Assume the AppID has a 14-day retention period.
- First call for the transaction was made on 1st Jan. The FT call was also made on 1st Jan.
- Data would expire on 15th Jan.
- Now, before data expires, the user tries again on 5th Jan and another FT call is made.
- The expiry becomes
5th Jan + 14 days= 19th Jan. - If in the above scenario the FT call, for some reason, did not reach the backend or was not successfully processed, the expiry would remain 15th Jan.
How to update retention days for an AppID
Update the client-configurations folder on hv-central-config:
- Create a new file for the AppID as
{appId}.jsonif it does not exist. - In the
{appId}.jsonfile, add a keydataRetentionDays. The value should be a number, one of the supported values below.
Sample MR.
Supported values
Supported dataRetentionDays values
- 1 day
- 14 days
- 28 days
- 45 days
- 90 days
- 180 days
FAQs
Q: What will happen if we give an unsupported value for dataRetentionDays? The pipeline passes — what happens if the MR gets merged?
A: (Open question — to be confirmed with the platform team.)