feat: analytics

[jim-at-stink]

Adding simple event tracking, using the shared postAnalyticsEvent() function.

Currently triggers for all of the events originally mentioned in the doc shared with @dominoweir.

• versus-banner
• hero-animation-first-capture
• hero-animation-critical-hit
• hero-animation-...
• annotation-komi
• annotation-false-eye
• annotation-...
• info-open
• info-closed
• settings-open
• settings-closed
• settings-reduce-motion-on
• settings-hero-animation-off
• settings-...-on/off
• sound-on
• sound-off
• game-over

But I know some of these are not so interesting for the Kaggle team so might be taken out, it was more to try out how the naming events would work and if simple strings for each are ok. Or if using the ability to pass in an object to postAnalyticsEvent and more structured events would be handy.

To make it easier to check if the events are triggering rather than having to watch the parent window for messages being posted , added logging that can be enabled in .env with VITE_LOG_ANALYTICS.

Just currently not sending a game property to postAnalyticsEvent, should this be go or go-v2?

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jim-at-stink]

@dominoweir Is this the kind of thing you were thinking, that we'd grab the postAnalyticsEvent from the web/core folder and use it in this kind of way? Let me know what you think!

cc: @kjsutherland

[dominoweir]

thanks, this is precisely what I was thinking!

[dominoweir]

I like this added logging- I'm guessing that dev environment variable is specific to this visualizer? if not we should consider moving this to web/core

[jim-at-stink]

We use of .env for a few things like this, from logging out the board from the game object to picking a replay file to preview with, so yep it's specific here just now.

We'd generally leave this kind of logging as a project specific thing, as we'll log just what we're sending to our trackEvent function formatting it to be easier to read in the console and omitting common stuff that's repeated across all the final tracking calls that we're not so interested in when while we're implementing and testing it.

But as the data in the tracking events are nice and simple how you've set it up having in in core would totally work too.

[dominoweir]

ah I'm guessing I forgot to export this and hence it doesn't show up as an export from @kaggle-environments/core, I can fix that real quick

[dominoweir]

oh wait it's exported- you should be able to do import { postAnalyticsEvent } from "@kaggle-environments/core" which is a bit cleaner

[jim-at-stink]

That's much nicer, my bad I should have spotted that and tidied it up. Thanks!

[dominoweir]

Just currently not sending a game property to postAnalyticsEvent, should this be go or go-v2?

I'm fine with it just being go, the basic one ofc doesn't have any logging and if we say v2 we'll have to go back and edit it later

[jim-at-stink]

I'm fine with it just being go, the basic one ofc doesn't have any logging and if we say v2 we'll have to go back and edit it later

When I log out gameName where it's being used in ReasoningLogs.tsx it's the name from where creating the ReplayAdapter.

kaggle-environments/kaggle_environments/envs/open_spiel_env/games/go/visualizer/v2/src/App.tsx

Lines 11 to 21 in 825a127

	const gameName = 'open_spiel_go';
	const ui = 'side-panel';
	const adapter = new ReplayAdapter({
	gameName,
	GameRenderer,
	ui,
	transformer,
	getStepRenderTime,
	getStepLabel,
	});
	createReplayVisualizer(element, adapter);

So our case it's currently open_spiel_go since this used to relate to the transformer to use when it was in the core stuff.

Now the transformer is in our visualizer's code I seem to be able to change this without anything breaking. I'm not sure if it's still used anywhere apart from your new postAnalyticsEvent calls in ReasoningLogs though.

Is this correct @dominoweir that we can change this without effecting anything else now?

So I'm thinking we need to make sure our tracking calls set game to the same thing as gameName in ReplayAdapter to make sure the events you've added and the visualizer specific ones I've added all end up under the same name. (1a0281f)

open_spiel_go or go?

[dominoweir]

So I'm thinking we need to make sure our tracking calls set game to the same thing as gameName in ReplayAdapter to make sure the events you've added and the visualizer specific ones I've added all end up under the same name.

Totally agree with this take- I think for sanity purposes as we scale up the number of games, having confidence that the name we should look up is the same as the name in replays will be great. open_spiel_go makes sense to me.