Check current Member Values before reassigning

Most functionality within the platform relies on the latest Member Values. Since Member Values are a time-series, it is possible to POST the same information for a given member (e.g. City=Vancouver) many times without noticeable functional implications. Doing so will simply record that City=Vancouver was known to be true at these several points in time.

However, when you create a query using the /membervalues/asof/{datetime} resource through that time (including for 9999) the same information will always be returned. If these distinct Member Values are not meaningful to you, then they create excess data that can affect the performance of the API, particularly when using /membervalues.

Whenever you have information on the actual effectiveDate where a piece of information is known (e.g. if the information was collected in a web form from a person on a specific date), we recommend including effectiveDate when posting the Member Values. This will minimize storage of excess data and also assist in cases where information on a member is collated from several sources (e.g. API integration + survey responses) into this service.