Data Collection

Data EngineeringData Integration

AE Tracking Code Generation

Automatically generate complete code for AE SDK initialization, event reporting, common property setup, and user property reporting from a tracking plan, covering client and server across all platforms, with LogBus2 configuration and a validation script included.

IndustriesGamesE-commerceToolsSocialContent

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Query console

generated

query.sql · generated

SELECT channel, count(*)

FROM v_payment

GROUP BY channel — 0.4s

12 rows returned

Analysis readyevidence attached

The AE Tracking Code Generation Skill is a code-generation capability in ThinkingAI's industry Skill library. From a tracking plan (xlsx or AE project), it helps dev and data teams generate, in one click, SDK initialization code, event reporting code, common property setup, user property reporting code, LogBus2 configuration files, and a validation script for each platform, covering more than ten platforms including Android, iOS, Web, mini programs, Unity, Java, Python, and Go, ending the inefficient practice of hand-assembling code event by event and property by property. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

ae-tracking-code-generation

The tracking plan for our match-3 game is already in the AE project, 45 events total. I need all the reporting code for the H5 client and the Java server written before this Friday. Last time I hand-wrote a version and got a pile of package names and API signatures wrong. Inject the H5 code straight into the project; independent files are fine for the server.

Read the AE project tracking plan

45 events / 120 properties; 28 client events, 17 server events

Force-read the official Web JS SDK and Java SDK wiki docs to lock down package names and API signatures

Generate H5 client code (insert mode): initialization, super properties, and ta.track reporting injected into the project

Rewrote 6 files including src/lib/ta-tracking.js, covering 28 client events

Generate Java server code (snippet mode): LoggerConsumer architecture + LogBus2 daemon.json

Generate the validation script TaDebugTest.java

Simulates reporting for 5 sampled events, for verification on the AE Debug page

Code for both ends is generated. 45 events and 120 properties split by platform: the H5 client's 28 events are injected directly into the project in insert mode, and the Java server's 17 events are output as independent files in snippet mode. Every package name and API signature was checked against the official wiki docs before generation, so no more piecing APIs together from memory.

1. H5 client code excerpt (initialization and reporting)

javascript

// Initialize the AE JS SDK (appId / serverUrl come from AE project settings)
ta.init({
  appId: 'demo-appid-2c9f81',
  serverUrl: 'https://receiver.demo-project.com'
});

// Super properties carried uniformly; the 28 client events no longer redefine them one by one
ta.setSuperProperties({ channel: 'official_h5', app_version: '1.8.2' });

// Bind the account inside the login-success callback (associates distinct_id with account_id)
ta.login(accountId);

// Stage-settlement reporting: event name, property names, and types all match the plan
ta.track('stage_end', {
  stage_id: 'level_042',
  result: 'win',
  duration: 97,
  coin_gain: 380
});

2. Instrumentation best practices

Pass numeric properties as number: the type of fields like duration and coin_gain is set by the first report; sending them as string throws off every downstream BI definition.

Call ta.login only in the login-success callback; calling it too early mis-binds guest behavior to the account.

Set super properties once after initialization; the 28 client events no longer carry channel and app_version repeatedly.

All 17 asset-related events like payment go through server-side reporting; the client keeps no amount-related calls at all.

3. Output artifacts and mode per platform

Platform	Output mode	Artifact	Events covered
H5 (Web JS SDK)	insert	Injected into 6 files including src/lib/ta-tracking.js	28
Java server	snippet	TaTracker.java (LoggerConsumer architecture)	17
LogBus2	Config file	daemon.json (directory and appId pre-filled for the project)	N/A
Validation script	snippet	TaDebugTest.java	5 sampled

← Scroll to see more

Recommendation

Run TaDebugTest before going live: the script reports 5 sampled events to the test project, so you can confirm the data arrives on the AE Debug page before switching the appId to the production project. Hand-writing both-end code at this scale (45 events) takes 3 to 5 days on average; this batch should go from generation to verification within half a day.

Artifacts are output to the project directory; the official Java SDK and LogBus2 doc links are in the header comments of each file.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

Once the tracking plan is designed, turning it into code is the most time-consuming and error-prone step. Hand-writing tracking code for a mid-sized project (30 events, 80 properties) usually takes 3 to 5 days, and each platform's SDK initialization, API conventions, and package references are completely different. More than 40% of first-time tracking-code integrations have typical problems like wrong package references, missing initialization parameters, unset common properties, or missing user-identity linking. Server-side reporting also involves the LoggerConsumer + LogBus2 architecture choice and config-file authoring, which most developers are not familiar with.

What it does

Cross-platform coverage: client (Android / iOS / OpenHarmony / Web / mini programs / Unity / Cocos) plus server (Java / Python / Go / Node.js / PHP / C#)

Two output modes: insert (inject directly into project code) and snippet (generate standalone code files), chosen flexibly by project stage

Server-side standard of LoggerConsumer + LogBus2: generates a safe reporting architecture by default, with a daemon.json config file and official documentation links included

Automatic validation script: generate test code in one click to verify reporting is correct, taking you from finished code to confirmed data arrival in AE in a single step

Strict alignment with official SDK docs: before generating code, it mandatorily reads the corresponding SDK's official wiki, never guessing package names or API signatures

When to use it

Quickly generating each platform's SDK code for production once the tracking plan is done

Multi-endpoint reporting projects that need client and server code generated together

Repeated errors in hand-written tracking code that call for automated generation

A new project integrating the AE SDK from scratch that needs initialization code and reporting templates

Server-side reporting that needs the LoggerConsumer + LogBus2 architecture configured

A validation script before launch to verify tracking is reporting correctly

In the field

Case

A game project · Android and Java dual-endpoint reporting

The tracking plan contained 45 events and 120 properties. The Skill generated the Android client `android-sdk.kt`, the Java server `java-sdk.java`, the LogBus2 `daemon.json`, and the validation script `te-debug.java`. After running the validation script, the AE Debug page confirmed data arrival, and the team completed the full flow from plan to production code within 3 days, more than twice as fast as the previous 7-day hand-written average.

FAQ

How does this differ from the Tracking Plan Generation Skill?

Tracking Plan Generation produces the plan document; AE Tracking Code Generation produces executable code, including SDK initialization, track() calls, and config files. The former is design, the latter is implementation.

How do I choose between insert and snippet mode?

Choose insert when you have existing project code and want direct injection; choose snippet for a new project or when you just want the code for reference. Different platforms in the same project can mix modes.

Why is LoggerConsumer the server-side default?

LoggerConsumer writes data to a local log file, which LogBus2 syncs to AE in batches, giving no data loss and controllable retransmission. The LoggerConsumer + LogBus2 architecture is recommended for production.

What can the validation script verify?

The validation script simulates reporting test data, and after running it the developer confirms on the AE Debug page whether the data arrived, quickly verifying SERVER_URL, APP_ID, and the reporting logic.