Track user's activity per application

The only way I could really see this happening is if you had some form of logging message that was sent to the backend logs on basically every interface of the system that sent info including timestamp and results of the loggedInUser() function every 30 seconds.  You could find when a user stopped looking at an interface by when the messages had a different interfaceId coming in, and you'd know when the user logged off or started looking at their own profile or something by when the messages stopped coming in altogether.  Then you would also log every key interaction in the system, possibly writing to the log table in addition whenever you write to some other table.  That handles item 3, which in all practical terms is probably the most you really want.

At the end of the day, the most important question you can ask is "Why?"  Why do they need to log this much?  Why do they need to know the moment the user logs in and exactly how long they look at each page?  The logs are going to get exceedingly enormous, and all that logging in a continual basis is going to be a huge performance drain on the system.  It's going to be a huge drain on whatever tries to scan those logs.  When you have too much data, you can't see the patterns in it anymore.  It also shows an alarming lack of trust that could alienate employees and prevent adoption of the system.  I wouldn't want to use an app that nannied me so much.

It requires really sincere sober judgement to say, "What do we really need?" Try do explain the concerns and costs associated with that much surveillance.  Try to help your customer see the exact level of logging that should be built.

It is possible to collect productivity timelines, such as how much time workers spend reviewing loan applications. However, it will require additional development at every application/feature level. You can logically capture task start and end timestamps per activity/feature. Still, Appian doesn't support native time tracking features like Hubspot or google tag manager (form, section, action level tracking). 

You can build a standard utility to capture productivity milestones & use it across applications based on requirements.

Appian also captures users' session metadata, and you may use the Log Reader plugin to extract login activities for audit purposes. 

With reference to your specific questions:

1. Track their login/logout timestamp per application per user

Logins are logged by Appian to the 'login-audit.csv' log. 

There is no logout event recorded. Note that users' sessions can automatically timeout (which is different from them actively logging out) so it depends on what you're aiming to measure/report on

2. Track their time spent on viewing each interface per user per application

3. Track their action performed inside the application (clicking button, submitting the form, user input task etc.)

For both 2. and 3. you would have to build a custom framework to write the necessary "events" for those user interfaces that a user is presented in the context of a process model i.e. write an event when they enter a User Input Task (UIT) and write another when they exit. Also note that UITs can be configured to exit automatically after, say, a given timeframe so you'd have to catch those as well. You would also have to attach writing events to each component e.g. button-clicked. Note that for all such events you'd need some form of correlation token so you can weave the events together as part of a single user's journey through a business process.

There are other classes of User Interface that are not part of a process e.g. Record views. There is no programmatic way to capture events for when a specific record is accessed, but Appian does record these to the ' records_usage.csv'. What you won't have is a correlation token to join the event of a user accessing a record and a specific instance of any action taken on that record. You would have to infer such by using any date/time values recorded in your custom events.

I would also echo comment regarding "What do we really need?" before diving into designing./building based upon the "requirements" expressed.