For technical reasons, it is necessary to restrict the number of data that can be recorded in some places. Mapping limits are used for this. If such a limit reaches 100%, no new values are recorded. Instead, they end up in the value "webtrekk_fallback". Only those already measured are then counted up.
For example, there is a limit of ContentIDs or pages, which is 5 million by default, but depends on your contract. This means that a maximum of 5 million different page names can be entered in the account. There is no fallback for categories, the new characteristics simply do not appear any more.
Webtrekk can perform an automatic cleanup to make room for new characteristics again. Basically, this applies to all conceivable standard objects, such as pages, products, search phrases, media or actions, as well as most types of custom parameters. In general, these are always text values, numbers are not subject to any restrictions.
During the cleanup, a number of references are specified, for example 5, and the values below them are cleaned up. This means that all characteristics are combined that have been measured a maximum of 5 times. These are all written to or turned over on the "webtrekk_aggregated" label. The number of measured values remains the same, but the summary no longer shows which values are hidden behind them. The higher the references are chosen, the more characteristics are included and the more space is created.
We use the "unimportant", because few measured, characteristics to gain space, so that new characteristics can be recorded.
The limit applies per parameter type, so the cleanup always takes place for all parameters of a type; individual parameters cannot be cleaned up. However, we can protect the last x months and leave the most recent data untouched. One month corresponds to 30 days. If 2 months are protected during a cleanup, 60 days are spared retroactively from the day of the cleanup.
The alternative to the cleanup is to increase the limit. This is usually with costs.
Webtrekk will actively inform you if a limit moves towards 100%.
If a limit is regularly reached, the implementation should be revised conceptually if necessary. For example, you can use a generic parameter that knows no limit. The generic property can be set for each parameter in the respective configuration.