Deciding what data to track in Leanplum

Leanplum automatically logs session and user information for you. If you want more detailed information, such as how much ad revenue you made, or how long your users played each level of your game, you can set that up with Events and States.

One of the most important parts of the onboarding process is deciding what to track in Leanplum. You may already have an event schema from another analytics provider. If so, it is completely acceptable to copy your existing schema into Leanplum. If not, don’t worry, and read on!

First, let’s look at the different types of data you can send to Leanplum, either from the client or the server.

  • An event is anything that can occur in your app. Events include clicking on a link, sharing, purchasing, killing enemies, etc. All events are timestamped according to when they occur. Thus, it is not advisable to log too many (thousands) of events, as each one will have to be sent to our server.
  • A state is any part of your app a user can be in. For example, some states can include being in a particular level, watching a video, or browsing an in-app store. Leanplum has the option to automatically track all screens in your app as states. All states have a time and a duration. The duration is set automatically -- when one state begins, the previous one ends.
  • A parameter is a piece of data associated with an event or state. You can supply parameters as a dictionary along with events and states. Parameters are great for adding contextual information about an event, e.g. price for the purchased items or destination city for a booked flight. This information can then be used to personalize messages and content, and to run contextual reports for deep analysis on specific cohorts of users.

For more information on how to instrument events, states and parameters, please review our developer documentation.

Before your development team begins integration, here are some best practices to keep in mind.

Events, States and Parameters

  • Identify the core milestones in your app
    • Some customers can become intimidated, thinking that every last button in their app must have an event. For the record, some customers do! But many customers instead focus on the core user activities their app is trying to drive and focus on tagging those, and the activities surrounding them with events.
    • For example, most customers will want to tag events around user onboarding flow and conversion/purchase
  • Pick unique event names for distinct actions
    • For example, the following should each be separate events: Login, Register, Add To Cart, Rate Item, Checkout
    • Each step in a funnel should have its own event name
  • Use parameters to differentiate similar actions, cutting down on the number of unique events
    • Separate event names (necessitating 2 unique events):
      • track("Open App Tesco Bank")
      • track("Open App Blinkbox Books")
    • Same event name with parameters (necessitating 1 unique event):
      • track("Open App", "app_name": "Tesco Bank")
      • track("Open App", "app_name": "Blinkbox Books")
  • Use multiple parameters for more dimensions:
    • track("Open App", "app_name": "Blinkbox TV", "category": "Featured", "page": "Entertainment")
  • Parameters can be numeric (for example, “number of items ordered”), and if marked as numeric, Leanplum will compute averages and sums for that parameter. Parameters can also be strings.

Variables

  • Think about what you want to test and how these tests will influence your goals and KPIs
  • Configure your Variables or Resources to represent what you want to be able to remotely change
  • Here are some common use cases for the different types of variables:
    • Boolean:
      • Turning features on or off
    • String:
      • Changing configurations
      • Changing display text
    • Arrays and dictionaries:
      • Ordering of elements
      • Complex configurations

User Attributes

  • A user attribute is any piece of data associated with a user that you provide to the SDK
  • Intended to store user data that is persistent throughout a session, and to get copied from one session to the next
  • Typical use cases include:
    • Personalizing content (variables, messages, resources, and interfaces) to different types of users
    • Targeting an A/B test
    • Filtering reports by a particular user attribute, like only looking at data for “whales”
    • Grouping reports by different attribute values. E.g., create a histogram of average session length by number of friends
  • Examples of user attributes include:
    • Gender
    • Age
    • Number of friends
    • User interests
  • Constraints:
    • Up to 200 attributes per app
    • Attribute names must be strings, and values must be strings or numbers
    • Attribute values will be the same across all events and states in a particular session

Was this article helpful?
Have more questions? Submit a request