-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: track the answers to allow_list questions in analytics_logs #2487
Conversation
🤖 Hasura Change Summary compared a subset of table metadata including permissions: Updated Tables (1)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solution is looking good to me, but I am getting some unexpected results when going through a flow in the analytics_logs
table on this pizza that I want to flag:
What was happening (db rows here):
- The first row for
proposal.projectType
is right - But then my answer is incorrectly recorded for two Set Values with un-allow-listed fns of
proposal.droppedKerbOnly
&proposal.treeWorksOnly
(is it possible to make mutation param check stricter to ensure it only writes answers for allow-listed fns?) - Then I hit a follow-up, more granular project type question "Select all the works to replace windows or doors" that correctly records answer
["alter.replace.windowsToWindows"]
- There's also a number of duplicates (maybe writing on component renders or user interactions within the card rather that whole-card transition??) - I realise this may not be introduced here and a wider caveat of analytics tracking / happy for it to be thought about in a separate PR
As for the larger question in your description about currently only working on "forward" and whether we should track on "back":
- My high-level opinion about this would be that we should try to track allow-list answers as similarly as possible to other interactions like "help click" & "input errors" - so if those are tracked on back, then let's try to track answer changes on back too. Helps keep the "explainability" of analytics methodology more straightforward for external consumers in the long run!
...rations/1700845956731_alter_table_public_analytics_logs_add_column_allow_list_answers/up.sql
Show resolved
Hide resolved
- As per #2487 (comment)
6028404
to
1a06af7
Compare
I'm struggling to replicate the issue 🤔 Looking at the analytics it seems like you were using the If the flow you tested with is available would you mind sharing a link to it? |
@Mike-Heneghan I was using Lambeth's FOI on the pizza (FOI flows outside of active council teams likely don't have maintained content) - I'm almost always the only Linux user in pizza logs 🐧 The project type checklist and set values are nested in the |
Thanks @jessicamcinchak! That's really helpful, I imagine the issue is that I wasn't testing auto-answer questions which will completed really quickly and are more susceptible to this issue! I'll use the lambeth foi to have something a bit more representative to the real behaviour. |
- The passport variable of a node is on either the `fn` or `val` optional attribute - It can be useful going forward for this data to be stored - Node title might change but the passport variable might not allowing us to better compare trends if rewording for example - Added a new column to the analytics_log of node_fn to store this value
analytics_logs - Add new column on the analytics_logs to store allow_list_answers in an array - On component transition check if the previous node was an allow list question - If allow list then update the previous log with the answer - This relies on previousCard function which is computationally expensive - This can cause itiming ssues where allowList answer of previous node stored in a log
- The function previousCard is computationally expensive - Rather than repeatedly call previousCard instead store what the node was in state on component transistion
- As per #2487 (comment)
- Resolves: #2487 (review) - If there's a timing issue avoid storing sensitive data by verifying db node_fn in allowlist - When finding answers remove null values - Note: doesn't resolve edge case that subsequent questions with node_fn may be updated with prevous questions answer
1a06af7
to
80512c9
Compare
const { data } = flow[nodeId]; | ||
const nodeFn = data?.fn || data?.val; | ||
if (nodeFn && allowList.includes(nodeFn)) { | ||
const answerIds = breadcrumbs[nodeId]?.answers; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the reason this doesn't work going backwards is that the current approach has an assumption that we always want to update the analytics log for the previous node with the answer which is stored in the current breadcrumbs.
When we move backwards through a flow the breadcrumbs are removed and the answers for the question go with them.
We could track what the saved answers were when a user loads a node they've already answered in the analytics logs.
Although I'd be tempted not to and only track allow_list answers when a user explicitly hits continue. I think this might be more consistent with the broad approach to user's answers?
What:
Passport variable tracking:
fn
orval
of anode
node_fn
on theanalytics_logs
Answers to allow_list question tracking:
node
fn
orval
is in the allow list and if so update the log with the user's answerWhy:
node_title
andnode_type
.fn
orval
if they're assignednode_title
code change but we could easily continue to track via the passport variable which is unlikely to changeallow_list
Screen recoding
Screen.Recording.2023-11-28.at.12.21.48.mov
Note
proposal.projectType
that wouldn't be stored on the analytics_log which was generated on hittingBack