-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom dimensions in Log Analytics to replace custom variables #290
base: 4.x-dev
Are you sure you want to change the base?
Conversation
* Integrate Custom dimensions, as a replacement for Custom Variables. (Closes #188) Signed-off-by: Samuele Kaplun <[email protected]>
@diosmosis that was you last comment on #214, which aimed to fix #188 Checking if all custom dimensions exists before the log is being parsed isn't possible if the dynamic resolver is used, as it's determined for each single tracking request which site_id is being used. Not sure how to handle that. Also I was wondering if we should completely remove the custom variable / dimension for Tracking the HTTP-Status-Code is also automatically done. I would actually do that on demand only or at least make it possible to deactivate that |
IMHO @sgiehl it would be acceptable to break BC for this. (it would have been better to have included this in the 4.0.0 release already but it's still fine). Just need to document it clearly in the chnagelog (can you create a new issue specifically to announce the BC break more clearly?)
Thanks for your explanation. Sounds good to remove the user agent value from it. Would it be possible to still have a Custom Dimension "Bot" set to 0 or 1 based on device detector detection? it would be quite helpful to still be able to segment out the "bots" visits, since we know so much of the traffic is from bot, and people need/want to see the non-bot traffic (which they could do by creating a segment Bot is 0)
Is there a potential issue to do it automatically? if not, then it might be easier to leave it tracked automatically (and means we don't have to implement a new flag/parameter to the tool to disable the feature) |
Some ideas:
|
Sure, we could do that. But as I explained before, that would be very inaccurate, as the log analytics script only detects a generic set of bots. Matomo does actually detect a lot as it uses the device detector. So if we want to provide an easy way to enable bot tracking we could create a simply plugin that only has that one dimension and is filled with the result of device detector.
It's not an issue, but we should at least give the possibility to disable it, as it otherwise might consume a custom dimension, where people might need it for something else maybe.
Imho that sounds a bit too complex. Maybe we should simply ignore not existing dimensions if the auto-create option is not given. So we should imho document that custom dimensions with specific names are required to import those values (unless the auto-import option is set) |
The only potential problem I see w/ that is that if a user doesn't realize this or doesn't realize that those custom dimensions shouldn't be applied to every log, and the log importer fails silently, then they will have data they don't expect. So they may not realize their data is broken, may create bug reports, and when they realize the problem, will have to re-import, which could be a very complicated and long process depending on how they imported in the first place (and can break some data that requires logs be imported in order). This seems like it could lead to a very poor UX for some users. |
This is currently a port of #214 to 4.x-dev branch.
Will start applying the suggested changes here