aws-analytics
aws-analytics copied to clipboard
Analytics module events to track in Altis
Related issue https://github.com/humanmade/altis-accelerate/issues/122
@roborourke I have this ready for review when you have a gap.
- I haven't tested this sending to Segment yet, I am still to do that. Should I send to the main Segment account we all are using or should I setup a free personal account for testing?
- I setup translations for the values, should I have left that untranslated?
I managed to get this hooked up to Segment with a free account to do some initial tests. So far everything looks pretty good.
I noticed a minor discrepancy in some places the date ranges have different "values". Two examples below:
analytics.track('filter', {
filter_type: 'date range',
filter_value: '90 Days',
location: 'dashboard'
});
&
analytics.track('filter', {
filter_type: 'date range',
filter_value: 90,
location: 'insights'
});
Should I work on that when ever it's a date range it will always be the number
and include "days" ?
Check the guidance again if you need to, details for the test account to use are documented there:
https://github.com/humanmade/product-dev/blob/master/docs/tracking-and-telemetry.md
Ideally we should have standardised those values so if you can do that as part of this work it'd be super helpful. We should probably normalise the date range values to allow other values in future too. I'm thinking:
-
7_days
-
30_days
-
90_days
Also for the filter_type
if the <select>
(or other input type) has a name
attribute use that for the value - should be date_range
in this case I think - note the underscore there.
Hey @roborourke
Thanks for the suggestions and direction. I have pushed changes now.
analytics.track(
__( 'filter', 'altis-analytics' ),
{
location: __( 'dashboard', 'altis-analytics' ),
filter_type: __( 'author', 'altis-analytics' ),
filter_value: e.target.options[e.target.options.selectedIndex].text,
}
);
In the above example the select hasn't got a name attribute. So would the structure and names/labels be appropriate?
In the above example the select hasn't got a name attribute. So would the structure and names/labels be appropriate?
Are you referring to the code example? Then yeah, although the values should not be translatable. That would make querying in Mixpanel near impossible!
Thanks @roborourke, would it be better if I didn't translate all the items sent to Segment? Or should I use it more sparingly?
Thanks @roborourke, would it be better if I didn't translate all the items sent to Segment? Or should I use it more sparingly?
For sending data to segment we shouldn’t use translation at all. We could end up with different values for the same thing
@roborourke When you get a gap, I have gone through your previous review and pushed up the relevant changes.
I have added a comment on the changes for the DateRange
with 2 questions around the structure.
Lastly the values used for the Author
filtering , I'm not sure what/if we want to action anything further?
Something seems a little strange here, there are unrelated changes from another PR. What was the reason for force pushing?
Something seems a little strange here, there are unrelated changes from another PR. What was the reason for force pushing?
aaah! I had conflicts with master, ran a merge and had all the commits come through and a lot of unrelated changes. I managed to undo the merge and then got the branch back to the Update for WIP. commit. I was then trying to get the branch back to that commit before trying the merge again.
We have the basics of the tracking here from the new updated dashboard so we're changing the purpose of this issue a bit to normalise the API endpoints - to that end I'll remove it from the beta release milestone as it's not a hard requirement for now.
Lets put this on hold for now until I've written up a proper spec for how everything should work in terms of the API endpoints.