I couldn't really find an issue about the addition of the possibility to use this module's own storage, so I can only guess at the rational (not that I think it doesn't make sense). AFAICT, the reasoning behing adding the option to use a separate table in the first place, is to be able to run the module without Statistics module enabled at all. Good show.
I do have a few suggestions (in order of importance, at least to me). Maybe I should have created separate issues for these. If you would like me to, please let me know.
The settings screen clearly states that the option to use the tables created by Statistics module is deprecated and that it is only available for legacy reasons. I think the use case for using the module to overwrite Statistics data goes beyond legacy reasons. For example, I have a site that uses Advanced Forum, which includes various Views that also pull data from the core statistics table. I could either refactor those to use this module's data (and have all sorts of annoying issues with updating), or I could have it overwrite statistics module. I can imagine there are other community projects that rely on statistics module data, so allowing this module to overwrite that data seems like a sound option that should not be considered deprecated (as the text in the settings screen says), but as just one of two perfectly valid options. That is actually part of the beauty of this module; just add a module, don't change anything else, and the view counts are suddenly retrieved from Google Analytics.
I would have posted a patch, but I didn't want to rule out I was missing something (plus, it's probably good to first agree on the wording). But, I basically feel that the "own storage" option is the "lightweight" option, without the need to have statistics module enabled at all, and the "overwrite statistics" option is the power user option and the wording in the settings screen needs to be changed in order to reflect that. E.g.
Data storage location *
- Use this module's database table. Use this if you don't want or need to enable core Statistics module.
- Overwrite total pageview values in table node_counter provided by the core Statistics module. Use this if you need core statistics data but don't want the overhead of Statistics module gathering that data itself. This option is only available when Statistics module is enabled.
Of course, there is a "risk" involved with statistics module, in that it will add overhead when its statistics gathering functions are enabled. In that case, the reason for adding this module is probably performance issues with Statistics module. I am actually planning on adding some code to the mentioned site that prevents anyone from enabling the options of the statistics module itself. This could well be something this module does, i.e.:
- Have a hook_requirements that checks whether statistics module tracking is off (adds a warning if it isn't).
- Have a setting that locks the statistics module settings page (i.e. sets access to FALSE on the form elements and adds some text explaining what happened and why, with a link to this module's settings page to disable the lock if somebody really wants to enable the settings).
One thing that stung me was that I refactored one block that I thought was the only place where view counts were being shown, switched over the module, and found there were other places where the statistics data was being used. It would be useful if both storage options could be used in parallel while everything is being moved over. This actually triggered me to reconsider my decision to move over to this module's storage and revert back the originally changed View instead of refactoring all the other Views where view counts are shown (and opening this issue). Allowing both storages to be used at the same time would e.g. help those that start out with the internal storage, and later add standard components that need statistics tables. The configuration option could have a little warning stating that it is recommended to use only one of the two options, because it does constitute duplication of data, obviously.
Closed: outdated
3.0
User interface
Because of the Universal Analytics shutdown, version 7.x-3.x is no longer supported.
As Drupal 7 EOL is close, please consider upgrading to the latest Drupal and latest version of this module with Google Analytics 4 support.
If you are still here and experiencing problems with the latest version using GA4, then please open an issue about it.