Applications in Apsalar

Last Updated: Jan 17, 2016 10:55PM PST


The Applications page lets you view which applications are tracking analytics. It contains the following items:

  • Application Name - identifies your app in the Apsalar web interface. If more than one app has the same application name, a longname (the unique app store identifier for the application) is displayed.
  • OS - the operating system on which your application runs (Android or iOS).
  • Latest Version - the most recent version of your application as defined in the iOS or Android version value set in your application's code.
  • Date Created - the date that your app was created in the Apsalar interface or its first session start after SDK integration.
  • SDK Version - the SDK package that the latest version of your application contains. If an application was created without instrumenting an SDK, "N/A" will be displayed. If an application SDK is out of date, "-deprecated" will be displayed.
  • Status - describes the visibility of the application in drop-down menus and reports across the Apsalar interface; an application that is "Hidden" will not show in drop-down menus. Please note that viewing data for "All applications" in a report will include data for "Hidden" apps, and that data collection will continue for all applications, regardless of their status.

Editing Applications

Once your application is stored in the Apsalar system, only certain items can be edited. Namely: Your Application name and longname are passed in from your application code. For the iOS application longname, Apsalar receives the Bundle Identifier you have set (or CFBundleID in Xcode 3.x and earlier). For Android, we use the package name defined in the manifest.xml file. The long name is the unique identifier for your application.

The app long name is used to identify your app when a session is started and for all subsequent interaction through the SDK. If you change the Bundle identifier/CFBundledID or package name and rebuild your app, it will be seen as a different app.

Application display names originate from the Bundle name (CFBundleName in Xcode 3.x and earlier) for iOS or the application label (e.g., <application android:label=”@string/app_name” > ) from the manifest.xml file for Android. We use the display name to reference your app in the reports and other places on our site. If you have more than one app with the same display name, the long name will also be displayed to differentiate between them. You might have this condition if you have one app with a long name reflecting a test version but uses the same display name as the production version. These would be two different apps with the same display name.

Hiding Apps and Events

In your Apsalar account you may hide applications, application versions, and event names. You may want to do this if:
  • ​An event is no longer instrumented or relevant and is only crowding the events page and reports
  • An application (e.g. a lite version) is discontinued and no longer relevant
  • An application version is a development build or obsolete
The Apsalar Applications tab has several major features worth using.

1. Visibility. To change the status of an application(s), check the box next to the app you want to configure; the "Change status" button at the top of the table will become enabled. Click the button and select, "Hide selected" to conceal an application and "Show selected" to display it.

Note: Changing the status of an event to "hidden" will remove it from drop-down menus across the Apsalar interface, but data collection will continue.

2. Status Filtering. To filter by status, select 'Status':

3. Instructional Help. For more explanation or information regarding terms, consult the help '?' icon in the upper right hand corner:

4. Accessing Events through Applications. You may now see all of your events under the Applications page by selecting the application of your interest. In this example, the BuyIt3 application was selected. Selecting certain events allows you to show or hide them:

5. Combined Applications and Events page. Access your event data through the application in which they occur. All in one place.




Events can now be accessed through the applications page. This section assumes you have already instrumented events in your application code. If you still need to instrument, first read ApScience iOS Integration and ApScience Android Integration.

To view your events, select the Application of interest. The events associated with that application and its versions will appear.

Under Actions, you may view the report for that event. For a full list, view the Event Reports page. Events will show up, either under Applications or Event Reports, if:
  • You have properly instrumented events with the Apsalar SDK in your application code or are sending events through the Apsalar API.
  • Users have triggered the event on an application with the Apsalar SDK.

Testing Event Instrumentation

If you are testing your events' implementation, the Event Tracking Console displays calls just a few minutes after they occur. To see what events have been registered in ApScience, go to the My Events page. This will show you a listing of all of your events grouped by your applications. 

In this example, the iOS application instrumented an event called SecondScreen as follows:

- (void)viewDidLoad
    [super viewDidLoad]; 
    [self configureView]; // Record that user has hit a Detail View 
    [Apsalar event:@"SecondScreen"]; // Event is called SecondScreen
    NSLog(@"Apsalar Event SecondScreen Completed."); // Log the message in the debug console
  • Event Revenue Attributeyou may manually enter revenue attribute values for an event. If your application has Apsalar’s iOS SDK version 5.0.0+, you do not need to track revenue by assigning it in your code for in-app purchases (see Revenue). With the latest SDK, international revenues for in-app purchases are also automatically converted in Dashboard, Trending reports, Real-Time Cohorts, and Funnel reports. Get the latest SDK here.
  • Apsalar supports multiple parameters / arguments for iOS and Android events. If you implement event arguments, track them by clicking "View Attributes". The screen shot below shows an event without attributes (top) and one with attributes (bottom). See Apsalar's iOS and Android Integration Guides for technical instructions on how to instrument event attributes.
  • Engagement Index: you may enter an engagement value (e.g. 1, 3, 10, etc.) for an event to gauge interaction value within your app. If the event is "low engagement", such as launching the app, assign a smaller numerical value. If the event is "high engagement", such as getting to the last level in a game, assign a bigger numerical value. 
  • Actions: View Report, View Attributes (if any), Assign/Change Revenue, and Assign/Change Engagement Value.

Best Practices

Events are associated with a specific application name and OS, so you should choose names that will help you identify your event.

  • If you remove an event from your application code, the event will still be registered and appear in your event list. Best practice is to not remove events once they are instrumented.
  • If you remove an event, do not include that event in any Funnel or Segment, since your application will no longer be tracking the event.

Event Name Limit

There is a limit of 400 event names per app version. If you exceed the 400 event name limit in your application, new event names for that particular app version will not register. 
Your events should be hard-coded within your application, never created dynamically when a user action is triggered. To keep event names to a minimum, Apsalar recommends implementing attributes for your event (e.g. purchase_one_tree, purchase_two_trees; product_id; etc.). In summary:
  • If you have dynamically generated event names, you should remove them and use attributes instead.
  • If you are over this limit, all new event names will be rejected.
  • Release a new application version with less than 400 (usable) event names if you have more than 400 event names. 
Clicking View Report will bring you to the event report where you may filter for granularity (day, week, month), time range, metric (total count, unique users, average per session, events per session, revenue, ARPU), and segment. In the example below, the Event Name is SecondScreen and the Application Name is Apsalar (com.apsalar.myapp.Apsalar).

Funnels, Cohorts, Segments, and Revenue Attributes

  1. Funnels (see Managing Funnels) — events define the steps and goal of your conversion funnel. Funnel steps and goals can only be events that have been registered with ApScience. You may create conversion funnels that track events across applications, such as users who downloaded a free app and bought the paid version. Events may also be used to define user segments that are specific to a conversion funnel and will be used to provide even more insight into your conversion funnel analytics.
  2. Cohorts (see Managing Cohort Analytics) — Your events can be used to define a cohort, or a group of users who share an application experience during a specified period of time. They may also be used to define user segments that are specific to a cohort analysis and will be used to provide even more insight into your user cohort analytics.
  3. Segments (see Managing Segments) — By defining ‘global’ segments based upon events, your users will be placed into the appropriate segments when they trigger ‘segmentation events’. From that point on their behavior will be associated with that segment as a group. A user may be a member of multiple segments.
  4. Revenue Attributes – By assigning revenue attributes to your events, you can use the observed attribute values for users in Revenue analyses.  This will help you understand the Revenue and Average Revenue per User (ARPU)  of users, segments, and cohorts.  Revenue data is available in the dashboard, trending, cohort analyses, funnel analyses, and event reports.

To learn more about event reports and event analysis, see Event Analysis.
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found