Relational databases these days are knocked for being inefficient, but when storing the type of logs you're talking about, you don't really need efficiency because they won't be constantly accessed by the game or its users - only your team will need to read the data.
So "efficiency" doesn't matter that much. What matters more is ordering the data in a way that makes it easy to tell the story of what users are doing in the game. Your developers will generally need to consume this data and display it in an interface that's easy to read for analysts and analysts will sometimes need to query the data to dig deep into user behavior. For instance, if players are purchasing a certain item before an update, but stop purchasing it after an update, an analyst will benefit by writing certain queries that expose certain numbers about behavior surrounding that purchase to determine why users no longer buy it. It's best if they have a standard query language to work with that is well documented. If they have to make these queries into a custom binary format their jobs will be made MUCH harder, and that's INEFFICIENT.
Generally game events look something like this (this is DeltaDNA's format in particular)
{
"eventName":"specific event code – eg. gameStarted",
"userID":"ABCD1-4321a879b185fcb9c6ca27abc5387e914",
"sessionID":"4879bf37-8566-46ce-9f3b-bd18d6ac614e",
"eventTimestamp":"yyyy-mm-dd hh:mm:ss.SSS",
"eventParams":
{
"platform":"WEB",
"param1":"stringParam",
"param2":true,
"param3":1234,
"param4":["a","b","c"]
},
}
The event usually includes an event name, a userID, a session ID, timestamp, and parameters that allow you to record whatever data you find useful to record surrounding that event. And in my experience, relational database formats are the best for recording such a structure.