Today I worked on improving the queries we already have to use more display components. We used to have a “User Story” and a “Hit Story” which showed time lines of the hits the user performed and of the actions the user performed on that hit respectively. This has been changed so that we have three queries:
- “User Story” which shows a summary of information (which can be expanded in the future) about the user *as well as* a time line of the sessions the user performed in their history. A session is a group of hits on a particular device.
- “Session Story” which shows a summary of information about the session as well as a time line of the hits the user performed during that session.
- “Hit Story” which shows a summary of information about the hit, including what user agent the user’s devices had during the hit, as well as a time line of the actions the user performed on the page (clicking etc) during that hit.
Each time line item shows the id of the item it represents. This means that if a user runs one query and is particularly interested in one time line item in that query’s results, they can copy and paste the id of that time line’s item and use that to run another query (which may itself produce another time line).
For example, if they run a query on a user to see their user story, they can then use the id of the last session of the results to run a session story query, and then look at the ids of the first and last hits in those results to run hit story queries. They can find a particular user and example how their browsing behavior changes between their first and last visit. Are they getting more or less interested in the material? Were those visits longer apart (implying a regular) or were they close together (implying a disinterested user who will not return).
This is an example of the kind of behavior we’re planning to implement, making this tool flexible and extensible for the Engineering.com staff. We aim to make all of our queries “pipe” or “flow” into each other like this. We may even be able to leverage the framework to detect what types of queries the results of one query could be piped into, and make it so that the user can do this with as little effort as possible.