Detailed explanation of the implementation of manual and automatic tracking of WeChat applet (Taro)

If every company wants to increase its user base, it must collect and analyze user operation data, so tracking data is essential.
For front-end career development, traditional manual tracking is undoubtedly a tedious and boring task, so it should be simplified if possible.

1. Manual Burying

Manual tracking means adding a code for reporting tracking points wherever it is needed. It affects the reading experience of the code, and the scattered embedded code is not convenient to manage.
Taking page pv as an example, we previously reported pv in every page:

// src/manual/home/index.tsx

import tracking from "./tracking";

// pageSn is the "unique identifier of the page in the tracking system" agreed upon by the front-end and the product. For example, the identifier of the homepage of this project is the number 11664
const pageSn = 11111;

export default () => {
 // useDidShow is a Taro-specific Hook, which is equivalent to the native componentDidShow lifecycle of the mini program and will be called when the page is displayed.
 useDidShow(() => {
 // Send pv embedding point sendPv(pageSn) through the unified encapsulation sendPv method
 });
 return <View>Manual embedding page</View>;
};

2. Automatic Burying

Automatic tracking can be divided into fully automatic tracking and semi-automatic tracking. Fully automatic point burial will bury all points regardless of whether they are needed or not. The front-end developer must be happy and said, "Don't come to me for product development in the future." But the data scientist started crying.

For example, Tencent and the Taro team jointly launched Tencent Youshu automated tracking, which is super easy to connect to. For example, configuring proxyPage to true will "report all page browse, leave, share and other events", and configuring autoTrack to true will "automatically report all element tap, change, longpress, confirm events".

But in terms of data volume and effectiveness, "full burial" is equivalent to "no burial", because "full burial" requires a very high amount of data storage on the one hand, and on the other hand it will bring a lot of work to our students who are responsible for data cleaning.

So next, we should seek a balance and focus on semi-automatic tracking.

1. Page exposure (pv)

Page exposure (pv), the ideal reporting method is:

In a unified place (such as trackingConf.ts), configure the identifier of each page to be tracked (i.e. pageSn)
After the page is displayed, it automatically determines whether it needs to be reported (whether it is in the trackingConf.ts configuration file). If it is, report it directly.

Specific implementation

(1) Unified configuration of tracking points fields, pageSn represents the identifier of the page in the tracking point system

//trackingConf.ts
export default {
 "auto/home/index": {
 pageSn: 11111,
 },
};

Of course, if your business allows you to report all page PVs (with the path so that the product can filter by itself), then you can skip step (1) and go directly to step (2). This method can be called "fully automatic PV tracking".

(2) Encapsulate the usePv hook. When the page is displayed, get the current page pageSn, determine whether to embed PV, and send PV if necessary.

// usePv.ts

// Get the current page path with Taro's getCurrentInstance
export const getPath = () => {
 const path = Taro.getCurrentInstance().router?.path || "";
 // Remove the leading /, for example, change '/auto/home/index' to 'auto/home/index'
 return path.match(/^\/*/) ? path.replace(/^\/*/, "") : path;
};

// Get the current page pageSn, determine whether to embed pv, and send pv if yes
// The getExtra parameter supports carrying additional parameters const usePv = ({
 getExtra,
}: {
 getExtra?: () => any;
} = {}) => {
 // Page exposure useDidShow(() => {
 const currentPath = getPath();
 // Get pageSn from trackingConf
 const pageSn = trackingConf[currentPath]?.pageSn;
 console.log("Automatically get pageSn", currentPath, pageSn);
 if (pageSn) {
  const extra = getExtra?.();
  // Send pv embedding point extra through the unified encapsulation sendPv method? sendPv(pageSn, extra) : sendPv(pageSn);
 }
 });
};

(3) Then encapsulate the page component WrapPage and use the above usePv():

import React from "react";
import { View } from "@tarojs/components";
import usePv from "./usePv";

function WrapPage(Comp) {
 return function MyPage(props) {
 usePv();
 return (
  <View>
  <Comp {...props} />
  </View>
 );
 };
}

export default WrapPage;

(4) Finally, wrap all page components with a layer of WrapPage to achieve "on-demand embedding of all pages":

// src/auto/home/index.tsx

const Index = WrapPage(() => {
 return <View>Automatic embedding page</View>;
});

When you develop a new page later, in addition to wrapping it with WrapPage, you only need to add pageSn of the page in trackingConf.ts in step (1).

Question session

Curious kids may ask:

(1) Since usePv() is encapsulated in WrapPage, how can we support reporting of custom fields?
For example, the product hopes that when the src/auto/home/index.tsx page reports pv, it also reports the current page URL query parameters, namely params.
It's very simple. Don't wrap this page with WrapPage. Instead, call the usePv function directly after getting params:

// src/auto/home/index.tsx

const Index = () => {
 usePv({
 getExtra: () => {
  const params = Taro.getCurrentInstance().router?.params;
  return { params };
 },
 });
 return <View>Automatic embedding page</View>;
});

(2) Each page component here must be wrapped with WrapPage, which is still invasive to the business. The native applet can rewrite the Page and directly usePv() in the Page. The Taro project should also be able to do this and achieve 0 business intrusion, right?

In the Taro project, it is indeed possible to intercept native Pages uniformly in the App, just like native mini-programs. However, in this case, the problem of "some pages need to calculate additional parameters and report them" mentioned above will be difficult to solve.

2. Page Sharing

There are two types of sharing in WeChat Mini Programs:

• Share with friends: useShareAppMessage.
• Share to your friends: useShareTimeline. Support started with Mini Program Basic Library v2.11.3, and is currently only available on the Android platform.

Specific implementation

Take useShareAppMessage as an example (the same applies to useShareTimeline):
(1) Still in the trackingConf.ts unified configuration file, add the sharing tracking point identification field eleSn (and additional parameters)

//trackingConf.ts
export default {
 "auto/home/index": {
 pageSn: 11111,
 shareMessage: {eleSn: 2222, destination: 0 }, // Add shareMessage to include the eleSn of the friend being shared and the additional service parameter destination
 }
};

(2) Encapsulate the useShareAppMessage method and replace the Taro.useShareAppMessage method with this useShareAppMessage method in all business calls.

// Share with friends and bury the message in one place export const useShareAppMessage = (
 callback: (payload: ShareAppMessageObject) => ShareAppMessageReturn
) => {
 let newCallback = (payload: ShareAppMessageObject) => {
 const result = callback(payload)

 const currentPath = getPath(); // getPath gets the current page path, please refer to getPath in "1. Page Exposure (pv)"
 // Get pageSn, shareMessage, etc. from trackingConf const { pageSn, shareMessage } = trackingConf[currentPath]
 const { eleSn, ...extra } = shareMessage || {}
 let page_el_sn = eleSn
 const { imageUrl: image_url, path: share_url } = result
 const { from: from_ele } = payload

 const reportInfo = {
  from_ele,
  share_to: 'friend', // 'friend' means share with friendsimage_url,
  share_url,
  ...extra
 }
 console.log('...useShareAppMessage tracking', { pageSn, page_el_sn, reportInfo })
 sendImpr(pageSn, page_el_sn, reportInfo) // You can encapsulate the sendImpr method yourself to send sharing information return result
 }
 Taro.useShareAppMessage(newCallback)
}

In this way, if a page needs to add a tracking point for sharing with friends, just add the eleSn of shareMessage in trackingConf.ts, and the same goes for useShareTimeline.

Question session

Curious people may ask: If the page needs to add tracking points for sharing with friends/friend circles, is it possible with zero configuration (that is, without modifying the above trackingConf.ts file)?
Similar to the "PV fully automatic tracking" in the previous article, as long as you agree with the product on the method of collecting data, it is also OK. For example, the author and the product agreed on:
For each page shared with friends/friends circle, eleSn is 444444. Then the product uses pageSn to determine which page it is, and uses share_to to determine whether it is shared with friends/friends circle. For the scenario of sharing with friends, from_ele is used to determine whether to share through the upper right corner or click the button on the page to share.
In this way, page sharing can also be automatically buried.

3. Element Burying Points

The research on automatic element tracking has encountered resistance and has not yet been implemented. The following article mainly discusses the problems encountered with different ideas. If you have any good suggestions, please feel free to communicate in the comment area.

We embed elements, the higher frequency ones are exposure and click events, and the medium and low frequency ones are scrolling, hovering and other events.

The manual tracking method is to manually execute sendImpr to report the tracking point (with the page unique identifier pageSn and the element unique identifier eleSn) when the element specified event is triggered.

Can this step be made easier? There is no intrusion on the business, and the general approach is still:

Add a hook to the Component to trigger the specified event -> Determine whether to report the tracking point -> Report if the conditions are met

The problem is divided into two parts:

(1) Intercept element event callbacks

You can intercept and traverse the options.methods received by the mini-program Component. If it is a custom function, when the function is called, determine whether the type of the first parameter (assuming it is named e) is equal to events such as tap. At this time, you can decide whether the conditions for reporting the tracking point are met based on information such as e.
The implementation in the native applet is as follows:

// App.js
App({
 onLaunch() {
 let old = Component
 Component = function(config) {
  //Intercept the config passed in by the business
  const newConf = proxyConfig(config)
  old(newConf)
 }
 }
})

const proxyConfig = function(conf) {
 const methods = conf.methods
 // Get custom methods (exclude some non-embedded methods as needed)
 let diyMethods = Object.entries(methods).filter(function (method) {
 let methodName = method[0]
 return ![
  "onLoad",
  "onShow",
  "onReady",
  "onHide",
  "onUnload",
  "onPullDownRefresh",
  "onReachBottom",
  "onPageScroll",
  "onShareAppMessage",
  "onResize",
  "onTabItemTap",
  "observer",
 ].includes(methodName);
 })
 diyMethods.forEach(function(method) {
 const [methodName, methodFn] = method
 // Modify the methods in conf
 methods[methodName] = function (...args) {
  const e = args && args[0]
  if (e && e.type === 'tap') {
  console.log('...tapping', methodName, args) // When a click event is triggered, report the tracking point as needed}
  methodFn.call(this,...args)
 }
 });
 // Return the modified conf
 return conf
}

In the Taro project, you cannot use Component directly in the component code, but you can achieve the same purpose in a roundabout way, such as:

// myProxy.js
module.exports = (function() {
 let OriginPage = Page
 let OriginComponent = Component

 return (Page = function(conf) {
 conf.forEach(function(e) {
  let [methodName, methodFn] = e

  if (typeof methodFn === 'function') {
  conf[methodName] = function(...args) {
   // Do what you want, such as rewriting conf, etc. methodFn.call(this, ...args)
  }
  }
 })
 return OriginPage(conf)
 })(
 (Component = function(conf) {
  const methods = conf.methods
  methods.forEach(function(e) {
  // Do what you want, such as rewriting conf, etc.})

  OriginComponent(conf)
 })
 )
})()

Then directly import myProxy.js in app.tsx

(2) How to automatically generate unique element identifiers

Currently, elements are uniquely identified by eleSn applied for in the tracking system. If you want automatic identification, it can be divided into:

• XPath: It works fine in PC/mobile, but it does not support directly getting the node's XPath/getting the node based on XPath in mini-programs. Can WeChat Mini Programs support obtaining DOM elements via XPath?
• Automatically obtain component method names: In native applets, because the methods in Component options are directly intercepted, the original method name can be obtained when the event is triggered. However, this is not possible in the Taro project because the methods are proxied. After the event is triggered, the method name you see is eh.
• AST parses the source code to analyze the page name, method name and the corresponding comments of the method to identify the elements: This method is the only one that can be used in the Taro project, but it is costly and "whether the existing data can still be used after continuous code iteration" is also a problem, so the author did not try it.

Conclusion

This article outlines the idea of ​​​​changing the manual tracking to the automatic tracking of WeChat Mini Program (Taro). And according to the page tracking (pv, sharing) and element tracking, the implementation method is analyzed:

• Page pv:
  • Encapsulate usePv and read pageSn from the configuration file according to the current page path
  • Wrap the page component WrapPage and call usePv()
• Share with friends/friend circle: customize useShareAppMessage, useShareTimeline, read pageSn and shareeleSn from the configuration file according to the current page path, and then obtain the passed parameters and report them.
• Element tracking: It provides an idea of ​​rewriting Component methods to intercept event callbacks. However, since the element unique identifier cannot be obtained automatically, it is not suitable for automatic tracking.

This concludes this article on the detailed explanation of the implementation of manual and automatic tracking of WeChat Mini Programs (Taro). For more information about manual and automatic tracking of Mini Programs, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!