Content Pillar Analysis for a Clearer Next Content Batch

This guide follows a fictional home-organizing service. Use the Content Performance Analyzer after tagging your own rows; the tool does not read posts or discover pillars with AI.

Give each pillar a job before judging its numbers

Content pillar analysis is a comparison of recurring subjects, not a search for a perfect mix of themes that every account should copy. A pillar should describe a recognizable reader need that several posts can address. Names such as quick decisions, finished projects, and working process can be useful if the team understands what belongs in each. Names such as best content or low engagement are not useful topic definitions, because they already contain a judgment about performance. Write the purpose of each pillar before looking at its counts so the grouping does not quietly change to favor the result you wanted.

Fictional scenario: Rina runs a home-organizing service and reviews twelve posts from one Instagram account. Her pillars are small-space tips, finished room projects, and working process. Each has four posts collected at a declared 96-hour age under an organic traffic context. She wants to decide what to emphasize in the next small content batch. Saves are available for every post, so she begins with that raw count objective. This invented service and its figures are teaching examples, not industry averages or recommended posting ratios. Other accounts should choose subjects and measures that reflect their actual work and available records.

A lower count does not automatically make a pillar unnecessary. Working process may answer practical questions that a finished room photograph cannot address, while a project story may help explain the service even when it receives fewer saving actions. Those purposes need their own evidence and judgment outside the analyzer. The tool summarizes supplied counts; it does not read comments, assess customer trust, identify buying intent, or score editorial quality. Decide which concrete planning choice the review can support. Rina chooses to allocate a few exploratory posts, not to declare one permanent winner or remove an entire pillar from the business.

Build a small manual tagging rule that another person can use

For every pillar, write a short inclusion rule and one boundary example in a separate working document. Rina defines small-space tips as advice a reader can apply to one limited storage problem. Finished room projects show the result and explanation of a completed organizing job. Working process explains how a task is prepared or carried out. A photograph of labeled baskets could belong to any of these, depending on its actual purpose. The reviewer reads the post and assigns the main topic manually. The analyzer receives that label as supplied data; it does not infer meaning from the photograph, caption, or post ID.

Give each row one primary topic and one format. When a post includes both a practical tip and a project result, choose the main reader promise using the written rule. Keep any secondary tags in your own source notes rather than duplicating the row under several pillars. One publication copied into two groups would not become two independent observations, and identical post IDs are rejected. Avoid comma-separated topic bundles such as tips, process, projects. They create a new literal label rather than giving the post membership in three pillars. This tool groups a single supplied topic value for each record.

Keep format separate from subject. Rina might use photo sequence, short video, or single image as her presentation labels, while the topic identifies the reader need. Do not use carousel tips as a topic for one row and tips as a format for another unless those distinctions have a deliberate consistent meaning. The project supports at most twelve topics and twelve formats, so start with useful categories rather than a different label for every publication. The format comparison guide covers the separate presentation question. The pillar review becomes clearer when the same subject can be recognized across several formats.

Prepare the review scope without pretending it is normalized

Use one platform and account for a dataset, with a shared declared observation age and traffic context. Rina intends to compare counts captured after 96 hours, so she collects suitable snapshots before entry. The age field is a declaration, not an automatic normalization or a check against publication timestamps. Entering 96 will not turn a month-old lifetime count into a four-day count. There is no source lookup that can fill that gap. If records were collected at different ages, repair the source collection or make separate reviews with clear limitations rather than claiming the settings have corrected the difference.

Prepare stable IDs and reconcile the selected posts with the source inventory. Use the exact CSV template when importing, or Quick entry when the collection is small. The analyzer accepts up to 120 rows, and every row needs a topic, format, ID, and at least one supported count. Enter whole count values without thousands separators or abbreviated notation. Leave unknown counts blank and use zero only for a known zero. Native names can differ even when platforms use similar words such as views or reach, so document what the source figures mean. The tool does not automatically map a native export into its schema.

Tag the selected records before inspecting the comparison whenever practical. A second reviewer can check a small sample against the written rules without seeing the performance numbers, which helps expose ambiguous pillar definitions. If you later discover an inconsistent tag, correct it openly and analyze again. Editing a topic changes the dataset and invalidates the previous result; it is not a harmless cosmetic label change. Keep the old collection note when the reason for a revision matters. The project has no custom tag-history field or built-in reviewer approval workflow, so that explanation belongs in your ordinary working document beside the saved project.

Compare pillar medians while keeping the exceptional post visible

Rina supplies small-space tip save counts of 40, 50, 60, and 70. The median and mean are both 55. Finished room projects have 15, 25, 35, and 525 saves, producing a median of 30 and a mean of 150. Working process has 30, 40, 50, and 60, producing a median and mean of 45. Finished projects contains the largest individual saving count, while small-space tips has the highest group median. The two observations are compatible. One describes the standout post, and the other describes the middle of each supplied pillar collection rather than declaring which subject is inherently better.

For an even number of eligible values, the median averages the middle pair after sorting. The finished project middle pair is 25 and 35, so its median is 30. Its mean reflects all 600 supplied saving actions divided by four posts, giving 150. The range from 15 to 525 makes the unevenness easy to see. Do not delete the large value simply to make the group look more consistent, and do not let it erase the three ordinary records. First check that the figure was copied correctly. If it is valid, keep it and interpret the complete group instead of treating the arithmetic as a verdict.

Across all twelve eligible posts, the dataset median is 45 saves. Small-space tips therefore has an index of approximately 122.2, from 55 divided by 45 times 100. Working process has 100, and finished projects has approximately 66.7. These are internal references to the median of this selected collection, not quality scores, industry benchmarks, or predictions of next month’s counts. The baseline includes the groups being compared. A zero baseline would make the index unavailable. Rina writes that tips had a higher median save count in this review, without turning saving actions into a count of unique readers or future customers.

Ask a separate question when using a reach-based rate

Raw saves compare the number of supplied saving actions per post. Save rate by reach compares each post’s saves with its own suitable supplied reach denominator. The two objectives can rank pillars differently without either being wrong. In a separate numerical illustration, one post has 40 saves and reach of 1000, giving 4 saving actions per 100 reach units. Another has 100 saves and reach of 10000, giving 1 per 100. The larger post has more saving actions but a lower rate. Choose the objective that matches the review question rather than switching until a preferred pillar moves to the top.

The analyzer calculates those post rates first and then summarizes them. For the two illustrative posts, both the median and mean of the individual rates are 2.5. Pooling their 140 saves and 11000 reach units would produce approximately 1.27 per 100 instead, which is a different calculation and not the tool’s method. Each eligible post contributes one value to the group distribution. The rate describes actions relative to denominator units, not the probability that a unique person saved something. It should not be called a conversion rate for people, and reach across different posts should not be summed into a distinct audience.

Coverage can change substantially when you select a rate. A known zero numerator and positive denominator is eligible with a zero rate. A missing numerator, missing denominator, or zero denominator makes the row ineligible for that objective. If a pillar has four supplied posts but only two complete compatible rate records, read its median as a two-post summary. A known raw zero remains eligible for a raw count objective. Missing is never a substitute for zero. Keep the sample and missing counts visible when comparing the rate review with the earlier saves review, because the two rankings may describe different subsets of the original collection.

Check whether presentation or coverage is tangled with the pillar

A pillar comparison can inherit differences in presentation. Suppose every small-space tip in Rina’s original batch uses a photo sequence, while most finished projects use single images. A higher median for tips does not isolate subject from format. It may still be a useful observation about the supplied batch, but it does not prove that changing any single image into a tip would improve its result. Group by format for another descriptive view, and inspect which topics make up each group. The analyzer has no adjustment for creative effort, post length, publication date, or differences in the people who encountered the posts.

Use the format filter before grouping by topic when a narrower collection answers a clearer question. For example, a later batch might include photo sequences across all three pillars. Filtering to that format can make the practical comparison more focused, provided enough eligible records remain. Filters run before baseline and group calculations, so indexes use the median of the filtered dataset rather than the earlier full collection. Do not compare those indexes as if their denominators were unchanged. If only one pillar survives the filter, you have a summary of that pillar, not a between-pillar ranking against the missing subjects.

Set the minimum post threshold to a review preference between two and twenty and treat it as a reminder about coverage. Below-threshold groups remain visible with a flag; the setting does not create statistical significance or certify a winner. Twelve supplied posts can still be a narrow selection, especially if one pillar has many missing values for the chosen objective. The overall baseline also reflects the composition of the selected collection, so a heavily represented pillar can influence that reference. Keep the counts alongside the medians and explain any uneven selection before using the result to allocate the next batch.

Allocate a small next batch with a written question

Rina decides to explore the observed pattern with six new posts: two for each pillar, using the same broad presentation approach where practical. That balanced allocation is her operational choice, not a ratio generated by the tool or a claim that two posts are enough evidence. She keeps all three subjects because each serves a different reader need. Her written question asks whether small-space tips continue to have a higher middle save count in another comparable collection. The analysis has helped her choose a specific next review rather than simply producing a league table that changes nothing in the content plan.

Keep the next-batch brief outside the analyzer. Include the pillar definition, intended reader question, format, responsible person, traffic plan, and collection reminder. The tool has no calendar, scheduling connection, custom notes field, or automatic recommendation engine. Rina also records unusual circumstances that may matter later, such as a project collaboration or a change in the service offer. These are observations to consider, not factors the analyzer can normalize away. Use the same tagging rules when the new posts are ready, and resist moving an unexpectedly successful post into a different pillar simply because its result makes another label seem more attractive.

Decide in advance how the review will affect a manageable choice, such as the subjects of the next two posts, rather than a permanent publishing formula. If tips again have the highest median, explore further while keeping the limits visible. If the ranking changes, inspect the supplied records and context before drawing a larger conclusion. Ordinary content batches do not establish causality merely because their labels are consistent. Keep audience understanding, service inquiries, and customer outcomes as separate questions. Broader account routines can sit in a SMTasker workflow without turning this local comparison into an automatic planner or publishing integration.

Preserve the tagging method alongside the exported result

Save project JSON to preserve the full supplied dataset and settings for reopening. Save and Open JSON form the lossless project route, while review CSV is a report rather than the input template. CSV replacement imports only the prescribed row data and keeps the current context declarations, so recheck the account, age, traffic, objective, grouping, and filters afterward. There is no autosave or cloud project storage. Keep the manual label dictionary and collection procedure in your own folder beside the project, because those human rules are not additional supported fields and cannot be reconstructed from the finished chart alone.

Use copied results, review CSV, or PDF when another person needs to inspect the current comparison. These review outputs retain all raw supplied rows, including records outside active filters, and the PDF attaches complete project and review data. Check the contents before sharing, especially when post IDs or account labels are internal references. A filtered view is not a promise that the downloaded file contains only that subset. After any edit, analyze again before exporting the current review. Files already downloaded remain unchanged, so keep clear revision names in your own folder rather than assuming the latest browser state updates an earlier report.

Rina’s final handoff states the finding, method, and next step together: small-space tips had the highest median saves among the twelve supplied posts, using manually assigned topics and a declared organic 96-hour context. The declaration was not normalized or independently verified. She plans a six-post follow-up and will keep the tagging rules stable. This is more useful than saying the analyzer discovered her best content pillar with AI. Return to the free tools directory when a separate writing or preparation task is needed. The comparison has done its job when the team understands the records well enough to choose its next practical question.

Questions about Content Pillar Analysis

Continue with another performance guide

Apply the comparison in the Content Performance & Topic Analyzer, or choose another guide below. Discover more resources in all free tools.