@code-penguin opened this Issue on February 21st 2017

I have the use case that I want to manually trigger a conversion when a user clicks on a button, and store additional data with that conversion. My goal is configured to allow multiple conversions per visit. For the data I have created an 'action dimension'.
I trigger the conversion manually as described in the documentation:
https://developer.piwik.org/guides/tracking-javascript-guide#tracking-a-custom-dimension-for-one-specific-action-only
_paq.push(['trackGoal', idGoal, customRevenue, {dimension1: 'DimensionValue'}]);

In this scenario, the custom dimension is not saved with the conversion; I would expect the custom_dimension_X field in each newly added row in the piwik_log_conversion table to be filled, but this is not the case.

I have taken a look at the code and think I have found the cause. In the CustomDimensionsRequestProcessor class the dimensions are only updated on visits (onNewVisit, onExistingVisit) and on actions (afterRequestProcessed), but not on conversions. To work around this I have modified CustomDimensionsRequestProcessor::afterRequestProcessed to temporarily store the dimensions as metadata on the request, and then retrieve this metadata in GoalManager::recordGoals and add it to the goal. With these changes the dimensions are now saved in the piwik_log_conversion table as expected.

Would love to hear your opinion on this, if there is any "proper" way to accomplish this or if it really is a bug / missing feature.

@tsteur commented on February 21st 2017 Member

It is supposed to write into custom dimension in log conversion via the Tracker.newConversionInformation event in the method CustomDimensions::addConversionInformation(). The thing is by looking at the code: It seems to only look for visit custom dimensions, not action custom dimensions which is the behaviour you describe.

Why is this the case? Because we can still get the action dimensions for this conversion why the link from the log_conversion table to the log_link_visit_action table on idlink_va.

So the tracking itself should be fine. It might be maybe more of a reporting issue that likely only conversion dimensions are shown in the reporting but not related action dimensions? This is likely same behaviour as for custom variables I reckon.

@code-penguin commented on February 22nd 2017

Thank you for your reply!
Yes I haven't tried it with visit dimensions because I only want to save this extra information for the conversions and not for the visit.
As far as I can tell though it's not possible to get the action dimensions for conversions from the log_link_visit_action table if you trigger the conversions manually. Because in GoalsRequestProcessor::processRequestParams the action is set to 'null' in this case, so there is no action..

@tsteur commented on February 22nd 2017 Member

@mattab what do you think? It sounds to me like adding action dimension reports to goals "by dimension" report but not sure.

Another way that may work (rather a workaround) would be to go to "Actions => $YourActionDimension" then apply a segment by Goal "Visit converted a specific Goal ID". You should see the dimensions used when it was converted but haven't tested it.

@mattab commented on February 23rd 2017 Member

It sounds to me like adding action dimension reports to goals "by dimension" report but not sure.

That's my understanding as well. I wonder why we didn't implement it as it seems to make sense that action-dimensions would be duplicated in log_conversion.

@code-penguin maybe you could create a pull request with your changes to have action dimensions stored in log_conversion?

@code-penguin commented on February 23rd 2017

@mattab I have just created two pull requests with my changes:
https://github.com/piwik/plugin-CustomDimensions/pull/56
https://github.com/piwik/piwik/pull/11400
Unfortunately I had to make changes outside the plugin because I couldn't find an easy way to have the extra data picked up automatically. For actions there is $action->setCustomField but for goals there are no objects. If you have suggestions on how to prevent changing the piwik core for this, those are of course welcome.

@code-penguin commented on March 10th 2017

Hi guys, it looks my fix is not quite complete. The custom dimensions are now correctly stored in the log_conversion table, but there doesn't seem to be any way to then use them in reports. I think part of the problem is that Archiver::aggregateDayReport only adds custom dimensions to archives from visits and actions, and ignores the action dimensions stored in log_conversion. But even when I work around this, a segment on 'dimensionX=myvalue' will always return 0 for nb_conversions. Maybe one of you can look into this and let me know how it should work, so I can start making a fix.

@peterbo commented on April 15th 2021 Contributor

@code-penguin - What are the ToDos on this ticket? Only the reporting? This seems to be a quite good feature if it worked!

@sgiehl commented on April 15th 2021 Member

@peterbo Did you check if that still doesn't work? I've just tested it with a manually triggered _paq.push(['trackGoal', idGoal, customRevenue, {dimension1: 'DimensionValue'}]); locally. And the custom dimension was set correctly in the log_conversion table. Maybe this issue has been fixed meanwhile and can be closed?

@peterbo commented on April 15th 2021 Contributor

Hi @sgiehl ! - For visit scope custom dimensions, this works, but not for action scope Custom dimensions. This would make a lot of sense to attach multiple attributes to a conversion. Otherwise, you'd have to send an event along with all custom dimensions attached. But getting this reported afterwards is a nightmare.

For example, the request:
https://example.com/piwik.php?cdt=2021-04-14+15%3A52%3A28&revenue=130&idsite=123&uid=XXX&token_auth=XXX&rec=1&r=735130&idgoal=58&dimension31=test&dimension32=depot&dimension33=test

results in the following goal reported in the API:

actionDimensions

dimensions31/32/33 are all action dimensions.

@sgiehl commented on April 15th 2021 Member

I guess that is actually by design. For the scope conversion the defined dimensions of scope visits are used, so there won't be any action dimensions tracked. See e.g. https://github.com/matomo-org/matomo/blob/539faeac7f49fac5d63e78edeaef25ab40f4020f/plugins/CustomDimensions/CustomDimensions.php#L335-L356

@peterbo commented on April 15th 2021 Contributor

@sgiehl - thank you for providing the code! Ok, I see. Having this would be great, also an action custom dimension report in the goals report would be a fantastic tool.

For other users, that are pulling their hair out, searching for the reason, why this doesn't work, we should probably note this in the documentation until this might be implemented, because from a user's perspective, this is not self-explanatory (even if it makes sense from a coder's perspective):
https://developer.matomo.org/guides/tracking-javascript-guide#tracking-a-custom-dimension-for-one-specific-action-only

@sgiehl commented on April 15th 2021 Member

The "problem" is that the log_conversion table holds his own customdimension columns. Currently they are kind of synced with the visit dimension ones. If we would like to have visit and action dimensions here we would need to hold columns for both.
But actually I wonder why it holds the visit dimensions at all. Those could be determined by joining the log_visit table any time. So in theory it might make more sense to store the action dimensions here instead.
Another possibility would be to allow defining the dimensions for scope conversion...

@peterbo commented on April 15th 2021 Contributor

Great ideas, @sgiehl !! - I would vote for the scope conversion proposal. From an analytical perspective, conversion attributes are most often distinct from attribute types that are tracked for (behavioural) actions. And also from the coding perspective, this could make things a bit easier (no values would have to be kept in sync or doubled in the conversions table).

The only place where it could make sense to copy values, is an event that triggers a goal (goal setting). In this case, it would make sense to copy the action dimenions (that were attached to the triggering event) to the conversion scope custom dimension.

Powered by GitHub Issue Mirror