feat: add next_log_created_at to analytics_log to allow time tracking per card

[Mike-Heneghan]

What:

• Catch when a component is transitioned and a new analytics_log record is created.
• Store the created_at of this against newLogCreatedAt
• Use the lastAnalyticsLog to mutate the last log with the new newLogCreatedAtstored against the new next_log_created_at column.

Why:

• We want to be able to track how long users spend on each card
• When querying we can compare the difference between created_at and next_log_created_at to have a number for how long was take on the card in the context of a user in a session.
• Allow null to show that user's don't always proceed in the flow and might "resume" later kicking off a new session.

Rationale:

• Is this a logical way to store this information

  • Shares the same format as existing data
  • Based on the system time which avoid conversion issues
  • I believe it will be easy to interrogate the data with SQL.
  • Also, nullable as sometimes there is no time spent on cards and there's not guarantee another log will be added in the session hence the field remains null.

• Is it actually representative of how long was spent on a card

  • Yes as it's scoped to a session

• How do we handle auto answer questions which create instances of analytics_logs but aren't even shown to the user.

  • I don't think we do need to handle this as card which effectively have no time on them can be filtered out of the query.

  Screen Recording:

Screen.Recording.2023-10-17.at.15.01.17.mov

[Mike-Heneghan]

How do we handle auto answer questions which create instances of analytics_logs but aren't even shown to the user?

On this point I don't think it's necessarily a problem that we still create records for components which the user doesn't actually see and in these cases the next_log_created_at is null as the time spend should effectively be 0s.

I do wonder whether it would be worth adding an auto_answered flag to these analytics_log instances? It definitely took me a while to figure out what was happening in these circumstances although this could be more related to familiarity with the codebase.

[github-actions]

🤖 Hasura Change Summary compared a subset of table metadata including permissions:

Updated Tables (1)

• public.analytics_logs permissions:

  	insert	select	update	delete
  public		➕/➖	➕/➖

  2 added column permissions

  	insert	select	update
  public		➕ created_at	➕ next_log_created_at

[Mike-Heneghan]

In the course of this ticket noticed a warning around in the console around setting state:

[Mike-Heneghan]

Another warning:

[github-actions]

Removed vultr server and associated DNS entries

[Mike-Heneghan]

Track time spent on each card

[DafyddLlyr]

Looking good 👌 I think we covered most of this yesterday - nothing more to add!