Wow such empty. Let’s change that!

We’ve had great need for a cart change history in the past. Our requirements meant for us to have some automatic updates on carts based on external system responses. Not our use case, but think of e.g. external prices for customer tailored products. 
 

As always with external systems, things are not always going great. Changing the cart automatically means that sometimes, these changes go south. If something else that writes to the cart depends on this (e.g. some calculation for the delivery time based on the product complexity), then it starts to become very important to have a cart history. Only then can one find out which of the systems writing into the cart messed up. Otherwise, the cart would have to be used as an error message store as well (or some other workaround). 
 

Now that I’ve painted out the (obvious) use case, let me try to answer the questions from my perspective: 

how long? Ideally that would be adjustable. 30 days sound good, but as you already mentioned this is a lot of data. Can I save costs by having only 10 days? Then maybe I would like to opt for that. 
 

paying extra? I gotta level with you, there is probably already a logging system in place somewhere. So I’d rather log cart changes myself as that will be more flexible and probably about as expensive as using the audit log. For us, so far, it was never a factor that a non IT person had to look at cart history. So dumping it into a logging system has been just fine. So I’d advise my company not to invest here. 
 

how would we use it? I think that’s already become clear and is probably highly dependent on the use case. 
I’m not that creative but I can’t really picture any other use case other than debugging and support cases. 
 

I hope this perspective gives you some helpful input. 

We’re utilizing the audit log APIs in our project, primarily for scheduled orders, to monitor changes made by both our custom app users and customers.

To manage costs, we opted against premium logging. Instead, we implemented a combination of out-of-the-box logging for tracking changes from the custom app and stored customer changes in MongoDB, which provides us with the necessary flexibility.

I see the potential for tracking cart changes to analyze customer behavior, which could enhance the marketing campaigns. However, a 30-day retention period isn’t sufficient. Users should have the option to configure which changes to track as you mentioned ‘’ Carts have high rates of change and to cover carts in change history would create more change records than all currently covered resources‘’, as not everyone may want to incur costs for data they can’t control, especially regarding the time-to-live (TTL) settings.
 

Thank you for your input.  For clarification, are these worries around realtime cart updates?  meaning an external price calculation gone wrong leading to abandonment or contact centre calls?  or is this some type of asynchronous process that would update a cart which is essentially idol?  Just curious.

Yes, they were about real time cart updates. If an external system, which has to put information in the cart, fails, then the customer will get stuck. We can’t sell the product if we don’t have a price (for example). But since there is multiple systems which also depend on each other (i.e. the price calculation needs some information from the cart which another system put there), it’s really hard to tell which system messed up just by looking at the current cart. Especially if the customer tried to solve it by removing stuff and re-adding it and so forth. 
So yeah, we need a cart history mainly for support cases.