Editorial illustration: An installation ID is not a player name

An installation ID is not a player name

The problem I needed to solve

A player name serves personalization, while an analytics ID connects events. I did not want changing a display name to turn installation history into a new user.

Implementation in this snapshot

AnalyticsIdentity.GetOrCreateUserId creates a local GUID and keeps it in PlayerPrefs. GetOrIncrementSessionNumber advances session numbering; ShouldSendFirstOpen and MarkFirstOpenSent track the first opening.

The design decision and its cost

This contract is independent of the name string. The transport can also accept an existing ID, allowing one identity source to feed multiple events.

Current boundaries

Cleared data or reinstallation can create a fresh ID. This is not an authenticated account, a verified person’s identity or a cross-device identifier.

Review scenarios and contract meaning

On the PHP side, a session key combines player_id and session_id. This prevents aggregation from merging matching session identifiers belonging to different players. A session start comes from app_open or session_start and its end from session_end. Without valid start and end observations, duration remains unknown; the gap between first and last events should not be substituted for a complete session. Identity and lifecycle definitions therefore directly shape report numbers. The player count here counts observed identifiers, not verified unique human beings.

retention_cohorts uses each identifier’s earliest observed event day as its cohort. Returns on days one, seven and thirty mean activity on those exact UTC days, not any time after them. The target day must precede observedUntil to constitute a completed observation window; the current day is unfinished. Archiving away early history changes the meaning of first observation in the remaining data, while reinstallation can generate a new identifier. Retention consequently depends on available history and local identity. These boundaries are part of an honest Bunny Circus Analytics interpretation and differ from authenticated accounts or cross-device identity.

A collection key authorizes game event submission rather than authenticating a player. This matters if analytics is later proposed as proof of a balance or reward. Observed identifiers and events do not establish account ownership here. I distinguish behavioral analysis from economic authority so downstream use does not inherit an unintended promise.

What this stage taught me

For me, interpreting data correctly begins with defining identity correctly. Session and first-open counts make sense only when I know they describe a local installation rather than a player’s entire history.

Explore Dalo

Project source and discussion: GitHub · Telegram

Latest devlogs

Editorial illustration: Presenting selection and captures in Pasur

Presenting selection and captures in Pasur

Pasur motion should explain which hand card was played and which table cards were captured.

Read article
Editorial illustration: Pasur bot decisions from capture options

Pasur bot decisions from capture options

My teammate’s Pasur bot chooses among legal options without inspecting hidden opposing cards.

Read article
Editorial illustration: Capturing table cards in Pasur

Capturing table cards in Pasur

In my teammate’s implementation, Pasur combines selecting a hand card with selecting table cards. Its rules must produce valid sets and prohibit ignoring an available capture.

Read article
Dalo