Flurry Custom Events: Best Practices¶

The Basics¶

Logging an event is easy:

You can have all of the following with Flurry events:

• Named events

• Named events with up to 10 parameters

• Timed events with up to 10 parameters

• The ability to update a value on a timed event when ending the timed event

There are also a few other limitations that are important to consider:

• No more than 1000 events will be captured in a given session. This is done in order to manage size of the data. If you capture more than 1000, the first to be captured are lost. We are working to eliminate the cases where this could possibly be the case. This is already an extremely rare occurrence.

• Param keys and values must be strings and have a limit of 255 characters

• If an event is logged that has more than 10 params, that event is dropped (though if debug logging is turned on, it will complain loudly)

Planning for Events¶

The planning process takes three steps:

1. Define goals: To frame the conversation about the goals, the good question to ask is: “Why does your app exist? ” To help with capturing the goals you can look at some general questions like: “Are you going to monetize your app?”, “Are you going to get users to level 4?”, “ Are you going to elicit as many shares to as many social networks as possible? “

2. Determine KPIs: You develop a set of KPIs (Key Performance Indicators) from the earlier mentioned goals which inform whether or not you’re attaining your goals. KPIs take the form of statements, such as: Derive $1.99 average revenue per user; Get 50% of users to level 4; Get an average of 5% shares on each article based on view.

3. Structure events: Finally, you start instrumenting your events in order to inform the KPIs. The events should help track the KPIs. You will track all in-app purchases and capture the in-app purchase price. You log an event when a user makes it to a new level including the level achieved as a param. You log an event on every share with params to capture content ID and the network shared out to.

An Example: Goals¶

Let’s see this in action. Take an example of an app that presents the vertical stream of some intersting contnet.

This app exists to show interesting content from various sources (like Tumblr, but it is to see any other content source being added). However, it also exists to generate revenue for the app developer.

So, what would the goals be?

• Consistently show quality content

• Generate revenue

For the first goal we could log an event for every time the content is read, along with some attributes / parameters that describe the content to understand which types of content attract higher read rates.

We’re going to dive deep on the second goal, which is to generate revenue. From the general set of the options for generating revenue :

• Up-front charging for the app

• Offering in-app purchases

• Showing ads

we are choosing to focus on the goal of showing ads.

Flurry’s native ads platform allows us to intersperse ads into the app’s content stream. While ads are being clearly marked as advertisements, they have a similar appearance to the rest of the content presented in the app.

There are a lot of different types of ads. Some ads make money by simply being shown (cost per impression, or CPM), some by being clicked on (cost per click, or CPC) and some by a downstream action like an install or other action (cost per install or cost per action, CPI or CPA respectively). Flurry Native is a CPC product, so we need to get users to click on the ads we show.

An Example: KPIs¶

Our KPIs are :

• Show a consistent number of ads

  • Why: Find the optimal ratio of ads and content presented to the user

• Percentage of shown ads are clicked on

  • Why: clicks generate revenue

These KPIs are tracked through the events logged on ad related events and activities:

• To track how many ads are shown on a regular basis we can add in an event that tracks whenever an ad is displayed:

[Flurry logEvent:@"stream_ad_displayed" withParameters:@ {@"ad_space":nativeAd.space,
                                                          @"type":adType,
                                                          @"model":[Util getDeviceModel],
                                                          @"network":@"Flurry"}];

You can see that the event name is “ad_displayed”, but there are quite a few more parameters. Going back to the different types of ads, you’ll recall that there are CPM, CPC, CPI, etc, ads. There can also be different types of ad, such as video, native, banner, etc.

• As a user clicks an ad, we capture this event:

[Flurry logEvent:@"stream_ad_click" withParameters:@{@"ad_placement":adPosition}];

You can see here that we are capturing an event called ‘stream_ad_click’ and we’re inputting the position within the stream of the ad. Obviously, simply having a record of an ad being clicked is important, but the parameter that we’re collecting is of importance.

‘ad_placement’ tells us the location in the stream at which the ad was clicked. We may have an assumption that this is always as high as possible, but what if it turns out that ads placed later are clicked more? That’s actionable information we can work with by making the first 6 or 8 posts not have ads and then putting an ad in the 9th spot.

Conversely, in the case ads placed higher up in the stream get clicked more often, we can decide to place an ad early, possibly the second slot, as to drive as much revenue as possible. This makes your event structure actionable.

In our example, we’re specifically showing native ads, but these native ads can be display or video, so we’re going to track that. It’s also possible that you are showing ads from various networks and not just Yahoo, so you would probably want to tracking that is a great ideal.

Lastly, it may be interesting or important to know what the device model is (note: Flurry does this for you already, but it’s worth calling out here that it’s an important factor to keep in mind). All of this is tracked in the params of this event.

An Example: Analyzing the Results¶

For all the events that are logged, Flurry has many tools which allow you to analyze your data. From simple dashboards, segments, funnels, cohort analysis, to Explorer - the instant query engine.

Explorer can do some extraordinarily analysis. For example, find an answer to a question of where an extreme spike in new users came from. Using Explorer, you can iterated over the data and quickly narrowed in on the cause which drove the spike in new users.

So, let’s take a look at our data in Explorer (This is sample app data and is for demonstrative purposes only which accounts for the small sample size. With a truly rich data set, the analysis can get deeper and more precise).

For instance, what if you found out that most of your ad views were coming from small-screen phones? Here’s an Explorer query that shows just that:

That unlabeled high spike is the iPhone 5S. What can you do with that?

Perhaps your ads don’t work well on large screen devices. Did you test there? Is something wrong? Do small screen users monetize better because the ad takes up proportionally more of the screen?

All of these are valid questions. What’s more, you can now go out and take definitive action to begin answering those questions. Break out the big screen devices and test to make sure that the ads are showing up and that the look isn’t horrific. Take a look at the small screen devices and compare the real estate taken by ads to the large screen devices.

If all of that looks fine, then you can begin modifying your app such that one experience exhibits the behavior of the other. .

These are the types of questions that you should be able to explore if you log your events correctly.

Naming Events¶

Naming events can be as important as simply collecting them. Consider the following names:

• stream_ad_click

• stradcl

These represent the same event, but the way you express the name allows someone without domain knowledge to come in and understand pretty quickly what’s happening.

In the first name, you see that we are: in a stream; in an ad; that an ad was clicked. In the second name, it’ s not obvious what’s happening.

As a rule of thumb, we recommend that you use a nomenclature that identifies several things:

• The view

• The object in the view

• The action that was taken on the object

If you follow this rule, then anyone can come in with little foreknowledge of your app and make sense of your event structure.

Wrap Up¶

Our hope is that this conveys to you the best practices in terms of eventing with Flurry. We’ve identified the basic capabilities, shown you how to structure your events starting with answering questions like why your app exists and carried you through some examples about how events roll up to KPIs which then inform your goals.

We also covered nomenclature of events and how you can bring anyone in to help make sense of your analytics.

The best part? This is completely generalizable. You can use these best practices with any analytics system.

And when you know more, when your analytics are actionable, make your app better.