Function introduction of Shence data wechat applet SDK


1、 Foreword

Shence data wechat applet SDK is a data collection embedded point SDK for wechat applet. Specifically, it means that developers integrate the SDK into the developed wechat applet project, collect user data by configuring or calling the interface provided by the SDK at a specific time, and send it to the specified server through the network.

2、 Data acquisition

For SDK, data collection refers to the digitization of user behavior according to the established data format when user behavior is triggered (e.g. applet startup, clicking a button, etc.). According to different collection methods, it can be divided into code buried point, full buried point and user-defined full buried point:

Code embedding point refers to calling the track () interface provided by SDK to collect custom events;

Full buried point refers to the collection of preset events by SDK through agent life cycle function and various event processing functions;

User defined full burial point means that the function of SDK automatically collecting preset events is turned off, and the developer manually calls the specific interface quick() provided by SDK to collect preset events.

Shence data wechat applet SDK also provides full embedded point version and user-defined embedded point version:

The full buried point version is that the SDK automatically proxies the three interfaces of app, page and component of wechat applet. The automatic collection of preset events depends on the full buried point version of SDK;

The user-defined embedded point version refers to the function of automatically collecting preset events without using the SDK. The developer manually calls the interface provided by the SDK to complete the collection of preset events.

2.1 code embedding point

2.1.1 overview

Code buried point is also called user-defined buried point. Specifically, after SDK initialization, call the track() interface in the relevant event handling function to save the collected data to the sending queue, and then send the data to the specified server according to certain sending policies. For example, if a view element in the applet is clicked, and you want to collect the click event of this view element, you need to call the track() interface in the event handler of the view element to collect the click event data of the view element through the code embedding point.

2.1.2 usage scenarios

Code embedding points have many advantages:

Accurately control the location of buried points and collect the required data;

Flexible and user-defined business and related data collection;

It can meet the needs of refined analysis.

Of course, code embedding points also have corresponding disadvantages:

The cost of embedding point is relatively large, and the corresponding code needs to be added to the embedding point of each control;

The cost of updating is relatively high, and the code concurrent version needs to be modified every time the buried point scheme is updated;

It is highly intrusive to the user’s business code, and the buried point code is relatively scattered, which is not easy to manage uniformly and has poor maintainability.

Therefore, the code embedding point is suitable for scenes that require precise control of the location of the embedding point, flexible custom events and attributes and other fine requirements.

2.2 fully buried points

2.2.1 overview

Full buried point can also be called automatic buried point. The SDK collects preset events through the life cycle functions of proxy app, page and component and various event handling functions. Full buried point refers to the integration of SDK, and after opening the corresponding configuration items, it can automatically collect some behavior data of users. The collection scope (preset events) of the full embedding point of wechat applet SDK includes: applet startup, display, entering the background, page browsing, sharing, element clicking, etc. the event trigger and collection rules are shown in table 2-1:
Function introduction of Shence data wechat applet SDK
Table 2-1 collection rules of preset events at all buried points (click to view the large HD picture)

2.2.2 usage scenarios

Fully buried points have the following advantages:

Display macro indicators to meet the needs of basic data analysis. By collecting PV, UV and other common indicators and analyzing these basic data, it is helpful for enterprises to understand user behavior and point out the direction for further data analysis;

The technical threshold is low and the use and deployment are simple. Only the SDK needs to be embedded, which greatly avoids the complex work of re burying points due to requirements change, wrong burying points and other reasons;

Reduce the workload of developers. After opening the corresponding configuration items, automatically send data to the server to avoid the error of manual embedding.

At the same time, the fully buried point also has some disadvantages:

Full buried points can only collect user interaction data, and are suitable for standardized collection. The collection of user-defined attributes needs the assistance of code buried points. Each user’s interaction behavior has many attributes, and the fully buried points cannot go deep into finer and deeper granularity. For example, in the e-commerce industry, users clicking on the “shopping cart” is an interactive behavior. Full embedding point will ignore user information, commodity category and other dimension information. At this time, it is necessary to cooperate with code embedding point to assist data collection; For another example, when the user slides up the screen, the bottom of the content waterfall flow is loaded, the goods or advertisements are loaded and displayed, and the data click of the content in the drop-down menu. The collection of this kind of custom behavior needs code embedding points to assist in the implementation. Because the full buried point is only suitable for standard scheme collection, some data analysis platforms also begin to support users to add custom attributes for each event, which can greatly expand the efficiency of event analysis;

The full embedding point of the applet SDK is realized by proxy app, page and component interfaces, proxy the corresponding life cycle function, and add our embedding point logic to the corresponding life cycle function. Therefore, if wechat is not allowed to rewrite the three interfaces of app, page and component one day, the full buried point function will not be used, but this possibility is relatively small.

Therefore, we can know that the full buried point is suitable for the scene of collecting as much user behavior data as possible at a small buried point cost.

2.3 custom buried points

2.3.1 overview

In some cases, the three interfaces of app, page and component are not allowed in the developer’s applet project, or the user-defined attributes in the preset event need to be obtained asynchronously. At this time, the user-defined full buried point function needs to be used.

Custom full buried point refers to that after integrating the SDK, the developer turns off the automatic collection function of the SDK and manually calls the quick() interface provided by the SDK to collect preset events within the specified life cycle function. The scope of user-defined full buried point acquisition (preset events) includes startup, display and entering the background. The event trigger and acquisition rules are shown in table 2-2:
Function introduction of Shence data wechat applet SDK
Table 2-2 custom preset event collection rules for all buried points (click to view the high-definition large picture)

2.3.2 usage scenarios

Custom full burial points have the following advantages:

Add some custom business analysis attributes while displaying macro indicators. The values of these analysis attributes are obtained through the back-end interface and set when sending preset events, which can not only collect PV and UV, but also meet some refined analysis requirements;

When using the customized embedded point version SDK to customize the full embedded point, the SDK will not proxy interfaces such as app, page and component.

At the same time, there are some disadvantages of user-defined fully buried points:

The developer needs to call the SDK specified interface according to the specific writing method;

Compared with fully buried sites, it will increase the workload of developers.

Therefore, the user-defined full burial point is applicable to scenarios where asynchronous acquisition of user-defined attribute values needs to be added to preset events, and applet projects that cannot be proxy app, page and other interfaces by SDK.

2.4 preset Attribute Collection

Preset attributes are some attributes of the applet collected in advance by the SDK, such as page path ($url_path), startup scene ($scene), screen width and height ($screen_height, $screen_width), etc. These attributes will be automatically collected by the SDK, and then sent to the specified server together with the manually collected attributes.

These attributes are collected automatically and do not require developers to add code, which greatly increases the scope and convenience of data collection. The preset attribute of collection is an important analysis dimension involved in data analysis. Automatic collection greatly reduces the cost of development and collection. It is a part that can be used immediately.

Advantages and disadvantages of preset attribute collection function:

Advantages: automatically help users collect relevant attributes on many pages, making the data more comprehensive and richer in analysis dimensions.

Disadvantages: the preset attributes of automatic collection have been fixed in the SDK, and the attributes related to the user’s business cannot be collected automatically (business related attributes can be collected through user-defined attributes).

Preset attributes cover a wide range, and there are many types of attributes. They will be explained in detail in subsequent topics, but there is not much to expand here.

3、 Data transmission

3.1 data storage

Each wechat applet can have its own local cache, and read, write and clean up the local cache through the API provided by wechat. The use of API is shown in table 3-1:Function introduction of Shence data wechat applet SDK

Table 3-1 comparison of different APIs provided by wechat applet (click to view the large HD picture)

The storage limit of the same wechat user and the same applet is 10MB. The storage is isolated by the user dimension:

1. On the same device, user a cannot read the data of user B;

2. Different applets cannot read and write data to each other.

3.2 sending sequence

The SDK collects the data of the client, and the user’s behavior data is sent to the specified server through the network request. However, network requests fluctuate. If the data is triggered successively, it may be sent first and then arrived. For example, in the case of full burial point, when the applet is started, three preset events will be sent successively: applet start, applet display and applet page browsing. However, the order of arriving at the server may be that the applet page browsing event arrives first and the applet start event arrives last. Intuitively, the user behavior will be very unreasonable: the page browsing event of the applet is triggered first, and then the startup and display events of the applet are triggered.

In order to ensure the sending order, the SDK will build a data sending queue before data sending to ensure that the user behavior data is stored in the correct order and form the correct behavior sequence. How did this happen? When the SDK sends the data in the data queue, it will send it in order by default: after the current data returns to the status of successful sending, it will send the next data in turn, which ensures that most of the data in the normal process is sent correctly. However, what if the previous data transmission is stuck and there is no status return? The SDK solution is to set the timeout:

send_ Timeout: queue sending timeout. The default value is 1000 milliseconds. If the data sending time exceeds send_ If the next data is not sent, the next result will be returned;

datasend_ Timeout: data sending timeout. The default value is 3000 milliseconds. If the data sending time exceeds datasend_ If the timeout has not returned a result, the request will be forcibly cancelled.

Therefore, the construction of data sending queue can solve the problem of disordered sending order of client behavior data.

3.3 sending method

3.3.1 real time transmission

The data collection in the wechat applet SDK uses the strategy of instant collection and instant sending by default. Because the local cache is not used, the complex control processes of caching, reading and sending are reduced. It should be noted that the data receiving address used in the online applet needs to be configured with the request legal domain name (wechat public platform → development → development settings → server domain name), otherwise the data collected by the SDK cannot be sent.

When sending data through the network, it is inevitable that when the network condition is poor, there will be the problem of data transmission failure. Once the data fails to be sent, the data will be lost because there is no cached logic. Therefore, the wechat applet SDK adds the function of batch sending.

3.3.2 batch sending

In batch sending mode, when the data is generated, it will be stored in storage first (there is a limit on the number of stored data, which can be stored up to 300), and the data stored in storage will not be merged and sent until the sending conditions are met. The sending conditions include:

Time interval: send data every certain time (6 seconds by default);

Number of stored data: send data once when the number of stored data reaches a certain number (6 by default);

Enter the background: send data once when the applet enters the background.

If any of the above three transmission conditions is met, data can be transmitted.

If the data transmission is unsuccessful, the transmitted data will be saved. After meeting the transmission conditions, try to send it together with the subsequent data. In this way, network requests can be reduced, server resources can be saved, and some data loss problems in the process of sending can be effectively reduced.

4、 Debug event information

After integrating the SDK and triggering some events, the collected data will be sent to the Shence background in real time by default. So how do we know whether the data collected by the SDK is complete and whether the sending is successful? Here we provide two ways to debug event information: local debugging and real-time data viewing.

4.1 local commissioning

By default, the SDK will print the collected data information on the console panel of wechat developer tool, as shown in Figure 4-1:
Function introduction of Shence data wechat applet SDK
Figure 4-1 data information printed by SDK

When you see the printed data information on the console panel of the development tool, it indicates that the SDK has collected the data in the applet, but it does not mean that it has been sent successfully. To view the sending of data, you can view the data request of SDK through the network panel of wechat developer tool, as shown in Figure 4-2:
Function introduction of Shence data wechat applet SDK
Figure 4-2 data request sent by SDK

As shown in the above figure, there is a data request from the SDK in the network panel, and the request status code is 200, indicating that the SDK has successfully sent the collected data to the Shence background.

4.2 real time data viewing

Section 4.1 describes the process of collecting data by the client SDK. Where will the collected data be sent? It can be viewed in the real-time data of Shence background. In Shence analysis background → buried point management → real-time import data query, click the “start refresh” button to see the data entering. As shown in Figure 4-3:
Function introduction of Shence data wechat applet SDK
Figure 4-3 real time import data query of Shence analysis background

5、 Summary

This paper briefly introduces the wechat applet SDK and summarizes the basic functions of the wechat applet SDK, in order to give you a preliminary understanding of it. Relevant knowledge about specific use and implementation principles will be introduced to you step by step in subsequent articles.

Source: official account Shence technology community