Hashtag Set Performance Analyzer

Start with a question about complete hashtag sets

A hashtag performance review is most useful when its question matches the evidence available. Instead of asking which individual tag generated your views, ask how posts carrying one complete recorded set compared with posts carrying another. The observation is a post, and its group is the exact collection of tags entered for that post. If a tutorial carries #CoffeeTips and #HomeBrewing, its measured views belong to that post in that two-tag group. They are not credited separately to both tags as audiences those tags delivered. This distinction lets you inspect actual publishing history without turning a label attached to content into an unsupported traffic source.

Choose one account, one platform context, one traffic category, and one declared observation age for the project. The available contexts are Instagram, TikTok, YouTube, Facebook, LinkedIn, Threads, X, and Snapchat. For Snapchat, the relevant context is Spotlight captions or topics, not private Stories or Chat. Threads uses one chosen topic label per post rather than a multi-hashtag block. These choices describe the supplied observations; they do not connect an account or verify the measurements. Keep cross-platform reviews in separate projects because a similarly named count can have a different definition, collection route, or practical meaning in a different context.

Write the decision you hope to make before choosing the most flattering result. A coffee educator might want to decide which two existing sets should be included in the next tutorial review. That is narrower than finding the best coffee hashtag everywhere, and it is answerable with the available records. The analyzer groups by complete sets, while topic and format serve as filters that help establish comparable content. For a review centered on content categories rather than tag combinations, use the separate Content Performance Analyzer. Keeping those questions distinct avoids explaining a difference in subject matter as if it were evidence about a tag.

Prepare one consistent observation for every post

Give every post a stable, unique ID and enter a content topic, format, and the tags actually recorded with it. Use short operational labels such as Tutorial and Short video so that the same category does not fragment into unnecessary variants. A post ID identifies a record in your project, not a verified platform object. IDs are case-sensitive after trimming and Unicode NFC normalization, so establish one naming convention before combining a colleague’s rows with yours. Never enter the same post twice merely because it used several tags. One row already holds the whole set and every measurement supplied for that observation.

Collect counts at the same age after publication, such as seventy-two hours, and enter that declared age in hours. A common age is a collection rule, not a command that converts older lifetime totals into younger ones. The analyzer has no publication timestamps from which to reconstruct an earlier snapshot. Likewise, Organic, Paid, and Mixed label the project’s traffic scope without separating it automatically. If one post was boosted and the others were not, obtain comparable measurements or keep the changed traffic context in a separate review. Preserve publication times, collection times, and the measurement source in your working record outside this compact post table.

Enter a known zero as zero and leave an unavailable measurement blank. A row can remain saved with every measurement unknown, which is useful when you have recorded the set but have not collected its results yet. Such a row contributes to selected-post usage counts but cannot supply a value for the chosen objective. Blank tags have a different meaning: they deliberately identify a no-tag control, not an uncompleted tag transcription. Resolve uncertain tag history before entering a blank control. The project can contain up to two hundred posts, so choose a coherent review batch rather than combining unrelated accounts and campaigns simply to enlarge the apparent sample.

Understand which spellings become the same set

For the seven hashtag-list contexts, enter tags separated by spaces, commas, or semicolons, with an optional leading hash on each token. Enter only the tag list, not the entire caption. The parser validates whole tokens rather than extracting convenient pieces from surrounding punctuation. A token may contain Unicode letters, marks, numbers, or underscores under the tool’s validation rules, but a phrase such as home brewing becomes two tokens when separated by a space. Record #HomeBrewing when that is the actual single tag. A malformed token causes the row to be rejected instead of being silently shortened into a different label.

Grouping uses normalized lowercase keys, while retaining the entered tag text in the project. Reordering #CoffeeTips and #HomeBrewing does not create a new group, and a case variant of the same normalized spelling merges with that group. Repeating #CoffeeTips twice on one post still counts as one distinct use on that post. However, #Home_Brewing and #HomeBrewing remain different labels, and accents are not stripped to force a match. The complete sorted membership defines a set. Adding #LocalCoffee creates another group even if every other tag remains unchanged. Do not rename that new group as an improved version until you have inspected its actual content context.

Threads needs a separate convention: enter the one topic label chosen for the post as the entire field. A multiword label remains one topic, not several tags. That local convention helps compare your records but does not validate what the current native composer accepts. An empty field represents no chosen topic. Exact spelling normalization is also not semantic matching: two labels about the same subject remain different if their normalized keys differ. Use the hashtag set comparison guide when you need to inspect membership and overlap. Keep original records available so a grouping correction can be distinguished from an actual change in publishing practice.

Choose an objective and read the denominators

Select Views, Reach, Impressions, Engagements, or Clicks when your question concerns a supplied count per post. Only records with that count known are eligible for its descriptive statistics. A post with known views and unknown clicks can therefore participate in a views review but not a clicks review. The platform label does not guarantee that every field is available in your analytics source. Do not substitute one metric merely to complete the table. Define Engagements consistently before entry, using the same action-count convention across every row. The analyzer does not infer that total by adding whatever unrelated figures happen to be visible.

The two rate objectives calculate actions per one hundred denominator units for each eligible post. Engagements per reach uses one hundred times engagements divided by reach; clicks per impressions uses one hundred times clicks divided by impressions. Both inputs must be known and the denominator must be positive. A zero numerator with a positive denominator produces zero, while a zero or missing denominator makes the rate unavailable. These are action ratios and can exceed one hundred; they do not automatically represent the percentage of unique people who converted. Group statistics summarize the eligible post-level rates, rather than pooling all actions and denominators into one ratio.

Read the group’s selected-post total, eligible count, missing count, median, mean, minimum, and maximum together. The median describes the middle of the eligible post values; the mean is more affected by unusually large observations. Minimum posts is a review threshold based on eligible observations, not a significance test or a promise that a set is sufficiently studied. Groups below it remain visible. The baseline median uses all eligible selected posts, including deliberate no-tag controls. A group’s index is one hundred times its median divided by that baseline median. Index one hundred means the medians match; a zero baseline leaves the index unavailable rather than proving the group has no performance.

Work through the coffee-post example before filtering

The fictional example contains twelve posts. Four Tutorial posts in Short video format carry #CoffeeTips and #HomeBrewing, with views of 1,000, 1,400, 1,600, and 2,000. Three more Tutorial short videos carry #CoffeeTips and #RoastNotes, with views of 600, 800, and one unknown value. Two Tutorial short videos intentionally have no tags and record 900 and 1,100 views. Finally, three Event posts in Image format carry #CoffeeTips, #HomeBrewing, and #LocalCoffee, with 4,000, 5,000, and 6,000 views. These are supplied teaching observations, not expected results for coffee creators or a recommended posting volume.

With Views selected, all twelve posts are in scope and eleven have eligible measurements. There are four exact sets, four distinct tags, and two no-tag posts. The overall median is 1,400 views. The event-image set has a median of 5,000; the first tutorial set has 1,500; the no-tag control has 1,000; and the roast-notes tutorial set has 700 from its two known measurements. Its third post remains missing, not zero. At a minimum of three eligible posts, the first tutorial and event-image groups meet the threshold; the other two do not. The large event result describes a different topic and format, so it is not evidence that adding #LocalCoffee caused an improvement.

Now filter the content topic to Tutorial. Nine posts remain selected, eight are eligible, and their baseline median becomes 1,050 views. The first tutorial set still has a 1,500 median because its records have not changed, but its comparison baseline has changed. Its index is approximately 142.86 rather than the approximately 107.14 obtained against all eligible posts. That difference demonstrates why an index needs its scope attached. The filter removes event images from the comparison rather than adjusting their views. The roast-notes group still has only two measured posts. A practical next step is to collect its missing value and plan more comparable tutorials, not announce an established winning set.

Use tag usage, co-use, and overlap for different jobs

Tag usage answers how often a label appeared in the selected supplied posts. In the unfiltered coffee example, #CoffeeTips appears on ten posts, #HomeBrewing on seven, #RoastNotes on three, and #LocalCoffee on three. The unknown-view post still counts toward usage because its recorded tags are known. The table also separates eligible and missing measurements for each tag and shows how many exact sets contain it. Its share uses all selected posts as the denominator, not just posts with a known objective. A tag appearing on ten of twelve posts has approximately 83.33 percent usage in this dataset, not an 83.33 percent share of platform searches or attributed views.

Co-use counts selected posts containing both members of a pair. #CoffeeTips and #HomeBrewing occur together on seven of the twelve coffee posts. Repeating a tag within one row cannot inflate that pair count. The interface shows the first twenty pairs and discloses the full count, while the result and report CSV retain the complete pair inventory. This view helps spot combinations you have repeatedly published together, which is useful when planning a change you can interpret. It does not isolate either tag’s contribution. If two tags always travel together, ordinary post measurements do not tell you which one, if either, accounts for a difference in results.

Overlap compares membership between distinct nonempty sets, using shared tags divided by the union of their tags. The two-tag coffee tutorial set and the three-tag event set share two tags out of three, giving approximately 66.67 percent token overlap. The tutorial and roast-notes sets share one tag out of three, or approximately 33.33 percent. No-tag controls are excluded from overlap comparisons. The displayed summary retains only the ten highest positive overlaps, not a full similarity matrix, and labels its coverage. These are literal normalized-token relationships, not similarity of meaning or evidence of audience overlap. Use them to make a proposed change explicit, then examine whether the associated posts are actually comparable.

Keep imports, editable backups, and reports distinct

For batch entry, use the tool’s nine-column input template: post_id, topic, format, tags, views, reach, impressions, engagements, and clicks. Header order can vary, but the required names and fields must match. Quote a tags field when its separators would otherwise create additional CSV columns. Empty count cells mean unknown; use ordinary whole-number strings for known counts rather than abbreviated values such as 1.4k. The importer checks the complete candidate dataset, including duplicate IDs, before replacement. Paste CSV requires its explicit replacement action, whereas opening a CSV file follows the file-import flow. Commit or clear an unfinished post entry or paste before analyzing or saving.

Save project creates the editable JSON backup, including its settings, all saved rows, original entered tags, filters, and next-test note. Open project restores that saved format. The downloaded report CSV serves a different job: it documents the review and is not the input template or the editable reopening format. Keep both when a colleague needs to inspect the calculations and you need to resume the underlying project later. Save a dated project before a substantial correction so changes in tag transcription, metric choice, or scope can be explained. The browser tool does not maintain an automatic persistent history, so closing the page is not a substitute for deliberately saving your work.

Treat Copy results, Download CSV, and Download PDF as full-review sharing actions. They include the raw source rows and project context, including rows outside the current topic or format filters and the next-test note. The PDF presents a bounded visible summary with the complete project JSON and report CSV attached. A filtered screen therefore does not produce a redacted file. Prepare a separate project with sensitive rows and labels removed before generating something intended for wider circulation, then inspect the output and attachments. Local calculation avoids an account-connection workflow, but a downloaded report can still reveal exactly the private material you supplied.

Turn the review into one answerable next comparison

After reviewing scope and missingness, choose one narrow follow-up. You might compare the two tutorial sets on the same account, in the same format, at the same observation age, with the same traffic scope and action definition. Keep a deliberate no-tag group when it answers the practical question, and decide its inclusion before seeing outcomes. Record the proposed difference in Next test: for example, retain #CoffeeTips and replace #HomeBrewing with #RoastNotes while keeping the tutorial series consistent. That note is an operational reminder, not an executed experiment. The hashtag testing plan explains how to predefine observations without treating an organic-post ranking as causal proof.

Review the result in a stable order: confirm the account and collection age, inspect selected and eligible counts, examine group coverage, read the medians alongside their ranges, then consult usage and overlap. Correct a measurement from its source rather than deleting an inconvenient high or low post. If a standout observation coincides with an event, collaboration, or promotion, describe that context and decide whether a separate review is appropriate. Do not move records between topics simply to improve a set’s index. Reanalyze after changes because a corrected count, filter, or objective can alter the baseline and the eligibility of several groups at once.

Use the platform guides for collection examples, then return to all free tools for adjacent planning tasks. When the next job is account operation, SMTasker supports platform-specific publishing and other workspace routines. Skye can help review or prepare supported settings, and permissioned MCP access can support available workspace actions. Those capabilities do not import this review as an experiment or establish hashtag attribution. Keep the measurement record and your interpretation with the publishing brief. The useful outcome is a clearly described next comparison, with its evidence and uncertainty intact, rather than a universal list of tags claimed to guarantee reach.

Questions about tag-set performance