Most games need to send behavioral data and analytics to services like ad networks, analytics platforms, and purchase verification systems. Typically, each service requires its own SDK in the game client, adding download size, network overhead, and ongoing maintenance burden.
Events let you capture this data once and route it server-side. Your game client sends lightweight event data to Nakama, which processes it in the background and forwards it to whichever third-party services you’ve configured. Players experience minimal interruption, and you avoid embedding multiple SDKs into your client.
This approach gives you three practical benefits: a smaller game client (which improves your first-time user experience and download conversion), less network traffic from the client to external services, and significantly lower integration and maintenance cost for your team.
Internally, Nakama processes events using a high-performance circular buffer and a pool of worker goroutines. This means large volumes of events won’t overload your server even if your event handlers are slower than the ingestion rate. See Advanced settings to tune the queue size and worker count.
Events can be sent to the server by game clients or created on the server. An event has a name and a map of properties which decorate the event with more information.
You can also take advantage of after hooks in the server runtime when you want to send events from other features in the server. For example when a user account is updated and you might want to send an event to be processed.
Server
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
funcafterUpdateAccount(ctxcontext.Context,loggerruntime.Logger,db*sql.DB,nkruntime.NakamaModule,in*api.UpdateAccountRequest)error{evt:=&api.Event{Name:"account_updated",Properties:map[string]string{},External:false,// used to denote if the event was generated from the client
}returnnk.Event(context.Background(),evt)}funcInitModule(ctxcontext.Context,loggerruntime.Logger,db*sql.DB,nkruntime.NakamaModule,initializerruntime.Initializer)error{iferr:=initializer.RegisterAfterUpdateAccount(afterUpdateAccount);err!=nil{returnerr}returnnil}
Server
1
2
3
4
5
6
7
8
9
10
11
12
localnk=require("nakama")localfunctionafter_update_account(ctx,payload)localproperties={my_key="my_value"}localtimestamp=nk.timelocalexternal=false-- used to denote if the event was generated from the clientreturnnk.event("event_name",properties,timestamp,external)endnk.register_req_after(after_update_account,"UpdateAccount")
The server will generate built-in events which can be processed specifically for the SessionStart and SessionEnd actions. These special events occur when the server has a new socket session start and when it ends. See below for how to process these events.
Events can be processed with a function registered to the runtime initializer at server startup. Events will have its external field marked as true if its been generated by clients.
Processing events through Lua/TypeScript runtime functions is not yet supported.
Server
1
2
3
4
5
6
7
8
9
10
11
12
13
14
funcprocessEvent(ctxcontext.Context,loggerruntime.Logger,evt*api.Event){switchevt.GetName(){case"account_updated":logger.Debug("process evt: %+v",evt)// Send event to an analytics service.
default:logger.Error("unrecognised evt: %+v",evt)}}// initializer runtime.Initializer
iferr:=initializer.RegisterEvent(processEvent);err!=nil{returnerr}
Code snippet for this language TypeScript has not been found. Please choose another language to show equivalent examples.
Code snippet for this language Lua has not been found. Please choose another language to show equivalent examples.
Events which are internally generated have their own registration functions. The SessionStart is created when a new socket connection is opened on the server.
Code snippet for this language TypeScript has not been found. Please choose another language to show equivalent examples.
Code snippet for this language Lua has not been found. Please choose another language to show equivalent examples.
The SessionEnd event is created when the socket connection for a session is closed. The socket could have closed for a number of reasons but can be observed to react on.
To protect the performance of the server the event processing subsystem is designed to limit the resources allocated to process events. You can adjust the resources allocated to this subsystem with these configuration settings.
Configuration Key
Value
Description
runtime.event_queue_size
int
Size of the event queue buffer. Defaults to 65536.
runtime.event_queue_workers
int
Number of workers to use for concurrent processing of events. Defaults to 8.