How Visual Event Tracking Transforms Front‑End Data Collection: Inside Ctrip’s Hetu System

This article examines Ctrip's Hetu visual event‑tracking system, comparing it with traditional code‑based tracking, detailing its architecture, SDK modes, configuration workflow, and best‑practice implementations that improve efficiency, reduce coupling, and enhance data reliability across web, app, and mini‑program platforms.

Ctrip Technology
Ctrip Technology
Ctrip Technology
How Visual Event Tracking Transforms Front‑End Data Collection: Inside Ctrip’s Hetu System

Background

Visual event tracking (visual event tracking) is a widely used user‑behavior data collection solution that replaces traditional code‑based tracking with a visual configuration interface, addressing long development cycles, high communication costs, heavy code coupling, and verification difficulties.

To improve tracking efficiency and simplify management, Ctrip developed the Hetu visual event‑tracking system, which is integrated as a sub‑system of the internal Fuxi tracking management platform.

System Overview

Hetu’s role in the tracking ecosystem and its relationship with other components are illustrated below.

Hetu consists of three core parts:

Hetu SDK : Provides multi‑platform adapters with consistent core functionality.

Configuration Platform : Offers a visual interface for defining and managing tracking rules, including quality‑check reports.

Backend Service : Bridges the SDK and configuration platform and supplies data services for deep analysis of custom events.

SDK Architecture

The SDK supports four runtime modes:

Configuration Mode : Allows rule definition through a visual interface.

Acceptance Mode : Tests and validates configured rules.

Reporting Mode : Automatically assembles and reports event data when conditions are met.

Heatmap Mode : Visualizes event distribution on pages.

Only the configuration and reporting modes are covered in detail.

SDK Implementation

The SDK works via two key phases: compile‑time preprocessing and runtime interception. It includes a compile‑time plugin that replaces original UI components with enhanced ones without modifying source code, and a core package that handles rule management, trigger interception, data processing, and asynchronous reporting.

js // Before compilation, developer code:
import { Text, Button, TouchableOpacity, TouchableHighlight } from 'react-native'

// At runtime, equivalent to:
import { Text, Button, TouchableOpacity, TouchableHighlight } from 'path/to/sdk/core'

Configuration of Tracking Points

Tracking points are identified by visual selection. Three positioning schemes are supported:

Fixed Identifier : Uses a unique testID when available.

Relative Path : Describes location via node hierarchy, less stable.

Hybrid Path : Combines a fixed parent identifier with a relative path for robustness.

/RCTView[S_FLT_N_List_Flight_Label_Infor_Actual_Total]/RCTView[1]/RCTView[0]/RCTView[0]/RCTView[0]/VetTouchableOpacity[0]

Elements can be grouped as “current element” or “similar elements” (e.g., list items). Regular expressions enable batch configuration for dynamic lists.

Reporting Rules

Reporting rules define data sources and processing steps. Sources include:

Current element and its ancestors.

Associated elements elsewhere on the page.

Global context data assembled at runtime.

Data is filtered, combined, and mapped before being sent.

// Field mapping example:
payWay: child.props.nqhGuideTipsData.payWay // payment method
title: child.props.nqhGuideTipsData.title // discount title

// Runtime component data structure:
{
  props: {
    testID: "Flight**",
    nqhGuideTipsData: {
      payWay: "Installment",
      title: "Save $10"
    }
  }
}

Only the mapped fields are reported, while other component data is automatically filtered.

Best Practices and Reliability

Key practices include:

Data acquisition extensions : Multi‑element composition and global context data to capture non‑UI information.

Reporting stability : Asynchronous queues with retry, batch reporting, and cross‑page loss prevention.

Version control : Gray‑scale rollout, release gate checks via automated testing, and health monitoring reports.

Conditional rendering optimization : AST‑based placeholder insertion to keep page structure stable across data‑driven branches.

Conclusion

Visual event tracking offers non‑intrusive, real‑time, and decoupled data collection, significantly improving tracking efficiency. Integrated with the Fuxi platform, it ensures standardized output and field completeness while lowering the technical barrier for non‑technical users. However, limitations remain for complex interactions, non‑UI data, and dynamic rendering stability, so it should complement other tracking strategies.

frontendSDKdata collectionvisual trackinglow-codeevent tracking
Ctrip Technology
Written by

Ctrip Technology

Official Ctrip Technology account, sharing and discussing growth.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.