Three Failures First

The user journey map was done, but the tracking event list just wouldn't come together—this is the norm for many indie developers and small teams. I've been through it too, and I failed three times, each representing a classic mistake.

First failure: I threw the journey map directly at the AI and told it to "generate a tracking event list." The AI was very cooperative, quickly spitting out over a hundred events, each with names and attributes. It looked professional, but at the review meeting, one question stumped me: what's the relationship between this page_view and the page_view in our third-party analytics? Why should "registration success" be split into three events? The AI had made all the decisions for me, but no one had verified them. Two weeks after launch, three naming styles coexisted in the data. The analysts came to me, and I had no answers.

Second failure: I asked the AI to "optimize" an existing tracking document. We actually had an old version of the event list, and to save effort, I asked the AI to "fill in the gaps" based on it. The AI diligently added more than forty new events—in retrospect, the majority of them were "plausible-looking data no one would ever consume." More tracking is not better; every added event is a long-term maintenance cost. The AI had no idea which reports actually existed—it was simply completing things based on its imagination of a "comprehensive tracking system."

Third failure: I skipped the team-consensus step. The AI's output looked beautiful, and I posted it straight to the group chat for developers to implement. As a result, the dev side and the data side got into arguments over the definitions of several key events—for example, whether "payment completed" means the payment callback succeeded or the order status changed. These debates should have happened before the list was finalized. The AI wasn't wrong—I was wrong for treating it as a replacement for the process instead of an accelerator for the process.

The common thread in all three failures: I treated AI as the "endpoint," expecting it to deliver a finished product in one shot. In reality, what AI is truly good at is compressing this dirty work—normally requiring three meetings and lots of documentation—into a single high-quality input for review.

The Right Approach: Let AI Be the "Translator," Not the "Decision-Maker"

After figuring this out, I redesigned the process. There's only one core principle: decisions stay with the team; AI handles exhaustive enumeration, structuring, and follow-up questions.

Specifically, there are four steps:

Step 1: Feed it enough context. Give the AI the journey map, the product's existing event naming conventions (even if they're just a few verbally agreed rules), the old tracking list, and "the business questions this tracking effort needs to answer" (e.g., registration conversion rate, key feature funnels). The quality of the context directly determines the quality of the output.

Step 2: Have the AI produce a "draft with justifications." The key is requiring the AI to provide, for every event, the trigger timing, the journey stage it belongs to, and "what analysis it supports." With justifications in place, the review can go item by item and decide what to keep or cut.

Step 3: Have the AI ask reverse questions. This is the most effective step—ask the AI to take the perspective of a data analyst and list "questions this list cannot answer." It will force you to answer easily overlooked decision points like "should we track the reasons for cart abandonment after adding to cart?"

Step 4: Human review and finalization. The team goes through the draft, cuts events no one will consume, unifies naming, and makes on-the-spot calls on conflicting definitions. The AI's draft turns this meeting from "starting from zero" into "item-by-item confirmation," and it can wrap up in an hour.

A Reusable Prompt Template

Here's the template I've settled on after iterating—just replace the bracketed content and use it directly:

你是一位资深数据分析师，帮我把用户旅程图转化为埋点清单草稿。

【产品背景】
[一句话描述产品及核心业务目标]

【用户旅程图】
[粘贴旅程图内容：阶段、用户行为、触点、情绪、痛点]

【分析目标】
[列出本次埋点要回答的业务问题，如：注册漏斗转化率、功能A的使用深度]

【已有规范】
[事件命名规则、属性命名规则；如没有请写"暂无，请先建议一套规范"]

请输出：
1. 埋点清单表格：事件名 | 触发时机 | 所属旅程阶段 | 关键属性 | 支撑的分析目标 | 备注
2. 每个事件必须标注"支撑的分析目标"，无法关联到目标的不要输出
3. 标记出可能与既有统计工具重复采集的事件
4. 最后以数据分析师身份，列出这份清单"无法回答但业务可能关心"的 3-5 个问题，供团队讨论

注意：不要发明旅程图中不存在的用户行为；命名规范保持全局一致。

Item 4 is the "reverse questions" mentioned earlier—don't skip it. It's often more valuable than the list itself.

Before and After Using AI

The more important change is implicit: the tracking specification itself has become part of the prompt. On the second and third uses, the AI's draft quality was noticeably higher, because the specification keeps accumulating in the template. For a small team, this is essentially using one prompt to get what would otherwise be an unaffordable data governance consultant.

A Few Reminders

First, don't let AI interface directly with the development process—AI output is always a draft, and the final version must be signed off by a human. Second, when it comes to tracking events, less is more—don't be soft-hearted when cutting events; every event is years of future maintenance debt. Third, if your team is already using LLM APIs for this kind of document processing, token costs rise with the number of calls, so choosing the right billing model matters—refer to the official pricing page.

This approach isn't limited to tracking events: converting API docs into interface lists, or requirement docs into test cases—these are all essentially "structured translation + reverse questions," and you can adapt this template for all of them.

If you also want to run this kind of AI workflow in your small team and need a stable model API to support daily calls, check out this platform: https://api.thistoken.ai/register

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.