Compare Follower Snapshots: A Reproducible Two-Date Review

Use the Follower & Connection List Checker in snapshot mode with Earlier list in A and Later list in B. Select the actual platform first and add optional dates in chronological order. Snapshot comparisons are available for Instagram, TikTok, Threads, X, LinkedIn, Facebook, and Snapchat. The checker examines local data you supply; it does not capture a baseline, retrieve a new list, or confirm a live relationship for you.

Define one list type and two observation dates

Begin with a narrow question: which identities from an earlier follower list also appear in a later follower list for this account? Keep platform, account, relationship type, and collection scope the same. Comparing an earlier follower list with a later following list answers a different question. Comparing two clients or two platforms also breaks the intended timeline, even if the filenames happen to contain different dates.

A-only is labeled ‘Absent from later list.’ B-only is ‘Added to later list.’ The intersection is ‘Present in both.’ These labels describe accepted identities in the two sources. Added does not necessarily mean a first-ever follower, and present in both does not prove uninterrupted membership between observations. Someone could leave and return between dates without producing a difference at the two endpoints.

Record what each date means. A download date, export request date, and stated data capture date may differ. Use the best-supported observation date in your notes and record uncertainty rather than inventing a precise capture time. Optional dates provide context; they do not repair the source or reveal an exact event time. Keep the same timezone convention for any collection timestamps you record outside the tool.

Choose an interval that supports an actual review cycle, such as a monthly client report, and keep it consistent when feasible. A week and a quarter expose different opportunities for membership changes, so their absence percentages should not be treated as interchangeable performance scores. Save each original before preparing a working copy. The earlier source should remain evidence of that observation, not a spreadsheet that changes every month.

Use consistent IDs and handle renamed accounts explicitly

An identity key is the value used to decide whether two rows represent the same account. Use the same key type across both dates. X archive accountId values become id:NUMBER, which avoids relying on the visible handle for that comparison. Keep large numeric IDs as text in preparation work so a spreadsheet does not round them or rewrite them in scientific notation.

For handle-based sources, a renamed account can appear as one absence and one addition even if the underlying account is unchanged. Imagine an earlier entry called studioeast and a later entry called eaststudiohq. The checker cannot infer that they belong together. Similar profile photos, names, or biographies are not automatic identity evidence. Handle reuse can also make an unchanged string a weak account-level continuity signal.

If trusted source records establish a rename, document it outside the checker. Preserve the originals, record the evidence, and prepare a separate common-key comparison only when the selected platform accepts that key. Label the adjusted result separately from the original handle comparison. There is no built-in rename resolver, alias map, or display-name fuzzy matching. Leave uncertain pairs unresolved instead of quietly editing them into apparent retention.

Instagram, TikTok, Threads, and X handles are lowercased, lose a leading @, and can match recognized same-platform profile URLs after tracking is removed. LinkedIn uses canonical /in/ profile URLs; Facebook uses canonical profile URLs or explicit id: identities; Snapchat accepts handles or recognized profile URLs. These matching rules reduce formatting differences, but they do not verify live accounts or make every URL a permanent identity key.

Check completeness before calculating any retention figure

Make a source inventory for each date. Record the account, list type, original filenames, included parts, collection method, and any selected filters. A later export containing only recent relationships is not comparable with an earlier complete list. A manual sample can be compared with another defined sample, but its result must stay limited to that scope. More rows do not automatically mean better or complete coverage.

Check whether the source was split across files and include every relevant part for that date. Do not combine an old missing part with a new partial export and call the mixture a later snapshot. Deduplication can remove repeated identities, but it cannot make mixed observation times coherent. If a part is missing, recover a comparable source or report the limitation before drawing a membership conclusion.

Inspect input, invalid, duplicate, and unique counts independently for A and B. Duplicate rows change the raw size without changing distinct membership. Invalid identities can create apparent disappearances if one date has poorer preparation. A parser success only means the supplied structure was accepted, not that the source covers the entire relationship list. Unexpected count differences should send you back to the original files and selected identity columns.

Use an account’s displayed total only as a rough contextual check, not proof that a file is complete. Timing and source scope may differ. A close total cannot prove every expected identity is present, and a mismatch deserves investigation rather than an invented explanation. When comparability remains uncertain, describe observed differences between supplied files and withhold an account-wide retention claim. A clear limitation is more useful than a precise unsupported percentage.

Prepare supported local inputs and run a controlled comparison

For a manual comparison, paste one identifier per line. For file-based sources, select the relevant local TXT, CSV, or JSON files for each date. Explicitly select the identity column in multi-column CSV files; bundled PapaParse handles CSV locally. With a LinkedIn connection CSV, choose the profile URL column rather than names or emails. Prepared JSON should be an array of identifier strings, not arbitrary account objects.

Instagram JSON support covers follower arrays with string_list_data values or href fields and relationships_following arrays. X follower and following archives support accountId and validated window.YTD.follower.partN or window.YTD.following.partN JavaScript wrappers as data, never executed code. Select the same relationship type on both dates. Adapter availability is not a promise that the checker extracts every list from every platform archive.

Other native archives require a prepared identity column or list first. Full TikTok, Threads, Facebook, and Snapchat archives are not automatically extracted. There is no ZIP or HTML import: extract locally and choose supported relevant files. Limits are 5 MB per file, 10 MB per source, and 100,000 candidate rows per source, with at most 100 characters per handle and 500 per profile URL.

Choose the platform and snapshot mode before reviewing source roles, then add the ordered dates if known. Leave a date unset when you cannot support it. A blank source is not a confirmed zero-member snapshot; use the explicit intentionally empty setting only when that accurately describes the source. Resolve per-source parsing errors and inspect cleanup counts before calculating. Empty invalid input cannot produce results, and rejected imports must not become evidence of total audience loss.

Calculate retention in a distinct agency reporting example

Consider an illustrative agency reporting on an arts venue’s X follower list from September 1 to October 1, 2026. Both supplied snapshots use archive account IDs. The earlier source contains 1,284 candidate rows; 24 duplicate occurrences and ten invalid entries leave 1,250 accepted unique identities. The later source contains 1,370 candidate rows; 22 duplicate occurrences and eight invalid entries leave 1,340. The agency reviews those exclusions before approving the comparison.

The checker finds 1,180 identities present in both. Earlier-only is 1,250 minus 1,180, or 70 absent from the later list. Later-only is 1,340 minus 1,180, or 160 added to the later list. Reconcile both totals: 1,180 plus 70 equals 1,250, and 1,180 plus 160 equals 1,340. Net change is 160 minus 70, or 90, agreeing with 1,340 minus 1,250.

Observed baseline retention is 1,180 divided by 1,250, multiplied by 100, or 94.4 percent. Observed baseline absence is 70 divided by 1,250, multiplied by 100, or 5.6 percent. These sum to 100 percent because both partition the earlier accepted set. Net growth is 90 divided by 1,250, multiplied by 100, or 7.2 percent. These are calculations the agency makes from counts, not additional checker result buckets.

Do not substitute 1,180 divided by 1,340 for baseline retention; that measures the shared identities’ share of the later list, about 88.1 percent. The union contains 1,180 plus 70 plus 160, or 1,410 identities, but it is not the baseline denominator either. The agency’s summary can say the supplied later list grew by 90 while 70 earlier identities were absent. It cannot say which people clicked unfollow during the month.

Investigate differences without inventing a cause or event time

Select the absent bucket for source-quality review first. Search the sorted identities and use 50-row pagination to examine manageable batches. Counts remain full even when the current view is narrow. Compare a questionable identifier with the original earlier file, then check whether it was rejected, represented differently, or omitted from the later preparation. Do not assume that an apparently clean chart settles those row-level questions.

In the agency example, account IDs reduce handle-rename mismatches, but they do not explain why any identity is missing. The team can retain a separate issue log for unexpected exclusions and preparation decisions. If the common ID is accepted in both snapshots, a changed label does not need to become an absence. If only handles are available, unresolved rename possibilities should accompany the reported result instead of being presented as proven departures.

A missing identity is not proof of who unfollowed, unfriended, blocked, or deleted an account. Nor does it prove a particular campaign caused the change. Two endpoint lists do not show the intervening sequence, the precise moment, or the person’s reason. Use wording such as ‘absent from the supplied October snapshot’ and keep independently documented explanations separate from the checker’s membership result.

The venue’s event calendar may suggest questions worth exploring, but a list comparison does not attribute audience movement to a workshop or announcement. Review campaign outcomes with separate evidence when needed. The Social Media ROI Calculator supports a different question about financial inputs and outcomes; it does not supply missing identity history. Keep observation, interpretation, and business decisions visibly distinct in the agency’s report.

Make the review reproducible and choose appropriate exports

Create a local review folder containing untouched originals, prepared input copies, and a brief comparison note. Record platform, account, list type, both observation dates, preparation steps, selected columns, included archive parts, and unresolved limitations. If you correct a source, save a new version and state what changed. Another analyst should be able to repeat the run without reconstructing decisions from a message thread or relying on your memory.

For stronger version tracking, record a file checksum with your normal local tools alongside each source filename. A checksum can identify whether the same file was used; it cannot prove that the file was complete or genuine. Ask a second reviewer to repeat the import and verify unique counts and all three buckets. The checker is not persistent storage, so reproducibility depends on the evidence your team deliberately keeps.

Copy saves the selected list, and CSV exports the full categorized validated results rather than only a searched subset or visible page. Both expose raw identifiers and suit restricted row-level review. The PDF instead contains aggregate counts, the chart, exact input and cleanup counts, optional dates, comparison context, and practical next steps, with the tool URL in the footer. It does not include raw identifiers and suits an aggregate client summary.

Input processing stays in the browser without social login, scraping, live lookups, or list persistence. Profile results are safe text, not external links. Local downloads and clipboard contents still need deliberate handling by your team; choose the export that fits the recipient’s task. After changing inputs or a rejected import, stale exports are unavailable. Rerun and save fresh outputs with the matching source version so old and corrected findings cannot be confused.

Carry the baseline forward without overstating the trend

For the next review, preserve the accepted October source and compare it with a newly collected November source using the same key type and scope. Do not regenerate the September baseline from today’s account view. Keep consecutive comparisons separate from longer baseline comparisons: September to October and October to November answer different endpoint questions from September to November, even when all files are comparable.

Do not add monthly absence counts and call the total unique people lost over a quarter. An identity can appear in several monthly buckets after leaving and returning, while another can move only once. Deduplicating those exported buckets answers a separate set question and still does not reconstruct event history. Likewise, present in every monthly snapshot means present at the observed endpoints, not verified continuous membership throughout the interval.

If a new export changes format or removes the identity field you previously used, treat that as a method change. Rebuild comparable prepared inputs where evidence permits, or begin a new baseline and explain the break. A smooth chart is not worth concealing an incompatible source. The Growth Health Checker can support a separate broader review, but it does not repair missing snapshots or resolve account identities.

Close each report with the date pair, supported membership findings, source limitations, and the next observation you intend to make. Keep any later account workflow separate. The checker does not send results to SMTasker, import lists automatically, confirm live accounts, or run bulk actions. A well-kept baseline and a reproducible calculation are the practical gains here, even when the honest conclusion is that source coverage prevents a reliable retention estimate.

Questions about Compare follower snapshots

Continue with another list guide

Return to the Follower & Connection List Checker to compare your prepared data, explore a related guide below or browse all free tools.