SuperAPI AI Directory

x-data-review

Marketing & growth

View repository

Updated 10-15 23:44

About this skill

80/20 Data Review Four-Step Closed Loop

R — Original Text (Reading)

Step 1 data collection (What Happened); Step 2 analyze causes (Why); Step 3 optimization iteration (How to Improve); Step 4 record and track. Use data-driven methods and avoid subjective assumptions. Goal: identify the 80/20 rule (20% of content contributes 80% of value). Small reviews focus on data (weekly review interaction rate), large reviews examine strategy (monthly review monetization path).

— AIP Overseas Tutorial, 9.3 Content Data Review


I — Methodology Skeleton (Interpretation)

This is a structured content data review framework. Its core is replacing ledger-style recording with a "layout-execution-review-iteration" closed loop.

The four steps proceed in order: (1) Data collection — pull impressions/interactions/bookmarks for all posts in the period, group by content type (story/list/opinion/tutorial), and record external factors (trending topics/algorithm changes); (2) Cause analysis — compare performance across types, check whether the Hook captures pain points, whether the Body has depth, and whether the CTA guides action, and analyze audience active hours; (3) Optimization iteration — ask "how would I do better if starting over" and set executable action plans (adjust frequency/test new angles/double down on high-efficiency types); (4) Record and track — build a review template in Notion or Excel and track long-term to form a closed loop.

The guiding principle is 80/20: find the 20% of content contributing 80% of value and double down, rather than spreading effort evenly.

During review there are two sets of reference metrics: (1) Lifecycle — a tweet's natural lifecycle is 1-3 days, so before reviewing wait at least 3-4 days for the data to finish running; (2) Golden length — posts of 120-220 characters have a higher probability of entering the top 10%, which can serve as a reference for the correlation between length and performance. But both are references rather than hard metrics; data distributions differ across niches, and applying them directly is overfitting.

Frequency layering: weekly reviews focus on data (whether interaction rate is >2%), monthly reviews examine strategy (whether the monetization path/positioning needs adjustment).


A1 — Application in the Book (Past Application)

Case 1: Xiangyang Qiaomu 3-Year Data Review

  • Problem: After posting 3,861 posts over 3 years, how to find the key patterns of content growth from massive data
  • Use of the methodology: Use 3.4G of own data for a systematic review — Step 1 collect interaction scores for all posts (likes + 3x reposts); Step 2 classify by content archetype (resource entry type 51%/tool tutorial type 39%/AI tool discovery type 24%/ordinary expression type 9%), compare median interactions and probability of entering the top 10%; Step 3 discover that resource entry type and tool tutorial type are the 20% of content contributing 80% of value, and double down on these two types; Step 4 continuously track to form 3 years of longitudinal data
  • Conclusion: 20% of content (resource entry type + tool tutorial type) contributed 80% of growth; bookmarks > likes (370k > 310k) shows readers treat the account as a "toolbox" rather than a "content source"
  • Result: The account grew from 100 followers to 110k; growth nodes appeared when "units worth bookmarking appeared continuously," verifying that the direction of 80/20 doubling down was correct

Case 2: AIP Tutorial Review Metric System

  • Problem: Which metrics should be looked at during review, and what are the target values
  • Use of the methodology: Define four core KPI categories—impressions (exposure efficiency), engagement rate ((likes + replies + reposts + quotes)/impressions, target >2%), save rate (high = valuable content), reply depth (community stickiness); check engagement rate in weekly reviews, check monetization path in monthly reviews
  • Conclusion: An engagement rate >2% is a healthy baseline; save rate reflects long-term value better than like rate; reply depth reflects community stickiness rather than the performance of a single post
  • Result: Form a reusable review template (Notion + AI dual review), including three columns: "what was done right," "where to optimize," and "next steps," to track over the long term and form a closed loop

A2 — Trigger Scenarios (Future Trigger) ★

In what situations will users need this skill?

  1. The weekly/monthly review cycle has arrived — "I posted 15 this week, help me review the data"—the user needs a structured process to analyze the performance of all posts in the cycle and decide the next strategy
  2. Batch content performance varies greatly, and the reasons need to be found — "They're all tutorial-type, so why do some get lots of saves while others get no attention?"—need to group and compare by content type, and check differences in Hook/Body/CTA
  3. Decide the direction for adjusting the next content strategy — "What type should I post more of next week? How should I adjust frequency?"—need to use data to find the 20% of content contributing 80% and double down on it
  4. Review metrics are unhealthy and need diagnosis — "The engagement rate is only 1.2%, below the 2% target. Where did it go wrong?"—need to systematically check whether it's insufficient exposure (algorithm/timing), insufficient expansion (weak Hook), or failure to enter the Profile (poor storefront)

Language signals (activate when these appear in the user's words)

  • "How do I review 15 posts this week" / "weekly content review"
  • "Which content types have high engagement" / "which content type performs better"
  • "How should I adjust next week's content strategy" / "optimize next week's content strategy"
  • "Help me analyze the data" / "help me analyze my content data"
  • "Which type has a high save rate" / "which posts get more saves"
  • "Look at the monetization path in the monthly review" / "monthly review conversion path"
  • "If I could do it over, how could I do better" — the core wording of step 3 in the original text

Distinction from adjacent skills

  • Difference from x-longtail-strategy : longtail-strategy is "adjusting mindset and goals when posts don't go viral" (mental model), while this skill is "systematically analyzing data to find the 80/20 and optimize" (operational method). longtail answers "is this normal," while data-review answers "how to change." First adopt a long-tail mindset to accept the norm, then use data review to find optimization directions.
  • Difference from x-foryou-algorithm : foryou-algorithm is "understanding how the recommendation algorithm scores" (algorithm knowledge), while this skill is "using data to review content strategy" (operational execution). One is the underlying mechanism, the other is iteration based on result data.
  • Difference from x-short-content-craft : short-content-craft is "choosing the type + Hook-Body-CTA when writing a single piece of content" (content production), while this skill is "reviewing the performance of a batch of already-published content" (data review). One is pre-production, the other is post-production.
  • Difference from x-content-archetypes : content-archetypes is "predicting the spread ceiling by dividing into four archetypes by function" (classification framework), while this skill uses archetype classification as one of the analytical dimensions in review, but its core is the four-step closed-loop process rather than the classification itself.

E — Executable Steps (Execution)

After the skill is activated, the agent should execute the following steps:

  1. Data Collection (What Happened)

    • Have the user list all posts within a period (e.g., one week/month), grouped by content type (story/list/opinion/tutorial), and pull each one's impressions, interactions (likes + replies + reposts + quotes), and saves
    • Calculate key metrics: interaction rate = (likes + replies + reposts + quotes)/impressions, target >2%; save rate = saves/impressions
    • Record external factors: whether there were trending events, algorithm changes, or posting time slots during the period
    • Completion criteria: Have a data table grouped by type (impressions/interaction rate/save rate)
  2. Cause Analysis (Why It Happened)

    • Compare performance across types: Which type has the highest interaction rate? Which type has the highest save rate? (e.g., high saves for list-type -> readers treat it as a toolbox; high interaction for opinion-type -> sparks discussion)
    • Check Hook/Body/CTA one by one: Does the Hook capture the pain point within 3 seconds? Does the Body have depth/steps? Does the CTA guide action?
    • Reference metric checks: Is the post length within the 120-220 character golden range (refer to p09, not a hard metric)? Has the lifecycle already run 1-3 days (refer to p08, data that has not finished its lifecycle does not represent final performance)?
    • Completion criteria: Be able to point out "which type of content performs well/poorly, and what the cause is (which link: Hook/Body/CTA/length/timing)"
  3. Optimization and Iteration (How to Improve)

    • Ask the core question: "If starting over, how could it be done better?"
    • Find the content types where 20% contributes 80% of the value, and set a plan to double down (e.g., list-type has high saves -> post more list-type next week)
    • Set specific action plans: adjust posting frequency (2-5 posts per day, avoid bursts), test new angles, match time slots (post tool tutorials at midday/post opinion cases in the evening)
    • Completion criteria: Have >=3 specific, executable next-step action items
  4. Recording and Tracking

    • Recommend that users build a retrospective template in Notion or Excel, including three columns: "What was done right" "Where to optimize" "Next-step plan"
    • Differentiate retrospective depth: weekly retrospectives focus on data (interaction rate/save rate), monthly retrospectives examine strategy (whether the monetization path/positioning needs adjustment)
    • Track long term and form a closed loop - this week's next-step plan is the comparison baseline for next week's retrospective
    • Completion criteria: The user has a reusable retrospective template and knows what baseline to compare against in the next retrospective

B — Boundary ★

Do not use this skill in the following situations

  • Single content production — "Help me write a tweet about Claude Code" should go to x-short-content-craft / x-five-piece-checklist. Data retrospectives are periodic analysis of a batch of already-published content, not for writing a single post.
  • Anxiety/mentality adjustment when posts do not go viral — "I posted 20 in a row and only 2 passed 100; should I give up?" should go to x-longtail-strategy. Anxious mentality needs long-tail benchmark calibration, not a retrospective operating process. First accept the long-tail norm, then do data retrospectives.
  • Understanding recommendation algorithm mechanisms — "How does the For You algorithm score?" should go to x-foryou-algorithm. This skill performs retrospectives based on result data and does not explain how the algorithm works.

Failure modes the author warns about in the book

  • ce07 only focuses on traffic without building content capability — The most dangerous trap in a retrospective is looking only at data metrics (impressions/engagement/saves) and not at content ability itself. Platform tactics and data metrics will change; content ability (topic selection, narrative, depth) is the transferable long-term asset. In a retrospective, besides looking at "which type of content performs well in data," also ask "has my content ability improved" — otherwise you are building a house on quicksand. Signal of abnormal metrics: content output relies on templates rather than genuine insight, and follower growth relies on tactics rather than content quality.
  • ce15 Treating an overfit experience as a universal formula — The reference metrics cited during a retrospective (such as a golden length of 120-220 characters, a lifecycle of 1-3 days, an engagement rate > 2%) come from overfit data of a specific account (AI/product R&D niche, Chinese-speaking audience, 2023-2026 algorithm version). Different niches, different audiences, and different periods have different data distributions. During a retrospective, these should be treated as reference directions rather than hard metrics — use them to discover "whether length and performance are correlated," not to judge "if it is not within 120-220 characters, it must be bad."

The author's blind spots / limitations of the era

  • The 80/20 rule is an empirical observation, not a causal law. "20% of content contributes 80% of the value" is a statistical phenomenon, and it does not guarantee that doubling investment in that 20% will necessarily produce 80% of the output — there may be uncontrollable factors such as timing/luck/platform traffic bias (ce16 survivorship bias).
  • The retrospective metric system (engagement rate > 2%, save rate, etc.) is based on the current algorithm version. After an algorithm update, the metric baselines may drift.

Adjacent methodologies that are easily confused

  • x-longtail-strategy(long-tail mindset) — longtail is the premise of "accepting that most posts are ordinary," while data-review is the operation of "finding the 20% to double down on." The long-tail mindset must come first, then data review; the order cannot be reversed.
  • x-content-archetypes(four archetypes) — Archetype classification is one of the analytical dimensions in step 2 of the retrospective, but the core of data-review is the four-step closed-loop process, which is not equal to the classification itself.

Related skills

  • depends-on x-longtail-strategy: Data review depends on the long-tail mindset coming first — first accept that most posts being ordinary is the norm (median 42), then use 80/20 to find the 20% to double down on. The mindset must come first, then the review; the order cannot be reversed.

Audit information

  • Validation passed: V1 ✓ / V2 ✓ / V3 ✓
  • Test pass rate: pending test (see test-prompts.json + test-results.md for details)
  • Distillation time: 2026-07-14