I am not sure how to fix this properly. Is this the VisitsSummary.get report? Do you mind posting an English one next time? :)

Would we handle this in VisitsSummary.get API and remove the column there if needed? If so, the API response would vary depending on the time of the day or the day or date range itself. Meaning sometimes the property would be there, if there was a user recorded, and sometimes not which could lead to random bugs etc. We'd maybe have to check for any given site whether there was a userId recorded in the last 2 months and if so, return the property in API. If there was none recorded we would hide the column. It would otherwise appear buggy as one would never know whether there was no user or whether the information is missing due to a bug etc.
Also imagine someone uses a segment which selects a set of visitors that do not have userId. In this case you want to display users: 0 as it is an important information.

We could fix it in ScheduledReports but this would require a hack specifically for VisitsSummary.get in that plugin. Fixing it in VisitsSummary.get would also make it work in Piwik Mobile app and other clients. Consistent behaviour...

We have basically the pretty much same solution in https://github.com/piwik/piwik/compare/6705?expand=1#diff-ce58a897abf6df1abe41055566f151ecR89 for UserId and https://github.com/piwik/plugin-Bandwidth/blob/master/Columns/Bandwidth.php#L91 for Bandwidth. It would be nice to find a universal solution for this. I worked on it by using API\API::get() but it ended in a nested loop. Also with the current solution we always end up in requesting an additional report with period=month which could be slow.

Another solution could be following:
If any dimension class returns a $value !== false in one of the tracking events we could set an option $dimensionName_used_by_SiteId_28=true or metrics_used_by_siteId_1=visit.userid,action.bandwidth,visit.visit_goal_buyer or $dimension_is_used_by_sites=1,2,3,4,8 (last solution results in less entries in option table) . Just an example... When rendering reports we would always check whether a metric was actually used or not for a given siteId and if it wasn't used for the given site we would automatically exclude it from processed reports etc. A developer would not have to implement any logic anywhere. Downside: It would result in many option entries that we would have to cache via TrackerCache. This is not really optimal as it still makes everything slower... Maybe we should save an option entry only for dimension entries where we actually need it. Meaning there could be a method function checkForUsage($idSite) { return true }. Need to try it.

Edit: This possibly won't work automatically since Dimension != Metric and here we are interested in the metric

I worked on a proof of concept for the mentioned idea storing entries in the option table during tracking. This has a big disadvantage: If someone clears the option table or if someone only wants to move all log_* table another / new Piwik instance, the new Piwik instance will think those features were not used since the entries in the option table do not exist. And they would not be recreated since they are only written during tracking. This is not really optimal. Also if eg. userId was only used once for testing it would assume the site uses this feature and always return the user metric. Even if it was not used over a long period. Accessing the nb_users metric seems like the best solution for me so far.

Will think of more solutions.

I couldn't think of any other way to solve this apart from using the metric. We could not do a separate API call for period=month (last 30 days including today would be even better but slower) and just check whether it is zero as requested initially but I still think it would be only an easy hack and not a good solution.

I will stop working on this issue until @mattab is back to discuss further steps.

In a chat with @diosmosis we came up with an idea that userId (and bandwidth as same problem in Bandwidth plugin) could be a Site setting that can be basically managed in Sites Management (optionally). This setting would be automatically enabled once a userId was tracked once. We would have a new column in piwik_sites for this probably. In an update script we would detect whether the userId was used in the past and enable the feature if needed for old installations.

A problem would be still the detection of userId usage when someone moves the log_* tables to another Piwik installation etc. since we would enable that setting only as soon as something was tracked. Another problem as mentioned would be also still that someone might stop using this feature after a while but setting would be still enabled as it was maybe used years ago.