If we really want to figure which instances to suggest, it could maybe be good to have some additional statistics tracked per instance, and compare to the global averages. It might even be able to influence default choices for like the join-lemmy website.

I understand this might sound gross, but maybe there’s a good idea in here?

  • user retention (percentage of users that are still active after 6 months? 1 month?)
  • percentage of anonymous visits that result in a signup (ignore those that result in a login)
  • ban rate
  • signup acceptance/rejection speed
  • percentage of accepted signups vs failed/declined (maybe this just promotes accepting spammers)
  • average time spent on signup page
  • bounce rate of signup page (opened but never completed)
  • Nutomic@lemmy.mlEnglish
    6·
    4 days ago
    • user retention (percentage of users that are still active after 6 months? 1 month?)
    • ban rate
    • percentage of accepted signups vs failed/declined (maybe this just promotes accepting spammers)

    These wouldnt be hard to add as we already have the data. Its not relevant for normal usage of the site, so it could be a new endpoint /api/v4/statistics. Feel free to open an issue.

    • signup acceptance/rejection speed

    Already being added: https://github.com/LemmyNet/lemmy/pull/6126

    • percentage of anonymous visits that result in a signup (ignore those that result in a login)
    • average time spent on signup page
    • bounce rate of signup page (opened but never completed)

    These are more difficult as it would require new frontend logic to collect the data, then send it to the backend and have more changes to store it in the db. Not worth the effort in my opinion, but you can also mention it in the issue.

  • asudox@lemmy.asudox.devEnglish
    2·
    4 days ago

    Not everything, but some might be possible with plugins. Lemmy v1.0.0 will have some sort of plugin system and afaik Piefed already has them.

    • Nutomic@lemmy.mlEnglish
      2·
      4 days ago

      Plugins mainly have hooks which are called when a new post is created, a comment is updated or things like that. Giving plugins access to everything in the database is more complicated. We could let plugins execute SQL and get the results, but that has security risks.

      • asudox@lemmy.asudox.devEnglish
        1·
        4 days ago

        Instead of letting plugins execute raw SQL, why not expose certain functions like ones for crud operations on db models?

        • Nutomic@lemmy.mlEnglish
          2·
          2 days ago

          That wouldnt be enough to get the kind of statistics mentioned in this post.

  • Auster@thebrainbin.org
    1·
    4 days ago

    Only instance I think you’d find such things is Threads and only if you work there. Also, it sounds rather telescreen-ish, so I would think this depth of info can’t be found here.

    Personally, I’d recommend based on features, the instance’s scope, monthly active users (that is usually tracked by fediverse database sites), and the experiences with a given instance’s community.