Control how long Data is held in the Alterian Cache (TTL)

Expiry Times

Data stored in the Alterian Cache is used for varied purposes; it could be your current favourite category, your churn risk, your email address or your preference information.

As can be seen from the examples above the requirement to keep this data varies hugely over time. Some of the examples could be out of date in a matter of hours and can be safely removed, others should be kept for a long time and always kept up to date.

To ensure optimal efficiency and performance of your solution, as well as compliance with global data protection regulations such as GDPR, we implement automatic "Expiry Time" values (TTLS) for all data fields being written into the cache.

The Expiry time is employed purely to indicate the duration for which a field's value should endure within the cache subsequent to its initial writing or rewriting. Once the Expiry time elapses, the value will be automatically purged. The Expiry time is denominated in seconds, with a minimum threshold of 1 second and a maximum span of 20 years.

When storing data in the Alterian CX Cache the Expiry Time can be set in three ways:

Open

Cache Step Expiry Time

Firstly, we check the Cache step in the Rule and then honour the value provided. In the example below the values being written to the Cache will be kept for 1200 seconds or 20 mins. The data is not useful after this time so we are sensibly removing it after a short period of time. This Expiry time can be set in the Template, via a parameter in the Rule or via a field.

Although the upper limit for this is technically 20 years there are very few use cases where data should be persisted this long.

Please consider carefully how long data should be held and apply appropriate expiry times as you build your rules. Don't forget the cache steps can be configured to read and then rewrite the value therefore renewing the expiry time, thus allowing data that's used to persist and data that is not to be purged.

Alterian provide a fair usage in this area. Please review your Alterian service catalogue for details.

Open

Customer Default Expiry Time

If no Expiry time is added to the Cache step or it’s at the default of “0” we will check to see if the customer has setup a Customer Default Expiry Time. Customers often have data protection policies that require data to be removed after a set period of time. For example, customers often opt to remove marketing data after 14 months.

To setup a Customer Default Expiry Time please raise a support request. The Customer Default Expiry Time works at an account level but cascades down to tables when they are created. All Cache writes therefore that do not have a Expiry Time set will subsequently get this value.

This Customer Default Expiry Time can be set to anything but we will be strigent to ensure customers request a suitable value. Anything beyond our default of 2 years will need a business case as part of the request. (See Application of expiry times for details on when changed values will be applied.)

Alterian Default Expiry Time

If neither a Cache Step Expiry Time or a Customer Default Expiry time exists then we fall back onto our default value. This is 2 years.

Alterian fields

Alterian write many fields to the cache to service our solution. The Public Templates that use these fields have been configured to read and then rewrite the value therefore renewing the expiry time each time a field is used. This means that fields that are read will persist and those that are never read will be purged after the alloted time. The fields that we have set to be purged are set out below.

Application of Expiry Times

The default Expiry Time was added in early 2022 to meet customer data protection requirements. Values written before this date that did not have a Cache Step Expiry Time would not have had an expiry time at all. This will mean they will persist in perpetuity.

The Customer and Alterian Default values as defined above are set at a table level when the Table is first created. This means that changes to the Default values after a table has been created will not change the Default for any tables already created.

Due to this it is important to be clear on your data retention requirements before onboarding so the appropriate defaults can be applied.

Functionality within to the Access Cache step allow a write to directly follow a read thereby reapplying the TTL or expiry time set in the step to that value. This will ensure data that is regularly used is persisted, the TTL will reset each time, while data that is not accessed is removed as expected.

If changes are required for existing tables please contact Alterian support and we can talk through possible next steps.

L