Settings goals

7 min read

(for more resources related to this topic, see here.)

You can use the following code to track the event:

[Flurry logEvent:@"EVENT_NAME"];

The logEvent: method logs your event every time it’s triggered during the application session. This method helps you to track how often that event is triggered. You can track up to 300 different event IDs. However, the length of each event ID should be less than 255 characters.

After the event is triggered, you can track that event from your Flurry dashboard. As is explained in the following screenshot, your events will be listed in the Events section. After clicking on Event Summary, you can see a list of the events you have created along with the statistics of the generated data as shown in the following screenshot:

You can fetch the detailed data by clicking on the event name (for example, USER_VIEWED). This section will provide you with a chart-based analysis of the data as shown in the following screenshot:

The Events Per Session chart will provide you with details about how frequently a particular event is triggered in a session.

Other than this, you are provided with the following data charts as well:

  • Unique Users Performing Event: This chart will explain the frequency of unique users triggering the event.
  • Total Events: This chart holds the event-generation frequency over a time period. You can access the frequency of the event being triggered over any particular time slot.
  • Average Events Per Session: This charts holds the average frequency of the events that happen per session.

There is another variation of this method, as shown in the following code, which allows you to track the events along with the specific user data provided:

[Flurry logEvent:@"EVENT_NAME" withParameters:YOUR_NSDictionary];

This version of the logEvent: method counts the frequency of the event and records dynamic parameters in the form of dictionaries. External parameters should be in the NSDictionary format, whereas both the key and the value should be in the NSString object format. Let’s say you want to track how frequently your comment section is used and see the comments, then you can use this method to track such events along with the parameters. You can track up to 300 different events with an event ID length less than 255 characters. You can provide a maximum of 10 event parameters per event.

The following example illustrates the use of the logEvent: method along with optional parameters in the dictionary format:

NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
@"your dynamic parameter value", @"your dynamic parameter name",nil]; [Flurry logEvent:@"EVENT_NAME" withParameters:dictionary];

In case you want Flurry to log all your application sections/screens automatically, then you should pass navigationController or as a parameter to count all your pages automatically using one of the following code:

[Flurry logAllPageViews:navigationController]; [Flurry logAllPageViews:tabBarController];

The Flurry SDK will create a delegate on your navigationControlleror tabBarController object, whichever is provided to detect the page’s navigation. Each navigation detected will be tracked by the Flurry SDK automatically as a page view. You only need to pass each object to the Flurry SDK once. However you can pass multiple instances of different navigation and tab bar controllers.

There can be some cases where you can have a view controller that is not associated with any navigation or tab bar controller. Then you can use the following code:

[Flurry logPageView];

The preceding code will track the event independently of navigation and tab bar controllers. For each user interaction you can manually log events.

Tracking time spent

Flurry allows you to track events based on the duration factor as well. You can use the [Flurry logEvent: timed:] method to log your event in time as shown in the following code:

[Flurry logEvent:@"EVENT_NAME" timed:YES];

In case you want to pass additional parameters along with the event name, you can use the following type of the logEvent: method to start a timed event for event Parameters as shown in the following code:

[Flurry logEvent:@"EVENT_NAME" withParameters:YOUR_NSDictionary

The aforementioned method can help you to track your timed event along with the dynamic data provided in the dictionary format.

You can end all your timed events before the application exits. This can even be accomplished by updating the event with event Parameters. If you want to end your events without updating the parameters, you can pass nil as the parameters.

If you do not end your events, they will automatically end when the application exits as shown in the following code:

[Flurry endTimedEvent:@"EVENT_NAME" withParameters:YOUR_NSDictionary];

Let’s take the following example in which you want to log an event whenever a user comments on any article in your application:

NSDictionary *commentParams = [NSDictionary dictionaryWithObjectsAndKeys: @"User_Comment", @"Comment", // Capture comment info @"Registered", @"User_Status", // Capture user status nil]; [Flurry logEvent:@"User_Comment" withParameters:commentParams timed:YES]; // In a function that captures when a user post the comment [Flurry endTimedEvent:@"Article_Read" withParameters:nil]; //You can pass in additional //params or update existing ones here as well

The aforementioned piece of code will help you to log a timed event every time a user comments on a picture in your application. While tracking the event, you are also tracking the comment and the user registered by specifying them in the dictionary.

Tracking errors

Flurry provides you with a method to track errors as well. You can use the following methods to track errors on Flurry:

[Flurry logError:@"ERROR_NAME" message:@"ERROR_MESSAGE" exception:e];

You can track exceptions and errors that occurred in the application by providing the name of the error (ERROR_NAME) along with the messages, such as ERROR_MESSAGE, with an exception object. Flurry reports the first ten errors in each session.

You can fetch all the application exceptions and specifically uncaught exceptions on Flurry. You can use the logError:message:exception: class method to catch all the uncaught exceptions. These exceptions will be logged in Flurry in the Error section, which is accessible on the Flurry dashboard:

// Uncaught Exception Handler - sent through Flurry. void uncaughtExceptionHandler(NSException *exception) { [Flurry logError:@"Uncaught" message:@"Crash" exception:exception]; } - (void)applicationDidFinishLaunching:(UIApplication *)application { NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); [Flurry startSession:@"YOUR_API_KEY"]; // .... }

Flurry also helps you to catch all the uncaught exceptions generated by the application. All the exceptions will be caught by using the NSSetUncaughtExceptionHandler method in which you can pass a method that will catch all the exceptions raised during the application session.

All the errors reported can also be tracked using the logError:message:error: method. You can pass the error name, message, and object to log the NSError error on Flurry as shown in the following code:

- (void) webView:(UIWebView *)webView didFailLoadWithError:(NSError *)error { [Flurry logError:@"WebView No Load" message:[error localizedDescription] error:error]; }

Tracking versions

When you develop applications for mobile devices, it’s obvious that you will evolve your application at every stage, pushing the latest updates for the application, which creates a new version of the application on the application store. To track the application based on these versions, you need to set up the Flurry to track your application versions as well. This can be done using the following code:

[Flurry setAppVersion:App_Version_Number];

So by using the aforementioned method, you can track your application based on its version. For example, if you have released an application and unfortunately it’s having a critical bug, then you can track your application based on the current version and the errors that are tracked by Flurry from the application.

You can access data generated from Flurry’s Dashboards by navigating to Flurry Classic. This will, by default, load a time-based graph of the application session for all versions. However, you can access the user session graph by selecting a version from the drop-down list as shown in the following screenshot:

This is how the drop-down list will appear. Select a version and click on Update as shown in the following screenshot:

The previous action will generate a version-based graph for a user’s session with the as number of times users have opened the app in the given time frame shown in the following screenshot:

Along with that, Flurry also provides user retention graphs to gauge the number of users and the usage of application over a period of time.


In this article we explored the ways to track the application on Flurry and to gather meaningful data on Flurry by setting goals to track the application. Then we learned how to track the time spent by users on the application along using user data tracking and retention graphs to gauge the number of users.

resources for article:

further resources on this subject:


Please enter your comment!
Please enter your name here