Ability to track individual events about shynet HOT 12 OPEN

This is really a very useful thing.
My suggestion is to have client API like ga has https://developers.google.com/analytics/devguides/collection/analyticsjs/events
But this needs really complicated interface

shynet.sendEvent(category, action, label?, value?)
/*
Also, track the page location of the event
*/

Or to simplify tracking just track an event name

shynet.sendEvent('button:clicked') 

And just show all events in a table like all other numbers currently

from shynet.

This is the sort of thing that we should support, even though it’s unclear to me what the interface would look like. I’m going to put this on the roadmap for v1.0.

from shynet.

Hi folks. I also think this is a super interesting feature.

I'd just like to put my two cents in the requirements perspective here.

We currently use category/event tracking mostly to add debug info to some important "money paths". Something like: User completes first page of wizard, second page, payment complete. vs. payment incomplete but why?

That said it is

1. nice to be able to "deep dive" into a user's journey instead of counting events, only (I am not saying you should provide an UI for this in the first shot but maybe it is something to think about in terms of data architecture)
2. sometimes it an event can carry some value it is good to be able to sent string (something meaningfull ;) , too)

Anyways, it is just my two cents and - of course - your decision :). Keep up the good work!

from shynet.

This is a great idea. Having some form of API to increment hits or send data in this regard would be great.

It would be nice to be able to track, for example, command usage in a Discord bot by sending an event to the API stating to increment a certain counter.

E.g.:

• Help command: 20 hits
• Meme command: 5 hits
• Invite command: 53 hits

And then be able to see usage graphs for them.

Just my input though. It's a great piece of software as it stands. Keep up the great work!

from shynet.

This is a very big feature. It may be too much for one person to contribute (There was one attempt already).
It will be a good idea to split scope into smaller parts. Maybe add a separate feature branch?
For example:

1. Extend Hit model. Adjust ingress_request() and Service.get_core_stats()
2. Extend JS tracker.
3. Add API endpoint.
4. Extend dashboard (It can be split too probably)

That way every aspect can be discussed separately and implemented by different person.

from shynet.

I opt for a simple tracking with event category, name and value, like

shynet.sendEvent(category, name, value = 1)

and show it in a table, where you can filter by event name / category:

+--------------------------+
| filter input             |
+--------------------------+

+--------------------------+--------------------------+
| button:clicked           |      registerButton (13) |
| button:clicked           |           moreButton (8) |
| button:clicked           |           lessButton (8) |
+--------------------------+--------------------------+

It'd be nice to show the sum, sum by value and timeline views

• sum view would sum all of the values of events with same name and category (if the values are numbers, when values are strings, it'd add 1 for each such event)
• sum by value view would add a third column to the table and show how many times particular value occured

from shynet.

I have similar needs to @tmerten - be able to see what an individual user did in a session. I was thinking it could fit in nicely with the existing session design. I made a mockup of how it could work.

Design notes

• I kept the header largely the same, I just changed the session duration to use the same format as the events table
• I think Shynet should reverse the order of time / page visits. Have the first hit at the top of the page, and the last one at the end, so I can read the "story" of the session from top to bottom.
• I personally don't find the load time and tracker useful so I left those out, but I wouldn't be surprised if others find the load time at least useful. If I put them in this design, they would go as small, grey, supplementary text in the top-right of the white boxes.
• I omitted the "via {{url}}" part - in my sites it's always the previous hit. If I added that into this design, I'd do it the way Shynet does it today - small, grey, supplementary text underneath the url.
• The "Time to event" is the amount of time that elapsed before the event occurred. I like it this way because it is explicit about the duration (I don't have to do the maths to work it out) and it lets me ponder what they might be doing during that time.
• I wasn't too sure about the event data to record, but I think I'd like the event, a bit more about the event (I called it sub-type here), and then extra stuff attached to the event. All information would be user (programmer) definable. It's just some broad types the user could use to add structure to the data.
• The third hit in this mockup is show that when there are no events, no table is displayed.

Other

I think the other need people referred to in this issue - being able to see aggregated counts of events - fits in with the general theme of the service dashboard, but would probably need its own page to have enough room for interactive controls.

from shynet.

This is neat — curious about the decision to fundamentally nest all events under page views. Are there any contexts in which you wouldn't want an event to be associated with a page view? And are there places in the interface where you'd want to run analytics independently (e.g., running analyses on all the share project actions)?

from shynet.

This is neat — curious about the decision to fundamentally nest all events under page views.

I wanted to see if I could include events in Shynet without changing too much of the existing design. Nesting the events under page views means that, if a service doesn't use events, it will look like Shynet does today, which I thought was nice.

I originally saw it as a compromise between user needs and build effort but after thinking about it some more, I quite liked it. It gives context to the events - almost like a namespace.

Are there any contexts in which you wouldn't want an event to be associated with a page view?

I see this page in Shynet (both the design above and the current Shynet design) as a session history, and I think anchoring everything to page views is a good way to present that info to the user. If there are other events occurring that aren't page view related, they're not part of the session - they're something else (I think).

And are there places in the interface where you'd want to run analytics independently (e.g., running analyses on all the share project actions)?

I haven't had a need for this personally, but I can see that lots of the other comments in this thread would like something like that. I think if there were non-session (non-pageview) events, this would be the place to show those.

I'll do some mockups this week of what it could look like.

from shynet.

I explored some designs for showing events in a view that isn't a based on sessions as per above ☝️

Without knowing what the most valuable views of event data are, the designs ended up turning into a graphical SQL querying tool. Which in hindsight, is unsurprising 😆. Here's an example wireframe.

I didn't pursue this avenue further as, while I'm guessing the standard querying options presented as a table wouldn't take a lot to implement, the next feature people would want is the ability to save particular views (combinations of the filters and columns etc) - aka reports. And then there needs to be a way to manage reports - select from a list to view, update, delete, maybe permissions 🤷.

As an alternative, Shynet could just include a tile or two of tiny reports on the main page for a service - which fits in well with the current design.

Here's a mockup of what that could look like. Note: only the bottom tile is new, the others are just there for context 😄.

It seems like this would cover off most of the comments in this Github Issue.

from shynet.

I made a couple of updates to the session-based view design while I was at it.

Changes from previous version:

• I put the time to load and tracker type in the top-right of each hit block (the big white blocks).
• I removed the domain name from the hit URLs - except for the last hit block (the sistersite.com one). What I'm wondering here is if we can reduce noise in the UI by showing just the pathname when the service has a Link set (the service's primary URL - on the Manage page) and the hit URL matches that Link. For example, in this mockup, all the hits are for example.com, except for the last hit which is for sistersite.com. Because sistersite.com doesn't match the Link, the full URL is displayed.
• In similar logic, I wondered if the UI could show the via URL only when that URL is something other than the URL of the previous hit. So when the user is reading through the session, they can assume the hits URLs are the URLs the user went to in order, and the via URL only shows up to tell them when that assumption isn't true.
• Renamed columns to "Event", "Name", and "Value". I don't have a strong opinion on the names of the event attributes (e.g. could be event, event name, event type, subtype, category, notes, details, data, extra, value, etc). Calling the first two attributes "Event" and "Name" works well for the tile on the main page in my previous comment though, as it's a bit more obvious what the data is, given that those tiles don't have headings to give context to the data.

from shynet.

I was thinking about this feature lately. The biggest problem is extending Hit model because it affects whole project.
It requires changes in many places. There is a high risk of introducing serious bugs.
Implementing it as a separate module with separate db model may be easier and safer.
It could be added behind feature flag in settings.
This way we could keep regular users out of potential bugs until feature becomes mature.

DB model could look like:

class Event(models.Model):
    service = models.ForeignKey(
        Service, on_delete=models.CASCADE, db_index=True, verbose_name=_("Service")
    )
    session = models.ForeignKey(
        Session, on_delete=models.CASCADE, db_index=True, verbose_name=_("Session")
    )
    source = models.TextField(verbose_name=_("Source"), blank=False, db_index=True)
    action = models.TextField(verbose_name=_("Action"), blank=False, db_index=True)
    group = models.TextField(verbose_name=_("Group"), blank=False, db_index=True)
    debug = models.BooleanField(verbose_name=_("Debug"), default=False)
    identifier = models.TextField(
        blank=True, db_index=True, verbose_name=_("Identifier")
    )
    count = models.IntegerField(verbose_name=_("Count"), default=1)
    time = models.DateTimeField(
        verbose_name=_("Time"), default=timezone.now, db_index=True
    )
    data = models.JSONField(verbose_name=_("Data"))

    class Meta:
        verbose_name = _("Event")
        verbose_name_plural = _("Events")
        ordering = ["-time"]

from shynet.