Te Model Selector

AE Model Selection & Configuration Assistant

Based on user's data analysis requirements, intelligently recommend the most suitable AE (AgenticEngine) analysis model, and combine with actual tracking data dictionary to provide step-by-step configuration guide with precise event and property mapping.

🎯 Trigger Rules Details (Agent Must Read)

Strong Trigger Conditions (Force trigger if any one matches)

• Model selection question words: "which model to use", "what model", "which one should I choose", "recommend a model", "which model should I use"
• Model comparison hesitation: "should I use event analysis or XX analysis", "don't know whether to use retention or funnel", "which analysis to use"
• Configuration inquiry: "how to configure this requirement best", "how to configure", "how should I configure"
• Explicit model consultation: Mentions specific model name + seeks advice (e.g., "can retention analysis do this", "is funnel suitable for this requirement")

⚠️ Judgment Principle: Whenever user expresses doubt or hesitation about "which model to choose", this Skill should be triggered. ⚠️ Boundary Note: This Skill only solves "select model + provide configuration method", and does not execute setup operations. Route execution requests such as "help me set up" or "help me configure" to the ae-analysis Skill, which uses current ae-cli commands.

Exclusion Conditions (Never trigger)

1. Simple data query requests (no model selection keywords): "check XX data", "help me check XX", "statistics XX", "view XX metric" → Do not trigger
2. Explicit commands to execute specific business investigation (e.g., "check game inflation", "check High Spender profile") → Hand to business Skill
3. Direct requests to write code (e.g., "help me write SQL") → Hand to SQL/code Skill
4. Explicit requests to design tracking schema → Hand to tracking design Skill
5. Execution requests (e.g., "help me set up", "help me configure", "create a retention analysis") → Hand to ae-analysis for ae-cli execution; this Skill only provides configuration guidance
6. Configuration requests with known model name (e.g., "help me configure retention analysis") → If no selection hesitation, hand to ae-analysis

Key Distinction Examples

🔄 Core Workflow

⚠️ Requirement: Phase 1 (metadata resolution) is required only for a precise configuration bound to real fields. Model selection itself does not require a projectId — the decision tree can always run. When no project is available or the user only wants model selection, proceed in consultation mode (generic-example configuration).

🚫 Prohibited Actions

• ❌ Do not fabricate real event/property names as if verified. Without project metadata, use [to-replace: xxx] placeholders and label them as examples, never as the project's actual fields
• ❌ Do not guess or fabricate event names/property names (e.g., writing "payment" as pay_event without verification)
• ❌ Do not refuse or block model-selection consultation just because no projectId was provided — offer project candidates via ae-cli team +list-projects, and if the user declines, proceed in consultation mode

Phase 1: Metadata Query & Field Mapping【Required only for precise configuration】

1.1 Confirm projectId

• If the user provided a projectId → use it directly, go to 1.2 for field resolution.

• If the user did NOT provide a projectId → do NOT hard-ask. Instead:

  1. Run ae-cli team +list-projects to fetch the projects the current user can access.
  2. Present the choices via AskUserQuestion. The picker shows at most 4 options, so take the first 3 projects as candidates plus a fixed trailing option "No project needed — consultation only" (3 projects + 1 fixed option = 4). If fewer than 3 projects are available, list the actual number plus the trailing "No project needed" option. If more than 3 projects exist, tell the user only the first 3 are shown and they may reply with a specific projectId instead. If the list is empty (no accessible project), skip the picker and go straight to consultation mode.
  3. Based on the user's choice:
     • Picks a specific project → take its projectId, go to 1.2 for field resolution (precise mode).
     • Picks "No project needed — consultation only" → skip 1.2, go straight to Phase 2. In the configuration template, fill every event/property field with a [to-replace: xxx] placeholder, and note in the output that this is consultation mode — project fields not verified; providing a projectId later yields a precise configuration (see 2.3 Case D).

• Branch contract:

  • Picks a project → must complete 1.2 field resolution before Phase 2.
  • Picks "consultation only" → skip 1.2, go to Phase 2 and handle via 2.3 Case D.

1.2 Resolve Tracking Fields

For non-SQL analysis models, submit the semantic AI-facing definition first and inspect meta.resolved, meta.warnings, and structured errors. Only after clarification or an explicit resolution capability error, call:

ae-cli analysis-meta event list --project-id <id>       → Get event candidates
ae-cli analysis-meta property list --project-id <id>    → Get property candidates
ae-cli analysis user-tag list --project-id <id>         → Get user tags (optional)
ae-cli analysis user-cluster list --project-id <id>     → Get user clusters (optional)

Data Type Explanation

After querying, clearly distinguish these three data types:

1.3 Field Mapping Principles

• Exact match first: User says "payment amount", first search properties whose propDesc contains "payment amount"
• Ambiguity must confirm: When event property and user property have same name/description, must ask user which one to use
• Not found then explain: If no matching event or property in project, clearly inform user and suggest supplementing tracking

Phase 2: Model Determination & Configuration Generation

2.1 Determine Model via Decision Tree

Select the most suitable analysis model according to 【Model Decision Tree】and【AE Analysis Model System Introduction】below

2.2 Generate Configuration (Based on Real Fields)

After determination, output recommended model in specified format, and output configuration suggestions according to【Model Configuration Methods】.

• Fill mapped real fields into configuration template
• Check if required fields are complete

📋 Output Format

## 📊 Recommended Model: [Model English Name] ([Model Identifier])

### 💡 Recommendation Reason
Concisely explain why this model was chosen, pointing out which decision rule was matched.

### 🛠️ Configuration Suggestions in AE
**(Agent Internal Instruction: Please strictly follow the structure below, converting natural language requirements to underlying fields and calculation logic. Output fields in format "Display Name (Identifier)")**
Based on the determined model, output using the configuration template below according to different model configuration methods.

**Configuration Template**: (Using event model as example, adjust dynamically based on different model configuration methods)

| **Configuration Item** | **Selection** |
| :--- | :--- |
| **Select Event** | Login (login) |
| **Calculation Method** | Triggering User Count |
| **Group By** | Channel (channel) |
| **Time Range** | Last 7 days |
| **Time Granularity** | By Day (optional, view daily trend) or Total |
| …… | …… |

### 🔄 Alternative Solution** (If applicable):
[Explain under what conditions should switch to alternative model]

### ⚠️ Notes:
[Point out common pitfalls for this scenario, or tracking data definition issues to note (e.g.: payment amount doesn't include gift portion)]

2.3 Exception Handling Mechanism

Case A: Field Missing

Detection: Required field for configuration doesn't exist in metadata Handling:

1. Prompt user: Current project lacks [field name], cannot complete configuration
2. Provide alternatives:
   • Recommend similar field substitution
   • Suggest supplementing tracking (provide tracking design suggestion)
   • Suggest creating virtual property/user tag/user cluster

Example:

❌ Missing field: User Level (user_level)
✅ Alternatives:
  1. Use existing field vip_level as substitute
  2. Or create user tag: classify levels based on total payment amount
  3. Or supplement tracking: add user_level in user properties

Case B: Model Capability Boundary

Detection: User requirement exceeds selected model's capability range Handling:

1. Explain model limitations
2. Provide SQL alternative (based on Trino syntax)

Example:

⚠️ Model limitation: Retention analysis cannot support hourly granularity statistics
✅ SQL Alternative:
SELECT
  date_trunc('hour', "$part_time") AS hour,
  COUNT(DISTINCT "#user_id") AS user_count
FROM ta.v_event_1
WHERE "$part_event" = 'login'
  AND "$part_date" >= '2024-01-01'
GROUP BY 1
ORDER BY 1

Field Explanation:

• "$part_date": Partition date
• "$part_event": Event name
• "#user_id": User ID
• "[real_property_name]": [property description]

Case C: Requires Pre-data Preparation

Detection: Configuration needs user tag/cluster/virtual property but not yet created Handling:

1. Prompt user to create pre-data first
2. Provide creation steps and configuration suggestions

Example:

⚠️ Requires pre-preparation: High Value User Cluster
✅ Creation Steps:
  1. Go to AE → User Clusters → New Cluster
  2. Filter condition: Total payment amount >= 1000
  3. Save as "High Value Users"
  4. Use this cluster for comparison in event analysis

Case D: Consultation Mode (user chose "No project needed" in 1.1)

Detection: In 1.1 the user picked "No project needed — consultation only" (or no accessible project exists). Handling:

1. Do NOT trigger 1.2 field resolution.
2. Still run the full decision tree and give the model recommendation + reasoning normally.
3. In the configuration template, fill every event / property field with a [to-replace: xxx] placeholder (e.g., [to-replace: register event], [to-replace: channel property]).
4. In Notes, state that this is consultation mode — project fields are NOT verified — and that providing a projectId (or picking a project) enables the precise Case A / B flow with real field mapping.

Example:

ℹ️ Consultation mode — no project queried, fields not verified
- Select Event: [to-replace: registration event, e.g. register]
- Calculation Method: Triggering User Count
- Group By (optional): [to-replace: channel property, e.g. channel]
⚠️ To map real fields, provide a projectId and I'll switch to precise configuration

AE Analysis Model System Introduction (12 Models Total)

1. Event Analysis (event) — Default/Most Common Model

Core Positioning: Perform metric statistics and trend observation on single behavior event. Most basic and core analysis model. When no clear signal points to other models, default to event analysis.

Supported Aggregation Metrics: Total Count, Triggering User Count (DAU/MAU), Per User Count, Cumulative Value (e.g., total revenue), Maximum/Minimum, Distinct Count, Average Per User, Average, Formula Metric (custom formula combining multiple metrics)

Core Functions:

• Support viewing multiple metrics simultaneously
• Support dimension grouping comparison (e.g., by channel, region, device type)
• Support multi-date comparison
• Support filter conditions (event property, user property filter)

Strong Signal Keywords: DAU, MAU, user count, count, amount, revenue, quantity, total, sum, statistics, query, calculation, trend, report, dashboard, payment rate (when appearing alone), first-day payment rate, active, new user, register, login, payment, revenue, ARPU, ARPPU, average per user

Typical Questions: DAU for last 7 days / Query revenue for last 30 days / Paying user count by different channels / ARPU analysis / Help generate dashboard for register count, login count, payment amount for last 7 days

2. Retention Analysis (retention) — Second Most Common Model

Core Positioning: Analyze revisit behavior of users who completed initial event in subsequent time periods. Quantify user retention and churn, measure product health. Also the carrier for LTV and ROI calculation.

Core Concepts:

• Initial Event: User's "starting" behavior (e.g., register, first login)
• Return Event: User's "revisit" behavior (e.g., re-login, re-payment)
• Retention Rate: Proportion of users revisiting on day N/week/month relative to initial users

Retention Types: N-day retention, N-week/N-month retention, unbounded retention, custom retention

Extended Functions: Can display LTV / ROI as an add-on on the retention curve. ⚠️ When LTV / ROI / payment revenue is the primary analysis goal, use the revenue model instead (see Model 12).

Strong Signal Keywords: retention, retention rate, churn, churn rate, churned users, churned count, next-day retention, N-day retention, revisit, decay, day-1 retention, day-3 retention, day-7 retention (note: LTV / ROI now route to the revenue model by default — see Model 12)

⚠️ Core Rule: churn is always retention. LTV / ROI / payment rate now default to the revenue model (the dedicated cohort revenue & cost-recovery model); use retention for LTV/ROI only when the user explicitly wants them as an add-on on a retention curve.

Typical Questions: Query user retention this month / LTV for last 7 days / 7-day ROI for last 10 days / 7-day churned users / 30-day retention for paying users

3. Funnel Analysis (funnel)

Core Positioning: Analyze conversion and loss at each step in multi-step process, find optimization direction.

Core Configuration: Supports up to 30 steps, window period 1 minute~180 days, supports ordered/unordered funnel.

Strong Signal Keywords: funnel, funnel analysis, conversion (multi-step context), first...then..., A→B→C, penetration rate, conversion rate (multi-step context)

⚠️ Key Distinction:

• "Payment rate" appearing alone → event (single metric)
• "First-day payment rate" → event (single calculated metric)
• "Penetration rate" → funnel (implies A to B conversion process)
• "First A then B" + no other model keywords → funnel
• "First A then B" + "retention" → retention (explicit model keyword priority)

Typical Questions: Funnel conversion from login to draw card to payment / Generate registration→login→payment conversion by channel / New user first-day payment penetration

4. Interval Analysis (interval)

Core Positioning: Analyze time interval distribution between two causally related events. Answer "how long it takes users to complete two things".

Core Metrics: Median, Average, Percentile (P75/P90), Duration Distribution

Strong Signal Keywords: interval, interval analysis, interval time, interval distribution ("interval" is strongest signal, almost 100% match)

⚠️ Distinction from Funnel: Funnel focuses on "how many people converted", interval analysis focuses on "how long conversion took".

Typical Questions: First payment interval distribution / Interval from level up to payment / Login interval for last month

5. Distribution Analysis (distribution/scatter)

Core Positioning: Divide metric values into intervals, get user count and proportion in each interval. Analyze user engagement depth and stickiness for specific feature.

Distribution Dimensions: By count distribution, by day distribution, by numeric property distribution

Strong Signal Keywords: distribution, distribution situation, distribution analysis, user distribution ("distribution" is almost decisive signal)

⚠️ Distinction from Event Analysis:

• "Payment amount trend" → event (time series aggregation)
• "Payment amount distribution" → distribution (user-level distribution)
• "Daily XX distribution" → distribution ("distribution" priority > "daily")

Typical Questions: User login count distribution / Payment amount distribution / Active days distribution / Payment count distribution trend

6. Path Analysis (path)

Core Positioning: Explore user behavior trajectory, generate Sankey Diagram, intuitively display behavior inflow/outflow. Suitable for discovering "unexpected behavior patterns".

Analysis Direction: Forward path (what did after certain event), Backward path (what did before certain event), Full path

Strong Signal Keywords: path, path analysis, behavior trajectory, Sankey diagram, inflow/outflow, user path, what did

Typical Questions: What users do after entering game / Behavior before churned users leave / Behavior path before payment

7. Composition Analysis (composition)

Core Positioning: Profile analysis based on user properties (not behavior events), supports dual-dimension cross analysis and crowd comparison. Answer "who are the users/what do users look like".

Strong Signal Keywords: composition analysis, user profile, property distribution (when analyzing static user properties rather than behavior metrics)

⚠️ Distinction from Distribution Analysis:

• Composition Analysis: Analyzes static user property (level, region, device type) distribution
• Distribution Analysis: Analyzes behavior metric (payment count, login count, payment amount) distribution among users

Typical Questions: User region distribution / Age group and device brand distribution for paying users / Profile difference between VIP users and normal users

8. Attribution Analysis (attribution)

Core Positioning: Evaluate contribution degree of multiple touchpoints/channels to conversion target. Supports last touch, first touch, linear, position decay, time decay attribution models.

Strong Signal Keywords: attribution, attribution analysis, touchpoint contribution, channel contribution, contribution degree, which touchpoint, which ad slot contributes most

⚠️ Distinction from Funnel Analysis: Funnel looks at conversion rate of one fixed process, attribution analysis looks at contribution degree of each touchpoint in multiple paths.

Typical Questions: Which ad slot contributes most to payment conversion / Promotion channel contribution evaluation / Impact of multiple popups on conversion

9. Ranking (rank)

Core Positioning: Rank dimensions by metric value size, display Top N leaderboard, can track ranking change.

Strong Signal Keywords: TOP, Top N, ranking, leaderboard, which is highest (+ analysis dimension)

⚠️ Key Distinction:

• "Which game has highest payment" → rank (ranking object is game, can be grouping dimension)
• "Highest paying user" → other (finding specific user needs user cluster or SQL)

Typical Questions: Top 5 games by payment in last 7 days / Top 10 channels by revenue / Top 20 servers by activity

10. Heatmap (heatmap)

Core Positioning: Flexibly display user heat distribution in each area on game map or application interface. Game industry specific requirement.

Strong Signal Keywords: heatmap, heat map, hot area, coordinate distribution, position distribution, map heat

Typical Questions: Hot areas where players gather/battle/die in game map / Player distribution density in different map areas

11. Revenue Analysis (revenue)

Core Positioning: Track how a cohort's paid revenue, payment conversion, and cost recovery evolve over time after an initial event. Divide cohorts by an initial event, then combine payment event, revenue caliber, and cost data to observe each cohort's revenue on the initial day and subsequent observation days. This is the dedicated model for cohort LTV / ROI / payback analysis.

Core Concepts:

• Initial Event: Defines the cohort (e.g., register). Each date row = the batch of subjects who completed the initial event that day.
• Payment Event: Determines whether a subject paid (e.g., pay_success).
• Revenue Caliber: How revenue is computed — payment event + numeric property + calculation method (Sum / Per-user / Period-cumulative sum / Period-cumulative per-user); supports formula.
• Cost Data (optional): Cost event + numeric property + calculation method; required for ROI.
• Observation Window: Days to track after the initial event (e.g., 30 → shows Day 0 to Day 30).

9 Result Metrics (three groups):

• Revenue: LTV, Payment Amount, Cumulative Payment Amount
• Payment Conversion: Payers, Cumulative Payers, Payment Rate, Cumulative Payment Rate
• Cost Recovery: LTV Multiple, ROI

Strong Signal Keywords: LTV (cohort context), payment amount, payment rate, cumulative payment, ROI, payback / payback period, LTV multiple, Day-N LTV, D7/D30 LTV, revenue by cohort, channel ROI, cost recovery

⚠️ Distinction from Retention Analysis: Retention answers "did users come back" (retention rate, churn); Revenue answers "how much did users pay and did we recoup cost" (LTV, payment rate, ROI). When LTV/ROI is the primary ask, use revenue; when it is an add-on displayed on top of a retention curve, use retention.

⚠️ Distinction from Event Analysis: Event analysis aggregates a metric over calendar time (e.g., daily total revenue trend); Revenue analysis tracks a fixed cohort across observation days (Day 0, Day 7, Day N per cohort).

Typical Questions: D7/D30 LTV of daily new users / Payment rate and amount difference across channels / When does each channel's ROI hit target / Which cohort dates have abnormal revenue

12. SQL Query (sql)

Core Positioning: Directly query underlying data through SQL. "Universal fallback" of analysis system, meeting custom requirements not covered by above models.

Applicable Scenarios: Cross-model complex calculation, special statistical definition, temporary data exploration validation, analysis requiring JOIN of multiple tables

Typical Questions: Help me query users with balance > 1000 / Cross-model complex calculation / Metrics requiring special statistical definition

Model Decision Tree (Execute by priority from high to low)

When determining, strictly check in following order, first matched rule is final result:

Step 1: Did user explicitly mention model name?
  → User says "funnel analysis" → FUNNEL
  → User says "retention analysis" → RETENTION
  → User says "interval analysis" → INTERVAL
  → User says "distribution analysis" → DISTRIBUTION
  → User says "path analysis" → PATH
  → User says "composition analysis" → COMPOSITION
  → User says "attribution analysis" → ATTRIBUTION
  (Explicit model name highest priority, use directly)

Step 2: Contains "interval" (time interval) keyword?
  → YES → INTERVAL

Step 3: Contains funnel related keywords or conversion description?
  Judgment conditions:
    - Appears "funnel", "penetration rate", "conversion rate" (multi-step context)
    - Appears "first...then...", "first...and...", "A→B→C"
  → YES → If also contains "retention" → RETENTION
          → Otherwise → FUNNEL

Step 4: Contains revenue / payment-value / payback keywords?
  Judgment conditions: Appears "LTV", "ROI", "payback", "payment rate", "payment amount",
    "cumulative payment", "LTV multiple", "Day-N LTV", "cohort revenue", "channel ROI", "cost recovery"
  → YES → Is it explicitly an add-on on a retention curve (e.g., "retention curve with LTV")?
          → YES → RETENTION
          → NO  → REVENUE

Step 5: Contains retention related keywords?
  Judgment conditions: Appears "retention", "day-1 retention", "next-day retention", "N-day retention", "churn", "decay", "revisit"
  → YES → RETENTION

Step 6: Contains heatmap related keywords?
  Judgment conditions: Appears "heatmap", "hot area", "coordinate distribution", "position distribution", "map heat"
  → YES → HEATMAP

Step 7: Contains "distribution"?
  → YES → Is analysis object static user property (level, region, age etc. inherent property)?
          → YES → COMPOSITION (composition analysis)
          → NO → DISTRIBUTION (distribution analysis)

Step 8: Contains "TOP" / "ranking" / "which is highest"?
  → YES → Is ranking object analysis dimension (game/channel/product etc.)?
          → YES → RANK
          → Is ranking object finding specific user?
          → YES → OTHER

Step 9: Contains "path" / "behavior trajectory" / "Sankey diagram" / "what did"?
  → YES → PATH

Step 10: Contains "attribution" / "touchpoint contribution" / "channel contribution degree"?
  → YES → ATTRIBUTION

Step 11: User filter/export/list requirement? Or prediction type? Or cannot classify?
  → YES → OTHER / SQL

Step 12: None of above matched?
  → EVENT (event analysis is default model)

Edge Cases and Ambiguity Resolution Rules (Must Strictly Follow)

Core disambiguation rules summarized from 500+ real cases:

Model Configuration Methods

【Event Analysis (event) Configuration Method】

Pre-data Mapping Requirements (Agent Must Read):

Before configuration, must check underlying data dictionary, clearly distinguish these three data types and correctly map:

• Event: User's specific behavior (e.g., register, login).
• Event Property & Common Event Property: Describes specific context or value of event occurrence (e.g., amount, channel). Note: Common event property can be used for filtering and grouping of all events.
• User Property / User Tag / User Cluster: Describes user's own inherent static characteristics (e.g., VIP level, cumulative payment amount).

## Analysis Metrics (Support multi-metric combination and formula)
(For each user data requirement, configure corresponding metric line. Supports following three modes)
### Mode A: Basic Event Aggregation
Select Event: [matched real event, e.g.: Register (register)]
Calculation Method: Select [Total Count / Triggering User Count / Per User Count]
### Mode B: Event Property Aggregation (For numeric property)
Select Event: [matched real event, e.g.: Payment (payment)]
Select Property: [matched event property, e.g.: Payment Amount (pay_amount)]
Calculation Method (Different event property types provide different calculation methods):
  - If event property is numeric type, can only select one of: [Sum / Average / Average Per User / Median / Maximum / Minimum / Distinct Count / Variance / Standard Deviation / 99th Percentile / 95th Percentile / 90th Percentile / 80th Percentile / 75th Percentile / 70th Percentile / 60th Percentile / 40th Percentile / 30th Percentile / 25th Percentile / 20th Percentile / 10th Percentile / 5th Percentile]
  - If event property is text/string or time, can only select [Distinct Count]
  - If event property is boolean, can only select one of: [True Count / False Count / Empty Count / Non-empty Count / Distinct Count]
  - If event property is object/object array, can only select one of: [Empty Count / Non-empty Count / Distinct Count]
### Mode C: Composite Metric (Custom formula, supports add/subtract/multiply/divide)
Formula Logic: Use basic metrics built from above A or B modes for four arithmetic operations.
Example Configuration: [Metric A: Payment (payment) Triggering User Count] Divided by (/) [Metric B: Login (login) Triggering User Count]
Event-level Filter: Events in formula support event-level filter, filter condition 「Event Property/User Property/User Cluster/User Tag」「Logical Operator」「Specific Value」
Event-level Filter Example Configuration: [Metric A: Payment (payment) Channel = Official Website Triggering User Count] Divided by (/) [Metric B: Login (login) Triggering User Count]

📌 Filter Condition Level Explanation:
｜Filter Type｜Scope｜Use Case｜
｜Global Filter｜All metrics｜Unified filter condition applicable to all metrics｜
｜Metric-level Filter｜Current single metric｜Filter condition only for specific metric, other metrics unaffected｜
｜Event-level Filter｜Certain event in formula｜Only available in events of composite metric (custom formula)｜
Example: Query "Average gold consumption count by different device types for users in Shenzhen in last 30 days, total draw card count for V1.0 version"
Global Filter: City = Shenzhen (applicable to all metrics)
Metric-level Filter: Version = V1.0 (only applicable to draw card metric, average gold consumption count unaffected by this filter)

🔍 Metric-level Filter (Optional, can add multiple, logical relation AND/OR, only acts on current single metric):
If certain metric needs a separately setting filter condition (e.g., "Total draw card count for V1.0 version"), need to add filter separately under this metric: [Property Name] [Logical Operator, e.g.: Equals/Not Equals/Contains] [Specific Value].
🔍 Event-level Filter (Optional, can add multiple, logical relation AND/OR, only available in events of composite metric (custom formula))

## Global Filter (Optional, can add multiple, logical relation AND/OR, acts on entire chart)
(Used to define overall analysis sample range)
Select Filter Condition: [matched Event Property / Common Event Property / User Property / User Tag / User Cluster]
Select Logical Operator:
  - If filter condition is text type, can select [Equals / Not Equals / Includes / Excludes / Has Value / No Value / Regex Match / Regex Not Match]
  - If filter condition is time type, can select [In Range / Less Than or Equal / Greater Than or Equal / Relative to Current Date / Relative to Event Time / Has Value / No Value]
  - If filter condition is numeric type, can select [Equals / Not Equals / Less Than / Less Than or Equal / Greater Than / Greater Than or Equal / Has Value / No Value / Range]
  - If filter condition is boolean type, can select [Is True / Is False / Has Value / No Value]
Set Specific Value: [Specific number or string]
Example: 「Channel」「Equals」「Official Website」; 「Level」「Less Than or Equal」「100」; 「Is First Login」「Is True」

## Group By (Optional, can add multiple grouping items, used for breakdown comparison)
(Break down overall data by specific dimension, observe multiple trend lines)
Group By Dimension: Select [matched Event Property / Common Event Property / User Property / User Tag / User Cluster]
Example: Group by User Value Tier (user_value_level)

## Time Range & Granularity
Time Range: Select based on matched time range [e.g.: Last 7 days / This Month]
Time Granularity: Display by [Day / Hour / Week / Month / Minute (1min/5min/10min) / Total]

【Retention Analysis (retention) Configuration Method】

Pre-data Mapping Requirements (Agent Must Read):

Before configuring retention model, must check underlying data dictionary and strictly follow these mapping relationships:

• Initial Event and Return Event: Must map to real Events.
• Property Level Constraint: When grouping using event property, must and can only use 「Initial Event」 event property (or common event property/user property). Absolutely cannot use return event property for outer grouping!

## Analysis Subject
Select calculation perspective: [matched real analysis subject, e.g.: User (user_id) / Role (role_id) / Visitor (distinct_id), if not found prompt user to create]

## Core Event Configuration
▶️ Initial Event (Start): Select [matched real event, e.g.: Register (register)]
🔙 Return Event (Target): Select [matched real event, e.g.: Login (login)]

## Use Simultaneous Display (Advanced optional, calculate additional behavior or LTV for retained users)
(For users who completed 「Return Event」, calculate their performance on another specified event)
- Participate Event: [matched event, e.g.: Login (login) or Payment (payment)]
- Analysis Metric (Choose one):
  1. Basic preset metric: [Total Count / Triggering User Count / Per User Count / Cumulative Sum of Total Count by Period / Cumulative Average of Total Count by Period / Cumulative Sum of Triggering User Count by Period / Cumulative Average of Triggering User Count by Period], e.g., Draw Card (draw_card) Triggering User Count / Total Count
  2. Event property metric: [matched event property, if property is numeric type, can select Sum/Average Per User/Cumulative Sum/Cumulative Average Per User; if property is boolean, can select True Count/False Count/Empty Count/Non-empty Count], e.g., Payment (payment) Is First Pay True Count, represents count of first-time payment among returning users
🔍 Metric-level Filter (Only for this display metric): Set [Event Property, e.g.: Channel (channel)] [Logic, e.g.: Equals/Not Equals/Includes/Excludes/Has Value/No Value/Regex Match/Regex Not Match] [Specific Value, e.g.: Official Website]

## Use Relation Property (Advanced optional, for extremely precise same-category return)
(Used to limit user not only to return, but return specific object must match initial action)
Match Logic: Require 【Initial Event】 [matched event property, e.g.: Activity Type] Equals 【Return Event】 [matched event property, e.g.: Activity Type] (If simultaneous display is enabled, must also equal simultaneous display's matched event property)

## Global Filter (Optional, define overall analysis scope)
Select Filter Condition: [matched Event Property / Common Event Property / User Property / User Tag / User Cluster]
Select Logic: [Has Value / No Value / Greater Than or Equal / Less Than or Equal / In Range / Equals / Not Equals / Includes / Excludes etc.]
Set Specific Value: [Specific number or string]
Example: OS (os) Equals ios

## Group By (Optional, breakdown retention curve)
(⚠️ Warning: If grouping by event property, can only extract 「Initial Event」 event property)
Group By Dimension: Select [matched Initial Event Event Property / Common Event Property / User Property / User Tag / User Cluster]
Example: Group by app_version (initial event property)

## Time Range & Granularity
Retention Period: By [Day / Week / Month] - [Current Day / Next Day / Day 7 / Day 14 / N Days]
Analysis Range: [e.g.: Yesterday / Today / Last Week / This Week / Last Month / This Month / Last 7 days etc.]

【Funnel Analysis (funnel) Configuration Method】

Pre-data Mapping Requirements (Agent Must Read):

Before configuring funnel model, must check underlying data dictionary to ensure event sequence rationality:

• Multi-step Event Mapping: Each step of funnel must map to a real Event.
• Single Event Deep Funnel: If business requirement is "gradual conversion of same behavior" (e.g., Level 1→Level 2→Level 3), need to use same event, and stack independent event property filter within each step.

## Analysis Subject
Select conversion tracking perspective: [matched real analysis subject, e.g.: User (user_id) / Role (role_id) / Visitor (distinct_id), if not found prompt user to create]

## Funnel Steps (Core flow configuration)
(Add must-trigger events sequentially by business logic, supports up to 30 steps)
Step 1 (Start): Select [matched real event, e.g.: Register (register)]
- Step-level Filter (Optional): Set [Property Name] [Logic] [Specific Value]
Step 2: Select [matched real event, e.g.: Login (login)]
- Step-level Filter (Optional): Set [Property Name] [Logic] [Specific Value]
Step N (End): Select [matched real event, e.g.: Level Pass (level_pass)]
- Step-level Filter (Optional): Set [matched property, e.g.: Level (vip_level)] [Logic, e.g.: Equals] [Specific Value, e.g.: 5]

## Analysis Window Period (Conversion validity)
Set time limit for user to complete entire funnel starting from triggering 「Step 1」.
Window Range: Suggest setting based on business common sense [Minimum 1 minute, Maximum 180 days. E.g.: 1 day / 2 hours / 15 minutes].

## Use Relation Property (Advanced optional, for precise product/activity/match series)
(Not only require sequential trigger, but force require certain core property value in series steps to be completely consistent, property null then exclude)
Match Logic: Require [matched core event property in each step, e.g.: Item ID (item_id) / Activity ID (activity_id)] to be completely equal.

## Global Filter (Optional, define funnel analysis scope)
Set Filter Condition: [matched Event Property / Common Event Property / User Property / User Tag / User Cluster]
Select Logic: [Has Value / No Value / Greater Than or Equal / Less Than or Equal / In Range / Equals / Not Equals / Includes / Excludes etc.]
Set Specific Value: [Specific number or string]
Example: OS (os) Equals ios

## Group By (Optional, breakdown conversion rate comparison)
(Break funnel into multiple lines by specified dimension, compare conversion capability of different crowds)
Group By Dimension: Select [matched Step 1 Event Property / Common Event Property / User Pro

…(truncated)