I'm working on a multiplayer game and I want to use Flurry to record game events.

In the game you can build, grow and train troops. In Flurry you can log an event (optionally with parameters).

It would be great to be able to track the progress of a player depending upon what kinds of things they build, grow and so on and at what experience levels they do that at, but I don't know whether it's best to just have different sets of events for different types of actions... like this:

NSDictionary *buildParams =
   [NSDictionary dictionaryWithObjectsAndKeys:
      @"Build_Type", @"Castle", 
      @"EXP", @"234523", // Capture user status

[Flurry logEvent:@"Build_Action" withParameters:buildParams];

And so on... so another for growing something, another for training, et cetera.

Or is it better to have one global type of record of an event like this:

NSDictionary *actionParams =
   [NSDictionary dictionaryWithObjectsAndKeys:
      @"Action", @"Build", 
      @"Type", @"Castle", 
      @"EXP", @"44234",

[Flurry logEvent:@"Game_Action" withParameters:actionParams];

In this method all the data is stored in the one event type. I'm not sure which will give me the best result when it comes to funneling, segmentation, and all that?

  • 1
    \$\begingroup\$ I used Flurry on one of my projects, and the problem I found with it was that it had a maximum events per session. Then it was 200 events per session. So if the player plays for a long time, all of the events will not be logged. Have you come across GameAnalytics? They are especially designed for gaming and have a very handy custom eventing. \$\endgroup\$ – Esa Aug 28 '13 at 6:09
  • 1
    \$\begingroup\$ Can you point me to where Flurry states 200 events per session? I've not been able to verify this. \$\endgroup\$ – Phil Aug 29 '13 at 23:31
  • 1
    \$\begingroup\$ I could not find the original location where I came across this information, but I found couple of other URLs: quora.com/Mobile-Analytics/How-does-Flurry-make-money/answer/… and bugs.yoyogames.com/view.php?id=9314#c17516 . Plus I checked my flurry event logs on one of the applications I have and the logs stop at 200 on each longer session. \$\endgroup\$ – Esa Aug 30 '13 at 5:56
  • \$\begingroup\$ The limit is now 300, from the official site: stackoverflow.com/questions/18517386/… \$\endgroup\$ – ashes999 Aug 1 '14 at 15:50

It sounds like you are trying to decide between a system where the event parameter describes a specific kind of event (a build event, a destroy event, a purchase event, et cetera) and one where the kind of event is encoded in the parameters and all events are "game events."

You should choose the first one. The second option discards information and useful querying functionality: when everything is a "game action," there is no point to even having that field in the data, and since everything is a game action there's no way you can usefully query using that field.

Flurry exposes the event name field for a reason. By making it a first-class citizen, it can perform storage or query optimizations on it. It also uses the event name as a way to associate the start and end times of timed events; if you record all your events with the same name, this becomes less useful.

Flurry's own documentation and example event set for a game agree with the pattern of using the event name to actually name each kind of event, as well.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.