[ Request for feedback ] Things you want to know when a player joins?

Developers
1

Hi there,

I’m taking on more developer relations work lately, and I want to hear from you what things that are missing when a player joins that you would like to know. So far, I have

  1. The user’s language
  2. Whether they joined with a spawn token

Anything else you want to add? I’d like to do it in one pass if possible.

2

I was also interested in the ability to read any additional props from the URL when the player joins. This could include specific props, like spawn tokens, but maybe also custom ones that are sent, as it would allow for more flexible development.

A specific one that I would like to see is something like ?origin=DATA , so we can track where users are coming from, be it links from multiple sites, or portals from multiple servers.

Thanks!

1 Like
3

Not exactly sure what the best solution is, but related to the spawn token, it would be nice to know if the player has been in this space before and is being spawned into the last location they logged out versus being spawned the default spawn point in the default room.

4

Just wanted to add some things that I think would be helpful. Not sure everything here is even possible, but it would be interesting to capture this info on join to help with troubleshooting if players have any issues. :grinning:

  1. Desktop or Mobile
  2. Browser
  3. Latency
  4. CPU Usage
  5. IP Location Region (for global event participant stats)
  6. New vs Previous join (agree with Julian on this)
  7. Date of last login on Gather

Thanks!

5

A few other things I would love to see ( including the above )

• If participant is anon or not
• Length of time they remain in the Space

6

These are all helpful to know! Some of these we will almost definitely not be able to include unfortunately because of privacy & compliance - but I will include as much as I can. @Shawn , to handle this case, I would recommend just subscribing to playerJoins & playerExits, and recording on your extension the amount of time it took between those two events.

1 Like
7

That’s a great way to track that. Good idea Opal.

8

Each player does have an ‘isLoggedIn’ property, which should tell you if they are anon or not. I use that for discarding player ids which will not likely revisit.

1 Like
9

I’m caught between two stools on this, by default not having any tracking is crucial for some German works councils that no behavioural control can be exercised with Gather.Town. This would be the case with tracking of e.g. usage time and similiar…

On the other hand, as a social scientist, I would love to be able to study the behaviour of the users in order to be able to adapt the offer if necessary. So far, I have had to make my observations, analyses and evaluations on a qualitative level. So interviews and field observations.