Countly Mobile Analytics | Blog @countly - Tumblr Blog

👋 Announcing Countly 16.06

Today we are announcing the release of 16.06 version for both Countly Community Edition and Countly Enterprise Edition. This release adds several new functionalities while continuing to provide the maturity, ease of use and scalability required to meet the needs of mobile, web and IoT analytics and mobile marketing for both small businesses and enterprises.

When we started 3 years ago, we couldn’t imagine that Countly servers would be tracking more than 6K mobile apps and 2K web sites, recording well over 60 billion API points per month. Being the only self-hosted and white-label analytics platform in the market, Countly is now the software of choice for both SMBs and Fortune 500 customers, including leading telecom operators, financial institutions, health organizations and gaming companies.

Countly 16.06 is a major release with a long list of release notes. With this release, our tight-knit team builds on our past success to maintain Countly’s status as the world’s #1 open source, enterprise grade mobile and web analytics solution.

Let’s take a quick tour of what is new in 16.06.

🎁 General features available for Community & Enterprise Editions

We’ve added a one line installer, which helps download and install Countly with a single line. This is a very quick and handy method for those who want to get up and running with Countly as soon as possible. Try yourself:

wget -qO- http://c.ly/install | bash

We’ve introduced a Countly Code Generator to help developers integrate their SDKs more easily.

We’ve added several one liner explanations in Countly configuration options (under dashboard > Management > Configuration)

Charts now display full day results for today’s chart, instead of capping to current time.

Command line now checks whether user is root and displays meaningful message for root needed commands.

App key of application and API key of user can be changed from dashboard. This is useful in circumstances modifying SDK calls in your app is not an option.

Previously it wasn’t possible to rename events with key names containing dots. As you may have guessed, this is not the case any more.

Countly now uses bulk report sending through jobs, rather than cronjob for each separate report.

We dropped using Imagemagick due to maintenance issues, and started using Sharp node module instead.

Add IPv6 listen directive to Nginx config to make sure we are ready to use IPv6 in the future.

✌ Greatly improved user experience

App management is visually improved with hints and value order.

All apps data fetching has been optimized.

User management table has been redesigned with datatables.

Data populator plugin has been revamped so it generates less random and more meaningful data with less overhead for browser.

We removed unused fields for web analytics.

Where Google services is disabled (mainly for servers in China), switching between cities and countries and displaying simple table of countries on dashboard is now possible.

😍 Completely overhauled user interface

There is now a new and improved sidebar UI which looks and behaves a lot better than the old, one-level navigation bar.

There is a new, shiny pre-login page design that you’ll love ♥

The main dashboard has been redesigned and better graph tooltips have been added to graphs.

Removed app category from app creation since we think your time is valuable.

Loading bar has been updated with a modern one.

When clicked on cog, user settings are now displayed in full screen instead of popup.

Whole UI is now more modern — lots of small & lovely retouches everywhere

👑 Improvements exclusively for Enterprise Edition customers

Our Enterprise Edition customers will love this release, packed with several add-on features and improvements.

✌ Drill related enhancements

Bookmark management is now available through API.

Plugins can use disk space for large aggregated queries and can performBY queries without AND.

Sessions now can be queried by length/duration

👉 Attribution Analytics improvements

It’s now possible to report organic conversions with Web Analytics, and select which campaigns to compare.

There is a new configuration to pass all campaign data to end URLs or not.

Attribution analytics can now pass all the properties to postback url, including custom ones.

User can hide a campaign when completed.

Optimization of loading data by separating campaign properties and analytical data.

🎉 New plugins for Enterprise Edition

Countly comes with several plugins, and now more plugins are available with this release.

Retention with segments, where retention table can be drilled down into segmentation values.

Restrict access, where admin can define who can see what part of the dashboard.

Block requests, where admin can block certain type of requests coming from devices or web apps.

In addition to all these new features and improvements, there are also several bug fixes, including but not limited to:

Push notifications work with Apple’s new switch to HTTP2 transmission method.

User estimation with active users data is corrected throughout the dashboard.

There is a fix in bulk API that now helps API run smoothly in certain conditions.

Unique click reporting in attribution analytics is fixed.

We have made a few fixes for data types interpreted incorrectly for custom properties and provided historical values of user properties for selected period.

Download Countly Community Edition directly from Github, or try Enterprise Edition now.

The Countly team is proud of each new feature, and we are also delighted to see how Countly has become the platform of choice when companies need a trusted partner to provide a private, on-premise, customizable and extensible analytics and marketing platform for their mission critical applications.

The work we’ve done on our core feature set, together with a new, refurbished user interface and use of new, faster MongoDB 3.2 greatly improves performance and increases ease-of-use.

And we are just getting started!

-- Onur Alp Soner, CEO

iOS developers will love our new Countly iOS SDK. Here is our changelog.

Recently we have introduced our new iOS SDK, dubbed v16.06. Under the hood, there are several improvements to code, and we wanted to mention all those. As usual, all of our SDKs are open source just like our server code, and iOS SDK can be downloaded directly from Github.

Enjoy!

1. Switched to POST methods for all requests

Due to problems with large query strings in GET requests, we switched to POSt for all type of requests, not only crash and user_details.

2. Changed default device ID type for tvOS

Default device ID type for TVOS was IDFA, and we changed it to NSUUID to prevent possible confusions with the App Store upload.

3. Fixed crash report send failure persistency problem

Checking for “result”:”Success” in server response to decide if crash report is delivered to server. Otherwise crash request will be considered failed and stored persistently.

4. Logging

iOS SDK internal logging will prepend [Countly] to every log message it prints. On Android we use different TAG’s for each section, and info (i), debug (d), and error (e) log types. It is useful especially working with a lot of other SDKs.

5. Added isTestDevice flag to CountlyConfig

This flag is used for explicitly marking test devices for Push Notification. Currently iOS SDK will be sending test_mode with token session as below:

6. Added storedRequestsLimit property to CountlyConfig

It is used for limiting number of request to be added to the queue. In case Countly Server is down or unreachable for a very long time, queued requests may reach excessive numbers, and it may cause problems with being delivered to server and being stored on the device. To prevent this, iOS SDK will only store requests up to storedRequestsLimit. If number of stored requests reach storedRequestsLimit, SDK will start to drop oldest request while inserting the newest one instead. If not set, it will be 1000 by default.

7. Added buildUUID and build number to crash reports

A buildUUID (ex. 70B0DE66-D337–3952–914D-A1E542667E20) inside crash reports will be used for symbolication. Build number (ex. 1.0.3) will be used for semantically distinguish builds on the dashboard, while uploading dSYM or displaying crash information.

8. Fixed setNewDeviceID for system generated device IDs

In our previous version, there was a small glitch with this method — it caused incorrect change device IDrequest to be sent with the same device ID as new and old. It caused each session to be counted as a new user. This problem has been fixed in new version.

9. Improved Auto View Tracking

Auto View Tracking was reporting some non-visible foundation viewcontrollers. For the first version, only exception was UINavigationController. Now we added a few more like UIAlertController, UIPageViewController, UITabBarController, UIInputViewController etc. Some of them are just introduced with minor iOS 9 releases like iOS 9.1 and 9.2. We are going to check each minor iOS updates after this, and keep the exception list updated.

10. Added optional parameters to CountlyConfig

We added ISOCountryCode, city and location to be sent with each begin_session. For details, please see this link.

11. Disabled timed events persistency

Timed events are not persistently stored anymore. They behave as described in updated SDK development guideline, documented here.

12. Added SDK name to all requests

Starting from this version, we decided to add SDK name to all requests for future enhancements on dashboard. With each request “sdk_name” will be sent just like “sdk_version”. As an example, its value will be “objc-native-ios” for current iOS SDK. As you may have understood, the first part gives programming language. Second part is SDK origin (e.g native, titanium, customer modified etc.). Last part is SDK identifier. Even though current iOS SDK also supports tvOS, watchOS and macOS, we call it iOS SDK.

For our native Android SDK, this parameter it would be: “java-native-android”.

13. Changed default alert title for push messages

From this version forward, CFBundleDisplayName will be used for alert titles. Previously, we used kCFBundleNameKey which is sometimes meaningless depending on creativity of the developer.

Until next version, happy coding! :-)

— Erkan Yildiz

Android usage in the United States

Ever wondered how Android performs in United States? We have gathered this information for you, using data we collect from Android devices. Study was carried on between April — May 2016, over the course of 2 months. It covers 41M users with 4.5 billions of sessions. Report details will give several insights for both product managers and developers who are in search for reliable data and help them understand end user device, usage insights and technology employed.

Usage peaks high at 22:00

It’s no surprise that handphone usage tops at 22:00 — but what is interesting is, there are still people at 4:00 who wake up and check their applications. Basically speaking, number of users who open their app at 22:00 is 5.1X number of users who open at 4:00 AM.

Regarding day of week, we see that users open their app the most on Thursdays and Fridays, and on Sunday, usage drops considerably. During the week, usage increases starting from Monday, Tuesday and Wednesday. Looking at this data, it shows that the best time for push notifications is in the afternoon and either on Thursday or Friday.

Resolutions differ, but high end Android device usage surges

Android is quite fragmented when it comes to resolution. 1440x2560 is now the leading resolution in US, which is called “Quad HD”, or QHD. Most of the devices in this list include Samsung, with Galaxy S6, S7, Edge and Note. LG G4 also has QHD, and we see LG in the list (see below). Other players in this resolution include Sony Xperia Z5 Premium and Xiaomi Mi Note Pro, but they didnt make it in the top devices list. Top resolutions in US are (in order), 1440x2560, 1080x1920, 720x1280, 1080x1776 and 1440x2392.

Samsung is the king of device manufacturers

When it comes to device share, Samsung takes takes a big portion of all devices (65%). Top devices for Samsung include Galaxy S5, Galaxy Note5, Galaxy S6, Galaxy Note4 and Galaxy S4. Since Galaxy S7 has just entered market, it found its place in this list at a lower level, but its market share is consistently increasing and we expect that in 3 months, it will surpass Galaxy S6. After Samsung, comes ZTE, LG and HTC, which have 6%, 5% and 4.5% market share respectively. Other devices (Motorola, Sony and other brands) sum up slightly higher than 20%.

Android 5 tops, Android 6 gaining momentum

Google is working hard to make sure all Android devices get the latest version, by consistently collaborating with device manufacturers, including Samsung, LG, Sony, HTC, ZTE, Huawei and others. All of those manufacturers provide some heavy customization and historically this situation made it harder to update devices online. As Android started to be more modular and over-the-air updates are becoming common among device manufacturers, we started to see that Android is now approaching the speed to iOS in terms of device updates. We see that Android 5.1.1 leads the chart, whereas 6.0.1 and 4.4.2 come second and third.

Other insights

Unarguably, English is the most popular language used in Android devices in US with slightly more than 95% market share. Developers should feel safe if app is not localized unless it’s targeted to a global extend, but focusing only to US citizens. Android devices are used in French, Korean, Chinese, German, Arabic, Russian and Turkish follow English, with all less than 1% market share.

App retention in the world has been increasing slightly over the years, thanks to more quality apps, adherence to standards and increasing user experience experts working with app developers. However, our data shows that 31% of users open their app only once and then delete it. This percentage can be leveraged by creating more useful and personalized applications.

Data also shows that 90% of all users use their app for 2 minutes or less. While this is good for weather apps or apps that have low session duration by nature, developers should focus on user loyalty and try to understand ways that cause app abandonment. We at Countly care about retention strategies, and when they need, we directly work with our customers to increase engagement.

Methodology

We have carried this study between April — May 2016, over the course of 2 months with more than 41M users and 4.5 billions of sessions. Countly will be providing more insights from other parts of the world, thanks to ongoing collaboration between customers and Countly.

Eight Strategies for Successful User Retention: An Illustrated Guide

Our last piece was all about engaging your users. Now that you’ve got them interested and excited about your product, it’s important to make sure they want to stick around. ‘User retention’ might not sound as glamorous as user acquisition and user engagement, but it is just as important –arguably even more so.

Now, we’ll be reviewing the key tips and strategies for retaining your target users. We’re also switching it up a bit (user retention in practice!) and making this piece easier on the eyes: less text, more pictures, all the same great taste you love.

1. Onboarding, not Onboreding

First impression always counts. One of the most important strategies to improve retention is to ensure users have a positive initial experience with your product. If users have to interpret cryptic login instructions or complete unnecessarily complicated registration steps, you will lose them — plain and simple. As I mentioned in a previous post, technology has made us impatient and unforgiving when it comes to using new products. This means your app or website must demonstrate how intuitive and well-designed it is from the very moment it’s opened.

2. The Numbers Game

With few exceptions, websites and apps are not meant to be visited once and then forgotten. Rather, your product should be one that users want to return to again and again, like a favorite restaurant or vacation spot. Your website or app needs to be reliable and consistent in quality, yet dynamic and novel enough to encourage repeat visits (or sessions). How do you tell if you’re meeting user expectations?

Well, you start by crunching the numbers, and you look for patterns. Tables 1 and 2 in my last post define some of the most common user behaviors and engagement strategies, and these same metrics can be used to calculate your user retention and implement activities to improve retention wherever you spot problems.

3. Churning the Midnight Oil

While following the advice above, you should pay special attention to users who exit your product without completing the action you wanted them to, and/or who do not revisit your product within a desired timeframe. You can reduce churn by using your product data to identify points of user fall-off, and by comparing cohorts of users based on how they interact with your product. You can even employ user behavior tracking strategies, like heatmaps, or videos of user sessions, to see real-time examples of how people use your product.

4. Design for Success

I’ve written a bit about user experience (UX) here and here, and can’t reiterate enough how critical it is to understand what your users want and how they respond to different types of information. Creating an attractive, intuitive product takes time, and it may be tempting to simply implement whatever seems to ‘look good.’ However, the benefits of thoughtful UI (user interface ) and UX research design greatly outweigh the heavy lifting required up-front. If your product is losing users and you aren’t sure why, it may be time to revisit (and improve) its UX and UI design.

5. Keep the Spark Alive

I think we can all agree that the Google search engine provides immense value to pretty much every Internet user around the world. For those of us who have been using this search engine for a decade or more, part of its appeal has been its relatively consistent and simple interface. However, even while the search engine maintained its look and feel, those who managed Google’s growth never stopped innovating. Sure, they could have left us with a 2006 iteration of the search engine, and we’d probably still use it — but they didn’t. Why? Because even a seemingly-perfect product can and should be refined, tweaked, made more responsive, more useful, and more engaging. It’s not enough to create a great product, even if your users love it — your audience will drift away over time, unless you intentionally keep the spark alive. There is always room for something different, something exciting, and something better.

6. Abide by the Golden Rule

Great customer service goes a long, long way towards building user loyalty. When users raise concerns, address them — immediately, even if you don’t know the solution yet. Letting a customer know they have been heard and that your team is tackling the problem is a powerful demonstration of empathy and a critical component of relationship-building. Nobody (well, almost nobody) expects perfection from the products they use. If something goes wrong you might lose a few users, but you will keep the vast majority if you can acknowledge the issue, validate the users’ frustration, and provide concrete information on how the problem will be fixed (and when).

7. Engagement and Retention: Two Sides of the Same Coin

Many of the same tactics that are effective for increasing user engagement can also be used to promote user retention. I reviewed a number of these in my previous post, but it is worth noting that things like user incentives, rewards/perk systems, interactive content, and personalized features are not just activities that draw users in momentarily. These are all “carrots” that, when offered over time, can effectively promote long-term product engagement.

8. Make Your Product a Community

One of the biggest reasons people will use a product or service again is because they feel connected to it in some way. Whether we realize it or not, (most) people want to achieve a sense of belonging, and a sense of community provides a psychic reassurance that is extremely powerful.

One of the most common applications of this phenomenon is when websites and apps provide a forum for users (and sometimes even product managers or “mods”) to interact with each other. Comment sections, social sharing functions, user generated content, and user contests are all tactics that can be used to build relationships with users and among users. What it comes down to is finding the right strategy for your product, one that encourages user retention by inspiring a sense of “us.”

Today’s post provided a handy illustrated walk-through of user retention strategy. How do you approach user retention? Got tips or tricks to build user loyalty? Tell us in the comments!

-- Countly Team

This blog post first appeared in Medium.

#customer retention #growth #user experience

Mobile Websites vs. Mobile App Analytics: What is the difference?

I live in the smelly, wonderful metropolis of New York City, and as a result my keychain must hold the approximately 9,000 keys (may have rounded up there) it takes to get into my apartment. Occasionally when I am especially tired or it’s dark out, I pick the wrong key and endure a few anxious moments fumbling with the door, just waiting for someone to walk by and accuse me of trying to break in to the building. Adding to the confusion is that often two keys are shaped very similarly, and the impostor key will fit smoothly into the latch but then fail to turn and unbolt the door.

Where is this going? you may be asking yourself. Why is she telling me about her keychain? Fair questions! Well, this fourth and final installment of this introductory mobile analytics series is going to review some of the differences between mobile website and mobile app metrics. Since mobile websites are more powerful and responsive than ever, you might expect the measures of website success to be identical to the metrics used to describe app performance (for a review of common app metrics, check out my last piece). These measures — much like my house key and its impostor — might even seem so closely aligned as to be interchangeable.

The reality is that while mobile website and app evaluation strategies do share many similarities, it is important to know where they diverge when it comes to identifying and interpreting performance indicators.

This is especially helpful given that many mobile-enabled websites also have an app counterpart, and marketers and product managers are increasingly expected to be well-versed in tracking both.

Apps vs. mobile websites

A bicycle and a skateboard can both get you where you’re going, but they are quite different experiences — and one might work better for you than the other. Likewise, mobile-enabled websites and mobile apps are both vehicles for engaging users with a product, but there are important differences in how these platforms function. Importantly, these differences influence what analytics metrics can and should be measured. For example:

What does all this mean for my data dashboard?

Assuming your mobile analytics package collects and displays data on both mediums, it should be easy to view both mobile website and app data and the dashboard should clearly distinguish the two. Many of the metrics and analysis methods describing user/visitor behaviors are the same (e.g. ‘events’, ‘funnels’) but a few terms are slightly different for mobile website data compared to app performance data. Here are some metrics that are conceptually similar, if not equivalent, but have different names:

Other common terms you will see referenced when describing mobile website analytics are ‘traffic’, ‘hits’, ‘bounce rate’, and ‘exit rate’. I did not include these in the chart because there isn’t a precise equivalent for apps (e.g. ‘bounce rate’ is a bit like churn rate conceptually, but it would be misleading to say they are the same thing). So let’s define those:

Traffic: A measure of how much activity is taking place on your site, i.e. the total amount of visitors, visits, page views, and other measures of interaction.

Hits: This term is often used interchangeably with “visits”, but they aren’t the same thing at all! Specifically, ‘hits’ refers to the number of files that are downloaded when a page is viewed. For example, let’s say you make a single visit to a pet adoption website and the homepage contains an HTML document and five JPEGs of different puppies. You have now made one site visit, and generated six ‘hits’: the HTML file plus the five photos.

Bounce rate: The proportion of visitors who go to a site and leave after visiting only one page. If you visited the pet adoption page, took one look at those adorable puppies and clicked away, you just ‘bounced’ that site. Why don’t you like puppies? :(

Exit rate: For any given web page, the ‘exit rate’ is the proportion of visitors for which that page was the last one viewed before leaving the site. While the bounce rate refers to visitors who landed on a page and left right away, the ‘exit rate’ is calculated according to which page was the last one to be visited, regardless of how many pages the visitor looked at beforehand. So, if you went to the pet adoption website (page 1), clicked on “adopt a pet” and checked out all the puppies (page 2), selected “adopting a pet FAQs” (page 3) and then closed your browser, page 3 would be counted towards the exit rate for that website.

Now you’re a mobile app and website expert!

Whew, that was a lot of jargon and charts and terms that sound like one thing but really mean another. But you did it — you read all four pieces in this series and now you’re a mobile analytics champion! Congrats. You should adopt a puppy to celebrate.

A quick caveat: there are mobile website metrics beyond the essentials I covered here that you may need or want to measure. For example, if your product is intended to generate revenue or you are trying to determine which marketing strategy provides the most bang for your buck, there will be additional metrics to take into account.

That said, this piece was intended to provide a solid foundation for understanding the ways that users interact with mobile websites and mobile apps, and how those user experiences translate into product performance metrics. Did I succeed? What would you like to know more about, and do you have any tips for managing web and app data? Tell me below!

In this piece I helped you identify key similarities and differences between mobile website analytics and mobile app analytics. Stay tuned for future posts, and if you have a topic you want to see covered, leave it in the comments!

This blog has first appeared in Medium

Sarah Carter is a social science researcher, data fiend, and content contributor for Countly. She enjoys spreadsheets, the CTRL+F function, coffee, and the Oxford comma.

#analytics #mobile analytics #web analytics

Countly’s the most complete release ever: 16.02 with web Analytics, tvOS & Watch OS 2 support

After 6 months of hard work, Countly Enterprise Edition and Community Edition version 16.02 are here, and they are packed with a lot of new features. As you all know, we have already been providing sophisticated, flexible, and easy-to-use mobile analytics capabilities for apps via an easy-to-use interface. By greatly simplifying the tracking and analysis of in-app activity, Countly users can focus on important issues like improving in-app usability and user experience, increasing retention retention, and boosting in-app revenue.

We haven’t been resting on our laurels though. We have continued to enhance Countly as a 360 degree mobile & web analytics and marketing solution for product managers, marketing managers and developers, and we are proud of the results.

Let’s see what we have with this new release:

Countly can now track web pages (in detail)

The biggest change in this release is the addition of web analytics, something we have been working on for a while. In order to make web analytics a reality, we first developed a complete web SDK. This SDK has also been used in several mobile applications as well, since many apps out there are written in Javascript.

Note that, unlike some other vendors, instead of just providing custom events and basic data retrieved from Javascript SDKs, the Countly dashboard shows you a LOT of information about your web page, including but not limited to:

All sites overview

Heatmaps (*)

Javascript crash reporting

Custom events

Bounces, exits and entries

Page views

Last visiting users

Geolocations

Bot tracker removal

Browsers and devices

Time spent on pages

Segmentation (*)

User profiles (*)

Attribution analytics (campaign tracking) (*)

Funnel visualization (*)

Drill down granular data (*)

(*) denotes that feature is available in the Enterprise Edition

Web analytics is now publicly available for all editions. For more information about web analytics, please click this link, or see installation instructions on the resources page.

Support for WatchOS2 and TVOS

The Countly iOS SDK already had support for WatchOS, but now it’s time for WatchOS2. We also have been asked several times for TVOS, and now you can grab it via the same iOS repository on Github. Available for all editions, now you can get custom data from WatchOS2 devices and your Apple TV.

That means, iOS SDK now supports 4 types of platforms in a single SDK:iOS, tvOS, Watch OS and Mac OS.

Other updates with iOS SDK include:

Manual and auto view tracking capability

WatchOS 2 & tvOS support

Changing and merging device ID at runtime

Custom or system provided device IDs (IDFA, IDFV, OpenUDID)

Added crash reporting and user details tests

Updated iOS sample app for APM (hint, hint!)

Updated OS X sample app

Added tvOS & watchOS 2 sample apps

Updated sample apps for view tracking

Extensive Enhancements for the Push Notifications Plugin

Push plugin now uses new HTTP/2 interface which Apple has introduced during WWDC 2015 and recently made public. Old TLS socket-based interface is going to be deprecated.

This interface also makes possible the use of single certificate for development & production environments. While old certificates will still work, you’re strongly advised to generate new one and upload it to your Countly dashboard.

In this release, Countly now shows error message in the message popup in case of any unrecoverable error during message sending. There are also numerous bug fixes to provide you with a smoother user experience.

Other notable features

This release was really big. Features that deserve a notable mention are as follows:

Application Types, where each app has different views and dashboards depending on whether it is a web app, a mobile app or (very soon) an IoT app.

Upgrade to MongoDB 3 and Nodejs 5 for better API handling speed & performance.

Sources plugin showing the sources of your web visitors or the appstore from which of an Android app was installed.

User Profiles are now greatly enhanced, allowing segmenting users, and a user list view from drill, crashes and attribution plugins. You can also store custom properties as arrays, for multiple values, as well as provide atomic server operations, like increase, max or min. (Enterprise Edition)

Attribution Analytics is now more advanced and allows tracking of custom segments with Attribution Analytics. (Enterprise Edition)

Lots of new shell commands for managing plugins, changing configurations, and additional backup options have arrived. You can pretty much manage Countly from command line (we’re calling you, Linux’ers).

Views plugin for tracking the time which a user spent on specific application view/screen/page, either automatically or custom.

Allow Google services to be disabled, for users who live in regions where Google is blocked.

Outgoing emails are also now localized in your own language.

Theme support, so you can bring in your own theme!Download

You can download server and SDKs from usual places:

Countly Community Edition v16.02

Download new iOS SDK

Download new Android SDK

Installation instructions

Upgrade instructions

Looking for supported Enterprise Edition?

We suggest customers looking for a supported Enterprise Analytics Edition or Enterprise Marketing Edition with more features like real-time dashboard, crash reports, attribution & campaign analytics, advanced push notifications, user profiles and detailed segmentation have a look atEnterprise Edition page, compare different editions or get in contact with us for pricing information.

We are really excited to unveil our best platform yet with a changelog full of new features. Together, let’s build world’s most extensive, user-centric and powerful mobile analytics platform. Join us now and share the love.

Until next release … Enjoy! :-)

– Countly Dev Team (Artem, Arturs, Erkan, Igor, Kirill & Onur)

How did open source help us build our own mobile analytics platform?

It’s no brainer to understand that analytics is hard. Real-time analytics is harder. Building one that scales to billions of api requests per month is challenging, even for US Ministry of Defense. Multiply this with a good user interface, a viable open source model, ability to collect data from various sources and put a non-obvious business model on top. This is what we are doing in Countly for the last 2 years. Not your type so you want to go with ready-to-run tools? Then Google Analytics is for you and you do not need this document anymore. Read more if you are interested.

The primary value of building an analytics system is the ability to perform storing the data, and extracting useful and knowledgable information out of that, so you can know what works and what doesn’t. This is the sole, first mission. You just don’t have to think about scalability on day 1. After the skeleton is built, and you fix your bugs, then you need to build a horizontally scalable system. This was what we did, and we did good during we build our open source mobile analytics stack.

Without further blurb, here’s a list of open source components we use in the order of importance and how it helps us achieve our goals. I’ll provide you almost a complete list, because each of those libs or frameworks have been useful throughout our goal towards building an open source platform. Note that licenses of all of those components have been chosen in a way that it’s either possible to distribute the software as-is, or distribute modified versions where we need to patch. The most number of licenses we used (high to low) is 1) MIT, 2) BSD and 3) Apache.

Open source components in Countly

Ok, here’s the definitive list. There’s a total of 51 components we use, from Jquery modules to Node.js plugins to standalone components. For the sake of clarity, I only included 10 here but in case you need, here’s the full list. You can see the list in HTML here for clickable links.

MongoDB: Everybody knows it. Some hate, some love. It just does the work we need now, handling all incoming data storage and (to some extend) processing. Starting from 3.0, it has compression support but we haven’t tested it as of this writing. As we work on MongoDB more and more, we felt confident that it’s (almost) a perfect platform for an analytics service. When it comes to sharding to handle tens of billions of events per month, setup becomes complicated and headache-prone. Single write lock and replica set design decisions are other issues but we can live with them.

Node.js: It’s a simplified way of running Javascript on server side with a handful (thousands) of plugins to extend. If you know Javascript, and haven’t tried Node.js yet, we suggest you read this document later and start with it immediately. Now. If you ask me how we can come with a complete mobile analytics platform in a short time with a handful of developers, I’d point Node.js.

Expressjs: When it comes to web app server framework, we chose Expressjs because it’s really simple and good at building single-page, multi-page, and hybrid web applications. It is also the de facto standard server framework for Node.js. There are a lot of pros of Expressjs, but my top reasons would be 1) easy to learn, 2) great community & documentation 3) good routing API.

Other than those 3 warriors above, we used Geoip-lite to match IP addresses with city and countries, Mongoskin to connect Node.js and MongoDB, Nodemailer to send daily and weekly email reports, ImageMagick to shrink application icons, Gauge.js for the beautiful online users gauge on dashboard, InitialAvatar.js to render user avatar images with user’s name and surname and wonderful datatables.net library to show all data on a table, and download when necessary in XLS and CSV format.

Acquiring and storing your data

When it comes to feeding data, it really doesn’t matter to us whether data is retrieved from a REST API or an Android device. With more than 10 open source SDKs, Countly works well with several devices, including Mac OS X, Raspberry Pi, set top box and browsers. So if your source of data is not unique, I’d strongly suggest that you build unified method of how to collect and transmit data. If you are interested in how we did that, have a look in this example.

When you send a data, it should be handled by the application server. There are different approaches to this, and no method is really perfect. Again, if you want to make it done on a single server, then you do not need Kafka, Storm, or a similar distributed log handling method. We had a look at different solutions here, including but not limited to MySQL, PostgreSQL, PHP, Java, Tornado, Hadoop, Hive, and several NoSQL solutions and decided on MongoDB and Node.js.

MongoDB offered us a nice combination of high-throughput, low-latency read and write characteristics. It’s also a schema-less document database that supports high data volume along with the flexibility to add new event types easily. If you are going with a batch oriented analytics, it’s time to rethink your architecture now, better than later.

Visualizing data

Honorary UI related library mentions would go to Flotcharts, D3js, Gauge.jsfor their help in making Countly a reality. The reason we choose 3 different visualization library is that no library was good at meeting our requirements.

All time-series data are handled with Flotcharts. We have made extensive modifications to its color, since the green UI we have didn’t really match the default colors of Flotcharts. Initially unmodified Flot chart looked like that in our UI:

Our “slightly” modified Flot is in sync with our green, blue and orange color, and we even put high and low tags directly on the chart.

It’s interesting to note that not a single visualization library is enough to draw a specific type of chart. While we used Flotcharts on the main page, it’s not viable to use it for a realtime charting. To see the heartbeat of incoming users, we use D3js library, as seen below.

And that beautiful gauge is drawn by Gauge.js:

Journey of extending Countly with plugins

So every platform can be extensible, right? Wrong. If you don’t build a plugin or module based system, chances are you will spend less time building a system that is similar to monolithic Linux, but later find out that what you need a microkernel Linux. Our readers who have dealt with Linux may remember the flame war between Linus Torvalds and his teacher, Andrew Tannenbaum about which kernel type will win: a system where all services as well as core functionality are tight knit group sharing the same space (“monolithic”), or an approach where core functionality is separated and isolated from other system services and device drivers (“microkernel”).

Apparently, modular systems win. If you are going to write a big platform from scratch, design your system so that it is extensible by modules, plugins — whatever you call them. It’s harder in the beginning, but it’s better than making a plastic surgery to the whole body. Chances are you’ll come up with an ugly platform, in which you’ll spot bugs for quite some time after trying to make it “pluginifed”.

Ok, back to how we did that. As features started to soar with Countly, we sat down and decided to make Countly modular. This way, it was possible to develop a plugin without touching the core. We also had the need to disable a particular plugin which is not needed at all (e.g Density plugin is irrelevant for iOS apps), or make a plugin work in a different way when a web app or mobile app is viewed.

There were some hard times to draw a line between where the core ends, and where a plugin begins. Core part of Countly should have been minimal enough so that we could use Countly for any type of analytics task, and also should make sure that number of plugins are kept small and manageable. We had a look at how Atlassian, Wordperss, SugarCRM, Magento and many others handle those points and we (according to us) found a sweet spot.

Now, since version v15.08, Countly has a plugin mechanism where you can extend Countly as you wish. This was one of the best accomplishments of Countly Team. As of this writing, we have more than 35 plugins for Community Edition and Enterprise Edition. Soon this number will soar as we started helping our customers develop their own.

Bottom line: Open source is our life

If you ask what would one thing that we learnt from this journey is, it wouldn’t be possible without open source. All libraries, SDKs, database, application frameworks that we externally use are open source. A quick look at Countly codebase reveals that we are approaching 150 K SLOC, and open source components we use contain much more source line of code than this — even not counting MongoDB, Linux or Node.js into consideration.

If you think of using proprietary technologies, think twice. There is always an open source technology out there waiting to be used for the masses and Countly is not an exception.

-- Countly Team

#open source #analytics #mobile analytics #mobile marketing #dashboard

Parse shutdown: A reminder for our philosophy as a mobile analytics and marketing vendor

After Parse announced that they will be discontinuing their product next year, developers started worrying about where to migrate, and how. Most of them were quite frustrated with the fact that Facebook is not providing this service anymore, and skeptical with using another backend platform.

We understand how they feel about it - over 600.000 app developers will have to find another home for push notifications, backend services and mobile analytics. This can be something in between a quite easy task and a daunting work that can take several months, depending on the integration level.

We also know that many developers have been exploiting Parse only for push notifications and mobile analytics, and do not touch BaaS part. In this case, since Countly is both an open source and self-hosted solution, you can rely on our core business strengths to move forward (and not "move on" like Facebook).

Countly has always been friendly to developers, with its core values, including but not limited to:

Openness, both as a company and our source code so you can create your own building blocks on top of Countly and reach us to get help while innovating.

Completeness, from being an analytics platform to providing push notification services, crash analytics, user profiles and attribution analytics for mobile and web, so you do not have to integrate several SDKs to meet your requirements.

Free from vendor lock-in problems, as you don't have to worry when a cloud service will go down - simply download either Community Edition or Enterprise Edition and host it on your own servers.

I'd like to clarify the last point here - yes, you get full source code for Enterprise Edition, and even write plugins on top of it. That means you are not bound to us to add another feature for Countly. This has been our sharp focus for last year, since we understand how frustrating it is for developers not to see a specific feature in their favorite tool and have to rely on their provider.

We’d like to thank you for your humble support since our very beginning, and we’ll continue to make Countly backend and SDKs as open as possible in the future.

-- Onur Alp Soner, CEO

#mobile #analytics #push notifications #web analytics #attribution

Google's App Indexing Could Spell Big Changes for Mobile

In yet another giant step towards making mobile play nice with the traditional web—and bringing the tools and functionality of that web to the mobile world—Google recently rolled out its app indexing API and is encouraging mobile developers on both Android and iOS platforms to start making use of it.

Indexing offers a whole new opportunity to mobile developers, allowing your app and even its internal content to appear in mobile searches, even if they've never heard of let alone installed your app before (for Android apps at least). You can bet that this indexing will carry over to traditional web-based searches, first in a tricky of authority influence and then the in a torrent of direct search rankings for mobile app content.

That will have a significant ripple effect through things like PPC advertising, keyword competition, and targeting—not to mention user engagement and app installation opportunities. This inevitable turn of events is something both mobile and web developers will need to contend with, and the time to start planning is now.

Get Indexed, No Matter How You Feel About It

First things first: You need to get indexed. Not indexing your app is simply saying you don't want to be found even when users need you the most, and that you're cool with your competitors capturing interest and users at your direct expense.

According to Google's own numbers, one in four apps is never used at all, and only 26% of user installed apps see daily use. That's pretty low engagement for the majority of apps out there, and indexing provides an opportunity to change all that. Indexing your iOS app allows your app's existing content to surface in searches conducted by existing users; Android apps can be found by non-users in addition to having installed content rank for searches.

In other words, users (and potential users) will find you when you're relevant, and that can only mean a boost to engagement. Some will say that this is one more way for Google to wield authority in the mobile world, but...well, yeah. They're Google. They're sort of a big deal.

Start Developing for the Web

Google's app indexing will only work on mobile content that supports http requests so a modest amount of traditional web thinking is already an important part of current mobile development. Remember, though, that this is only one step in Google's (and others') quest to bridge the gap between the mobile and "fixed" or traditional Internet.

Users want a seamless experience. They want apps that function more like websites and websites that function more like apps, with information and functionality that translates from one to the other with ease. Google want to give it to them and App Indexing is a big part of that—it allows the search function on mobile devices to act more like search on a desktop or laptop computer, and it allows mobile content to be returned with the same likelihood as traditional web content.

Develop your apps for the web world as well as the mobile, and you'll start seeing the rewards right away.

Think About More Text-Rich Content

Here's where we get into the predictions, and this one might seem a little wacky at first. With video content all the rage when it comes to user consumption and to search rankings (for obviously related reasons), a recommendation to start creating more text based content might sound like suggesting you use a typewriter to write out your code.

Indexing is all about search rankings, and as much as Google loves to rank videos and other media-rich content it still needs text to crawl for the purpose of confirming keywords, determining relevancy, and establishing authority. You'd be amazed what a good description can do for a YouTube video's ranking, even if no one ever reads it.

Even though indexing is pretty limited at this point, you can bet that full-app crawling is just around the corner. Effective text-based keywording is going to matter for mobile apps just like it does for websites. We're not suggesting you adding some text and putting information where both users and search engine bots can read it is probably about to become really important.

Prepare to Rethink Mobile Competition

This change is more definite, and looming far closer. With a new way to discover apps—a way that you can bet Google is going to prefer due to its organic way of sorting relevance and user approval—app competition will no longer be limited to the app stores. Every time a user conducts a search, first on their mobile devices and soon enough on the web, your app will have the ability to compete and capture attention.

It's an entirely new way for you to reach out to your users, and an entirely new way for your potential users to organically discover you.

And—you knew it was coming—this changing competitive landscape means analytics will become ever more important. Cross-platform, detail-oriented, real-time data is going to matter for mobile more than ever, and integrating your web and mobile data in a single, easy-to-use dashboard will be all but essential.

Good thing we came along...

-- Countly Team

#app indexing #mobile app indexing #mobile analytics

Going Jedi with Your Web and Mobile Analytics

With all the Star Wars excitement in the air, we couldn't help but join in ourselves. Besides, the connection between the world's leading scalable mobile and web analytics platform and the saga of good versus evil unfolding in a galaxy far, far away is as clear as Yoda's mind while meditating on dagobah... right?

Data is like the Force, and Countly is the benevolent Jedi Order giving you the tools and training necessary to always be in the present while predicting the future. With proper focus, you can gain deep insight into the minds of others, achieve greater balance and success, and avenge the death of your moisture-farming family at the hands of the Empire.

Or something like that.

Here are few more ways you can take your analytics efforts to Jedi levels, creating your own saga of everlasting success.

1. Find Balance in Your Metrics

There's not so much a light side/dark side of web and mobile analytics that you need to worry about, but you do have to balance your resources in order to maximize the impact of your analytics efforts. You can measure pretty much anything, but if you try to measure everything you'll spend all your time chasing figures and no time putting the results into action.

If you're a young Padawan—a startup, entrepreneur, or developer who is just beginning to learn the ways of the Force...er, analytics—it's important for you to build your skills before you try to tackle the enormity of the force. The Internet, both web and mobile, provides so many opportunities for data gathering that it can quickly become overwhelming, especially when you're just learning the ropes. Being overwhelmed by your analytics potential can make you afraid, and fear is the path to shutting down your data and eventually going dark.

As in, out of business.

Even enterprise-level operations need to find balance in their analytics. There are some metrics that matter more and some that matter less; some that are more resource-intensive to put to use and others that can be directly translated into action; some that do more to inform product development and others that inform marketing. Allocating resources to cover what's necessary in a meaningful and actionable way means knowing how to focus and knowing what can can be snipped away.

It's almost like running an Empire.

2. Let the Data Flow Through You

After you've honed your data collection processes to a point as fine as a lightsaber's, you need to learn to let the data flow through and turn into meaningful action. Why spend your time and energy gathering information if you aren't going to put it to use? That would be like having the ability to manipulate film footage shot decades earlier and not changing a seemingly insignificant scene that proved pivotal in a character's development (Han always fired second, if you ask George Lucas…)

Be like a meditative Jedi with your data. Open your awareness to it, let your knowledge be all-encompassing, and then let the information flow back out of you in the form of tasks and tactics that you and your team can follow to improve user experience, increase conversions, and get your revenue to grow like a Hutt on space-roids.

This is going to involve some trial and error—it's not like Palpatine shot lightning bolts from his hands on his very first try; translating data into real physical results takes practice. But with real time data flowing past you in its never-ending stream, you'll be able to see how well your actions are working as soon as you implement them. You'll be able to see a disturbance in the data right as it happens, and adjust your actions accordingly.

3. You Must Unlearn What You Have Learned

You might already be a Jedi data master, but unless you're staying on the cutting edge of analytics capabilities and advice you've probably been exposed to a bit of misinformation. If your knowledge comes from "marketing gurus" who use landing pages that are thousands of words long and keep you scrolling even longer than the opening scene of the Star Wars films themselves, you've been exposed to a LOT of misinformation.

Either way, there are probably some things you think you know about analytics that you'll need to unlearn before you get better.

Think of all the unlearning that has to get done just in the first installment of the original trilogy. Han has to unlearn his attitudes towards freedom and money, Luke needs to unlearn what he knows about his father and his reliance on his targeting computer, R2D2 needs to unlearn his loyalty and motivational programming so he can carry Princess Leia's urgent message….it goes on and on.

You need to unlearn your programming when it comes to analytics, too, giving yourself a clean slate to build a strategy that works for your current business and its current position. Analytics is far from one-size-fits-all; you need a blueprint as detailed as the plans for the Death Star and as unique as a lightsaber you built for yourself.

How to Hit A Bullseye

Finally, you need a Jedi's confidence that you'll be able to drill down and dial in your data so you can hit a bullseye—metaphorically speaking, of course. You need to know that the tools and information you have at your disposal will let you target users so precisely that sales are all but guaranteed, and you need to do it while your business is racing ahead like an X-wing with a couple of TIE fighters on its tail.

The trick? Use the Force!

When you let your data do the work for you, analytics is easy. Let your data guide your thoughts and actions and make sure it's responsive to your commands, both shaping and shapeable like that all-pervasive energy that binds the universe together. become so masterful with your analytics that you can almost put them on autopilot—that's the true Jedi way.

And Countly can help.

#mobile analytics #mobile monitoring #mobile measurement

How to get analytics right the first time?

98% of all analytics data are never visualized and analyzed. It costs time, energy and manpower to collect right data that is synched with business objectives. This article shows the most important steps as you get to know how your customers are doing inside your app.

We have to admit — there is no silver bullet when it comes to data analysis. Many companies claim they do miracles about getting insights from their apps, but the fact is, they have data scientists that keep them sticked with graphs all the day long.

In order to get an understanding of how data works for you, and how to get the most out of your Countly data, you first have to make sure that you start at the right point. It’s important to visualize data, but in order to get insights, you need to collect the right data first.

For the last 3 years we have been in this space, finding out the right steps has always been challenging. You can find our experiences below, and apply it to your analytics dashboard:

1. Make sure you track right events

Choosing what to track is hard. Countly keeps track of both predefined events (e.g device and user specific), together with custom events. It’s the custom events that you want to think on over and over to make sure you collect the right “signal”. Those can be in app purchases, time it takes to complete a level, customer lifetime value, habits, attitudes, application settings and more. Make sure you don’t collect hundreds of events in order not to get drown in open ocean.

2. Prepare relevant reports and send it to all stakeholders

All product managers should live and breath data. But in a commercial and enterprise environment, not only product managers, but also data analysts, team heads and even CXOs should be properly fed with relevant and timely reports. Those reports could be prepared with the corresponding audience in mind, e.g a report sent to a manager who leads data analysts would be interested to see details, whereas a CXO wouldn’t mind (and wouldn’t be able to read) lengthy powerpoint slides filled up with several charts, comparisons, detailed numbers and stat graphs. So the bottom line is, make sure you present the right data, at the right time, to the right audience!

3. Collect user profile data and use wisely

Countly has the ability to collect user profile data automatically. Contrary to general market trends, we don’t charge from collecting this profile data separately, so why not use it extensively? Opportunities are endless:

You can assign any user specific information (avatar, email, social media handles) to a user.

You can send any number of properties and tie it to a specific user.

You can see which users have experienced crashes and exceptions.

You can view past habits, e.g whether a user has passed a specific, predefined flow.

User Profiles are tightly integrated into Countly, so you can also drill down collected data, and send push notifications to a group of users having iPhone 6S and living in London, or drill down user information (e.g list all users having phone numbers in Greece).

4. Use APIs wherever possible

One of Countly’s best well known secret is its API driven backend. What does that mean to you? Well, if you have another site, you can embed Countly data and show where your mobile app users are loading your app, on a beautiful dashboard. If you have another company dashboard that you list KPIs and important metrics, you can embed data retrieved directly from Countly backend via APIs. Opportunities are limitless, so it leaves to your creativity to come up with an exciting solution.

5. Use Countly mobile and iPad apps more often

Due to popular demand, we built Countly Android, iOS (iPhone & iPad) apps, which has proved to be popular among Countly fans. These apps help you check how your apps are doing, without the need to open your laptop. Easy, fast and runs everywhere. Give it a spin!

Get Android app

Get iPhone/iPad app

6. Understand how to read retention data

One of the most important metrics of calculating user loyalty is retention graphs. With retention graph, you can calculate whether you have one shot users, or are they really coming back to your app after first installation. Usually when we speak about retention, as an industrial standard it’s better mentioning day 1, day 3, day 7 or day 30 retention. For example, day 1 means 1 day after the start date of the retention graph. For more information, read one of our earlier blog posts about how to read retention tables.

With those small steps, it’s easy to get the first steps towards your mobile and web analytics. Keep in mind that understanding what KPIs to measure takes time, and not all apps are the same!

Countly Case Study: Giving Everimaging Insights from 6 Billion Monthly Data Points

We know there are a lot of indie application developers out there who need a reliable way to capture, record, and analyze data from their users and sessions, which is why we strive to provide a simple and affordable solution that makes the most of your data without destroying your bottom line. Countly is here to help all developers succeed, and we know you can use all the help you can get when you're just starting out.

Of course, everyone is growth minded, and we want Countly to work for you when you've reached enterprise status, as well. Our dashboard and every tool connected to it is completely scalable and provides more than enough power for even the largest analytics endeavors—and we've got the case study to prove it.

EverImaging: Leading the Charge for Digital Photo Developments

Founded in 2009, EverImaging has quickly built a name for itself as one of the prime developers of digital photo handling and editing software.

With a heavy emphasis on research and innovation, EverImaging is at the cutting edge of High Dynamic Range or HDR image processing and reproduction—techniques that give printed/published images a greater range of luminosity than was actually captured in the initial photograph—as well as offering a suite of more traditional yet still highly innovative and highly effective portraiture editing, special effects, and "filter" software.

Not only does EverImaging produce a variety of digital image processing tools, but it also makes them available across a wide variety of platforms: Windows, Mac OSX, Android, and iOS. With all of these different platforms, not to mention the various versions still in use, EverImaging needed an analytics solution that could work across all users to provide truly comprehensive and relevant data without paying multiple vendors, logging into multiple dashboards, and manually integrating data from different sources.

Overall volume was also a concern; though EverImaging might not see as many user sessions each day as, say, Instagram, their users are still generating a substantial number of API calls—an average of SIX BILLION EACH AND EVERY MONTH!

An analytic platform that is diverse, robust, and scalable was an absolute necessity, and the list of requirements EverImaging had for their optimum data analysis partner didn't end there:

Accurate and reliable data collection across all users

Always-current data with real-time capabilities

Granular data collection, viewing, and analysis with multivariate segmentation

Individual department access to raw data and visualization as needed

It was a tall order, and EverImaging spent a fair amount of time looking into several analytics vendor options before coming to Countly.

Why Countly was the leading choice for EverImaging?

First, Everimaging started eyeing up Countly because our price point was way more attractive than many other operators. It's easy to overpay for your analytics, and you don't always get great customer service in return for your premium spend. With Countly, you get affordability and accountability—a real commitment to seeing you achieve great things with your data, with pricing that helps us all continue to scale.

Once we had EverImaging’s attention, they were sold by our comprehensive and all-inclusive feature list. Not only did Countly's existing services every item they had on their analytics wishlist, we could also help them do things they hadn't even dreamed of—and tailor a few other options to work seamlessly with their existing internal processes.

Comprehensive data collection and analysis capable of capturing the finest detail, push notifications to improve communications and put data to direct and immediate use, real time data viewing for always current and always actionable information, and an open-source backend with a low footprint SDK to allow for constant tinkering, tailoring, and ever more effective data analysis that atapts to EverImaging’s evolving needs.

Countly simply outperforms the competition in every area, while covering more areas than anyone else out there. Just listen to EverImaging CTO Jan He:

"We have been in search for a mobile analytics platform for quite some time and decided to go with Countly, given its strengths over other platforms, such as data collection and storage capabilities, real-time dashboard and ability to access raw data in-house. We will continue to use Countly to get insights about our mobile applications and understand how we can make our applications to serve better needs."

We're blushing, but just a bit.

Countly Puts Transparent Analytics Power Right at Your Fingertips

It takes a lot of careful design and purposeful effort to take six billion data points every month and turn them into clear insights and actionable information. EverImaging couldn't settle for a platform that only did part of the job, or only worked on some platforms, or only let you see summary data in real time—or that only allowed them to see part of that their system was capturing.

See, in addition to our competitive pricing, our responsive customer service, and our powerful and all-encompassing suite of data collection and analysis tools, there's one thing that truly sets Countly apart from all the competition: complete transparency.

The fact that Jan He mentioned the ability to see raw data in-house as one of EverImaging's reasons for choosing Countly took us by surprise, though maybe it shouldn't have. It only seemed natural that our clients should be able to see every piece of information they're counting on Countly to collect, but apparently that's not how everyone does business.

We're thrilled that EverImaging saw the benefits of working with us so they could let their mobile analytics truly shine, and we're proud to be a part of their efforts ever more useful and ever more engaging photo editing tools across all mobile, desktop, and web-based platforms.

You don't need six billion data points a month to make a partnership with Countly a worthwhile investment. Contact us anytime to see how we help developers large and small meet with success through data analysis.

-- Onur Alp Soner, CEO

#mobile #analytics #marketing

Big Players Go Mobile, But Countly Still Has Your Back

2015 has seen some big moves in the world of mobile, from Google's announcement that web sites' mobile-responsiveness now matters even more in search to the fact that people now spend the majority of their digital media hours on mobile devices.

Then there's the recent flurry of stories about major players like IBM, Adobe, and others finally stepping into the mobile analytics arena in a major way. These recent moves have been creating a lot of hype amongst tech media outlets, signalling that the rest of the world—and not just lowly mobile app developers like yourselves—are finally recognizing just how important mobile is to today's consumers and Internet users.

We've been making some major strides with our mobile analytics platform here at Countly, too, and we've been hard at work bringing the same powerful tools and easy-to-read dashboard to your non-mobile efforts. Given this year's trends and the past month's headlines, we thought this was a great time to give you the low-down on how we stack up to the competition in the mobile analytics space.

Why We Welcome the Competition

The list of big operators starting to eye mobile analytics as a serious sector has grown rapidly in the latter half of the year. Marchex has announced what they call a "breakthrough" that can help display advertisers attribute consumer actions to the ads they've seen on mobile; Wipro and IBM have announced a new partnership to speed up the development of the former's mobile analytics platform; and Adobe announced that its content-testing marketing platform, Target, is finally gaining some mobile capabilities.

You might think that all of these major new entrants to the mobile analytics space has us worried, but in reality we're celebrating the fact that our vertical is finally getting the attention it deserves.

Here's why.

1. Competition Drives Innovation

We've been innovating in the mobile analytics space for awhile now, and we've never planned on settling for "good enough." Still, the added competition will help drive innovation in mobile analytics even faster, and will give us more and better insights into how we can serve our clients—and how you can do more with your apps.

2. More Attention Means More Third-Party Agreements

Asmobile analytics finally heads into the mainstream, more and more mobile operating platforms, ad networks, and other relevant third-party players will include analytics demands in their development process. That means more access to information and more opportunities to put that increased data to use. That's good for Count.ly, and good for mobile app developers of all stripes.

3. Analytics Options Means More App Developers in the Market

Not only will the increased attention from big-time software and marketing firms pull more third-party vendors into the mix, but it will also encourage more app developers to pay better attention to their analytics—and maybe even encourage more people and companies to get into mobile app development in the first place. The more information you can gather, the easier it is to make things effective and efficient on a cost basis, and that means more rewards for the time and energy you invest.

4. Countly -Still- Does Mobile Analytics Better Than Competitors

Finally, if you take a look at how the new (and the existing) competition compares to what Countly already offers—and the great stuff we've got in the pipeline—we think it's pretty clear that most mobile app developers can benefit a whole lot by sticking with our greater experience, greater flexibility, and more responsive support.

What Countly Can Offer to Mobile Analytics Users

First, you might have noticed that the "big announcements" from larger firms are all about individual analytic features rather than comprehensive systems: allowing app managers to track attribution, creating a mobile development platform that can lead to better analytics down the road, or granting developers the ability to test ad content on mobile devices.

Countly does all of this and a whole lot more, all using one SDK to send data, one simple dashboard for viewing data, and one set of tools to expand features. You get comprehensive mobile analytics without the need to pay multiple vendors, log in to multiple systems, and create redundancies that drain your time and put your data at increased risk.

Second, you get more data than any competing platform currently offers (and we're adding new functionality all the time). From the basic data on your app's performance that you'd expect from any analytics platform to data on your users, attribution insights, crash reports, push notification capabilities, and more, Countly offers full app management and analysis, not just a few analytics bits and pieces that leave you with an incomplete picture.

Countly's platform is far and away the most comprehensive mobile analytics platform around. Add the fact that we're expanding to offer traditional web analytics that are just as robust, giving you a truly comprehensive one-stop dashboard to manage ALL of your apps, advertising, and other online efforts, and the choosing Countly becomes even easier.

Third, we're not Adobe, or IBM, or Wipro—we don't have dozens of other departments and products that drive us as a company, and that might cause us to simply drop our analytics platform if we feel it isn't profitable enough. Big companies enter and exit specific vertical niches all the time, trying out each new trend and seeing if they can come up with something that sticks, then leaving just as quickly if they don't see fast enough growth.

It's a viable business strategy for a giant corporation, but it can leave their clients out in the cold. The platform that seems so promising today might disappear tomorrow when the next glittery promise of profits glints on the horizon.

That's not something Countly will be doing. We're a mobile and web focused analytics, marketing, and performance platform, first and forever. Our focus means we're more committed and more flexible and responsive to our clients' analytics needs. Our retention rate is one of our biggest measures of success, and we don't plan on changing that any time soon.

-- Countly Team

Supercharging Your Analytics: The Metric That Matters Most for Your Mobile App

Data is awesome - and a little bit overwhelming (OK, it can be more than a little bit overwhelming. That's why we created the powerful yet simplified tools of the Countly suite to begin with). The right data gives you a great deal of actionable information about your users, your revenue, and your brand, but there's so much data going around that you can easily drown in the numbers and never get anything done.

We're here to help you change that.

While different mobile apps use different business models—sometimes drastically so—and therefore need to be tracking different things, there are some common areas that all mobile app developers need to be on top of.

One data point in particular should be the foundation of your analytic efforts, giving you the inside scoop on what's working, who it's working for, and how you can make it work even better for more revenue and bigger profit margins.

The Importance of Session Tracking for Your Mobile App

Everyone tracks app downloads, but all your download rate really tells you is how effective your lead generation and initial marketing efforts are—important, to be sure, but it doesn't tell you anything about the user experience or your revenue.

The number of unique user sessions, however, tells you a great deal about your app's effectiveness and engagement after a download, which means you're tracking the performance of your app itself and the effectiveness of your ongoing outreach efforts.

You're looking for regular engagement that signals users are finding your app useful and accessible. Different types of apps will find success with different average session numbers, of course; game and social apps might like to see several individual sessions per day, especially right after a download; financial apps might be doing great with unique sessions started once or twice a week.

Putting Session Numbers in User Context

Facebook probably wants to see the top users of its Messenger app starting unique sessions a half-dozen times a day or more. It's only useful as a central communication tool if users are constantly checking in; not every user will make it the cornerstone of their communications, but if those that do aren't creating plenty of daily sessions there's a problem.

USAA's banking and insurance app, on the other hand, is probably only accessed a few times a week by the heaviest users—maybe an average of once a day for the extremely budget-conscious.

Too many sessions might actually signal a problem, such as users being unable to locate the information they're after, giving up, then trying again.

Things like car sharing apps and other apps connected to real-world service provision will likely see an even large variance in session numbers across users—there are commuters who use Uber multiple times a day during the workweek, and other avid fans who only use it to get around for fun on the weekends. Both are engaged, but the session frequency varies dramatically.

This differentiation is part of what makes session number such an important thing to track for your mobile app: not only does it tell you whether or not people are really using your app after downloading it, but it can tell you a lot about your different types of users and their preferences.

This can help you develop app changes, added-value services, and other adjustments that target your highest-margin users, and help you segment your marketing and your app to different types of users.

Trends in Session Number Changes are Also Telling

Just as different apps will look for different average user session numbers to determine their success, and will also likely have different users with different levels of engagement that can all be considered successful, different mobile apps will have varying levels of stability in their average session numbers. tracking this stability and paying attention to changes in session number can also tell you a great deal about your audience and your app's performance.

Going back to USAA's app, one would expect the average session number to stay relatively flat: people's banking and insurance needs don't change much on a day-to-day, week-to-week, or even year-to-year basis. If the app continues to function and stay up to date, usage (as measured by unique session numbers) should stay relatively stable. If average session numbers start dropping suddenly, or if users start creating fewer sessions within a few weeks of their first use, it likely signals a problem with the app that needs addressing

Games like QuizUp, on the other hand, might expect to see dramatic changes in session number based on the length of time each user has had the app around—specifically, average session numbers for games tend to be relatively high after initial adoption (i.e. downloading), then drop significantly after a period of time, when people grow too familiar with the game.

This is exactly what happened with QuizUp, and can be attributed at least in part to a lack of new material and/or features for the game: heavy users were seeing the same questions again and again, and their interest in the app plummeted.

Using session number trends along with an understanding of your market and your audience can help you plan the most profitable development cycle for added features, new levels or twists to a game, refreshing the user interface, etc. Games should continue to see an up-and-down cycle, with session numbers spiking after a new feature is released and declining until the next release; other apps should seek out greater stability and make the necessary adjustments to keep session numbers stable.

There's Always More Your Analytics Can Do

This barely scratches the surface of what your average session numbers can tell you, and of course session number is just the beginning of your data collection and analysis efforts. You see how powerful and actionable even this one data point can be, however, and hopefully that inspires you to greater efforts and achievements with all your analytics. And if you're ever stuck on a particular app-tracking problem, please let us know—we're always happy to help, and we may even write an article about it!

We are open sourcing our crash analytics dashboard

Today we released a new version of Countly, v15.08, available from Github. In this release, the biggest feature is that we are open sourcing our crash analytics backend and supporting SDKs. It was available for Enterprise Edition customers for a year, and now it’s available for the masses. We are proud of opening our technology for developers to make Countly the best open source mobile analytics platform in the world.

Other than crash analytics, this release introduces daily and weekly e-mail reports plugin, a command line interface for most important tasks, browser plugin displaying browser metric for Countly Web SDK, Ubuntu 15.04 compliance, several UI/UX improvements and bug fixes (detailed list).

So here’s the resulting, shiny dashboard:

Coming back to crash reports, below you can see an overview of how it looks. This interface allows you to easily overview all the crash information you have, identify the root cause of the crash by examining the details and collected reports and manage resolved and unresolved crashes and how many users upgraded to resolved version of your application.

You can mark a crash resolved and it’ll never appear again. Mark it unresolved to take care of it later with your developers. Crash reports have lots of details to help you identify and resolve issues, including but not limited to application version, platform, screen resolution, RAM, disk, battery level, operating system and platform.

Crash reports is available for iOS, Android, Unity and Titanium Appcelerator SDKs. Support for more SDKs and development environments, including Cocos2d-X and Xamarin, will follow.

In this version the number of all open source libraries, SDKs and other components that we have used has exceeded 50. Without them, Countly would simply be not possible!

Last but not least, due to popular demand, we translated all Countly documents into Chinese, including API docs, FAQs, references, user guides and more. That was 52.000 words, or roughly as big as a 200-page book!

Download latest Countly Community Edition v15.08 from Github. All SDKs can be downloaded here. If you have any questions, use our support page so we can help you with installation or configuration.

Enterprise Edition customers

Since each Community Edition we release is synced with Enterprise Edition, there’s also an update with Enterprise Edition which includes all fixes and updates for Community Edition and also updates to Enterprise Edition-only plugins. Please ask your Countly representative to provide you the most updated version and instructions for installation.

— Countly Team

All Countly documentation are now in Chinese

After a long and hard work, we have translated all of our documentation into Chinese. This was a big task compared to the number of all words contained in Countly Resources page - about 56.000 words, or around 310.000 characters. Those who has written a book before can easily make a calculation that the work done is equivalent to writing a 200-page book.

Here’s how our Chinese documentation page looks like:

So why did we do that? In China, Countly is in fact very, very popular. China ranks #3 in visitor ranking and one in three of all Professional Edition inquiries are from China. Almost one in five of all Community Edition servers are installed in China, so this country brings a great opportunity for us to enlarge our user base.

This is why Chinese is very important to us. Besides documentation, Countly dashboard is also fully localized. We’ll keep maintaining Chinese translation up-to-date as we add more documents.

-- Countly Team

Countly behind the curtains: Here’s how we make Countly a better place for command-line lovers

Most of the Countly server underlying technologies (NodeJS, MongoDB, HTML, CSS) are cross-platform. However there are some parts that are quite platform specific, like managing NodeJS processes (using upstart, supervisor, etc). Previously, many community members helped us to support also other platforms (like Mac OS), add more translations, extend Countly with plugins and fix bugs on Github - which meant a lot to us (thank you for that!)

Unfortunately with recent changes with plugin system, upstart integration become much closer to core (due to the need to restart process when installing new plugins), and at some level, it broke backward compatibility with previous Countly ports.

We were thinking a lot on a solution to this problem, and finally the infamous issue with Ubuntu 15.04 moving to another init system (from upstart to systemd) was the last drop for us to stop the work we were doing and spend some time on making this process more robust and init system / platform independent.

And that is how Countly commandline came to be, after a few days of ongoing discussions. Now in development version, but soon in next release, there will be a “countly” command to start, stop, restart countly NodeJS process and do other operations through command line.

Here’s an output from command line (yes, that would require root access for usual reasons):

Since Countly core internally uses these commands, in order to support Countly on other init system/platform you just need to implement support to manage NodeJS process on that specific system.

For that purpose there is a bin/commands folder, where each init system is put in different folder. Also, each init system contains at least two files:

install.sh - to copy needed configuration files for managing nodejs process and do initialization processes, if any

countly.sh - to define bash functions that would execute countly commands, you may override any existing command

Then there is a bin/scripts/detect.init.sh file which installer files use to determine init system and copy this system’s countly.sh file into enabled folder.

And our main countly.sh file will load it from enabled folder, thus overriding existing functions from the new init system and execute them when command is ran.

Of course you can omit using detect.init.sh, do similar thing yourself, only forcing specific init system, like when creating installation file specifically for this system. Basically it is all in your hands.

In the future we’ll be adding more and more command line features, including but not limited to:

Adding and removing a user by name

Backing up all MongoDB data

Restoring data

Adding or removing an application

And many others that are not an immediate need, but would really be “exciting” to see:

Getting number of total users for today/this week/this month

Getting number of push notifications sent

Number of crashes received for (today/this week,.)

We are really thrilling to introduce Countly command line. Do you want more commands and automation tools? Just let us know which features we should support in the future. Feel free to submit a bug on Github and we’ll hear you!

-- Arturs Sosins

Trending Blogs

Recently Viewed Blogs

Countly Mobile Analytics | Blog