After you have integrated the Countly SDK into your app or website, to the best of your ability, whether you see some data or not in your Countly server, you should normally verify your integration by checking if everything is working as expected, both on your Countly server and your app/website. To have the most optimized verification process, we recommend you go through the following steps for these cases of integration validation and also for debugging if you are seeing partial or no data at all on your server.
1. Check SDK Logs
As part of the process of integration verification, you would want to enable logging into the SDK and have a look at the printed-out messages. If there were a warning, errors, or deprecation messages, it would indicate potential problems and action items that need to be fixed. Logging can be enabled during the SDK initialization, and the way you do that differs slightly from SDK to SDK. For specifics on how to enable it, you would want to check the documentation of the specific SDK that you are using from here.
After enabling SDK side logging, you would want to run your app or website and check the debug messages that are printed in the respective console. The specific location of that would change depending on the platform and SDK.
Check if requests are being created - this means you need to check whether you are calling SDK methods to actually send information to the server and that the SDK has been implemented correctly.
Also, check if requests fail or are successfully sent to the server because if they fail, maybe the server is not reachable from this specific network, or you made a mistake when providing the URL to the server.
2. Check Incoming Data Logs
Next, you would want to verify that your Countly server is receiving data from Utilities > Incoming Data Logs. Should there be an issue, the request logs usually state what this problem is about, why the request was not processed, or why incoming data may be incorrect - such as sending data for the incorrect app type, sending duplicate requests, incorrectly setting up parameter tampering, etc.
3. Make Sure You Have the Correct Configuration
Here the most important thing is to verify if your 'app_key' and 'URL' values are entered correctly. For more information on making sure that you are using your correct 'app_key' and server URL, you can check out the following section here.
4. Check Your Countly Server
If you have checked your SDK logs and everything seems to be working fine in your app or website, it is time to check Countly if the planned data is recorded as expected. As a simple test, you can simply open User Profiles in Countly to see if your app/website was able to connect and recognized as a user in your Countly server. If it is, you are good to go, and you can stop here on the list.
In case it seems like some data is not being recorded, it can be due to some requests being rejected related to problems with the checksum, or sometimes requests might be dropped if there are filtering rules set to do that. Sometimes filtering rules target more things than planned by accident. For debugging those issues and others, keep reading.
5. Check the Server for Errors
Check Management > Logs > Api Log for errors. Chances are, if there is a problem/bug with a specific plugin processing information, there would be new errors in the logs.
6. Check Plugins
Some plugins that might be necessary to process data and provide functionalities you want might not be activated, or you might have accidentally disabled them. You can check your plugins' status from Management > Feature Management
7. Check Filtering Rules
Events or requests may be blocked. In this case, check Main menu> Utilities > Filtering rules to see whether there are any rules that block events or any requests.
8. Check Event Limits
The event name limit may be exceeded (the limit is 100, by default), and may be adjusted under Management > Settings > API > Data Limits> Max unique event key.
9. Check Checksum
Some SDKs provide an option to send a checksum along the request data to prevent data breaches by a middleman. If you have set a salt for checksum in your SDK but did not set it at your server or mistyped it, and vice-versa, you should check your salt value from Management > Applications > Salt for checksum.
10. Check Time Zone
Your time zone may be different from the application’s time zone, explaining why it takes some time for you to be able to see events on the graph, something that should be available to you without delay. You can edit your time zone from Management > Applications > Edit > Select Time Zone.
How Long Does It Take for My Data to Show Up on Countly?
When you are checking Countly and sending events from your app or website, you might realize that sometimes there is a delay for the data to show up there. This is an expected behavior stemming from the internal logic of the Countly SDKs and the potential server-side calculations.
SDK Side Processes
In some cases, there might just be a connection issue. Either the user is offline or unable to reach your server (due to server maintenance or other issues). Thus they would not be able to send data to the server. If, during this loss of connection, the SDK is not able to perform any network activity, it will wait for a while before reattempting the upload of recorded information. By default, this delay is 60 seconds (can be changed during init) and is tied to the session update tick interval.
The second aspect that can influence this is the event queue. Before we send the recorded events to the server, we try to cache them to optimize the networking. They are cached until their amount exceeds the threshold (by default 100, but can be configured), or the session update tick happens, or some other internal trigger happens.
Server Side Processes
In addition to this, there can be server-side calculations that can add additional delay. Depending on where you are expecting the changes to show up, the types and the length of the calculations involved would differ. For example, a cohort can take minutes up to hours to process before showing up on Countly. But most data would show up within seconds after reaching your Countly Server.
Is My SDK Version Compatible with My Server?
If you have checked your Countly server and SDK versions, you might have noticed that they most likely do not match. Due to the way our development is structured, our Countly server releases happen more often than any single SDK. Usually, this will lead you to see that your server version is higher than your SDK version, and that is fine.
Our guidelines are that the major version of your server should be the same or higher than the major version of the SDK you are using. Our versioning scheme for our server releases and SDKs has three numbers separated by dots, something like "22.02.3". The first two numbers are what we call the major version, and those are the ones that you should be paying attention to ("22.02.X").
Finding SDK Logs
Ensure you have enabled SDK logs before proceeding with this process. For guidance on how to enable logs, refer to the SDK documentation's "Logging" or "Debug Mode" section.
Apple Devices:
- Launch your application through Xcode.
- Access the Output tab (annotated as 1).
- Filter the logs by typing in "countly" (annotated as 2).
Android Devices:
- Run your application on Android Studio.
- Open the Logcat tab (annotated as 1).
- Filter the logs by typing in "countly" (annotated as 2).
Web Browser:
- Open your website in a browser.
- Open the developer tools (typically by pressing F12).
- Select the Console tab (annotated as 1).
- Enable all log levels to view the SDK logs (annotated as 2).
Best Practices for SDK Integration
SDK Integration to Constantly Running Platforms
SDK integration to constantly running platforms, like servers or OSes, shares the same principles with other platforms; however, due to the continuous activity on these platforms, automatic session tracking can become a hinderance.
Frequent session update calls to your Countly server can put a strain on its ability digest data and responsiveness. To mitigate this problem, we suggest reducing the frequency of your session update requests to the bare minimum.
A 4-hour session update request interval is a recommended starting point to mitigate most issues. This value should be set at the init configuration object of your SDK and should also be changed at your server's Management > Settings > API > Data Limits > Maximal Session Duration section. You can reach the SDK-specific configuration settings from the corresponding documentation of your SDK here