Product
How Countly Works
Countly tracks users on mobile apps as well as web and desktop apps using a small plugin (SDK) that you integrate into your application (or website) in under 10 minutes. As soon as there is any activity or event on any of these platforms, Countly immediately starts collecting data. After installing the Countly SDK on your application, the application users will start sending event data to the Countly server. Countly gathers information from these events regarding their actions, how they behave, which operator they are on, etc.
Through a host of available plugins, Countly allows you to track the metrics that matter the most to you, as well as apply the results you get to engage with your customers, boost interaction and retention, optimize the user journey, minimize causes of friction, get feedback, and even test new features - all without leaving Countly. Each team can use Countly's product analytics to track the metrics that are important to them, and all teams can cohesively work toward applying this data to making better business decisions. The interconnectedness of Countly's various features unlocks the potential for companies to completely change their users' journeys and experiences.
Speak to an analytics expert at Countly here or our Customer Success team (for existing customers) to know more about getting the most from Countly.
Countly Updates, Update Schedules, and Update Notifications
We distribute each version through our Github page. Countly changelog lists all Countly versions and corresponding changelogs. The news of new version launches is also shared by email and on our blog. Follow the Countly blog to remain informed of all updates.
Updates for Countly Enterprise and for Countly Lite are handled differently. Regardless, whenever the Countly server gets updated, your Countly instance will be inaccessible for an estimated maximum of 5 minutes. Then, after completion of the upgrade, you may experience lagged performance due to the server processing queued requests. Depending on the number of requests, this impact may persist for no more than between 5 to 10 minutes.
Online Demos
You can contact us to try out Countly, and start working on your dashboard.
Downloading Countly Server and SDKs
Here is everything you need to download and start with Countly,
- Server source code (main branch) can be found on Github for those who want to try the latest code.
- Ready-to-install stable packages are on the Github releases page
- All SDKs can be downloaded from here, including Javascript SDK to track web pages and mobile websites.
Why Countly is an Open Source Code
We want our application created not by a handful of developers, but hundreds. We want to discuss the future of Countly in an open, democratic environment. We want your ideas to put in the next release, so academics, businesses, and enterprises can benefit immediately. Take part in our friendly community! Always feel free to send your bug reports or feature requests, and to provide fixes and best practices.
Other than Countly Lite, we provide Countly Enterprise for companies, a fully supported platform, which is a self-hosted or on-cloud deployed product analytics and innovation solution.
Hosting Options in Countly: Self-hosted vs. Private Cloud Deployment
Countly offers two hosting options. You may either install Countly on-premises (i.e., self-hosted) or let Countly handle the deployment, maintenance, and backup procedures for you through private cloud deployment. The differences between both are highlighted as below:
Private cloud | Self-hosted | |
Server setup | Countly is responsible for the setup and configuration of the operating system, Countly server, MongoDB (including the replica set support), Ngnix, and additional components. | Countly provides the customer with the recommended specifications and configurations for servers that will be used to host the software. The customer obtains and configures the servers according to these recommendations and installs the supported Linux OS along with Countly. |
Maintenance | Countly is responsible for the maintenance of the software and for the end-to-end health of the servers and network connectivity. Network-related issues by 3rd party hosting companies are handled by them accordingly. | The customer is responsible for the end-to-end health of the servers and network connectivity. Any maintenance related to Countly software is executed by the customer according to the directions provided by Countly. |
Backups | Countly establishes and executes backup procedures. | The customer establishes and is responsible for backup procedures. |
Upgrades | Upgrades are automatically applied and tested by Countly after a new version is released. | Upgrades are included as part of the subscription plan and are the responsibility of the customer to install and test. Countly provides documentation for installing any upgrades. Typically, there are 2 major upgrades annually, along with a few more minor upgrades. |
Monitoring | Server monitoring is done using a 3rd party professional monitoring service. In case an issue occurs, the support staff is alerted immediately. | Server monitoring is implemented by the customer and the customer is responsible for informing Countly about any app-level issues detected. Countly can make recommendations for server monitoring services if requested. |
Support | Countly has immediate and full access to the customer's instance and can assist, with client authorization and approval, with investigating, recreating, diagnosing, and resolving any reported issues. | The customer assists the Countly support team by documenting any issues, providing additional information as requested by Countly, and authorizing and approving remote access to the software upon Countly's request. |
Differences between Countly data and other providers data
There are a few reasons for data discrepancy among analytics providers:
- Users may download the application and open it when they do not have network access. In this case, some analytics providers may choose to discard the events, while others choose to store it. Countly stores it, for example, and as soon as the user regains internet connection, the event is sent again.
- Users with jailbroken iPhones may have analytics disabled. In this case, the data is never sent. Also, if a user chooses to not send analytics feedback for their iOS device, it's not possible to report data to iTunes.
- A user may download the application once, but run it on multiple devices, or may download the app multiple times, but run it on the same device. In this case, Google Analytics and other analytics services may count that user differently.
- Some services (e.g. Google Analytics) may sample data, e.g. discard it if the traffic is over their internal limit.
- Countly counts new users as unique device IDs, meaning if a user downloads the same app to their iPhone and iPad, it's counted twice. Apple's iTunes service only counts it once.
- SDKs may have issues with running in different environments. For example, it may send improper encoding, resulting in the server not parsing it. We see such behavior especially in Asian markets with some Asian languages using different encoding types.
- Some of the iOS and Android platforms are old and unsupported by analytics providers. In this case, if a platform is supported by one provider and not the other, then a discrepancy may occur as the SDK will gracefully fail on the unsupported platform.
- Different analytics services have different time-zone configurations. This directly affects how daily sessions, daily unique users, daily active users, and retention tables are calculated.
Other than the possibilities mentioned above, improper integration of the SDK may cause data discrepancy on the server-side, as seen below:
- If the SDK is integrated in a different way than what is shown in the official documentation,
- If the initialization of the SDK depends on any state on a device,
- If the SDK is being used in a non-native application environment,
- If the SDK’s original source code is modified,
- If more than one instance of the SDK is attempted to run at the same time.
Unfortunately, we do not know how the backend and SDK side works for closed proprietary services. However, Countly's SDK, data collection, storage, and visualization methods and database model are completely open source, and it's possible to retrieve stored raw data either via REST API or via MongoDB commands.
With that being said, we have run several units and stress tests to make sure no data is lost during transmission, and we are very confident with our codebase. In the event that you would like to have a separate discussion about how we collect, store, and visualize data, we are always happy to hear from you.
Monitoring Data Point Consumption
Data points include Sessions, Events, information sent when a crash occurs, or when a user responds to a Push Notification. These data points are automatically calculated and reported under Management > Data Points
.
You may view the sample screenshot below. Clicking on each of the months will give you the number of data points consumed by each application as well as all data points under the title "All apps".
Contributing to Countly
Countly appreciates receiving ideas, feedback, and constructive comments. All your suggestions will be handled by one of our staff and will be taken care of with utmost importance. If you are a developer, please fork our repositories and send pull requests.
If you want to see Countly in your own language, please join our localization efforts.
Do not forget to join our Discord community and follow our LinkedIn page, in order to follow our fast progress.
Security Measures in Countly
We take the privacy and security of all our users very seriously. To ensure that your data and that of your users is protected and private, Countly undertakes the following practices, among others:
- When you opt for private cloud deployment, all data is hosted on a dedicated server with Google Cloud Services, which are two leading global cloud services.
- All Countly employees are bound by strict confidentiality agreements. Access to data is provided on a need-to-know basis only.
- You own your data, and Countly does not share it with any 3rd parties.
- Countly has several security precautions like SSL connection, reCAPTCHA, brute force attack, password policy, and (for enterprise customers) data-at-rest encryption.
Version Names and Numbers
Version names are in the format of YY.MM.VV where YY and MM denote the year and month when the release is submitted, and VV is the minor release number (if any). We aim at two major updates a year, and additional minor updates as may be required. For the curious, numbering resembles Ubuntu's release model.
Using One Countly Account for Multiple Applications
You can use one Countly account to control more than one application. We see companies maintaining more than 300 apps at once, on a single server. With Countly's security and data management features, you can easily setup your analytics such that specific teams receive access to specific data only. This enables multiple teams to use Countly's product analytics without the concern of data being wrongly accessed.
Events to Track by Industry
Most of the basic events in your mobile applications and websites are similar, but some events specifically for a domain may provide more insights for your product.
We have created predefined events and shown you what kind of insights those events will give you:
SDK
Operating Systems that Countly Supports
Countly officially offers integration with the world's leading smartphone operating systems, Android and iOS. Also, Countly can track desktop applications and any devices which are capable of sending HTTP requests in general, including but not limited to Windows and macOS. For a list of SDKs, see this page.
Using Countly for Desktop Analytics
Countly uses the same SDK for iOS and macOS, which you can use to track all your macOS applications. There is also a Windows SDK that you can use to track your Microsoft Windows apps. There is also a Windows SDK that you can use to track your Microsoft Windows apps.
How Event and Session data are sent to Countly
As the user opens the application, the Countly SDK starts collecting data the way you define it. Events and Sessions are collected and then sent to the Countly (or your) servers using an HTTPS request every 60 seconds for mobile SDKs, and every 500 milliseconds for web SDKs.
Note that you should see Session data on your dashboard as soon as the app launches. However, for Events, you will need to wait for the next tick, which occurs every 60 seconds. If you record more than 10 different events inside the app, it will not even wait for the next tick, sending them immediately instead.
Dashboard
Tracking Data in Real-Time
When a Countly SDK sends data to Countly, you see the data in real-time. There are no batch processes running in the background to visualize or collect data. This helps Countly user the ability to respond faster to product performance issues, follow live activity when required, and review the same data at the same time across teams.
Impact of Countly on Application Speed
Countly has a negligible effect on the speed of your application, ensuring that it does not adversely affect any aspect of application load time and performance. Our lightweight SDK works asynchronously and doesn't block any function calls inside your code. Profiling for iOS shows that SDK has a 2% overhead on total CPU usage. Compared to the high CPU and data consumption for services that send in-app video, this is clearly an advantage.
Our tests with an Android profiler prove Countly takes up less than 0.1% of your CPU time for a single CPU core in a typical usage scenario of a 5-minute session where 5 events and 8 requests are sent. This number will be lower than 0.1% for more CPU cores.
Languages that Countly supports
Countly supports more than 10 languages. Head over to the Countly localization project and support us if your language is not on the list. Sending an email to us will suffice to start.
Using One Countly Account for Multiple Applications
You can use one Countly account to control more than one application. We see companies maintaining more than 300 apps at once, on a single server.
Browsers that Countly Runs On
We test Countly on Chrome, Firefox, and IE9+. A recent(ish) version of these modern browsers works well. We do not support IE8.
Roles of Each User Type
You can choose the role to assign to each person based on the access you wish for them to have to your data.
Regarding roles, there is a rule of thumb: "User" can only read and not write/modify; "Admin" can read and write/modify, but only in the context of the app that is given to them; and "Global Admin" can read and write/modify all apps and server-wide things. More information in this regard is provided here.
Server
Programming Language and Underlying Infrastructure
Countly relies on MongoDB, Node.js, and Nginx. The main programming language is JavaScript.
Why Countly Uses MongoDB and Node.js
We searched for the most reliable and performance-centric stacks and chose our stack carefully. MongoDB and Node.js are used across the globe and are powered and trusted by tens of thousands of companies, from Foursquare to Adobe and eBay to McAfee.
FAQ
What happens if the SDK cannot send requests?
If your mobile application cannot send event information (mainly due to the fact that the device is not connected to the internet, the user is on a plane, or currently underground in the metro), then this information is stored in non-volatile memory. As soon as the connection is established, it's sent to the server and the data is removed from the queue.
In which situations does a device ID reset?
There are some cases in which a device ID may be reset. You can see a breakdown of the platform and when a device ID may reset below.
Does device ID change? | App upgrade | App Reinstall | App Reset | Device Reset |
Android Open UDID | no | sometimes | sometimes | yes |
Android Advertising ID | no | if reset by the user in OS settings | if reset by the user in OS settings | yes |
iOS IDFV | no | if it is the only app from the developer | N/A | yes |
Why do events take time to appear on my dashboard, instead of appearing in real-time?
Due to time-zone differences (the time zone in which the event takes place on a device and the time zone of the app setting in the dashboard), there may be cases - while converting a timestamp to your app's time zone - that the events are added in real-time to the timelines, albeit with an hour delay. The delay may also depend on the devices and SDKs. For example, if a device is offline, the requests are queued and then synced with the Countly server. Since a recorded event’s timestamp will be in the past, newly added events will count as past events in the dashboard.
How do you calculate online users?
Online users are unique users for which we received a begin_session and have an ongoing session extended by session_duration and/or event requests. We consider the user as offline as soon as we receive an end_session request for them, or after 60 seconds have passed since their last request was received.
This feature is available only with the Enterprise Edition.
Sometimes I see "unknown" cities on the dashboard; why is that?
To determine cities/countries, Countly uses Geo IP Lite to determine the origin of the IP address from which the connection has come. There are two reasons why Countly may not be able to determine this information:
- Countly can't determine the IP address of the HTTP request. This information is usually provided in the HTTP header and if the sender does not include it, Countly cannot determine the IP address of the connection. In this case, you may try sending the IP address as a parameter along with the request.
- Some IP addresses might not be in the GeoIP database or they are not city/country specific, which is why the originating city/county cannot be determined.
Sometimes I see wrong city names on the dashboard while I am testing; why is that?
If no location is provided by setting user location, it will be approximated by using GeoIP. In this case, Countly determines city names based on the IP address as a default method. Some inaccuracy for city names may be observed for the below reasons:
- Some users may have used a VPN
- Some IP addresses are simply not correct
- Some inconsistencies in the GeoIP database
- Firewalls stripping IP addresses from requests and setting local ones
For more accurate city name on your dashboard, you can provide country and city in SDK or provide longitude and latitude. For this method, please read our SDK documentations.
Click for Windows SDK
Click for iOS SDK
Click for Android SDK
How do you calculate the live users bar chart?
When you login to the dashboard, the live users chart on the top right of the page displays how many users have opened your app in the last 10 seconds. For example, if you see the number "80" displayed there, that means your app has been opened by 80 users in the last 10-second time frame.
This feature is only available in the Enterprise Edition.
I see differences in total users; why is that?
By default, the exact number of users will be shown for 7 days, 30 days, 60 days, and any period that contains today. When you exclude today in your time period or provide a custom time, Countly estimates the total users.
What happens if my users send my application to the background?
As soon as your application is sent to the background, the session is over. Session calculation doesn't involve apps that are sitting in the background, so for a session to be live, the app should be running and sending data to the server.
Can I see the analytics of my social media accounts using Countly?
You can do it by creating a custom plugin and integrating it into Countly.
After a user opts out, will they be tracked as an anonymous user?
Opting out is not a part of tracking. Anonymous users are decided based on the information that they provide to your application.