Understand your players, and find out what went wrong.
Your game reports to Flock over two separate surfaces. They answer different questions, are read
by different people, and appear on different dashboards. Picking the wrong one puts your data
somewhere real but useless — so it is worth two minutes up front.
Analytics
Log events
Answers
What did players do?
What went wrong?
Read by
Design, product, LiveOps
Engineering
Covers
Sessions, screen views, transactions
Debug entries, logic errors, exceptions
Where to read it
Dashboards → Game Metrics
Diagnostics → Events and Diagnostics → Errors
A crash is not a funnel step. Sending one through the other surface does not fail and does not warn —
the entry is accepted, stored, and shown on a dashboard nobody was looking at.
Engagement, retention and monetization, built from the sessions, screen views and transactions your
game reports. Read on Dashboards → Game Metrics.
Dashboard
Unity
Unreal
Engagement, retention, and monetization dashboards in Flock.
Sessions start and end automatically around sign-in. Screen views tell you where players spend
their time, and purchases report their own transactions with no call from you.
FlockClient.Instance.Analytics.RecordScreenView("shop");// Optional: await delivery of everything queued (before a critical moment)await FlockClient.Instance.Analytics.FlushAsync();
Everything here is off when analytics are disabled in your configuration, and respects the
player’s consent decision where your game asks for one.
The Flock | Analytics nodes need no Target pin and are safe no-ops before the SDK initializes.
Sessions start and end automatically around sign-in, and purchases report their own transactions.
Gameplay events — a level completed, an item viewed — go through Flock Track Event
(TrackAnalyticsEvent), never through a log entry, which lives in the Flock | Diagnostics drawer.Build an event’s properties with the Flock Event Property nodes, which keep a number a number so
the dashboards can chart it.
Events are written to disk and delivered while a player is signed in; one recorded before anyone
signs in is credited to whoever signs in next. Everything here is off when Analytics Enabled is
unticked.
A session is the unit everything else is attributed to, and the SDK manages its whole life for you.
Starts
on sign-in, not at startup — a session belongs to a player, so there is nobody to attribute one to before then
Ends
on sign-out, on quit, and on timeout
Backgrounding
does not end a session — it pauses it, and time spent backgrounded is not counted as playtime
Timeout
a player who comes back after being away longer than the session-timeout setting (30 seconds by default) gets a new session; the old one is closed
That last row is the one worth knowing. Without it, a player who backgrounds your game overnight and
returns in the morning reports a single fourteen-hour session, and every average you build on top of
that is wrong.
Sessions are per sign-in, so a shared device reports one session per player rather than one per
launch. Signing out closes the session before the next player starts theirs.
Withdrawing analytics consent discards the session in progress rather than sending it. Objecting
to further processing is not a request to transmit one last record.
Developer diagnostics, in exactly three categories. Which one you pick decides where the entry
appears.
Category
Appears on
Use for
Debug
Diagnostics → Events
Trace and context — things that are not faults
Error
Diagnostics → Errors
Something wrong that did not raise
Exception
Diagnostics → Errors
A caught failure, with its stack trace
These are for diagnostics, not gameplay. A level-complete recorded as a debug entry lands in
Diagnostics → Events, where nobody building a retention chart will find it — and it will not
appear in Game Metrics at all.
Unity
Unreal
Log calls are synchronous and never block gameplay: they enqueue to an on-disk buffer and the
SDK batches and delivers them for you.
FlockClient.Instance.Analytics.LogEvent("matchmaking started"); // debugFlockClient.Instance.Analytics.LogError("quest ended with no reward"); // logic errorFlockClient.Instance.Analytics.LogException(ex); // exception
Log an entry and build its metadata with chainable builder nodes.
Sdk->LogDiagnosticEvent(TEXT("matchmaking started"), FFlockMetadata().Add(TEXT("queue"), TEXT("ranked")));Sdk->LogDiagnosticError(TEXT("quest ended with no reward"), Details);
Logging returns immediately: entries are written to disk and delivered later, so a call is cheap
and nothing is lost to a crash or a dead network. A run that dies without a clean quit is reported
on the next launch.These nodes live under Flock | Diagnostics, apart from the analytics ones, and their Extra Data is a
map of strings built with the Flock Metadata nodes. They were called Flock Log Event, Error and
Exception (LogAnalyticsEvent and friends) before SDK 1.21.0; the old names still work and the editor
points at the new ones.
If a play session ends without a clean quit — a crash, a hang the player force-killed, or the OS
evicting the game — the SDK detects it on the next launch and reports one app_termination
event automatically. No integration needed.
Property
Meaning
classification
background_kill (killed while backgrounded — normal on mobile) or abnormal (died in the foreground without quitting)
previous_session_id
The session that died
last_alive_at
Approximate time of death
unhandled_exception_count
Exceptions seen that run — context, not proof of a crash
Watch the abnormal rate per game version — a jump after a release is your earliest stability
signal, no crash reporter required. Closing the game normally (in-game quit, Alt-F4, swiping the
app away) never counts as abnormal.
Name things consistently. Whichever surface you are on, a small vocabulary of well-chosen names
makes a dashboard readable and a sprawling one makes it useless.
Qwacks
Flock
Protokite
Data Duck
