Completeness Enhancements

Who would benefit?

Users working with data enrichment - content editors/specialists/translators, data stewards (responsible for overall data set), data auditors, consumers of data pushed outbound from inriver.

What impact would it make?

Users would have detailed insights into data completeness in their specific market or other context. Data consumers would enjoy higher data quality.

How should it work?

For modern real-world use cases, Completeness needs to be enhanced in the following ways:

1) more standard rules are needed, and the existing rules should be enhanced with greater configurability.

2) Completeness states should be calculated in some contexts on the client side and in other contexts on the server side but in a more performant way than they are today. For example, less like a Server Extension and more like a Listener or even a Scheduled calculation basis.

3) It should be possible to include or disable Completeness Rules on the basis of the context (Segment, Fieldset). Example 1 - if Segment A is selected then Rules A, B, C apply, but if Segment B is selected then Rules B, C, D, E apply. Example 2 - if Fieldset A is selected then only Rules relating to FieldTypes in Fieldset A are considered in Completeness calculation.

4) Support for more granularity is primarily driven by the previous points, but for UX it would be practical to have a better UI, possibly exposed in the Portal rather than the Control Center - "better" in this case means a more performant UI, a UI that presents configuration of Rules and Groups in a more modern and compact way.

Why is it needed?

Today, Completeness as a core feature is limited in terms of:

1) the rules that can be applied - custom rules need to be developed for many real-world use cases;

2) the performance of the feature - Completeness states are calculated immediately when an Entity is saved, like a Server Extension;

3) context - when Segmentation or Fieldsets are used, there are different contexts in which an Entity is considered complete. For example, a FieldType might be required in one market but not another, or perhaps only the value in a specific language;

4) the granularity of the rules that can be applied - this is limited by the points described previously - with Completeness as it stands today, we typically recommend using Completeness at an aggregated level that requires a human eye to check the granular aspects to drive the aggregated Completeness state. That is an error-prone solution.