Localytics FAQs

The Lifetime Value (LTV) report provides insights on the value your users generate within your app in order to determine the volume and value of transactions that occur over time and which users generate the highest value.

LTV data must be passed as an integer amount. So, for example, if an item's purchase amount is $2.99, you would pass the integer 299 as its LTV.

You may configure your app (within the Localytics dashboard) to treat LTV as a direct monetary value (in $USD), in which case it will automatically append two decimal places to each value in your dashboard so in the example above, an LTV of 299 would be displayed in your dashboard as $2.99. Conversely, you may also have LTV treated as a direct "Raw Value" as well, in which case the dashboard will simply display the data as they were received (eg.299).

Additional information regarding LTV may be found in this article.

The following are a number of data fields collected by Localytics, outlining what is captured. It is important that prior to reading this article, you understand what a User is as defined by Localytics. For more background on how Localytics collects and analyzes data, read our Analytics Key concepts which can be found in our User Guide. For more on identifiers specifically in the context of Attribution, read our Attribution section within the User Guide.

General Identifiers

Device IDThe Localytics SDK identifies unique devices by creating a proprietary device ID which is generated using a combination of identifiers found on the device. The resulting unique device ID gets attached to all Event and Session data and it is what we use to count users. This ID is designed to persist through reinstalls. So, for example, if someone uses the app, uninstalls, and then reinstalls it, Localytics will treat them as a single user. Also, Localytics only becomes aware of users when a user first opens a version of the app that has Localytics installed.

Customer IDLocalytics allows your app to optionally assign an identity to a user, which we call the user's Customer ID. If your app has actively assigned a Customer ID, Localytics refers to this as a "known" Profile. If your app is either not assigning a Customer ID or the user is using the app with an unknown identity (e.g. not logged in), Localytics will assign a random identifier to which you can associate user-level properties, making their profile "anonymous." Your app can be configured to associate Profile Attributes with Customer IDs.

See the chart below for clarification:

Profile Type

Customer ID

Description

Anonymous

Random value

Localytics-generated random alpha-numeric identifier

Known

Username / CRM number / etc.

Identifier communicated to Localytics by your app, usually upon log-in or authentication

Importantly, if a user is first connected to an Anonymous Profile and later to a Known Profile - e.g. the user first uses the app anonymously, then logs in - the Known Profile cannot automatically inherit the Anonymous Profile's Attributes. Once a Known Profile is assigned, the user will be target-able based on that Known Profile (not the prior Anonymous Profile). Your app should have instructions to communicate important Profile Attributes upon setting Customer ID: they can be found here. You can also batch-upload Attributes either manually via CSV or programmatically via API.

For more on User Profiles, check out our documentation.

Advertiser IDIn addition to the above mentioned identifiers, Localytics can also collect a device's IDFA (iOS) or Google Advertising ID/GAID (Android) to attribute the source of the download. Similarly toDevice IDmentioned above, these identifiers persist through reinstalls.

For more on the iOS IDFA, read this post. For more on Android's Google Advertising ID/GAID, read this post.

Install IDIn addition, Localytics assigns an install ID, which is a random alpha-numeric identifier per app install that is created by the Localytics SDK and is Localytics-specific. When a user first opens your app, their initial Customer ID is the same as their Install ID.

The Localytics dashboard allows you to export certain reports as either a .csv or .pdf file.

Sometimes, after clicking "Export as PDF/CSV," the new window opens, the 4 steps are completed, and the dashboard displays a green message stating that your report has been exported successfully, but the file is not available in your downloads.

In that case, it is likely that your browser's popup blocker prevented the download of your report. You may verify whether that is the case, as well as configure your browser to accept downloads from Localytics, via the address bar the image below pertains specifically to Google Chrome.

The Localytics SDK collects country information by default and will default to the most reliable data when it exists.

The logic is based on a waterfall approach:

Latitude/LongitudeLocalytics will use when available. This information does not appear in the dashboard but can be available in raw data. You can report on GPS with Localytics if your app is collecting it. Localytics will not (and cannot) collect GPS information unless your app is both (a) authorized by the OS to collect this and (b) configured to hand it off to Localytics. Pass location to Localytics usingsetLocation.

High-confidence IP(wired/Wi-Fi) /Low-confidence IP(mobile/wireless traffic)

Network Countryif Latitude/Longitude and IP are not provided. We will track down to the metro and city level for sessions that occur over GPS or Wi-Fi (high reliability). Localytics does not report more specific location data when there is a low confidence connection in order to ensure you have the most accurate information in your dashboard.

Location history can be found in your raw data. If you are a professional customer and do not yet have access to your raw data, contact Support.

Funnels are an ordered collection of events enabling you to see how users flow through your app based on the app events you tag. For example, you might create a funnel forRegister > Upload photo > Share photo or Product viewed > Added to cart > Proceed to checkout > Purchase.

Localytics follows a few rules when computing funnels.

To complete a funnel step, a user has to perform that funnel step's event after performing all the previous funnel steps. If a funnel is defined asA > B > C, then a user must doAbeforeBandBbeforeC.-Any number of events may occur between funnel steps. Therefore, if a funnel is defined asA > B > Cand a user doesA > B > D > E > F > C, then the user is still considered to have completed the funnel.

Funnels span session boundaries. So, for example, a user registration funnel that takes three sessions over the course of several days would still be considered a completed funnel.

All steps in the funnel must occur within the date range specified.

Localytics only tracks the first time a user completes the funnel. If a user completes the same funnel again, that user is not counted a second time.

Funnels are retroactive for events tagged in the past.

Learn more about funnels here.

Rapid Push Verification Instructions

For the quickest way to find your specific customer ID, we recommend using our Rapid Push Verification tool in the Localytics dashboard. The Rapid Push Verification page can be found in your instance of Localytics in the "Settings" page. For instructions on using RPV, please consult this section of our User Guide. Alternatively, you still can use Charles Proxy to get the same results (and more). These instructions are outlined below:

Charles Proxy Instructions

In order to successfully find your customer ID, you must be set up to use Charles Proxy to see data as it gets passed from client to server. To set up Charles Proxy and connect your device, use these instructions from another Help article. Following that article will show you how to download Charles Proxy to see live data being collected by Localytics in raw form.

Once live data is being collected, a customer ID, either "known" or "anonymous," will be shown within the raw data. To learn more about customer ID, see this help article.

It is important to note that in the raw data, Customer ID is represented as "cid" and falls immediately before the alphanumeric string. Before "cid," there will be another field that classifies whether the ID is "known" or "anonymous". The graphic below shows where these fields are located. Other information has been hidden for privacy purposes.

In general, analytics tools count users, but each analytics tool has its own way of counting. Sometimes, user counts can appear to be incorrect for various reasons, especially when measuring users over time. For example, if a user installs your app on Monday and then returns on Tuesday, a usage chart that reports total usersper daywill show two users, one for each day. But if you modify the same chart to report total usersacross days(i.e.notsplit by day), the chart will show only one user, since there was only one unique user observed across the evaluated time period. This common source of confusion is called the Hotel Problem.

This can be particularly confusing when evaluatingnew versus returningusers. For example, Localytics counts a user as new only the first time they open your app. Therefore, a user who opens your app for the first time on a given day and returns again the same day will be counted once as a new user and once as a returning user. This means that if you split the number of users from a given day between new and returning, the total will likely exceed the number of unique users from that day (because some users are properly identified as both new and returning).

A variation of this problem manifests when counting users who have enabled or disabled Push Messaging. Over time, a user can enable or disable your ability to send them push messages in your app. Since our SDK tracks whether a user has Push Enabled on every event, they can show as being both enabled and disabled if the report time period covers when they switched. A discrepancy can also occur in the number of users push messages are sent to due to known versus anonymous users. For example, if a user enables push messaging while anonymous and later disables push messaging while known, the user will technically be counted as two different users with different push enabled settings.

Let's say you're looking at a Localytics report covering the month of April. A user who had push disabled on April 1 decided to enable it on April 15. If you filter the April 30-day report by Push Enabled, that user would be counted for April. If you remove that filter and instead filter by Push Disabled, they would again be counted for April, since that user was both enabled and disabled over that time period.

The Hotel Problem will also create a discrepancy betweenUnique UsersandTotal Usersover time. For example, when looking at Users by Day, the dashboard is displaying the number of unique usersfor that specific day. However, the summary bar at the top of the screen shows unique usersacross the entire time period, and users will inevitably overlap as they have sessions on different days. So, theUsers by DayTotal column is the sum of users each day instead of the desired time range a perfect example of the "Hotel Problem."

Generally, every time a user launches an application, a Session is created. Each Session represents one instance of a user opening the app. When a user closes the app or backgrounds it for more than the session timeout interval (set to 15 seconds for mobile apps and 30 minutes for web apps by default), the Session is then closed. For more, see Analytics Key Concepts from our User Guide.

A sent push notification does not create a new session unless this notification causes the app to open, which then creates a new session.

Specifically, when usingLocalytics.autoIntegrate():

On Android, sessions are opened/resumed when an activity hitsonStart(), and the timer for session close starts whenonStop()gets hit while no other activities have hitonStart(). Localytics keeps a running counter internally of calls toonStart()/onStop()to do this.

On iOS sessions are opened/resumed whenapplicationDidBecomeActiveorapplicationWillEnterForegroundis called, and the timer for session close starts whenapplicationDidEnterBackgroundis hit.

On the Web, sessions are opened/resumed when Localytics is initialized on a page, and the timer for session closes starts immediately. Event tags or new page loads that initialize Localytics again reset the session close timer.

Using alternative session management instead of automatic integration allows the developer to control session starts and stops to match their own logic.

Within Localytics analytics reports, auseris defined as aunique device. For example, if a user opens the same app once on two separate devices- a mobile phone and a tablet - in Localytics this is noted as two distinct users. If a user only opens the app on one device but does so multiple times, this is noted as one user.

Localytics also exposes contextual information about users, such as whether they areneworreturning. A user is considered new during their first session and returning during all subsequent sessions.

Localytics also allows your app to assign a known identity to users which can be used to power more targeted engagement campaigns; however, these identities are not used for the purpose of counting users within analytics reports. For more, see device and user identification.

Event groups are used to combine a number of Events together to see analytics aggregated from all of those defined Events. Event groups offer similar functionality to single Events in terms of filtering and splitting your data. Creating an Event group may be beneficial if you have a number of Events that you could bucket into a single category (i.e. grouping the viewing of certain men's clothing categories)

To set up and manage Event groups click the image below to view the animation:

Suppose that you track an event calledAdded To Cartwith an attribute calledProduct ID. The values that you pass forProduct IDmight be something like12345.

Localytics has a sophisticated data processing pipeline that allows you to treatProduct IDeither as a numeric value or a string for visualization purposes. Numeric values are grouped into buckets so that you can see the distribution of values, whereas strings are each treated as unique values. For example:

Numeric values:

Treat Event Attributes as Numbers or Text

String values:

Regardless of which option you select in the Localytics interface, Localytics will process the original value12345in its original string format and also recognize that this can be converted to numeric and therefore save a numeric version of this attribute. This is good because it allows you to visualize this attribute as either a string (i.e.an unbucketed, raw value) or as a numeric value (i.e.bucketed into numeric groups).

If Localytics has detected that you passed a value which could be numeric, we will default to showing this as a numeric value, but this can be easily adjusted. For instructions, see. If you don't have the ability to access the Event management section in Settings, you don't have the required level of permissions and should contact an account administrator.

To illustrate:

Typically when you view the Table format for an event, you'll see data that adds up to aTotal.

However, when you split those users by clicking "Add Split", you'll see aUnique User Totalinstead:

Note that this only happens forUsers, notOccurrences.

While the difference is subtle, this feature allows you to view unique users when you otherwise might double count users in the split.

If you export a CSV of the Split By report, you'll notice that summing the column does not add up to the Unique user total since the CSV includes the row values only.

In Localytics, an Event is a timestamped record representing a particular behavior which has occurred within the app. For example, an e-commerce app might trigger an Event called "Added To Cart" each time an item is added to the app's shopping cart. This traditional, granular approach to Event-tagging has the benefit of representing each behavior as a unique, individually-timestamped record, which means that if a user adds five items to a cart during a session Localytics will capture this with five unique timestamped Events (with one data point for each). This approach is advantageous when specific details about each behavior are required for reporting or are required to power downstream engagement campaigns. For example, if you want to be able to see which categories of items are being added to the cart.

Web

However, it can also be advantageous to capture behaviors using a so-called Session Summary Event, particularly in cases where tracked behaviors occur with great frequency. For example, consider a social photo-sharing app that wants to report on the number of photos that are liked during a session. The traditional, granular approach would call for every individual "Photo Liked" event to fire independently, which produces a high volume of data points and is likely to be noisy for reporting purposes. An alternative approach would be to use a Session Summary Event.

In this case, rather than tagging an individual Event every time a photo is liked, the app can be configured to keep track of thenumber of photosthat have been liked during a session and then record a "Session Summary" Event at the close of the session with an Attribute called "Number of Photos Liked". In a gaming app, the same concept could be used to trigger an event called "Level Summary" with Attributes such as "Number of Attempts to Reach Completion", "Number of Points Earned," etc. In a news app, this might be used to report on the number of ads seen during a session.

To summarize using an analogy: Consider a basketball game where there are 100 shots that are made over the course of the game. One way to represent this would be to capture everyindividualshot as a unique, timestamped record with its own individual Attributes (which would produce 100 data points). Alternatively, the summary approach would involve capturing game-level summary statistics in a single record that is triggered when the game is completed, with Attributes that record what happened during the game --e.g.number of shots attempted, number of shots made, etc. (which produces 1 data point). This summary approach can be advantageous both for reporting reasons and to ensure that data points are used strategically and sensibly.

In order to use Summary Events, your developers should configure your app to keep track of statistics that will be written as Attributes (e.g.in the screenshot above, the app would keep track of "Ads Viewed" and then pass this to Localytics as an Attribute). Developer documentation for tagging events is available on our Docs site (e.g. iOS, Android,).

Let's say you are looking at an event and you want to filter it by a specific event attribute value. Upon doing so, all you see are Unspecified and values that are all digits. This is because Localytics has a sophisticated data processing pipeline that allows you to treat data as either a numeric value or a string for visualization purposes. In this case, the event attribute data is being collected as numeric data instead of string (text) data and displaying only numeric values.

If Localytics has detected that you passed a value which could be numeric, we will default to showing this as a numeric value, but this can be easily adjusted. For instructions, see Treat Event Attributes as Numbers or Text. If you don't have the ability to access the Event management section in Settings, you don't have the required level of permissions and should contact an account administrator.

Apple issues push certificates that enable apps to receive messages. Certificates regularly expire after about a year, but a new certificate may be generated on your teams Apple dashboard at any time.

When you see the warning that your certificate is about to expire, your dev team will need to provide a new certificate to be uploaded into the Localytics dashboard viaSettings>Gear icon>Change Certs:

here

Detailed instructions for generating the certificate can be found.

Suppose you want to send a message to a specific device to validate that you have push messaging properly configured, or that you want to launch a message to a specific list of users that you have identified outside of Localytics. This is possible with Localytics, though it is important to understand exactly how this works both to ensure your app is set up properly and so that, if you don't see the expected results, you can troubleshoot quickly.

First some pre-requisites:

Make sure that your app is configured properly for Localytics push messaging, as described in our Developer Documentation ( iOS, Android ).

Make sure you or your developers have uploaded a valid push certificate for your app in the Localytics Settings page (as detailed in the Developer Documentation).

Make sure that any device you intend to target has successfully completed a session in a version of the app with Localytics installed.

In order to target a specific user or set of users:

Localytics allows your app to optionally assign an identity to users that interact with your app which can subsequently be used for targeting purposes. For example, if I use your app and your app knows me asUser12345then the app can tell Localytics this by calling[Localytics setCustomerId:@"User12345"];on iOS or similarlyLocalytics.setCustomerId("User12345");on Android ( iOS, Android ). Localytics refers to these identifiers as Customer IDs. If your app is configured to identify usersandLocalytics has the Customer ID on record, you can target based on this.

To target campaigns to a specific Customer ID, you have two options. If you're comfortable with APIs, we have a straightforward Push Messaging API that allows you to target push messages to specific Customer IDs.

If APIs aren't your thing, you can achieve the same result in a few simple steps. First, you assign an attribute to the Customer IDs you want to message, then limit the target Audience to include only users with that attribute. For example, to targetUser12345you could assign an attribute to this user calledTest Audiencewith a value ofTrue. This can be easily achieved by uploading attributes via a CSV file. Once you've done this, you simply create an Audience like so:

Why is the estimated Audience size different than the number of messages sent?

Be aware that there are a number of reasons why the preliminary Audience count might be different than you'd expect. See for more. Also, note that it's possible for the same user identity (Customer ID) to be observed on multiple devices and Localytics will by default send to the last device on which a Customer ID was active.

You may want to display an in-app message to users the first time they ever open the app. You can achieve this with Localytics if your Audience is defined to include all users and you schedule the message as described below.

Why "all" users? Because when a brand new user opens your app, Localytics is observing this user for the first time and onlyafterwe have observed the user can that user qualify for membership into a segmented Audience (i.e.they can only qualify for an Audience with more targeted conditions on their second visit or later). If you targetallusers, on the other hand, Localytics doesn't have to perform any segmentation to identify Audience membership, so we can successfully deliver messages to all new users.

To achieve this, you will need to create an in-app message and enter a trigger that Localytics automatically fires on a user's first session. While the trigger is configured within your app's codebase to automatically fire by Localytics, the name of the trigger must be entered manually within the UI; it is not exposed as a default option in the drop-down. If you use this approach, only new users will receive the in-app on their first launch of the app:

Go to messaging ->Create new in-app message

Set the audience toEveryone

Add your In-app creative

On the Scheduling page, select "AMP First Run" as the event. If the event doesn't show up in the dropdown, you can add it by typing it in and selectingAdd Option: AMP First Run

(This ampTrigger is automatically coded into your SDK so there is no additional development work required)

Confirm the setup of your campaign and you're good to go! The AMP First Run trigger will automatically target users that Localytics hasn't seen before (new users). This is a great way to improve the onboarding experience for your new users. You can include GIFs, videos, etc, to show users what your app is about and get them to engage from day one!

Localytics in-app messages can be generated codelessly using our creative builder, or you can upload custom HTML/CSS/Javascript which will be rendered as a web view. You may want to include a call to action (also known as a CTA) within the creative that, when clicked, links the user to a location outside of the app (like a website).

If you are uploading a custom creative, you will need to append two parameters to the end of your URL to tell the Localytics SDK to open the link outside the in-app message and to tag the impression. The parameters that should be appended areampExternalOpenandampAction.

Here is an example of a properly-constructed link that, if clicked within an in-app message, would send the URL-clicking user to the Localytics Docs site:http://docs.localytics.com/?ampExternalOpen=true&ampAction=click

Localytics logs users once they open the app for the first time. This means that Localytics measures app usage, not app downloads. If a person downloads your app but never opens it, Localytics will not count this person as a new user. If you are comparing Localytics data to data from other sources, remember that Localytics measures app usage, not app downloads.

Yep! The minimum size for the in-app dismiss button is 25 points.

For more on how to customize the dismiss button on in-app messages, see:

Android - customizing in-app dismiss button

iOS - customizing in-app dismiss button

You may set up multiple in-app campaigns to run simultaneously with the same triggering event,e.g.session start. Some users might qualify for several of these campaigns, so Localytics must use prioritization logic to decide whether both messages should display sequentially and, if so, in what order.

To resolve this, Localytics will not display the messages sequentially to avoid a potentially negative user experience. Instead, we will render only the earliest-created in-app message, where "earliest" is defined as the lowest campaign ID. If the user then performs the triggering event again and still meets the qualification criteria, then the user will receive thenextin-app message.

There are many metrics available to measure the performance of your push messaging campaigns. These include:

Click rate:percentage of users who opened a push notification

Conversion rate:percentage of users who did a conversion event after clicking on your message

Engagement:Average number of sessions per user after viewing a push notification

Conversion frequency:Average number of conversion events completed per user after viewing a push notification

Revenue:Average new revenue per user after viewing a push notification

To understand whether a campaign is successful, it is important to understand what the goal of the campaign is. Are you sending the campaign to increase engagement with the app in general, or is there a specific conversion behavior you are trying to encourage? Once you have established a clear goal, you can measure success in terms of your campaign's impact on that goal.

The best way to measure the direct impact of your campaign is to include a control group when you are setting up a campaign. A control group is a small group of your campaign's audience who do not receive a message from the campaign. Measure lift over the control group for each performance metric to understand exactly how much your messages move the needle.

Here are some examples of campaign goals and the best metrics to measure:

If you want toincrease visits to your app, measurelift in engagement.

If you want todrive more purchases, measurelift in conversion frequencyfor your purchase event.

If you want todrive more subscriptions, measurelift in conversionsfor your subscription event.

If you want toincrease revenue, measurelift in revenue.

Learn more about campaign metrics and the best way to measure success using Localytics True Impact on our blog.

Frequency capping for in-app is implemented on a device install level. The capping is calculated client-side to ensure that its always up to date and will work offline, but this also means it behaves somewhat differently than our server-side capping for push notifications. There are two reasons why a device which was supposed to receive an in-app once, ends up receiving the in-app more than once.

App is reinstalled or data is cleared

When the app is uninstalled, all the data will get wiped out which includes the rules for the in-app that specify frequency capping. If the app is reinstalled and the campaign is still running, the device will qualify again in which case the in-app payload will get downloaded again on the app.

User has multiple devices

If the user has more than one device, they will see the in-app more than once as the payload will be sent to all the devices that user interacts with and the rules will be specified locally on each device.

Apple recently changed the format of the .p12 file to a universal certificate.

New .p12 certifications now contain multiple keys, but our Localytics servers currently only handle single key certifications. In order to distill these certifications for appropriate upload to our servers, please follow these steps:

Download the combined .p12 file from Apple Developer website

Double click on the file to open it in Keychain Access (or drag the file into an open Keychain Access window)

In Keychain Access, click on "My Certificates" and you should see two new certificates.

Right click on the Apple Push Services certificate, and select Export (password is not required)

This newly created .p12 should contain only the Push certificate and should be able to be uploaded via the dashboard.

Localytics in-app messages can be generated without writing code using our creative builder, or you can upload custom HTML/CSS/Javascript which will be rendered as a webview. You may want to include a call to action (also known as a "CTA") within the creative that, when clicked, links the user to a location outside of the app, like a website or another page within your app.

If you are uploading a custom creative, you will need to append two parameters to the end of your URL/URI to tell the Localytics SDK to open the link outside the in-app message and to tag the impression. The parameters that should be appended areampExternalOpenandampActionas a query parameter.

Here is an example of a properly-constructed link that, if clicked within an in-app message, would send the URL-clicking user to the Localytics Docs site:http://docs.localytics.com/?ampExternalOpen=true&ampAction=click

To make the CTA within the app, replacehttp://docs.localytics.com/with a URI your app recognizes and append withampExternalOpenandampAction

At this time, all information within the Inbox is client-side.

What this means is that if a user views all the messages within the Inbox, then uninstalls and reinstalls the app, the messages will be shown as unread. This is due to the information being in a client-side state so the app is not aware of what occurred prior to when the app was uninstalled.

We recommend using the iPhone 6+ size as it will render identical on the iPhone 6 so that you don't need to worry about segmenting out iPhone 6 vs. 6+. Here are the specific phone specs that should be running:

Phone 6: 375x667 pointsiPhone 6+: 414x736 points

If you want to bridge things into the native app, this is commonly done by registering protocol handlers. Have the app register a protocol handler if it doesn't already, which would make it handle all URLs for a certain path, likeyourapp://example/example.

If you wanted to deep link into your settings page, for instance, you could do it by having the call to action of your creative specifyyourapp://settingsPageas the target URI.

Similarly, on the app side, you would write code that would register your app to intercept this URL, parse it, and do something interesting with the payload (in this case, navigate to the settings page).

Key-value pairs (a.k.a. name value pairs) allow the app publisher to pass along special instructions for the app along with a push notification. This functionality is commonly used for deep linking users into particular parts of the app after they have opened a push notification.

A news app, for example, may send a breaking news alert via a push notification, and it might include a key named "Article ID" and a value of "10042" along with that push. This relies on the app developer having encoded logic into the app that understands the "Article ID" key and how to handle the value appropriately.

When you create a new In-App message, we allow you to create and upload custom HTML, CSS and Javascript to fully customize the look and feel of the message. Here's an example HTML file you can use as a reference to build your own In-App Message:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Localytics In-App Message</title>

<script type="text/javascript">

function openDeeplink() {

window.open("appdeeplink://alert?ampAction=click");

localytics.close();

return false;

}

</script>

</head>

<body>

<a rel="noopener,nofollow" target="_blank" href="https://support.localytics.com/hc/en-us/articles/360001447133-How-should-I-code-my-custom-In-App-or-Inbox-message-#" onclick="openDeeplink();"><img src="http://www.localytics.com/images/3_session.gif" width="2000" height="1667" /></a>

</body>

</html>

You can either upload a single HTML file with all CSS embedded inline, or a.zipfile containing anindex.htmlfile and any needed CSS or images.

For more information on our In-App Javascript API, see our docs for iOS and Android.

There can be any number of reasons why you're not receiving an in-app campaign. If this is your first campaign, you'll want to ensure that you have the Android or iOS integration built correctly. If this isn't your first in-app campaign, some things to check include:

If you're using a custom creative element, is it too large or formatted incorrectly? The maximum file size for a custom in-app creative is 500 KB.

Is your campaign targeted to a custom audience? There could be a slight delay in segmentation, or you may not qualify into that audience

Always ensure you have a network connection to either cellular or Wi-Fi

If you have corrected for all of the above and are still not receiving the message, contact Support.

In-app messages can play a unique role in your app marketing strategy. By enabling you to reach users while they are already engaged in your app, they offer an opportunity to deepen the app experience with targeted, contextually-relevant content.

Onboard new users by using in-app messages during the first-time user experience

Highlight new app features

Target highly-engaged users with subscription offers

Send Net Promoter Score (NPS) Surveys and get promoters to rate your app in the App Store

Here are some recommendations for creating compelling in-app messaging campaigns:

Consider the context and target audience for your message. In Localytics, you can trigger an in-app message to display at session start, or upon a specific event in the app.

Use compelling imagery. In-app messages are fully customizable with HTML. Eye-catching message design is sure to capture user interest.

Include a clear call to action. Make it clear to your users what you want them to do next.

Use targeting to reach people at the right stage in the user lifecycle. You don't want to send a subscription offer to a brand new user, or an onboarding message to a long-term user.

For additional recommendations, check out our extensive best practices blog here

You can easily duplicate an in-app message campaign that is a Draft or an Active campaign. Just go to theMessagingsection, select the campaign you're interested in and click on theDuplicateoption. Please note that you cannot duplicate in-app message campaigns that are Expired, Sent, or Scheduled.

Push notifications campaigns can be duplicated regardless of their state (i.e, Draft, Active, Scheduled, Sent, Expired).

The discrepancy you're seeing in delivery is likely related to the fact that you are testing in a dev environment. A user will only be qualified for a push notification if they have a true session within Localytics, meaning the app was opened, push notifications were accepted, and the app was then opened again. In the instance of a dev environment, devices are typically constantly being reset which would render the push certificate invalid for that particular device. In addition, if the user accepts push notifications and then never opens the app again, they would never have a session registered with "push enabled."

This article assumes you are integrated withSDK v5.2 or aboveand have properly integrated In-App messaging.

Available In-App APIs

Localytics provides a number of APIs within its In-App messages which can be used to prompt users for permissions:

On Android:

//Prompt the user to provide location permissions

localytics.promptForLocationPermissions("action");

On iOS:

// An integer representing the current location authorization status as defined in CLAuthorizationStatus

localytics.locationAuthorizationStatus

//Prompt the user to provide location permissions always

localytics.promptForLocationAlwaysPermissions("action");

//Prompt the user to provide location permissions when the app is in use.

localytics.promptForLocationWhenInUsePermissions("action");

The above APIs will help you prompt the user, but in order to define an ideal user workflow, you may want to better understand the permission prompt process and potentially collect some additional information.

Permission Workflow

Android

Android introduced permission prompts in Marshmallow (Android 6, API level 23). Android allows the developer to request permissions from the user, and after the second request, the user has the option to suppress future permission requests.

To understand the devices current state Android provides a few APIs:

ActivityCompat#checkSelfPermission: This method will return a boolean indicating if the user is opted into a permission or not.

ActivityCompat#shouldShowRequestPermissionRationale: This method will return a boolean indicating if the app should attempt to show rationale behind their desire for a permission. This value is true if the user has denied the requested permission in the past, and hasnt suppressed all future permission requests.

(More info can be found in the Android Documentation )

We can visualize this behavior in the following chart:

Triggering the In-App

iOS

Starting with iOS 11, requesting location permissions from a user has been broken up into a multi-step process, as suggested by Apple. For apps thatdon'thave a requirement on geofencing or background location information, Apple suggests first requesting location permissions when the app is in use, and only some time after requesting and providing those permissions should the app request location permissions always.

Apple will enforce that the customer is not overly bothered by OS prompts by only showing one prompt of each type per app install. This means that you can only prompt the user once for when in use permissions, and regardless of if they accept or reject they will never be shown the OS prompt again for this app install. Similarly, the permission prompt for location always will only be shown once, but it will also be suppressed if the user denied the when in use permission, or has gone into settings and turned off location permissions for your app.

Because of this restrictive behavior, it is imperative that you set up a proper workflow to ensure maximal permission opt-in rates. We can visualize all the possibilities in the following chart:

In each flow chart, there is at least one dead end that results in no OS prompt for the user, despite requesting there be one. If any In-App message calls any of the permission prompt APIs when in the dead end state, the In-App will be dismissed without showing an OS prompt, resulting in bad user experience. In order to avoid these dead ends, it is up to you to only show an In-App message that attempts to request permissions when you know the user can be prompted by the OS.

Unfortunately, the state of the device at the time of potential dead end can be indistinguishable from valid prompting states when using the OS provided APIs. To ensure we know what state we are in, we need to capture one more piece of information: has the user been prompted before. We can then take advantage of this information to only show an In-App when the user can see the OS prompt.

To achieve this, we suggest triggering the permission prompt off of a specific event. Additionally, the app should keep track of whether or not the device has shown the OS level prompts for permissions in the past and add that as an attribute attached to the event (in addition to the current Location permission status):

On Android:

int locationPermissionGranted = ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION);

boolean shouldShowRationale = ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.ACCESS_FINE_LOCATION);

attrs.put("Can Show Rationale", Boolean.toString(shouldShowRationale));

attrs.put("Has Seen Location Prompt", Boolean.toString(hasPromptedForLocationPermissions()));

attrs.put("Location Permission Authorization", Boolean.toString(locationPermissionGranted == PackageManager.PERMISSION_GRANTED));

Localytics.tagEvent("location-prompt", attrs);

On iOS:

- (void)viewDidAppear:(BOOL)animated{

[super viewDidAppear:animated];

[Localytics tagEvent:@"location-prompt"

attributes:@{

@"Location Authorization":[self locationAuthorizationStatusString],

@"Has Prompted For Location When In Use": [self hasPromptedForLocationWhenInUse],

@"Has Prompted For Location Always": [self hasPromptedForLocationAlways],

}];

}

- (NSString *)locationAuthorizationStatusString {

CLAuthorizationStatus status = [CLLocationManager authorizationStatus];

if (status == kCLAuthorizationStatusDenied) {

return @"Denied";

} else if (status == kCLAuthorizationStatusRestricted) {

return @"Restricted";

} else if (status == kCLAuthorizationStatusNotDetermined) {

return @"Not Determined";

} else if (status == kCLAuthorizationStatusAuthorizedWhenInUse) {

return @"When In Use";

} else if (status == kCLAuthorizationStatusAuthorizedAlways) {

return @"Always";

}

//Shouldn't get here, but just in case.

return [NSString stringWithFormat:@"%d", status];

}

Take advantage of the events you tagged to only show the In-App to users who can see the OS prompt (This image follows the iOS workflow specifically):

Apps Running SDKs Below Version 5.1

If your app is using a version of the Localytics SDK below version 5.1, the beginning or end of Daylight Savings Time can cause messages using timezone-based delivery to be sent earlier or later than you intend them to be sent. Before SDK 5.1, a users timezone is recorded as the number of hours before or after UTC (for example, UTC -5). This offset is updated whenever the user opens your app.

When Daylight Savings begins or ends, the offset changes. For example, at the start of Daylight Savings Time, the Eastern Timezone goes from being UTC -5 to being UTC -4. As a result, after the start or end of Daylight Savings, we will not have accurate timezone information for your users in regions that observe Daylight Savings until they open your app. Users in regions thatdon'tobserve Daylight Savings will be unaffected. This can result in some odd behavior for campaigns that are using timezone-based delivery:

In the spring, users who havent launched your app since Daylight Savings started will receive your message one hour later than you intended.

In the fall, users who havent launched your app since Daylight Savings ended will receive your message one hour earlier than intended. If you have switched the starting timezone from the default of the international dateline to a timezone that is undergoing the change in Daylight Savings, users in that starting timezone who havent opened the app since the end of Daylight Savings will receive the message 23 hours later than intended.

If you are sending a message in the week after a change to Daylight Savings and the message must be received at a specific time, we recommend you modify your campaigns Audience to only target users who have opened your app since the change. Then duplicate the campaign, adjust the Audience to only target users who havent opened the app since the change, and change the scheduling as follows:

In the spring:Schedule the message to send one hour earlier than you normally would

In the fall:Schedule the message to send one hour later than you normally would and make sure you leave the starting timezone on the international dateline. Changing the starting timezone will result in users who havent opened the app since the end of Daylight Savings receiving the message 23 hours later than intended.

To target users who have launched the app after the change in daylight savings, add the following Profile criteria to your Audience: Last Session Date > is on or after > (pick the date on which the change in Daylight Savings occurs) > (date)

duplicate

To target users who have not launched the app since the change in daylight savings, add the following Profile criteria to your Audience: Last Session Date > is on or before > (pick the day before the date on which the change in Daylight Savings occurs) > (date)

Apps Running SDKs Above Version 5.1

Beginning with Version 5.1 of the Localytics SDK, we record a user's timezone using the actual timezone name (e.g. "America/Los_Angeles"), instead of a UTC offset. On our end, we track when changes to Daylight Savings occur and automatically update our systems to reflect the change in time. This ensures that users will receive all messages at the intended time, without requiring the user to open the app. As a result, theres no need to make any adjustments to a message's send time in order to compensate for Daylight Savings if your app is running SDK Version 5.1+.

If you have recently upgraded your app to SDK 5.1+, theres a good chance that many of your users havent updated the app on their device yet. These users will still encounter the issues afflicting older versions of the SDK. If you are sending a message in the week after a change to Daylight Savings and the message must be received at a specific time, we recommend you modify your campaigns Audience to only target users who have used a version of your app that uses the Localytics SDK version 5.1+. Thenthe campaign, adjust the Audience to target users who havent used a version of your app with Localytics SDK 5.1+, then follow the targeting and scheduling instructions provided above for apps running older versions of the SDK.

To target users of your app running SDK 5.1+, add the following Profile criteria to your Audience: Last SDK Version > is one of > (pick all versions listed with numbers greater than 5.1.0)

To target users of your app running an SDK below 5.1, add the following Profile criteria to your Audience: Last SDK Version > is none of > (pick all versions listed with numbers greater than 5.1.0)

Keep in mind that although the new approach used starting in SDK 5.1 automatically compensates for Daylight Savings, if the user physically moves to a location in a different timezone, they still need to open the app in order for Localytics to learn that the users timezone has changed.

Problem:

Upgrading from SDK 5.0 to SDK 5.1 results in a deadlock if any Profile API calls are made from an Analytics Delegate Callback.

Example:

- (void)localyticsSessionWillOpen:(BOOL)isFirst isUpgrade:(BOOL)isUpgrade isResume:(BOOL)isResume;

{

NSDictionary *attributes = @{@"isFirstSession": isFirst ? @"true" : @"false",

@"isFirstSessionAfterUpgrade": isUpgrade ? @"true" : @"false",

@"willResumeOldSession": isResume ? @"true" : @"false"};

NSString *tag = [NSString stringWithFormat:@"delegate_event_willOpen_%lu",(unsigned long)self.count];

// The following line will result in a deadlock.

[Localytics setValue:@"test" forProfileAttribute:@"testing"];

[Localytics tagEvent:tag attributes: attributes];

}

The Profile related calls will result in a deadlock when called from any of the following callback methods:

(void)localyticsSessionWillOpen:(BOOL)isFirst isUpgrade:(BOOL)isUpgrade isResume:(BOOL)isResume

(void)localyticsSessionWillOpen:(BOOL)isFirst isUpgrade:(BOOL)isUpgrade isResume:(BOOL)isResume

(void)localyticsDidTagEvent:(NSString *)event attributes:(NSDictionary *)attributes customerValueIncrease:(NSNumber *)customerValueIncrease

(void)localyticsSessionWillClose

Workaround:

- (void)localyticsSessionWillOpen:(BOOL)isFirst isUpgrade:(BOOL)isUpgrade isResume:(BOOL)isResume

{

NSDictionary *attributes = @{@"isFirstSession": isFirst ? @"true" : @"false",

@"isFirstSessionAfterUpgrade": isUpgrade ? @"true" : @"false",

@"willResumeOldSession": isResume ? @"true" : @"false"};

NSString *tag = [NSString stringWithFormat:@"delegate_event_willOpen_%lu",(unsigned long)self.count];

dispatch_async(dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{

// Wrapping the call in dispatch_async prevents the deadlock.

[Localytics setValue:@"test" forProfileAttribute:@"testing"];

});

[Localytics tagEvent:tag attributes: attributes];

}

At a high-level,Eventsare user actions that the app recordsfor example, "Added to Cart."

Each Event may optionally include additional descriptive information calledEvent Attributes. Whereas Events capture actions such as adding an item to a shopping cart,Attributesrecord additional context such as the name of the product, category, or price.

As a user of Localytics, the process to have those actions recorded and available on your dashboard is as follows:

Your team identifies a particular action that the app should track (ie.Added to Cart) as well as any additional information that should also be included when that behavior is recorded (ie. Product, Category, Price, etc).

Your developers implement the following piece of code in the app:

Localytics.tagEvent("Added to Cart", attributes: ["Product" : "Widget", "Category" : "Gadgets", "Price" : "50"])

Data appear in the Events screen in the dashboard:

The Retention report allows you to see how often new users are returning to your app. Use the Retention report to gauge user loyalty and see which behaviors drive repeat engagement. You can also compare retention among subsets of users.

Using the Retention Dashboard

Not Seeing Results for Specified Date Range

The Retention report summarizes the percentage of users who return to your app after a certain amount of time. The table displays the number of users who first used the app on a given day. It then shows the percentage of those users who returned one, two, three, or more days later. The table can also be adjusted to display retention dates Weekly or Monthly.

Like most analytics reports, Retention can be filtered By Dimension and By Profile. Read more about these Filters in the analytics report article.

Data from this report can be exported as a CSV or PDF, sent as a scheduled email, or saved in a custom Dashboard.

Session-Based Retention

Selecting this option will allow you to see the percentage of users who first used your app, and then returned to use it a second time on a later date.

Event-Based Retention

Selecting this option will allow you to track user retention based on the completion of two Events. The % of Users Returning will be based on the time it took a user to complete both Events. This means the user completed the first event, then left the app, then returned at a later date to complete the second event.

When setting your Events, its also possible to include up to four conditions for each Event to further refine your results.

Troubleshooting Retention Dashboard Results

If you're hitting an issue where you're not seeing the correct results for your date range, you could be running into a limitation of the Query API. The max number of results returned for Retention data is 30,000.

If you're running a query for a 1-year long range, you could end up having a result set size of 365x365, or 133,225 resultswhich is well above the results limit.

As a workaround, you can run the query with a reduced date range (ie, 3 months at a time) and then concatenate those results into the full year's results.

Many customers find it useful to show their users how many unread inbox messages they have from outside the app by using badging. Badging will add a small red circle with a white number to your app's icon.

Limitations

You can achieve this with Localytics Inbox. Follow the steps for iOS and/or Android.

iOS

iOS makes it very simple to update the Apps badge with one API call:

[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeNumber];

At any point you may get the unread count of your Localytics Inbox messages with the following API:

NSInteger unreadCount = [Localytics inboxCampaignsUnreadCount];

Note: The above method should not be called from the main thread.

First, you must ensure that your app has requested permissions for application badging:

if ([UNUserNotificationCenter class]) {

UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];

UNAuthorizationOptions options = (UNAuthorizationOptionBadge);

[center requestAuthorizationWithOptions:options

completionHandler:^(BOOL granted, NSError * _Nullable error) {

[Localytics didRequestUserNotificationAuthorizationWithOptions:options granted:granted];

}];

center.delegate = self;

} else if ([application respondsToSelector:@selector(registerUserNotificationSettings:)]) {

UIUserNotificationType types = (UIUserNotificationTypeBadge);

UIUserNotificationSettings *settings = [UIUserNotificationSettings settingsForTypes:types categories:nil];

[application registerUserNotificationSettings:settings];

}

Next, to make sure this number is kept up to date, you should be sure to update it whenever the app is launched and when the unread count changes.

To update the count when your app is launched, add the following code to your UIApplicationDelegateapplication:didFinishLaunchingWithOptions:methodafter callingintegrate:

[Localytics refreshInboxCampaigns:^(NSArray<LLInboxCampaign *> * _Nullable inboxCampaigns) {

//This callback is always made on the main thread.

NSInteger unreadCount = 0;

for (LLInboxCampaign *campaign in inboxCampaigns) {

if (!campaign.isRead) {

unreadCount++;

}

}

[[UIApplication sharedApplication] setApplicationIconBadgeNumber:unreadCount];

}];

For users with standard inbox integrations, this will mean overriding theLLInboxViewControllerclass and itstableView:didSelectRowAtIndexPath:method as follows:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

[super tableView:tableView didSelectRowAtIndexPath:indexPath];

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

// This Localytics API should not be called on the main thread.

__block NSInteger unreadCount = [Localytics inboxCampaignsUnreadCount];

dispatch_async(dispatch_get_main_queue(), ^{

// UIApplication calls should only be made on the main thread.

[[UIApplication sharedApplication] setApplicationIconBadgeNumber:unreadCount];

});

});

}

Additionally, for users with Push enabled, you may send a silent Push notification which will update the badge count when the app is in the background. To do so, ensure you have properly integrated Push messaging. Next, in yourAppDelegate'sapplication:didReceiveRemoteNotification:fetchCompletionHandler:, update the inbox badge number:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo

fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler

{

[Localytics handleNotification:userInfo];

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

// This Localytics API should not be called on the main thread.

__block NSInteger unreadCount = [Localytics inboxCampaignsUnreadCount];

dispatch_async(dispatch_get_main_queue(), ^{

// UIApplication calls should only be made on the main thread.

[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeNumber];

completionHandler(UIBackgroundFetchResultNoData);

});

});

}

Android

While Android doesnt have a perfect equivalent to badging on iOS, Android O introduced a similar feature which may be used in its place.

On Android, the badge is strictly a "notification dot," which when expanded via long press will show a number of notifications and some quick text.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

(NotificationManager) notificationManager;

NotificationChannel channel = new NotificationChannel("badging-updates", "Miscellaneous", NotificationManager.IMPORTANCE_MIN);

channel.setShowBadge(true);

notificationManager.createNotificationChannel(channel);

}

Because Android will always dismiss the notification dot when a notification is received, it doesnt make sense to update a badge number when the app is open. Instead, we will only update the badge whenever any notification is received. Your app will have to handle its own push messages as a result. If your app does not have a custom push handler, please consult the dev docs. The following code assumes a Firebase integration and updates code in theFirebaseMessagingService#onMessageReceived:

@Override

public void onMessageReceived(final RemoteMessage remoteMessage) {

super.onMessageReceived(remoteMessage);

Map<String, String> data = remoteMessage.getData();

Localytics.integrate(getApplicationContext());

Localytics.handleFirebaseMessage(data);

Localytics.refreshInboxCampaigns(new InboxRefreshListener() {

@Override

public void localyticsRefreshedInboxCampaigns(List<InboxCampaign> campaigns) {

int unreadCount = 0;

for (InboxCampaign campaign : campaigns) {

if (!campaign.isRead()) {

unreadCount++;

}

}

Notification notification = new Notification.Builder(MainApplication.this, "badging-count")

.setNumber(unreadCount)

.setSmallIcon(R.drawable.ic_launcher)

.build();

//Generate a random notification ID.

notificationManager.notify(1, notification);

}

});

}

Triggering push messages to update the badge

Finally, to actually trigger a silent push notification, you can use the Localytics dashboard to send a recurring push campaign with no content (no push title, subtitle, message body or rich attachment):

This will wake the app up and cause it to update the badge, but not present any notification to the user if the proper integration was followed.

This solution will help you keep a relatively up to date badge number but it has some limitations:

App badging is more "native" to iOS than Android.

The app may only update the badge client-side. Localytics does not provide any server side APIs which would allow you to retrieve the Inbox unread count and update the badge number.

The Localytics unread count may not be 100% up to date when called from a background state (in the case of silent Push). The returned number will only be indicative of campaigns currently downloaded to the device. This means that an Inbox message that was created between the last session and the current background update may not be reflected in the unread count.

Users may turn off app badging in their settings.

iOS Limitations

Background updating of badge count will only succeed if the user has an up to date push token and the app is in a backgrounded (not terminated) state.

The Badge count is not updated in real-time but is refreshed on application launch

Silent push notifications are not guaranteed to wake the app up as the OS itself may choose to suppress them.

Android Limitations

This functionality is really designed for iOS, and Android doesnt have a proper equivalent.

Androids pseudo equivalent is only Android O and up, which means a number of your users on older OS versions will not benefit from badging.

The badging number is hidden by the OS.

Notification badging can be turned off in the settings globally(not just on a per-app basis).

What is Attribution

How Localytics Understands Attribution

Attribution vs. Acquisition

Why Attribution is Important

Types of Attribution

Ad Network Integration

Ad-tracking Vendor

Custom Redirect URLs

Some Terms to Know

Attribution Report

What is Attribution

Reading time: 5 minutes

This guide is intended to introduce you to what Attribution is, and how you can make sure it's implemented properly.

Attribution in Localytics helps you find where your users originated. All app users come from somewherewhether thats a paid Facebook ad, a download link via email, or even organic traffic in the app store. To help you tell the full story of your users lifecycle, we have a feature called Attribution.

Attribution helps you figure out the download source for your app, so you can better target new users in the future.

How Localytics Understands Attribution

You should think of Localytics as just a piece of your whole attribution puzzle. Our attribution features allow you to connect data from your current attribution partner (or partners) to give you a better picture of your customer lifecycle.

Its important to note that Localytics should not replace your attribution partner, but instead join in your data suite.

Attribution vs. Acquisition

Sometimes Attribution and Acquisition are used interchangeably in the marketing world. But in our case, Localytics can help you understand usersyou'vealready acquiredand then we can backtrack through your acquisition channels to get a clearer picture of how those users interact with your app. At this time, Localytics attribution feature is not built to help you acquire new users.

You should use an outside source for your acquisition productand then Localytics can connect the dots to your current users via attribution.

Why Attribution is Important

Knowing what your users do in your app is only one piece of the puzzle. Youre likely tracking what your end users click outside your app, and Localytics can take care of what your users do within your app.

Attribution allows you to connect these two siloed pieces of datahelping you to invest in conversions instead of clicks or installs.

Handling App Store Differences

App stores ultimately decide what information is available to your app, in regards to attribution. Google and Apple have different rules for this, so its important to make sure youre following them each correctly.

Google allows you to use regular UTM data to pass information to your app from the originating URL. Apple does not allow for UTM parameters, so we recommend checking out this article for more information.

Types of Attribution

Localytics helps you connect users to their attribution source through three mobile attribution methods. Those methods are:

ad network integration

ad-tracking vendor integration

custom redirect URLs

Ad Network Integration

Ad network integrations receive data from a third-party source.

Ad networks can communicate information about which URL devices clicked in order to download your app. Localytics then matches this information to report originating ad network and campaign. Well communicate that information back to your ad network, notifying them of the install. Read more here.

Ad-Tracking Vendor

Like ad network integrations, add-tracking vendor integrations receive their data from a third party source (in this case, the ad network), as opposed to Localytics.

Ad-tracking vendorsdon'tdisplay ads themselves but pull together data from a variety of ad networks. From there,they'reable to determine the originating ad network and source through custom work.

Theyre then able to relay that information to Localytics when the end user opens the app for the first time. For more on ad-tracking vendor integrations, check out this article.

Custom Redirect URLs

The last type of attribution source is custom redirect URLs. These can come from Localytics! Well generate a redirect URL so that we can directly track devices that click the link. If were able to observe a matching device in our data, well report the originating ad network and campaign. For more on redirect URLs (for non-integrated sources), check out this article.

Some Terms To Know

There are a few words that are used in the Attribution space that are helpful to know before you dive in. The main two are postbacks and device fingerprinting.

Postbacks

Postbacks are a programmatic way for one system to communicate with another system. In the attribution context, Localytics will issue a postback to the integrated ad network once we learn that a new device has originated from that network.

By sending this information, the integrated ad network can keep track of how many users have actually opened the app.

In some cases, Localytics also supports event postbacks. This means that if you acquire users from app-install campaigns on select integrated ad networks, you can designate specific events tracked by Localytics that we postback to the originating ad network.

When a user you acquired from an integrated ad network completes one of the in-app events you designate, Localytics uses an API call to send the information back to the network.

Localytics supports posting back the Event name; it does not support posting back Attribute values or associated revenue values. Not all integrated ad networks allow for Event postbacks. Check out this article for a list of those currently available.

You should only select important conversion events to postback. Do not postback all in-app events, as doing so will dilute the significance of event postbacks as indicators of end-user value. Consider designating events for postback that indicate monetization (e.g. user completed an in-app purchase), engagement (e.g. end user completed my app's tutorial), community contribution (e.g. user rated an item).

Device Fingerprinting

As noted above, redirect URLs work by briefly routing URL-clicking devices to a Localytics destination for an invisibly brief period of time, just long enough for Localytics to collect device information before redirecting to the intended download destination.

When available, Localytics collects standard advertising identifiers which have the benefit of being definitively unique. These identifiers are not always accessible, for example, if you include URLs to drive downloads in email, mobile web, or organic social media campaigns. Notably, iOS has a more restrictive model that often makes traditional redirect URLs impractical due to the unavailability of devices' IDFA, as described here.

Given this, Localytics also supports a special type of attribution called "fingerprinting." Fingerprinting is functionally similar to traditional redirect URLs, except that rather than depending on a device's advertising ID, Localytics will retrieve a number of other device identifiers that are individually non-unique, but can be combined to create a single unique identifier, i.e. a device "fingerprint."

This method has the advantage of allowing you to track installs that otherwise would not be trackable if you were to only depend on advertising IDs. A rarely-observed disadvantage, however, is that under some idiosyncratic conditions outside our control device fingerprints may end up being non-unique and therefore not function as expected - e.g. if a high volume of people in the same area with the same device model download the same app at the same time.

The collection of identifiers for fingerprinting, as well as any advertising IDs used for attribution, is dependant upon those identifiers being made available for collection either through appropriate end-user consent, end-users data availability, or any other third party data collection and transfer rights. As Localtyics does not have a direct relationship with your end users to confirm appropriate data availability, we cannot guarantee all data is available. It is up to you to ensure all appropriate bases required for collecting this data are in place, and the data is available for processing.

Attribution Report

Once you've set up your campaigns, you can view their success in the Attribution Report. Click into any of the campaigns you're running to see more details about them. For more on the Attribution Report check out our article.

Overview

Building an Audience

Behavioral Conditions

Profile Conditions

Calculating the Size of Your Audience

Overview

Building an Audience is essential to sending a relevant message to your users. Audiences allow you to segment your users based on their behaviors within your app (and your messages) and their profiles. Audiences can be built using Events, Sessions, or Profiles data.

Audiences are also highly customizable. Some profile and behavioral attributes are tracked by default with the Localytics SDK out of the box. While others you can create and track using your own additions to the SDK. Talk to your development team or your Mobile Engagement Consultant (MEC) for more information.

When building an Audience, youll want to keep two things in mind:

Segmenting your users to give them the most possible value from the message

Keeping the audience large enough that youre actually getting a return on your investment in the message

Building an Audience

The first thing youll want to do is give your Audience a name. Make sure to give your Audience a descriptive nameas youll be able to access your Audiences from different parts of the product (messages, remarketing) by its name.

When you build an Audience, you can pick Behavioral Conditions or Profile Conditions. You can also build an Audience of both.

Behavioral Conditions

To add a Behavioral Condition, click the + Add Behavioral Condition button.

To begin, youll have the option of choosing to target behaviors on each individual device, or across a persons devices. So ifyou'vegot a user whos logged in on both their iPad and iPhone, youdon'thave to worry about double messaging them.

You also have the option of choosing the timeframe of the behavior. The default Localytics options are:

Last 180 days

Last 90 days

Last 60 days

Last 30 days

Last 7 days

If none of these options work for you, you can select your own last day option by choosing last from the list, and filling in your own number of days.

You can also choose a static date range by selecting static range from the drop-down.

Finally, you can get even more granular by choosing an hour window. Pick a window of time (ie, within the last 3 to 5 hours) to target users within.

Next up, youll want to pick the actual behavior users need to perform (or not perform) in order to qualify for the Audience.

You have four options for how your users need to interact in order to qualify for the Audience:

Performed event

Did not perform event

Had a session

Did not have a session

Well start will talking about performing (or not performing) a certain tagged event in your app. Youll want to work with your development team to build out custom events for your app, but by default, the Localytics SDK will track:

Localytics Inbox Message Viewed

Localytics In-App Displayed

Localytics Place Entered

Localytics Place Visited

Localytics Places Push Opened

Localytics Places Push Received

Localytics Push Opened

Localytics Push Received

Localytics Push Registered

Localytics Push Sent

Localytics Re-engagement

Localytics Uninstall

If your SDK is installed properly, you should see these options in the drop-down menu labeled (choose event).

Once you choose an event, youll be given options to add more details to the behavior. Depending on which interactionyou'veselected from the dropdown (performed event, did not perform event, had a session, did not have a session), youll be given different options for further granularity.

Heres a quick example:

Behavior: Across a persons devices during the last 30 days

People who: Did not perform event Localytics Push Opened

In the past 30 days (but were active in the above range)

Where Push Enabled is one of Enabled

You can add up to 5 profile dimensions to your behavioral condition (ie, the drop-down menu labeled Where), or just skip them. Well talk more about profile attributes in the next section. Use the Add Filter button to add more filters, and use the minus button to delete them.

Finally, if youre looking to further refine (or further open up) your Audience, you can add a second behavioral condition.

Again, choose your behavior from the dropdown list and refine it if necessary.

Between the two behaviors, you should see an AND button. This button allows you to specify how the two behaviors interact with each other. Your options are:

Modifier

Meaning

AND

User must fulfill both of these behaviors

OR

User can fulfill either of these behaviors

AND THEN

User must fulfill both behaviors sequentially

Youll only see the AND THEN option ifyou'vechosen two events. Otherwise, youll just see AND/OR.

Once youre satisfied with your Behavioral Conditions, feel free to leave the audience there, or to add Profile Conditions.

Profile Conditions

A Profile, at its base, is a user-level record. You can attach different properties (what we call Profile Attributes) like Gender or Last Website Visit. Profile Attributes can be dates, text fields, numeric values, or a non-ordered collection called a set.

Profiles allow you to select a group of users with a shared set of characteristics (what we call attributes). When building an Audience you can select up to 5 profile attributes.

Its important to note that profiles are memory-lessso they can only contain the users current state, with no associated history.

To add a Profile Condition to your Audience, click the + Add Profile Condition button. This will open a menu for you to build your profile conditions.

Like Behavioral Conditions, Localytics will track a few Profile Attributes by default through the SDK. If your SDK is installed properly, you should see the following options available to you in the drop-down menu labeled (choose attribute):

Scope

Profile Attribute

Description

App/Org

User type

Localytics detects whether a Profile is Known or Anonymous.

App/Org

Last session date

Localytics detects the last observed Session per Profile.

App

Last CustomDimensionName

For each Custom Dimension tracked by your app, Localytics will preserve the last observed value per Profile.

App

Last app version

For the last logged Session per Profile, Localytics captures the app version. If a user updates the app subsequently without recording a Session, this Attribute may not reflect current app version.

App

Last OS Version

Localytics detects the last OS Version being used by a Profile.

App

Total sessions

Localytics computes the total number of observed Sessions per Profile.

App

First session date

Localytics detects the first observed Session per Profile

App

Push enabled

For the last observed Session per Profile, Localytics detects whether push messaging was enabled or disabled. If a user updates this subsequently without recording a Session, this Attribute may not reflect current status.

App

Last push opened date

For the last push opened, Localytics detects the date the Profile opened it.

App

Last in-app displayed date

For the last in-app displayed, Localytics detects the date the Profile opened it.

Org

Last Country

Localytics detects the last country a Profile was in.

Org

Last time zone

Localytics detects the last time zone a Profile was in.

Org

Last city

Localytics detects the last city a Profile was in.

Org

Language

Localytics detects the last language a Profile was using.

You can also create as many custom attributes as youd like. Read more about custom profile attributes here.

Select your profile dimension from the drop-down menu. Depending on the type of attribute (numeric value, text field, etc), youll be able to choose a condition to further define the attribute.

Heres a quick example:

Profile

People where Last Push Opened is on or before 14 days ago

AND Language is one of English

And like with Behavioral Conditions, you can further define your profile attributes with the AND/OR selector. Clicking the button will flip between the two.

Add additional Profile attributes by clicking the Add Filter button. Again, you can add up to 5 attributes to your Audience.

Calculating the Size of your Audience

Finally, you can calculate the size of your Audience from within the Audience builder. Click the Calculate the number of users in this audience link.

Keep in mind, this is just an estimate, and might not fully align with the total number of users who end up receiving your message. For more information on why that is the case, check out this article.

Partner

Platform

Event Postbacks?

Type of Partner

Adjust (Adeven)

iOS, Android

N/a

Third-party attribution partners

Appsflyer

iOS, Android

N/a

Third-party attribution partners

Apsalar

iOS, Android

N/a

Third-party attribution partners

Branch.io

iOS, Android

N/a

Third-party attribution partners

Kochava

iOS, Android

N/a

Third-party attribution partners

Tune

iOS, Android

N/a

Third-party attribution partners

TapStream

iOS, Android

N/a

Third-party attribution partners

Yozio

iOS, Android

N/a

Third-party attribution partners

Aarki

iOS, Android

NO

Ad platform partners

ActionX

iOS, Android

NO

Ad platform partners

AdColony

iOS, Android

YES

Ad platform partners

Adperio

iOS, Android

YES

Ad platform partners

AdTheorent

iOS, Android

NO

Ad platform partners

AdXcel

iOS, Android

NO

Ad platform partners

Airpush

iOS, Android

NO

Ad platform partners

Appia

iOS, Android

NO

Ad platform partners

AppLift

IOS, Android

NO

Ad platform partners

AppLovin

iOS, Android

YES

Ad platform partners

Barometric

iOS, Android

NO

Ad platform partners

Cheetah Mobile

iOS, Android

YES

Ad platform partners

Conversant (Greystripe)

iOS, Android

NO

Ad platform partners

Drawbridge

iOS, Android

NO

Ad platform partners

Elephant

iOS, Android

NO

Ad platform partners

Facebook

iOS, Android

YES

Ad platform partners

Fiksu

iOS, Android

YES

Ad platform partners

Fyber

iOS, Android

YES

Ad platform partners

Glispa

iOS, Android

NO

Ad platform partners

GlobalWide Media

iOS, Android

YES

Ad platform partners

InMobi

iOS, Android

NO

Ad platform partners

IronSource

iOS, Android

NO

Ad platform partners

Instagram (Facebook)

iOS, Android

YES

Ad platform partners

Jampp

iOS, Android

YES

Ad platform partners

Liftoff

iOS, Android

YES

Ad platform partners

Millennial Media

iOS, Android

NO

Ad platform partners

MobFox (Matomy Media Group)

iOS, Android

NO

Ad platform partners

Mobvista

iOS, Android

NO

Ad platform partners

Motive

iOS, Android

NO

Ad platform partners

NativeX

iOS, Android

NO

Ad platform partners

Opera Mediaworks

iOS, Android

NO

Ad platform partners

Opera Response

iOS, Android

NO

Ad platform partners

Pandora

iOS, Android

NO

Ad platform partners

Phunware

iOS, Android

NO

Ad platform partners

Pinsight Media (Sprint)

Android

NO

Ad platform partners

PushSpring

iOS, Android

NO

Ad platform partners

RadiumOne

iOS, Android

NO

Ad platform partners

Rocket Fuel

iOS, Android

NO

Ad platform partners

Smadex

iOS, Android

NO

Ad platform partners

Spotad

iOS, Android

YES

Ad platform partners

StrikeAd

iOS, Android

NO

Ad platform partners

Supersonic (acquired by Iron Source)

iOS, Android

YES

Ad platform partners

Tapjoy

iOS, Android

NO

Ad platform partners

Taptica

iOS, Android

NO

Ad platform partners

Taptica Social

iOS, Android

NO

Ad platform partners

Twitter

iOS, Android

YES

Ad platform partners

Vungle

iOS, Android

YES

Ad platform partners

Yahoo

iOS, Android

NO

Ad platform partners

Overview

Using the Engagement Dashboard

Controlling Engagement Data

Three Engagements Types

Summary Data

Overview

The Engagement report lets you see how long users are spending in your app and how frequently they're returning.

This report provides session-level detail over a specified time period. This visibility exposes the frequency of use and session-length which indicates the health of your app.

Summary Data

The Engagement section of the dashboard depends on a session being closed in order to get its numbers. The Usage section of the dashboard only tracks session opens, which is why it's showing you a higher number of sessions. Often, session closes aren't recorded until the start of a new session, so once you have more information from people using the app these numbers should start to normalize.

Using the Engagement Dashboard

When viewing the data within the Engagement tool, you will want to set a specific date range to view said data in. Clicking on the date range in the top right corner allows you to choose the specific date range you are interested in.

Filters allow you to apply specific criteria to the results. This way you can view different kinds of users and the frequency that users are returning to the app. Some filter examples would be:

Push-Enabled - To see how data on users returning whether they have push enabled or not.

App Version - To look at users who are using a specific app version and ifthey'reconsistently coming back to the app with this version.

Like most analytics reports, you'll be able to FilterbyDimension and/orProfile, set a date range, change the view, save your report, and apply data splits. To learn more about these features, check out our article on the anatomy of an analytics report.

Controlling Engagement Data

Moving down in the tool, you have options to specify how you want to view the data, add splits to separate the chart into portions based on the selection you are splitting by, and choosing a shortcut.

Three Engagement Types

There are three types ofEngagementsthat you can view your session data by. These are:

Session Length

Session Interval

Loyalty

To view these, change theColumn (Sessions by) to the corresponding type of engagement. We'll walk through how we define each of these in this next section.

Session Length

Session Length shows how many sessions there have been (within the selected date range) in the broken down amount of time.

As shown in the screenshot below, the chart is broken up into different portions with the first one showing 0 to 10 seconds, 11 to 30 seconds, etc. This means if the app was opened and closed within 10 seconds, it will be categorized under the 0 to 10 seconds column.

Session Interval

Session Internal breaks up the chart to show how many sessions there have been in the date range that lasted 0 to 1 hour, 1 - 24 hours, 1 day, etc.

The benefit of this is to see a wider range of time and how many sessions there have been for each range of time.

Loyalty

The benefit of Loyalty is that you see how many sessions have taken place within the end user's app. In other words, you are seeing how many sessions there have been for users in the date range that have had their 1st session, 3rd session, 8th session, etc.

This way, you can see how many users have a lot of sessions in your app. You can also see if users are returning often. If they are, you will see more results in the groups of sessions to the right of the chart.

Interpretation of the Loyalty report is not always obvious. This reports the count of Sessions observed during the selected date range, split by visit number.

S for example, if a user has their first, second, and third ever sessions during the selected date range, each of these sessions will add one unit to each of the first three columns.

The sessions times at the end of the chart are grouped (for example, 9th - 14th) so you will see more numbers in this group as it will categorize sessions that were the 9th through 14th time they had a session in the app.

The Summary section allows you to see the Average Session Length as well as the Median Session Length. Both of these values are based on the date range and filter that is applied in the top right corner.

After applying the date range and specific criteria within the filter, your average and median session length data will be displayed.

Overview

Places Dashboard

Create a Single Geofence

Upload a CSV File of Geofences

Editing Individual Places

Deactivating and Deleting a Geofence

Overview

Places is a Localytics feature that allows you to send geopush notifications to your end users when they enter or leave a predetermined geofence. To read about sending a places message, follow this guide.

There are a few ways to load Places geofences in Localytics. Well go over those in this article, as well as walk through the Places dashboard.

Heads up, Places will be automatically disabled for users that are privacy opt-ed out. Refer to the details in the Dev Docs Privacy section ( iOS and Android ) for more details.

Places Dashboard

To navigate to the Places dashboard, click Places under the Marketing header in your dashboard. You can also use this handy link if you're logged in.

Events

On the dashboard you can do one of four things:

Create a single place,

Upload a CSV of Places,

Edit event attributes for Places,

Search your Places.

Lets walk through each.

Create a Single Geofence

If youre creating a new place, you can do some from the Places Dashboard. Click the + button to create a new place.

+

This will open the Create a Geofence menu. Here youll be able to enter the Location of the geofence (including its radius), the information for labeling on the Localytics side, and analytics tracking information.

For the location youll need to have:

Longitude

Latitude

The Radius of the geofence (sliding scale)

And for the information:

Identifier (what well call it)

Description (an explanation greater than the identifier)

Labels (well use these later when you need to pull in a group of places for a single messageex, Boston, museum, city, etc)

For analytics tracking, youll have the option to decide if Localytics tracks entrances to the geofence, exits, both, or neither. Simply check the boxes that apply.

Onceyou'vefinished creating your geofence, you should see the map at the left identify your location. Click Save to finish.

Upload a CSV File of Geofences

You also have the option to upload your geofences as a CSV file to Localytics. Several parts of the CSV file are required. Those parts are:

Identifier (ie, name)

Latitude

Longitude

Radius

Everything else listed is optional but highly encouraged.

To upload a CSV file, youll want to click the upload button on the Places dashboard (next to the greenNew Place button).

In the upload modal, youll have the option to download a sample CSV file. This is a great option if youre just getting started with Places, and need help formatting your upload. Click Download a sample CSV to download the file.

Alternatively, you can download your current list of Places as a CSV file. If you need to make updates to your Places, its helpful to use the most recent list of geofences in Localytics. Click Download your existing Places data CSV to access this file.

If you already have a CSV to upload, click the Click to Upload button. Otherwise, we support drag and drop uploadso you can upload your CSV by dragging it into the browser window.

The last thing in the modal is a sample table for what your CSV file should look like, along with definitions and examples for each of the columns. Here is that chart:

identifier

description

latitude

longitude

radius

labels

active

Store # 290003

Newbury St. Location

42.350187

-71.080062

500

ma | boston | big city | new location

true

A unique identifier for your place.

A description for your place.

The latitude of the center of your place.

The longitude of the center of your place.

Radius of your place in meters.

Pipe-delimited (|) labels, used for grouping similar places for campaign targeting.

Whether the place is active. When set to false, the place will no longer be monitored by devices.

Custom Places Event Attributes

You can set custom event attributes that trigger when an end user enters or exits a Places geofence. Youre limited to 10 event attributes, so use them wisely. Oncethey'recreated, youll be unable to rename or remove them.

To add Custom Places Event Attributes, click the ellipsis on the Places dashboard. Select Configure Event Attributes from the list.

This will open the modal to create new attributes.

Editing Individual Places

The last thing you can do on the Places dashboard is search for and edit individual geofences. Use the search bar at the top of the page to find the geofence youre looking for. Use the Filter option to look for geofences under a specific label.

Clicking on the ellipsis next to any individual geofence will give you three option:

View Analytics

Edit

Deactivate

To view the analytics of the geofence, click View Analytics. More on that in the next section.

To edit the geofence, click Edit.

This will pull up the edit modal for the geofence. This is the same workflow for if youre adding an individual geofence, so check out the guide above for more information.

Deactivating and Deleting a Geofence

If you need to deactivate your geofence for any reason, you can do so from the Places dashboard.

Find the geofence youre looking for with the search bar. From there, click the ellipsis at the end of the line, and click Deactivate. This will successfully delete the geofence from Localytics.

If youd like to bulk delete geofences, we recommend using the Places API.

The last thing you can do from the Places dashboard is View Places Analytics. This will take you to the Events section of your Analytics dashboard. Here youll be able to see all of the data about this Places that Localytics tracks. To learn more about events, check out our article.

Conversion and Churn

Using the Predictions Dashboard

Predictions Use Cases

Creating a New Prediction

How to Use Prediction Reports

Likelihoods

Related Behaviors

Related User Attributes

Using our predictions functionality, you can predict what your users are likely to do and serve up marketing and content to match. This is how truly personalized engagement happens.

Conversion and Churn

There are two key marketing events you can predict:

Conversion

Churn

Conversion predictions forecast user action. They tell you when users are most likely to perform key conversion events such as view products, make referrals, or finish a checkout.

With Conversions in Predictions, you can predict when users are likely to convert and send them promotional messaging that pushes them to take action.

Churn predictions forecast user inaction. It's typically an indication of users likely to disengage with you. You want to know churn predictions so you can anticipate and prevent user disengagement by sending marketing messaging that reignites their interest and keeps them coming back.

Using the Predictions Dashboard

Navigate to Predictions by selecting it from the sidebar (underAnalytics). On this page, you'll see a list of all of your predictions in Localytics.

Related User Attributes

Click into any of your current predictions to view the status of them. We'll talk about assessing their performance in further in this guide.

Predictions Use Cases

The purpose of Predictions is to anticipate and influence user engagement. For example, you can use our prediction analytics to:

Identify only those least likely to perform a conversion event so you can send them a discount to complete the sale

Discover key behaviors that indicate retention and loyalty such as the number of referrals a user makes

Identify users at high risk of churn so you can send them offers and messaging to rekindle interest

Creating a New Prediction

Localytics makes creating predictions to guide your marketing efforts easy. To create a new Prediction, hit the green plus button at the top of the Predictions dashboard.

+

You'll be prompted to build your prediction by selecting what you'd like to predict from a series of drop-down menus (for churn) or by selecting the conversion event.

We recommend naming your prediction by describing the type of user behavior you intend to forecast. This will help avoid confusion later on and will allow you and your team to more easily interpret and use new predictions as more are created. For example, a good name for the churn prediction is "Churn - no events in 30 days."

Our predictions engine is divided into two pathways: conversion and churn. First choose which pathway you want to take, depending on whether your goal is to retain users in danger of leaving or convert those ready to take further action.

For conversion predictions, you will also be given a series of drop-down menus. In this case, you can choose from a series of events (actions) you want the user to take.

If you choose the churn path, you will be given a set of drop-down menus that allow you to refine your predictions by events or actions users are not likely to take. You can also set a time frame from 7 to 90 days.

For both churns and conversions, the ability to choose multiple events is what lets you refine predictions in order to tailor your marketing to the expected user behaviors.

When you're finished building your prediction, don't forget toSave and Close.

Our predictions are programmed to use the most recent data possible, so we wait until midnight ET to generate them. They are then updated automatically every week to reflect changes in user data and trends.

How to Use Prediction Reports

Use your Localytics predictive analytics report to shape more effective marketing strategies and campaign messaging and offers.

For example, for users highly likely to not view a product within 30 days, send them a time-sensitive offer to entice interest before then.

For users who are multiple purchasers, reward their loyalty with an offer to purchase before the general market.

The predictive report can also help you identify the ideal time to send your marketing. Certain behavior attributes can indicate when certain users are more likely to open push messaging and even on which device types.

To access an individual predictions report, select the report from the Predictions dashboard.

You'll see all of the data Localytics has on your current prediction including:

Prediction Info

Type of prediction, criteria definition, next update, and baseline conversion rate

Likelihood of Conversion or Churn

Divided into low, medium, and high and broken out by users and % of active users

Related Behaviors

Compare the conversion or churn event by different related occurrences

Related User Attributes

The user attributes associated with the conversion/churn you're measuring

Let's dive into the last three of these.

Likelihoods

The results of each Prediction will group users into buckets of High, Medium, and Low Likelihood for churn or conversion based on the Events you have specified.

You should use these buckets as Audience criteria for targeted messaging. For example, you could send users at high likelihood of churn a 20% off coupon. At the same time, you could send your most loyal users a discount referral code.

To follow-up with any of these groups, click the ellipsis at the end of the line to access the Actions menu for that group. Target them with eitheraPush Campaign or anIn-App Campaign.

Related Behaviors

Below your the list of Likelihoods, you'll seeRelated Behaviors.

While its important to know which users fall into which buckets, its also important to understandwhy. Related Behaviors are the usage patterns that serve as lead indicators of future behavior.

These behaviors describe the "aha!" moments in your app when users discover core product value, and we observe the greatest shift in retention or conversion as a result of that discovery.

We comb through all of the event and attribute data sent from your app to find these inflection points over all time, as well as within certain key time bins like the first 1, 3, 7, 14, and 28 days of your users' lifetime. By default, Related Behaviors are both ranked by z-score and grouped by event.

FilterRelated Behaviorsby different Time Bins, Events, and Attributes.

Finally, the last piece of data we surface on your Predictions Report is Related User Attributes.

Related User Attributes are the attributes most related to the predictive target behavior. For each attribute, you will see the proportion of active users observed to have each attribute. You will also see the relative difference in churn/conversion between users observed to have that attribute vs. all active users.

Use top Related User Attributes to inform additional layers of segmentation on top of the High, Medium, and Low likelihood segments to create even more targeted and relevant predictive Audiences and messages.

You can display the Revenue Report based on 9 different metrics. Those metrics are defined below:

Metrics

Description

Average Revenue per User

Computed as revenue divided by unique users. Revenue is the sum of all value increases observed over the selected date range. Unique users is considered the count of unique users that performed an Event during the selected date range.

Average Revenue per Paying User

Computed as revenue divided by paying users. Revenue is the sum of all value increases observed over the selected date range. Paying users is considered the count of unique users that performed an Event with an associated value increase during the selected date range.

Cumulative Revenue per User

Computed as total cumulative revenue divided by unique users. Total cumulative revenue is the sum of lifetime revenue through the end of the selected date range for users active during the selected date range. Unique users is considered the count of unique users that performed an Event during the selected date range.

Cumulative Revenue per Paying User

Computed as total cumulative revenue divided by paying users. Total cumulative revenue is the sum of lifetime revenue through the end of the selected date range for users active during the selected date range. Paying users is considered the count of unique users that performed an Event with an associated value increase during the selected date range.

Paid Users

The count of unique users that performed an Event with an associated value increase during the selected date range.

Revenue

The sum of all value increases observed over the selected date range.

Revenue per Transaction

Computed as revenue divided by transactions. Revenue is the sum of all value increases observed over the selected date range. Transactions is the count of Events that occurred during the selected date range with a value attached.

Transactions

The count of Events that occurred during the selected date range with a value attached.

Transactions per Paying User

Computed as transactions divided by paying users.Transactions is the count of Events that occurred during the selected date range with a value attached. Paying users is considered the count of unique users that performed an Event with an associated value increase during the selected date range.

To access these different metrics, select the one you'd like to explore from the menu at the top of the page. Here's a quick gif of how you would access each of these different metrics.

You can choose to supply Customer Lifetime Value as a monetary, USD, value, which is most appropriate if the value maps to a purchase, OR as a raw numeric value, which most appropriate if your value maps to some other in-app metric like "movies watched" or "ads viewed."

Overview

Re-engagements

Conversions

Choosing a Remarketing Goal

Using the Remarketing Dashboard

Creating Your Audiences

Sync an Audience to Facebook

Exporting Your Remarketing Audiences

Overview

Remarketing, in simple terms, is responding to users who've engaged with you. They could be customers who have purchased from you or viewers who have simply shown an interest. When you check out a coat on your favorite retail site and then an ad pops up encouraging you to take another lookthats remarketing.

To access Remarketing in Localytics, simply clickRemarketing in the dashboard sidebar, located underMarketing.

Check out this article for a quick walkthrough

The whole idea of remarketing is to continuously engage the customer and nudge them to conversion. Before we dive into setting up a remarketing campaign, let's go over some terms you should know.

Re-engagements

Localytics measures a re-engagement as an app session within 14 days of viewing a remarketing advertisement. A user can have more than one re-engagement reported in Localytics if that user clicks on more than one remarketing advertisement.

Keep in mind, a maximum of one re-engagement will be attributed per remarketing ad clicked. You can view re-engagement charts and metrics in the remarketing Dashboard and can view results per campaign.

Conversions

Conversions are calculated based on users who re-engaged and completed the selected conversion event within the selected timeframe.

To select a conversion event, click into any of your remarketing reports listed at the bottom of the Remarketing dashboard. From there, chooseSet a conversion event. From there you'll be presented with a modal to allow you to choose which conversion event you want to track from a drop-down menu. Don't forget toSave conversion event.

Choosing a Remarketing Goal

Its important to have a specific remarketing goal in mind before you create your audiences and messaging. Then you have something to measure your efforts' effectiveness against.

The three most common goals are:

Nurturing: keeping your customers engaged based on previous behaviors with you.

Monetizing: moving your customers to buy a previously viewed product or service. Typical remarketing includes discounts and promotions on viewed items or abandoned cart reminders.

Re-engaging: Renewing interest from lapsed customers.

Once you have a goal, successful remarketing requires three key steps:

Creating well-defined target audiences

Meaningful, timely messages

The ability to analyze, learn, and optimize based on your learnings

The Localytics dashboard makes it easy to create remarketing audiences by using previous engagement behaviors and key profile characteristics.

It also makes it easy to export audiences to your remarketing distribution platforms (ie. Facebook).

Our True Impact tracking and analytics show you exactly how your remarketing initiative performed against your goals. This way you can build on whats working and stop wasting time on what isnt. Before you know it, youll be remarketing like a pro.

Using the Remarketing Dashboard

The Localytics Remarketing dashboard puts key tools for creating audiences, exporting them, and then analyzing your remarketing results in one place. To access the dashboard, simply selectRemarketing from the sidebar under theMarketing header.

Creating Your Audiences

Who are you targeting and why? This should be the first question you ask yourself. The more specific you can be, the better you can tailor your message based on the user's prior behaviors and profile information.

To create an Audience for export, head to the Remarketing section of your dashboard (under Marketing). From there, click the green plus button.

+

Select a Saved Audience, or build a New Audience by toggling between the two options.

Our remarketing dashboard makes it easy to identify and target audiences based on three criteria: Events, Sessions (considered Behavior Conditions), and Profile.

Events and Sessions data map back to actions that users have taken during previous engagements with you. Profiles refer to demographic and usage data. Add either of these to a new Audience by selecting+ Add Behavior Condition.

The dashboard allows you to build your audiences using simple drop-down menus to apply the events, sessions, and profile data filters you want to use.

Once you've built your audience, you can then export it to the appropriate social media or online remarketing platform in order to distribute your remarketing campaign.

Onceyou'velaunched your remarketing campaign, you can use the Remarketing dashboard in Localytics and report functions to analyze its effectiveness.

Sync an Audience to Facebook

Using Localytics robust audience-building to power your Facebook remarketing campaigns creates more meaningful and effective remarketing experiences.

Syncing your Localytics audiences with your Facebook ad platform takes just a few clicks. But first you must:

Have admin privileges on your Facebook Account

Have previously accepted Facebooks Mobile App Custom Audiences and Custom Audiences Terms of Service

To begin, selectRemarketing from under theMarketing header in the Dashboard. From there, press the green plus button to export an Audience.

+

Build a New Audience and select a Saved Audience. Once you've chosen, you might be prompted to login to your Facebook account. After verification, hitSend Audience and you're good to go!

Exporting your Remarketing Audiences

Localytics Audiences can be grouped for remarketing messaging distribution by Apple IDFA (Identifier for Advertising) and/or Google GAID (Google Advertising Identifier) or by Customer ID.

First, head to the Audiences section (Marketing > Audiences). Select the audience you wish to export. Hover over the ellipsis on the far right of the selected audience line to reveal the Actions drop down.

Scroll down under Exports to the Identifier you wish to use (IDFA or Customer ID), and select your export. A status bar will appear at the top of the screen.

Check on the Audience export by clicking on the status bar. When it is done, click on Download.

Next up, we'll walk through a Remarketing report. .

From the Remarketing Dashboard you can check on the status of any of your remarketing campaigns. Simply click into any of the campaigns you're running (listed at the bottom of the dashboard) to view more information.

Conversion

Localytics Remarketing Reports show you how well your remarketing initiatives are working according to specific metrics that you set.

The most common performance measurements are re-engagements and conversions.

Re-engagements

A re-engagement is when a user or customer views a remarketing ad or message over a specified period of time. Using the Remarketing Dashboard Reports, you can evaluate re-engagement effectiveness against a number of variables.

You can also set different response time periods: 1, 7, 14, or 30 days. Compare the number of re-engaged users against the total audience population and see which re-engagements led to conversions.

A conversion is when a user performs a specific action. For example, completing a checkout, sharing a piece of content, or viewing a product. The Localytics Remarketing Report allows you to identify the conversion event and the time period for evaluating the performance of your campaign.

Using the Remarketing Report with every remarketing campaign lets you determine which campaigns are more successful against various types of audiences. This is how you fine-tune and optimize your remarketing to develop more meaningful user engagements.

Overview

Afteryou'vegathered some new users through your acquisition sources, you can use Localytics to review the data about those acquisitions. The Attribution Report gives you an overview of how many usersyou'veacquired through your campaigns, and which campaigns were the most popular.

As with all analytics in Localytics, you can Filter your results by Dimension and by Profile. To learn more about filtering your data, check out our section on filtering. You can also adjust the data range. If you need more information on the Data Range feature, check out the Analytics Overview article. Finally, you can adjust the View to Chart or Table for easier access by selecting View.

Hover over any of the points on the chart to get more information about the piece of data.

Assessing the Performance of a Single Campaign

The attribution report includes a chart within your specified date range (including today), and a list of all of your campaigns ordered by Source name. You can toggle this option to sort by Campaign instead. In the chart, organize the list by any of the data including:

New users (acquired)

(Total) sessions per users

LTV per user

Total revenue

If youre ever confused as to how we define any of these metrics, hover over the question mark next to the title for a quick definition.

The last thing youll see on the Attribution report is a Summary of your data. Here youll see your total new users from all of your Attribution campaigns, as well as the total revenue from those users.

If you want to review the performance of a single attribution campaign, click into the campaigns name from under the Source menu on the Attribution dashboard (ie, Attribution Overview).

Here youll see the complete picture of your Attribution campaign. At the top of the page, youll see Key Metrics like:

New Users

Sessions per user

LTV per user

Total Revenue

Below this, youll see a chart of data about your users acquired per day.Like on the Attribution Overview reporting page, you can split the data by clicking Add Split. Select the secondary data youll like to split by, and wait for the chart to adjust.

Below the chart is a list of your different cohorts of users. This will depend on how your acquisition campaigns are set up in your attribution partner, so consult your third-party partner to better understand this data.