How to view data after data import?

App/Web/Mini Program SDK data reporting, troubleshooting method to check for received data in the event management page:

  1. Confirm if the data receiving URL is accessible. You can open the data receiving URL in a browser and use /debug to check if "Sensors Analytics is ready to receive your data!" is printed in the browser. If it's not accessible, ask the client to test with the IP address of the Sensors Analytics server to exclude the possibility of data not being received due to the unavailability of Sensors Analytics service. Then check if the data receiving URL in the project viewed on Sensors Analytics page is consistent with the one in the data receiving URL.
  2. If the data receiving URL is accessible and the project viewed on Sensors Analytics page is consistent with the one in the data receiving URL, check if the mode used in the SDK is debug mode. (Note: If debugAndtrack mode is used in the App, but the data is not visible in the event management page, check with the client if they have disabled the debug interface of Sensors Analytics.)
  3. It is recommended to print logs locally to check if the data is successfully collected.
  4. iOS log printing method for data collection: Debug Mode for iOS
    1. For iOS, you can print the data collection log locally by following the iOS debugging log settings.
    2. For Android, you can print the data collection log locally by enabling SensorsDataAPI.sharedInstance().enableLog(true); after SDK initialization.
    3. For Web, you can print the data collection log locally by adding show_log:true during SDK initialization (this parameter is at the same level as the server_url parameter, and if not set, it defaults to true).
    4. For Mini Program, you can print the data collection log locally by adding show_log:true during SDK initialization (this parameter is at the same level as the server_url parameter, and if not set, it defaults to true).
  5. If the data receiving URL is accessible, the projects are the same, and it is not in debug mode, but you still cannot see the data, you can check if the license has expired or if the data import has been stopped due to exceeding the data count limit.
  6. If the customer is using an HTTPS data receiving URL, you can check if the certificate has expired or if the certificate is invalid, as these issues can also affect data sending.

For server-side SDK data reporting, if you cannot see the received data on the event management page, you can follow these troubleshooting steps:

  1. Check if the SDK is using the BatchConsumer or ConcurrentLoggingConsumer.
  2. If it is using the BatchConsumer, check if the set cache count has been reached and if the sending conditions are met.
  3. If it is using the BatchConsumer and the sending conditions are met, check if the data receiving URL is accessible (refer to steps 1, 2, and 3 in the App SDK data reporting troubleshooting).
  4. If it is using the ConcurrentLoggingConsumer, and if the local logs have been printed, check with the customer if the SDK initialization configuration specifies the file write path and if the cache count has been reached (the default is to write a log file when the cache count reaches 8k).
  5. If ConcurrentLoggingConsumer is used and the local logs have been printed, check if LogAgent is installed on the SDK machine and if the LogAgent configuration is correct. Check for any error messages from LogAgent to further troubleshoot LogAgent-related issues. LogAgent reference documentation: LogAgent Import Tool

Buried point management has received, but the event analysis or custom query page can not find data, troubleshooting ideas:

  1. First go to the buried point management platform page,Confirm whether there is an error in the corresponding buried point data. If there is an error, you can find the RD to confirm the buried point problem according to the cause of the error;
  2. If check data is received but not stored. You can first confirm whether the import module is normal, and you can query only after the data is stored in the database.

> The buried point management shows that the data has been stored, and the customized query page can also find the corresponding buried point data, but the event analysis can not find the data, the investigation idea:

  1. You can first try to force a refresh of the web page to exclude data that cannot be found because of caching reasons.
  2. > If you still can't see it after forced refresh, you can confirm with the customer whether sampling or approximate query is enabled, resulting in no query.

How do I view debug logs?

After the SDK is initialized, run the following code to enable the debug logSA. Keyword filter, you can click herelinkto see more details.

//Enabling debug Logs
SensorsDataAPI.sharedInstance().enableLog(true);

How can I view my test data in the Sensors Analytics?

Method 1: View data through debugging. For details, see this section documentation configuration (Recommended if you are a business person)

Method 2: In the local code, after debugging logs are enabled, view the logsdistinct_idfield, that is, the field that identifies the user ID for Sensors, and then locates the specific user by searching for the user in Sensors analytics. How to search for users that can be viewed document

When full bury point is enabled, why does the application retreat to the background without exit event?

Android version 2.0.3 added a 30-second session mechanism. When the user exits the App to the background for 30 seconds, the exit event will be triggered. When the App is started again, the startup event will be triggered link to see more detail.

Does Sensors SDK support collection of third-party frameworks?

Currently the SDK supports RN, Flutter and other third-party frameworks, you can click herelink to see more details.

How to view SDK source code and update log?

Can from GitHub to view source code and update log.

How should we access data?

We offer a number of different ways to access data: using the bulk import toolBatchImporter to import historical data; UseLogAgent Incremental real-time data import monitoring log files. Or use the various SDKS to import data in real time. It can be selected according to different stages and different needs. For details, please refer to the introduction.

Your product is very powerful, so what other types of data can you analyze besides user data?

  • A:Sensors analytics providedEvent 和 User model, Users can be other types of entities than Internet users. For example, for a door-to-door service type product, in addition to caring about the behavior of the user, you will also care about the behavior of the technician who provides the service. Then, for this kind of demand, you can deploy a set of unique analysis, or create a part of the existing system in the event of the "user" is the technician, and these events record the technician to accept orders, door-to-door service and other information, and then you can also create a series of analysis technician core indicators and conversion funnel.

When I debug the program, there is a bug, the data import is wrong, can you delete the wrong data?

  • A:We do not recommend that you delete Data frequently for this reason. However, if you do need to delete data, you can contact our technical support personnel for further information. At the same time, in order to help users successfully complete the data import, divine analysis provides the following series of means:
    • Integrator Importer provides the format verification function;
    • Format verification is also provided on the product interface, and metadata can be created according to the verification results.
    • You can apply for a cloud trial environment for a short period of time to debug the import program. When the trial environment is used, the import progress is displayed on the interface, and data import errors are also displayed. Therefore, we recommend that customers can complete debugging on the cloud version of the trial environment, and then in the private generation environment for data access;
    • If previously meaningful events are no longer needed due to business development, you can stop importing such events on the one hand, and hide them through the hidden events feature provided by Sensors analytics.

Some analysis and query, we want to integrate into our own backend system, how should we implement?

  • Sensors Analytics is the customer's completely private data analysis system and, therefore, is specifically open Query API, users can obtain data wherever they need it, and then display and integrate it in any form. In addition, we also help customers build a completely private Data platform. Any incoming data is completely open to customers, which can be used in bulk and streaming. You can contact technical support personnel of Sensors Data.

How is the Sensors Analytics background implemented? What is the query layer used for?

  • Sensors analytics mainly USES the open source community some mainstream technologies, such as Hadoop/Impala, Kafka/MySQL/Redis/jQuery/ECharts/Kudu/Parquet, etc., as well as some of our own development core components.
  • Sensors Analytics mainly uses Hadoop, Impala and other open source distributed storage and computing suites, and combined with the specific scenarios of the business, they have made a lot of targeted modifications and optimization of their code.

Why can't your Demo import data?

  • The Demo environment is mainly to show you the query, visualization, analysis and other aspects of the divine analysis information, the imported data is our background simulation generated automatically imported data. If you want to try importing your own data for query and analysis, you can contact us for the appropriate trial environment.

What's the difference between deleting data and hiding events?

  • Deleting data is to truly delete the data, and hiding events, only in the interface to hide the data, and in the calculation of "any event", the event is not counted.

Does the data analyzed by Sensors analytics support modification /Update /Update?

  • The data in the Sensors analytics is divided into two categories:
    • For Profile data, because it describes the user's state, it is possible to change, so we provide complete data modification and deletion functions through profile_set, profile_unset, profile_delete and other interfaces.
    • For Event data, since it describes what the user has done in the past, semantically it should not be changed after it occurs. Meanwhile, in order to ensure the best query performance, the Event data is not supported to modify at present.
    • If users are concerned about incorrect data due to code errors or data transmission errors, we provide the following solutions to address these issues:
      • Our data analysts will help customers develop comprehensive data access plans based on their needs, and our technical staff will provide complete technical support during the customer data access process;
      • All of our SDKs and import tools provide a debug mode for debugging during data access;
      • We can provide customers with a testing environment. In fact, after the release of the multi-project feature in Sensors Analytics 1.5, customers can create a separate project for testing themselves;
    • If, under the above solutions, errors still occur due to certain reasons, we recommend that customers follow the steps below to delete the data and then re-import it:
      • Use the sa_clean tool to delete the erroneous data for the Event during the error time period;
      • On the basis of the previously erroneous raw data, make modifications to the data, and then re-import it;
      • If the original erroneous data was not backed up by the customer, we can assist in restoring the data from the system as appropriate.

After importing properties into Sensors Analytics, can the type of the imported properties be modified?

  • In order to ensure the accuracy of data imported into Sensors Analytics and the corresponding optimal storage solution, Sensors Analytics adheres to strong type checking. The type of properties imported into Sensors Analytics cannot be modified, but users can solve similar needs in the following ways:
    • First, during testing, a separate test project should be used to avoid type errors caused by test data. For test projects, all type definitions can be restored by resetting the project;
    • If it is already a formal project, a new property can be imported with the correct type. The new property should be named differently from the old property in terms of naming conventions. For display names, the new property can use the original display name of the old property, while the old property should be hidden;
    • If there is a strong need, users can seek assistance from Sensors Analytics technical support to modify the property type without modifying the property name. However, the historical data of the property cannot be retained, and the import process needs to be stopped.

How does Sensors Analytics iOS and Android SDK send data? Will it affect the user experience of the app?

  • By default, iOS and Android SDKs adopt a very conservative sending strategy, with a focus on preserving the user experience. The specific strategy is as follows:

    • Normal mode (non-debug)

      1. Except for "login" operations, all "track"/"profile_set"/"profile_append" operations are cached locally before being sent. When the cached data meets one of the following conditions and the current network is 3G/4G/Wifi, the data will be sent:
      2. The accumulated number of locally cached data reaches a certain amount (default is 100 records);
      3. A certain amount of time has passed since the last send (default is 15 seconds);
      4. For "login" operations, when the network is 3G/4G/Wifi, all data is immediately sent; otherwise, it is cached locally;
      5. When the App goes into the background, it will attempt to send data;
      6. The Android SDK tries to send data in onPause ;
      7. The iOS SDK tries to send data in didEnterBackground ;
    • Debug Mode

      1. For any operation, regardless of the network condition, the data will be sent immediately and the validation result will be verified.
        Note: Debug Mode is a mode set for developers to facilitate debugging. This mode verifies the data one by one and throws an exception when the validation fails. It has much lower performance than normal mode. Using Debug Mode in the production environment will seriously affect performance and have the risk of crashes. Please replace or disable Debug Mode before product launch.

Users can call the flush API to send data at any time. When data transmission fails, it will continue to be cached locally until it is successfully sent. When the cache data reaches the limit, the oldest 100 records will be deleted and then new data will be stored. The default cache threshold is 32MB for Android and 10,000 records for iOS.

After initializing the iOS or Android SDK, users can call the API to modify the sending conditions, such as setting the number of accumulated cache entries, the sending interval, and whether to send data when the App goes into the background. For more details, please refer to the documentation of the iOS and Android SDKs.