Skip to content
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

Add trackings for polls #85

Merged
merged 10 commits into from
Sep 12, 2023
Merged

Add trackings for polls #85

merged 10 commits into from
Sep 12, 2023

Conversation

julioromano
Copy link
Contributor

@julioromano julioromano commented Aug 25, 2023

  • ADDS: analytics for polls
  • BREAKING: refactors Composer analytics by condensing several message type boolean properties into a single "messageType" enum. This is a breaking change.

Closes element-hq/element-meta#2014

@julioromano julioromano changed the title [WIP] Add tracking for polls Add trackings for polls Aug 28, 2023
@julioromano julioromano marked this pull request as ready for review August 28, 2023 12:06
@julioromano julioromano requested a review from a team as a code owner August 28, 2023 12:06
Comment on lines 12 to 14
"numberOfAnswers": {
"description": "Number of answers in the poll.",
"type": "integer"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me "option" would be a better naming. To me an "answer" is picking a specific option.

Copy link
Contributor Author

@julioromano julioromano Aug 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the matrix spec it is called "answer". In the UI it is called "option". Not sure what nomenclature the analytics usually follow.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idk, staying aligned with the spec LGTM anyway 👍🏻

"eventName": {
"enum": ["PollStarted"]
},
"isAnonymous": {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the disclosed/undisclosed things? Votes are never anonymous. 🤔

Copy link
Contributor Author

@julioromano julioromano Aug 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the matrix spec it is called "disclosed"/"undisclosed". In the UI it is called "anonymous" true/false. Not sure what nomenclature the analytics usually follow.

BTW it is not the votes that are anonymous, it is the poll.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @alfogrillo wants to point out that the votes can be seen, so even if the UI does not tell who has chosen which option, it's not hard to see that information by inspecting content of (hidden) events in the timeline.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is well known within the team.
Design/Product decided to use anonymous in the user visible copy though.
I don't know if analytics tend to follow the product wording or than the Matrix Spec wording. Do you have any guidance on this?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be consistent in deciding which naming convention we want to use.
To me using the spec one is more robust, since copies in the UI can change much more easily.

schemas/Composer.json Outdated Show resolved Hide resolved
@@ -64,7 +64,8 @@
{"const": "Invites", "description": "Room accessed via space bottom sheet list."},
{"const": "CreateSpace", "description": "The screen shown to create a new space."},
{"const": "LocationSend", "description": "The screen shown to share location."},
{"const": "LocationView", "description": "The screen shown to view a shared location."}
{"const": "LocationView", "description": "The screen shown to view a shared location."},
{"const": "CreatePollView", "description": "The screen shown to create or edit a poll."}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a remark: don't we want to do the diff between creating and editing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes thanks, initially only poll creation will make the cut so a EditPollView will be added later.

"eventName": {
"enum": ["PollStarted"]
},
"isAnonymous": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @alfogrillo wants to point out that the votes can be seen, so even if the UI does not tell who has chosen which option, it's not hard to see that information by inspecting content of (hidden) events in the timeline.

Copy link
Member

@pixlwave pixlwave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, this is nice to see polls included in the analytics 🗳️

  • I wonder, do we really need poll created/edited/ended as 3 events? The guidelines suggest fewer events are better. We could e.g. have a PollManagement event with an action enum of Created, Edited, Ended.
  • The PR needs to include the generated files too, please run yarn and commit these :)

@@ -25,6 +25,10 @@
"description": "Whether this message it's a shared location.",
"type": "boolean"
},
"isPoll": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this property provide any value given there's a dedicated event for starting a poll?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked the same but @VolkerJunginger said they want the composer event as well, I'll post his answer here:

No, it is not redundant from an analytics point of view.
We need the composer Event to count "no of messages send" overall.
We need the poll event to get data for the poll

Copy link
Member

@pixlwave pixlwave Aug 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that makes sense, thinking out loud here: it feels like we're doing it wrong in that case. having isPoll, locationType as separate properties isn't very scalable. Because it sounds like we also want an isImage, isVideo etc if we want all messages sent.

Perhaps we should have a messageType enum here with initially, Text, Poll, LocationPin and LocationUser and then in the future this could be expanded to include other types of message content?

@VolkerJunginger does that sound reasonable to you (and would you have an issue if this caused any old events with the locationType property to be misaligned)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given what's been discussed in the analytics room I'll change this as suggested. Though it'll have to wait for me to be back from vacation (~1week).

Co-authored-by: Benoit Marty <[email protected]>
@julioromano
Copy link
Contributor Author

  • I wonder, do we really need poll created/edited/ended as 3 events? The guidelines suggest fewer events are better. We could e.g. have a PollManagement event with an action enum of Created, Edited, Ended.

@langleyd suggested to mimic the existing Call{Ended|Started} events. But if there are better ways I'm open to them.

Thing is the properties are not the same among the three events, so if we merge them into one most of the props won't be able to be "required" anymore, maybe this could be a problem data wise.

@julioromano
Copy link
Contributor Author

Included output of yarn build

@pixlwave
Copy link
Member

Included output of yarn build

I don't see any output in the swift or kotlin2 directories here? Possibly a python/poetry config issue?

@pixlwave
Copy link
Member

Thing is the properties are not the same among the three events, so if we merge them into one most of the props won't be able to be "required" anymore, maybe this could be a problem data wise.

Ok fair, I missed that PollEnded wasn't the same here.

Thought: if we're interesting is knowing e.g. the average number of answers/options in a poll, perhaps having those on ended would be useful anyway? E.g. You can't use the number from PollStart because it could be edited, and you can't correlate PollStart to PollEdited events. Whereas if you took the number from PollEnded you know that is correct. Same could be said for the isAnonymous property if that's editable in the spec.

@julioromano
Copy link
Contributor Author

A few changes for the better:

  • Separate MobileScreens have been added for create/edit.
  • PollCreated/PollEdited have been merged and renamed into PollCreation (they are very similar so one single event could cover both).
  • PollEnded -> PollEnd
  • PollAnswered -> PollVote (in the spec "answer" refers to the options of the poll, not to the act of voting. That is called "response" in the spec but it can be confused with "replying" so I opted to use "vote" which is also a term frequently used in the spec.)
  • isAnonymous -> isUndisclosed (to stick with spec terminology)

julioromano pushed a commit to element-hq/element-x-android that referenced this pull request Aug 29, 2023
NB: This is missing analytics, which will be added once matrix-org/matrix-analytics-events#85 is merged.

Closes element-hq/element-meta#2011
@julioromano
Copy link
Contributor Author

Since the python script will produce wrong code when there are 0 properties other than the event name, I had to add some dummy props to work around it. It would be great to fix the script instead but we're rushing for a release so there won't be enough time.

@julioromano
Copy link
Contributor Author

@pixlwave here's the proposed changes following your suggestion at: https://github.com/matrix-org/matrix-analytics-events/pull/85/files#r1311509508

I'm not sure whether startsThread should also be among the required properties. What do you think?

Copy link

@alfogrillo alfogrillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

"eventName": {
"enum": ["PollEnd"]
},
"doNotUse": {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be removed before we merge?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See: #85 (comment)
We can merge it and then remove this once the script that generates the Kotlin code is fixed.

"eventName": {
"enum": ["PollVote"]
},
"doNotUse": {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be removed before we merge?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto as above.

Copy link
Member

@pixlwave pixlwave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this looks cleaner to me now with the message type property 🙏

@pixlwave
Copy link
Member

I'm not sure whether startsThread should also be among the required properties. What do you think?

Given we don't support threads in the context of EX, I wouldn't worry about it here.

@julioromano julioromano merged commit e9cd9ad into main Sep 12, 2023
3 checks passed
@julioromano julioromano deleted the julioromano/polls branch September 12, 2023 09:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Tech task] Polls Analytics
4 participants