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.
How many users can a Countly server handle?
A high-end server can handle several hundreds of events per second. For more information, see the deployment scenarios for potential installation methods for different traffic levels.
Are there any video tutorials for installing and configuring Countly?
There are several videos on the Countly YouTube channel. Click here to go directly to these videos. If you would like more information on any specific feature or query, please write in to our support team.
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 time zones affect data?
The time at which data gets recorded in Countly varies depending on the type of data.
- SDK data gets recorded in milliseconds timestamps and in the GMT time zone.
- Granular data is recorded also with this millisecond timestamps.
- Aggregated data is recorded in the app's time zone. You can change the app's time zone by clicking in the top-right corner in Management > Applications > Time Zone. However, note that if the time zone is changed, it can create a gap or overlap in the aggregated data accounting for the time differences.
Similarly, some of the actions you take with these data sets might be different:
- When querying granular data (e.g., a drill query, funnel activity, etc.) from within Countly, the query period is adjusted to the app's time zone. But when querying raw data directly from the database, it will always be based in the GTM time zone.
- When viewing data in the Dashboard, timestamps will be based on the time zone of your browser or device. Keep in mind you will need to consider if there is a difference between the time zones of your app and of your browser/device.
What is the average disk-data usage per event?
As a simple example, a request carrying 10 events, where each event has 10 segments, will total around 8 KB. If this is a single event with 10 segments in a single request, it totals around 1 KB. The size depends on various factors such as the length of the event keys, the length of the segment keys, and the values. A reasonable event request will total around 1 KB.
Other than that:
- A request to change/add user properties would total around 1 KB for 10 properties.
- A standard begin session request will also total around 1 KB.
Basically, any extra event segment and user property will affect the data transfer volume, but to which amount is dependent on the size of the segment and user property. Roughly speaking, each 1M requests will cause a data transfer of 1 GB, however we have customers storing less than that, and significantly more than that.
By default, SDKs send data over to the server every minute or whenever the internal queue size reaches 10 (may vary based on the SDK), and these values are configurable. In a scenario where it is okay to get data with a delay and you’d like to save bandwidth, we recommend increasing these numbers, as the HTTP request itself has an overhead, thus sending the results in bulk in bandwidth savings. Obviously, keeping numbers of events, segments, and user properties low will lower the volume.
How can I increase the max size of data stored in the events logger?
It is possible to increase the max size of data stored in the event logger plugin. You will need SSH access to your server for this.
First, go to Management > Applications and note down your APP ID. Then, SSH to your server, and with root or sudo credentials, run the following:
mongo countly
db.runCommand( { convertToCapped: 'logs{app_id}', size: 10000000, max: 1000 } )where logs{app_id} should be replaced with your app_id, such as logs53ef75bg5c1ba8237a2d05 and the max should show the new limit, such as max: 2000. Here, size denotes the default document size, which has a 16M maximum.
Does Countly use all the cores in my server?
Countly uses a cluster mechanism in api.js to fork itself according to the number of cores in the server in order to increase utilization. This may also be configured from api/config.js by changing the "worker" count.
Are there any limits on data collected?
Both yes and no. In some cases, we limit the data sent to make Countly perform better and be able to handle difficult conditions:
- For Events View*: 500 events - 100 segmentations for each event - 1000 unique values for each segmentation
- For Drill: 500 events (together with Events View) - No limit on segmentations or values
- For Funnels: 8 steps (configurable from
Management > Configurations) - There are no limits on the server’s CPU or RAM and there are no limits on the number of accounts, applications, or users.
*The possible effects of increasing event views' configurations over the above defined limits:
- Events limit (maximum of 500 unique event keys): It would mostly slow down your event dashboard where it lists events on All Events page. It affects both drill and aggregated data.
- Event segmentation limit (maximum of 100 for each event): It would slow down UI lists as well as make documents bigger, thus it causes bigger writes and reads on database, lots of data transfer. It affects both drill and aggregated data.
- Unique values for each segmentation (maximum of 1,000 values): It would slow down aggregated data a lot. However, such segments can be omitted by aggregated data (omit segments functionality), in which case it would affect drill meta size until it switches to string. After that, it will only make BY queries for this segment slower.
Note that these limits are defaults and may be reconfigured under Management > Configurations in both the Community Edition (where applicable) and the Enterprise Edition.
How do I remove all users and define a new user?
- Login to your server terminal with root credentials
- Type
mongo countly - Type
db.members.drop()
This way, existing members will be deleted, meaning you will be redirected to the set-up screen once more.
How do I debug api.js when requesting servername/i URL?
You can use a module such as node-inspector if you would like to go into further detail.
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.
How can I test my new translations and where do I put my files?
There are three folders under countly/frontend/express/public/localization:
- dashboard
- help
- pre-login
There are also three translation files on Transifex. In order to test your translation, you may upload your translation file, such as dashboard_ru.properties, help_ru.properties, and pre-login_ru.properties, to the corresponding folder. In order to be able to switch between languages, you will need to edit:
Repeat step 2 for forgot.html, setup.html and reset.html under the same folder.
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.
How do you create a backup of the data? And how long is it retained?
The daily backup takes place at 21:00, UTC+000, daily.
The backup location is the same as the data location. The backup is retained for 14 days.