When to use a new field on the user account or a custom table and when use user.data service? Is there any rule when to use a new field in the user account for storing information and when to use the user.data service?

My initial approach was:
When the information should be editable either by an administrator or by the user itself, then use a new field. When the information should not be editable, only by code, use user.data service or a custom table.

E.g. in my case I am storing some information about where the user came from (marketing campaign) and some other information gathered during registration. This information is not meant to be shown to the user or edit by the user. Thus I decided to use the user.data service.

Now I am experiencing a very fast growth of the user_data table and I'm wondering whether my approach was correct. Maybe I should have created a new table for this or use a new field in the account. 

Is there any rule when to use the user.data service and any limitations?
The purpose of the UserData API is to allow the storage of certain pieces of information related to a particular user. Its concept is similar to the State API in that the type of information stored is not a configuration that should be exported. In other words, it is specific to the current environment (but belonging to a given user rather than a system or
subsystem).

Users are content entities, who can have fields of various data types. These fields are typically used for structured information pertaining to the user, for example, a first and a last name. However, if you need to store something more irregular, such as user preferences or flag that a given user has done something, the UserData is a good place to do that. This is because the information is either not something structured or is not meant for the users themselves to manage.

In the other hand if you want to be able to export and import your user information in different environments then you should use fields.