For instance the Country report has more than one segment. For the rest @mattab

In that case would it be better to create a Continent dimension?

there will be cases of a dimension having several segments. For example the "browser name" dimension could have segments browserName and browserCode

resolution could have screenWidth screenHeight

there are cases such as searchEngine==X dimension (currently not implemented) which would be a combination of two other segments like referrerType==search;referrerName==X

What about dimension <=> report mapping? Can creating a 1-1 mapping work or would it be limiting in some way?

FYI, I would support creating a 1-1 mapping of at least dimension <=> report as it would make using metadata easier. For example, if there are multiple reports for one dimension, it's harder to know what the 'official' one is (which could be a problem for the PivotByDimension filter). If it's possible to implement I'd also support making a 1-1 mapping of Dimensions & Segments. Or maybe allowing "composite" dimensions, ie, Resolution would be a composite of ScreenWidth & ScreenHeight.

there may be good use cases which we can't simplify but we can most likely define a default mapping or default dimension to use (or simply use the first from list), at least as first step. "composites" dimensions / segments will be needed sure. about dimension<>report it makes sense that each report has a dimension only. is there any report with more than one dimension? I'd be curious. (except when PivotBy or Flatten).

For example, if there are multiple reports for one dimension, it's harder to know what the 'official' one is

+1 are there such reports already?

GetExampleReport uses the ExitPageUrl dimension but that's all that I am aware of.

Here's what I'd like to do: create a POC in current Piwik code where every existing report has one dimension and every dimension has one segment. The code will still allow multiple mappings, but core code implements strict 1-1 mappings. Then we add some initialization code that checks whether the 1-1 mappings are violated and if so, logs a warning. This way we can be sure our code will be easy to work w/ and if problems come up w/ other peoples' plugins there will be log messages to help diagnose the problems. What do you think?

What do you think?

It sounds good. Though maybe not a warning because it seems that GetExampleReport uses the ExitPageUrl dimension is an acceptable use case for a plugin. So maybe log as verbose() ?

Is it an acceptable use case? It might've just been put in to avoid creating a new dimension?

Regarding log level: I would want the warnings to be noticed and reported by users so we can tell whether there is a valid use case for having more than one report use a single dimension, so warning would be better than verbose (which just means 'ignore').

ok for log level. Regarding valid use case, I think there will be valid cases of reporting enriching a given dimension (giving another view of same data). Maybe they could be done with a custom Filter rather than a new report with a custom dimension...

so +1 to assume the 1-1 relationship as you suggest and simply wait for developers feedback.

I'll post a proof of concept so you'll know what I mean (whenever I get around to it...).

Third party plugins might want to reuse existing dimensions. I think we had something like this with DevicesDetection and UserSettings but there was kinda worked around. Also third party plugins wanna build different reports for existing dimensions for sure. They can even pick to build a new report upon an existing dimension when generating a report. Will the solution still be backwards compatible?

Actually I was thinking we'll have to add properties, ie, Dimension::$mainReport or something. I think a 1-1 mapping of segment => dimension is possible and desirable. Not sure how easy it will be to maintain BC.