Wiki analytics/feedback/insights for discovery

[AnthonyMuscio]

Folks,

I have started this discussion thread to solicit ideas and support to turbo charge tiddlywikis analytics.

There are some key trends in information technology over recent decades I believe TiddlyWiki can respond to.

• The first which I think we have control of is search, rather than being forced to structure data (although you can) powerful search tools allows you to find content that was not structured to begin with. Although there are still opportunities in search consider analytics.
• An other is analytics, not just that used for SEO etc.. but analytics that is presented back to the user of a given system to tell them more about the system or their usage of that system. Such analytics presents immediate feedback or can be plotted across time and provides information about the system, in this case the Wiki, that exists already but was just not "surfaced" to the user.

Wiki analytics for discovery
Analytics information may have direct practical uses but it also allows innovation and discovery. As one builds a non-linear "database" TiddlyWiki already captures information the user may not already know from lists, references, backlinks, tag structure and more, however presently this is tiddler focused. See the Info drop down on a complex tiddler at TiddslyWiki.com. The thing is analytics can present information that emerges from the data organically.

In a recent discussion a user wanted to identify the day on which the largest number of tiddlers were created. Imagine this as a timeline graph, it would be possible to capture out of the box information such as created, modified tiddlers by date but also the increase or decrease in references, tagging, Net typing/pasting and import of content in bytes.

Analytics done the right way can also identify "behaviours" of the user, this can as a result present different types of information to inform the user or designer.

Are you persuaded?
If not I can detail some examples.

Key elements not available in tiddlywiki
The following is not a function available yet in tiddlywiki that we need to make use of to capture rich analytics.

• Regardless of when a user saves a wiki we need a logout or end session which perhaps in simple terms would clear the current user and force a new user "login"
• This same mechanism could also capture "as at" analytics into a history mechaisium for subsequent surfacing or presentation.
• Change counts and history are lost on reload, but could show activity if captured in a history.
• The navigation system is not capturing any usage ie how often a tiddler is opened interactively or programaticaly.
• Forcing user identity will be needed if we want the analytics to cope with alternate users of a wiki.
• I expect there are more...

An expected objection
I expect some of you may complain that this could cause bloat, however smart design can keep this to a minimum, such data could be saved externally. Of course this would be an optional feature.

In closing
Let you imagination run, or help us close some gaps, so we can turbocharge TiddlyWiki analytics. One day I foresee some analytics that guides a user towards maximising the information content of their data by providing feedback on the quality of relationships in their wiki not just the volume, perhaps productivity measures, user behaviours, or unsolicited discovery and innovation. As well TiddlyWiki could be a platform that contributes to computer science.

Regards
Tones

[pmario]

As you wrote, if you want to track user behaviour, you probably need to make the data publicly available for every user. For me that probably would be an incentive to allow tracking. ... Still depending on what will be tracked.

It should be simple to install a configuration like https://matomo.org/ (former Piwik) and integrate the tracking code into TW. ... The disadvantage is, that you'll need to run a server and you need to create some "Welcoming Opt-in Tracking Pages" ...

Default: Tracking is switched off, which will avoid the stupid "We use cookie dialogues"

[ght]

I understand the appeal of analytics, but I strongly suspect that I'm not the only one who neither needs nor wants this, at least not in every TiddlyWiki I create or use. So this would be perfect as a plugin, making analytics available for everyone who wants them, and not bloating Core further for anyone who doesn't.

Always keep in mind how seriously Backwards Compatibility is taken in TiddlyWiki. Adding anything to empty.html means supporting it Forever, and having a copy (or a backwards compatible new version) of it in every single wiki created ever after.

---

Also, found a small typo that had me stumble a bit when reading:

-Analytics does the right way can also
+Analytics done the right way can also

[abesamma]

I think this idea (which is great btw) needs to be fleshed out a bit more. I think there may be some compelling reasons for it. Maybe someone could build a demo to show off the benefits more clearly? What I would find compelling is native support for a social wiki: 'was this article useful' feedback widget, likes, hearts, actual social feedback that may give users a more useful way of providing feedback to public wikis than just merely relying on passive analytics, and more importantly, third party analytics. Given that native social features would be firmly under the control of the wiki owner, it would be beneficial gdpr-wise, and allow an opportunity to build communities around certain TiddlyWikis e.g. a football community running on TiddlyWiki.

…

On Tue, Jun 22, 2021, 14:07 Galdor ***@***.***> wrote: I understand the appeal of analytics, but I strongly suspect that I'm not the only one who neither needs nor wants this, at least not in every TiddlyWiki I create or use. So this would be perfect as a plugin, making analytics available for everyone who wants them, and not bloating Core further for anyone who doesn't. Always keep in mind how seriously Backwards Compatibility is taken in TiddlyWiki. Adding anything to empty.html means supporting it Forever, and having a copy (or a backwards compatible new version) of it in every single wiki created ever after. ------------------------------ Also, found a small typo that had me stumble a bit when reading: -Analytics does the right way can also+Analytics done the right way can also — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5817 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6NVYVJTX3A6RACE6U7E6TTUBVG5ANCNFSM47CULGGA> .

[AnthonyMuscio]

Folks

Do help me flesh this out a bit.

To be clear; I have always intended this to be a plugin only and whilst the term analytics is identical to website and social media analytics, these that I propose are purely for the consumption of the tiddlywiki user, the person wanting to extract information from the data in their wikis. This about monitoring ourself not others.

Tiddlywiki democratises software and internet tech to empower the user. Open source, private files you own not to support advertising or extracting information seripticiously.

A few hooks or hacks may need to be added to the core to support such features.

Tony

[pmario]

A few hooks or hacks may need to be added to the core to support such features.

I think we already have all the hooks, that are needed to track almost
everything, the user does. ...

The "change" mechanism will tell us, if content is changed programmatically and the $:/StoryList and $:/HistoryList tell us additional info, what's going on.

The difficult part will be to "only track" statistics that actually make sense for other users.

[AnthonyMuscio]

Mario,

I inadvertently used jargon, the hook. I mean that is accessible in wiki designer not wiki developer world.

Tony

[AnthonyMuscio]

Here are a list of possible sources or mechanisms such a personal analytics solution may include;

• Total Modified and Created totals graphed across dates click on a given date to see tiddlers for that date. Note subseqyenbt modifications looses dates of previous. So perhaps we need some accumulation.
• Tiddler totals as found in Control Panel > Info > Basics captured by day
• Allows graphing to include only active days or all days
• Wiki byte size trends
• Instantaneous and accumulated change counts, actually change counts against $:/StoryList and $:/HistoryList already provide an indication of activity.
• count of times opened (and from where?) per session or day
• Sessions (inc user name), sessions per day other "login" history
• ability to annotate or log against a time and date so that it is listed in future stats, one could make major changes and log the activity.
• Changes in counts of user filters eg; a count of the number of object-type(s) and instances of each object-type where object-type is a field.
• Optional tiddler content based tracking of changes as discovered in a difference comparison with prior version. Basicaly optionally used to target key content tiddlers.
• Tiddlers moved to trash
• Tiddslers deleted
• Tiddlers cloned from each tiddler eg log the clone action cloned tiddler to tiddler name if possible,

More, I am sure.
Tony

[pmario]

OK. ... Let's get all the 3-party stuff out of the way. They can't do this out of the box.

The TW server will be able to collect all this info. ... I think. ... So it would need a TW-server-side middleware plugin, that we could name "audit-plugin". Instead of "analytics" or "tracking" which have a negative association

You may also rename your thread into: "Wiki auditing for discovery"

[AnthonyMuscio]

Mario,

I can see how to do all this in the single file wiki, with a little help to Access the hooks you mention. When I refer to users I simply mean a name in the tiddler $:/status/UserName.

I am curious about the server approach and middleware idea, however I don't think it need be that for what I am asking.

Personally I would not be interested in calling it audit. The key and special idea is giving users access to Analytics about their own activity and data/information in a feedback that help uncover more about their use of their won wikis.

Since this alternative view to using the work analytics seems to have cause confusion here, we could call it "feedback metrics" or "usage monitor", or "insights". Yes "insights" sounds the best.

Tony

[pmario]

I do like "insights" ... Remove "analytics" and it will be much friendlier ;)

[AnthonyMuscio]

More thoughts;

I believe key to collecting many analytics is the need to collect information for each browser session and identify the end of session where we can role the current analytics into permanent or historical records. I imagine one or more sessions per calendar day with the ability to review states by sessions or days.

Consider this observation
Instantaneous and accumulated change counts, actually change counts against $:/StoryList and $:/HistoryList already provide an indication of activity.
If change counts can be accumulated then creating or changing any tiddler can be used to collect session activities. The same could be said if we had a similar open (to view) count mechanism (not requiring edit).

If user stats are to me collected we need a simple way to ensure users login and out of the session so sessions can map to users.

Total count of opened, modified and edited by user per session/date.

Tony

[pmario]

I personally would try to collect all of the discussed data in an anonymous way. So you don't get any privacy related problems.

If you need a personal relation, it needs to be "opt-in" from the user side. ... AND the users personal data has to be encrypted "at rest". I would consider this a minimum-requirement

[AnthonyMuscio]

Mario

I agree with your approach in general but the analytics I am talking about are for personal feedback only. It's not for someone else to harvest. For example if you look at the recent tiddlers tab in reflects activity in the wiki in a similar way to what I want to do. Most use cases would be for personal wikis and knowledge engineering. These analytics would be nothing that the user does not do themself in the scope of the wiki. As you know tiddlywiki allows users to own there own content and that dose not change, if you do not save to a host no one sees it. If it's multiuser in a team only the team sees it.

Tony

[pmario]

OK, but if it is for a single file wiki, I'd call it bloat. You need to record a lot of "timeline" data. That would be needed to be saved with the wiki. It may be compressed, when the wiki is loaded, but that would slow down the loading time of the wiki ...

There is a reason, why $:/HistoryList is not saved with the wiki.

In the early days we did have a lot of problems with wikis that had a 100 hundred content tiddlers and a size of 10MByte.

It would be possible to use the browser local-storage to "collect and process" the data that you mentioned.

But for me to make sense, every "value" that is created would need a reason, why it should be measured. ... "Because we can" is not a reason why we should record how many characters "e" I did type in the last browser session.

Values that should be measured, need to have the possibility to tell us something new.

It probably would be interesting to know, when I did delete the tiddler "Some valuable content". But without proper backups it would only hurt ;)

I can tell you with 100% certainty there will be "New Tiddler", "New Tiddler 1" ... "New Tiddler x" in my "deleted" list, in 99% of every session.
I can also tell you that this metrics is the same with my usage of tiddlywiki.com and tiddlywiki.com/prerelease ... So I don't see a reason to collect this information, that I already know.

[pmario]

... AND the users personal data has to be encrypted "at rest". I would consider this a minimum-requirement ...

I agree with your approach in general but the analytics I am talking about are for personal feedback only. It's not for someone else to harvest. For example if you look at the recent tiddlers tab in reflects activity in the wiki in a similar way to what I want to do. Most use cases would be for personal wikis and knowledge engineering. These analytics would be nothing that the user does not do themself in the scope of the wiki. As you know tiddlywiki allows users to own there own content and that dose not change, if you do not save to a host no one sees it. If it's multiuser in a team only the team sees it.

You are right ... But in combination with:

Optional tiddler content based tracking of changes as discovered in a difference comparison with prior version. Basicaly optionally used to target key content tiddlers.

It can be problematic in a not so obvious way. ... We did have a similar discussion with TiddlySpace "private" and "public" spaces. TS had tiddler versioning built in. So it was possible to see "older" versions of a tiddler. --- This is similar to tracking differences in tiddler content.

... The proposal was, If a tiddler was switched from "private" to "public" space it should be transferred including the full history. ... This seems reasonable BUT All the "private" content can be considered to be a "draft of public". The same is true for tiddler content, that is "in the flux". ... It is changed several times until it reaches the "final" status which is presentable.

The "private/draft" content could contain sentences like "Mario is privacy paranoiac, he wants to encrypt content, that is for my eyes only." ... The final content would "hopefully" look more like this """Mario has privacy concerns about "historic" data. We may consider the possibility to encrypt "insight" data """ ...

You may say it doesn't matter. The history data is for your eyes only and "Mario" won't ever see it. ... But what if you get interviewed and you screenshare the cool "insight" feature about historic tiddler data. ... Mario may see this ;) ... I think you know, what I want to say.

The other reason for "insight" data to be encrypted is, if the wiki itself is already encrypted. .. In this case the whole "local-storage" or "index-db" storage has to be encrypted "at rest".