User Analysis

User Tag System Design

Automatically plan a layered tag system by industry characteristics from real tracking data, covering RFM, behavior, state, and preference, so tags carry real business insight.

IndustriesGamesE-commerceToolsSocial

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Segmentation

by cluster

Analysis readyevidence attached

User Tag System Design is a user-operations capability in ThinkingAI's industry Skill library. It helps operations teams plan the tag architecture from scratch when building a user-segmentation system, designing dimension tags such as RFM tiers, behavioral preferences, and state lifecycle by industry characteristics, and defining each tag's business definition, use case, value tiers, and calculation logic. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

user-tag-system-design

Our tag library has piled up to 180, but operations actually uses fewer than 20, and new folks have no idea which one to use. Redesign a tag system based on the real tracking of our tower-defense game, one that can actually land in AE, and don't give me a generic RFM template.

Scan tracking events and properties, identify the industry and sub-category

Tower-defense category: dual main lines of level progression + deck building

Inventory the reference status of the existing 180 tags

Only 17 were actually referenced in the last 90 days, a 9.4% utilization rate

Match a tower-defense-specific tag framework, drop the payment-frequency dimension of generic RFM

Six-layer architecture design and a mapping that trims the existing tags

180 → 52 core tags

Generate a draft business definition, value tiering, and AE calculation logic for each tag

The system design is done. 180 cut to 52, a six-layer architecture, each one with AE calculation logic: the 128 that were cut aren't lost, they were merged, deprecated, or downgraded to derived fields. First, why not generic RFM: tower-defense payment is inherently sparse, most players only buy 1–3 times across their entire lifetime, and the payment-frequency (F) dimension has no discriminating power in your project, and forcing it in only gets you a pile of users bunched in the same tier.

1. Six-layer tag system (52 total, representative examples per layer)

Tag layer	Count	Example tags	Calculation method	Update frequency
Base attribute layer	8	Acquisition channel, device tier	#channel, #device_model direct-read mapping	Static at registration
State layer	9	Lifecycle stage (new / growing / mature / churn risk)	First/last event + days-since-login rules	Daily
Behavior layer	12	Level-progression speed, avg. daily battles	battle_start aggregated over the last 14 days	Daily
Preference layer	10	Main deck archetype, ad-watching tendency	Top-N stats on event properties	Weekly
Value layer	8	Payment-depth tier (dual dimensions, F dropped)	Cumulative payment amount × recency of last payment	Daily
Prediction layer	5	7-day churn probability, first-payment conversion tendency	Behavioral-feature model score	Daily

← Scroll to see more

2. Four design principles

A tag must answer an operational question: tags with no articulable use case don't make it into the system, and most of the 128 cut this time died on this rule

Industry framework over generic template: the value layer uses "payment depth × payment recency" two dimensions instead of RFM's three, matching tower-defense's payment structure

Decoupled layers: the state layer only describes "what stage they're in now," the prediction layer only describes "how they might trend next": no single tag doing two jobs

Compute cost declared up front: each tag is labeled with its update frequency: the prediction layer runs one daily batch computation, not real time, to avoid repeating the mistake of 180 tags dragging down maintenance

Based on the landing benchmark of comparable-category projects: after the system is trimmed and the calculation logic is filled in, tag coverage can rise from the current 8% to roughly 85%, operations goes from "sifting through 180 tags for a feel" to "picking by layer," and there's room for about a 3x improvement in push-configuration efficiency.

Recommendation

A note on scope: what this Skill delivers is the design: draft business definitions, value tiering, and AE calculation logic for the 52 tags; actually creating the tags in AE requires calling the tag-creation tool to execute, and from experience it can all land in 1–3 days. I'd suggest landing the state layer and value layer first (highest operational usage frequency), and bringing the prediction layer up last.

The tag-system draft (52 tags × definition / tiering / calculation logic) is synced to the project docs, ready for batch creation once confirmed.

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

Many teams directly copy the RFM model when building a user tag system, but it often works poorly in games: more than 70% of game projects find the payment-frequency dimension inapplicable, with user-segmentation accuracy below 40%. A more common problem is tag pile-up, where operations actually uses only 5 to 8 core tags out of 200+, the rest become a maintenance burden, and more than 60% of projects have tag utilization below 10%.

What it does

Automatically identify the industry and sub-genre and match an industry-specific tag framework rather than a generic RFM template

Six-layer tag architecture design: base attributes, state tags, behavior tags, preference tags, value tiers, and predictive tags, with a clear hierarchy

Deliver a complete definition for each tag: business semantics, use case, value-tier rules, and AE calculation logic, with no gap from design to production

When to use it

Planning a user tag system from scratch before a new product launch

An existing tag system that is bloated and disorganized and needs restructuring and pruning

An operations team needing an industry-specific tag framework rather than a generic template

A precise-push scenario needing behavioral-preference tag support

User lifecycle management needing state tags and predictive tags to work together

In the field

Case

A tower defense game · tag system restructuring

The existing 180 tags had a utilization rate under 10%. The Skill re-planned a six-layer architecture, base attributes, state, behavior, preference, value, and predictive layers, and pruned it to 52 core tags, each with a business definition and AE calculation logic. Push efficiency rose 3x and tag coverage rose from 8% to 85%.

FAQ

Does this Skill design tags or configure them?

This Skill handles planning and design, producing the tag plan, definitions, and calculation logic; actually creating tags in AE requires calling the tag-creation tool.

What is industry identification based on?

The Skill determines the industry and sub-genre from the customer's real tracking events and property data, not just the user's verbal description.

How soon can the tag system go live after design?

Once the design is delivered, AE tag configuration usually takes 1 to 3 days, and each tag comes with AE calculation logic.

Related Skills

Single-User Behavior Analysis

See a single user's full lifecycle in one click

Churned User Identification and Profiling

Define and profile churned users