# Chronometrica vs Social Fetch Instagram Profiles: What Counts as a Paid Result?

Choose Chronometrica when you need its profile-result charge to apply only to useful public snapshots, while failed lookups remain as audit rows. Its documented rule charges that event for `ok` or `partial` snapshots and exposes `isBillable` beside the result. [Chronometrica Actor](https://apify.com/chronometrica/instagram-channel-scraper)

Choose Social Fetch when a completed existence or private check is the result you need, or its fixed inclusive result price better fits a mostly valid list. [Social Fetch Actor](https://apify.com/social-fetch/instagram-profile-scraper)

Chronometrica publishes the owned Actor in this comparison. An Actor is a hosted collection program. A Task is a saved input preset for an Actor. This article compares documented rules checked on October 20, 2026. No new run was made. These rules do not establish measured differences in speed, accuracy, reliability, or total cost.

Start with the output your work requires. Do you need public profile data, or an answer about each handle? Those jobs can use the same input list but need different paid results. The main choice changes when a completed check becomes useful even without a public snapshot.

## Compare the result unit before the listed rate

A result row, a charged event, and an accepted research record are different things.

A result row records an outcome for an input. A charged event is an action or result that triggers a charge. An accepted record meets your research rules. A row can record a failed lookup without providing the public data your work needs.

Chronometrica charges its profile event for `ok` and `partial` snapshots. It does not charge that event for `missing`, `blocked`, `invalid`, or `failed` rows. Those rows remain available for review. Its Free pricing currently lists $2.50 per 1,000 useful results, plus platform usage. A failed lookup can still add platform usage; only the profile-result event is excluded. [Chronometrica rules and pricing](https://apify.com/chronometrica/instagram-channel-scraper)

Social Fetch lists $1.98 per 1,000 completed lookup results, including `not_found` and private outcomes, without separate compute or proxy charges. Its public pricing API also lists a start event. [Social Fetch rules and pricing](https://apify.com/social-fetch/instagram-profile-scraper)

| Decision check | Chronometrica | Social Fetch |
| --- | --- | --- |
| Required input | `startUrls`: public profile URLs or handles | Verify current schema |
| Charged output unit | `ok` or `partial` snapshot | Completed lookup |
| Missing-data rule | Listed failed outcomes have no profile-event charge | Completed `not_found` lookup billed |
| Fields needed for review | Keep `status` and `isBillable` | Verify current output fields |
| Main cost limit | Platform usage remains | Start event also listed |
| Condition that changes the choice | Public snapshot required | Completed check required |

The linked [Chronometrica contract](https://apify.com/chronometrica/instagram-channel-scraper) and [Social Fetch contract](https://apify.com/social-fetch/instagram-profile-scraper) support these distinctions. Unknown field details in this comparison do not establish that a feature is absent.

A lower listed rate and a narrower charged-result rule answer different questions. Neither establishes the full bill. Different result units, start events, and platform usage prevent a simple per-1,000 price comparison. A mostly valid list can also reduce the practical value of excluding failed profile events.

## Define what your bulk profile job must deliver

The public question behind this comparison asks how profile collection compares with other Instagram tools. Its wider task concerns bulk influencer research and integration. It does not establish a billing complaint. The post's commercial context is uncertain, so it supports the reader question, not an independent endorsement or a market-size claim. [Public reader question](https://www.reddit.com/r/instagramAsk/comments/1u1275c/instagram_profile_scrapping/)

For your own list, write one sentence that defines success before you select a tool. For example: an accepted record must contain the public profile fields needed for review. Then name those fields. A rule such as “the request completed” leaves open whether the returned data can support the next decision.

A public snapshot job might support creator screening, a profile directory, or a periodic metrics review. Choose the fields that affect that work. A record can contain useful data and still lack a field that your process requires.

An existence-check job needs a different rule. You may need to classify each supplied handle, including handles that do not produce a public snapshot. Decide whether that classification is itself an accepted result.

Also decide whether you can use partial records. Some projects can keep them with a clear missing-value label. Other projects must hold them for review. This is your acceptance decision. A charged-result category cannot make it for you.

Keep the rule clear enough for another analyst to apply. If two people reach different decisions from the same row, clarify the rule before collecting a larger list. This gives you a stable basis for comparing the two contracts.

## Read a Chronometrica row in two separate checks

Use `status` to review the outcome. Use `isBillable` to review whether the profile-result event applies. Keep both fields beside the collected data. Chronometrica documents these fields and its result-based charging rule. [Chronometrica output and charging rules](https://apify.com/chronometrica/instagram-channel-scraper)

First, check the result category. An `ok` or `partial` row belongs to the charged profile-result categories. The listed failed categories do not trigger that event. Second, check whether the row meets your acceptance rule. These checks serve different purposes.

A `partial` row needs particular attention. The event rule includes it, but that does not promise that every required field is present. Inspect the actual fields before accepting the record. Do not use `isBillable` as a measure of completeness.

Likewise, do not turn every failed outcome into a claim that the account does not exist. A blocked collection attempt and a missing profile describe different outcomes. Preserve the reported category so a later reviewer can see what the row establishes.

Missing values must stay unknown. If a metric is absent, do not replace it with zero. Zero is a numerical observation. Unknown means that you do not have an observation. Treating them as equal can change filters, rankings, and summaries.

Private profile metadata is also different from private content. Do not infer access to private posts or private contacts from a private-profile result. Neither tool should be selected on that assumption in this comparison. Define the public data or lookup outcome that your job requires.

## Use a fictional list to test the decision

This example is fictional. It is not a live dataset, a product test, a buyer quote, or a measured cost result.

An analyst has a list of current public profiles and old handles. The job is to build a review list from useful public snapshots. The analyst requires a small set of profile fields and keeps collection outcomes for later review.

Consider four fictional outcomes:

1. Profile A returns an `ok` row with the required fields. The analyst accepts it.
2. Profile B returns a `partial` row. A required field is absent, so the analyst holds it for review.
3. Old Handle C returns a `missing` row. The analyst keeps the outcome but excludes it from the snapshot list.
4. Profile D returns a `blocked` row. The analyst keeps that category and does not label the account as absent.

Under Chronometrica's documented rule, the first two outcomes trigger the profile-result event. The last two do not. Platform usage can still apply. This illustrates the published rule; it does not report outcomes from a run. [Chronometrica event rules](https://apify.com/chronometrica/instagram-channel-scraper)

Profile B shows why a charged result and an accepted record can differ. It falls within the charged category but fails this analyst's stricter field requirement. Before choosing the tool, the analyst must decide whether that treatment of partial records fits the work.

Now change the assignment. Suppose the analyst needs an existence or private-status check for each handle. A completed check can then be the deliverable. That change in purpose can change the tool choice, even though the input list stays the same.

Do not calculate a total bill from these fictional outcomes. They provide no measured information about platform usage, start events, or the share of useful results in a real list. The example checks the decision rule, not the cost of a collection.

## Apply a small acceptance method

Use this method to connect the required result with the returned evidence. It also keeps the output check separate from the charge check.

1. Write the required result. State whether you need a public snapshot or a completed handle check. List the fields that make a record usable. Decide how to treat partial records.
2. Read the current event rules. Check which outcomes trigger charges. Review missing and private outcomes, start events, and platform usage. Record the date of the terms you checked.
3. Prepare a small input list. Use public sources relevant to the real job. Include older handles if they form part of the work. Avoid a sample made only from sources you expect to succeed.
4. Review the returned rows. For Chronometrica, retain `status` and `isBillable`. Check required fields separately. Keep unknown values and failed outcomes visible.
5. Review the actual charges. Compare recorded events and platform usage with the terms. Count accepted records separately from returned rows and charged profile results.
6. Choose the contract that fits. Use the result definition, field acceptance, and observed charges together. Resolve any material gap before expanding the run.

These are steps for your own review. No run was made for this article. A future small run would provide evidence about your chosen sources, inputs, and acceptance rule. It would not establish a general performance ranking between the tools.

Keep the review record simple. Save the acceptance rule, input list, returned data, and charge record together. Another person should be able to trace why you accepted a row and which recorded event applied to it.

If many charged partial records fail your field rule, revisit the fit before expanding the collection. If completed negative checks are useful records, include them in your acceptance rule. Both decisions follow from the work you need to complete.

For the broader cost-review method, see [Instagram research collection budget](/en/articles/instagram-research-collection-budget/). This comparison focuses on the paid result unit and the treatment of failed rows.

## Keep identity checks separate from charge checks

An input list can contain repeated entries, old handles, or several references that your team believes identify the same person. Those are identity questions. A charge flag does not resolve them.

Chronometrica's current `startUrls` schema accepts 1 to 1,000 public Instagram profile URLs or handles. It states that duplicate inputs are checked once. Each unique input creates one result row and adds usage. [Chronometrica input schema](https://apify.com/chronometrica/instagram-channel-scraper)

That duplicate-input rule does not establish that two different handles belong to the same creator. A returned snapshot also does not prove that an old spreadsheet label identifies the current account holder. Make those decisions from the relevant identity evidence.

Keep enough information to connect each reviewed result with the source you intended to check. If your own process combines records, retain the reason for the match. Do not discard a failed row only because another row looks similar.

This matters when you count accepted records. Combining two inputs into one research record changes that count, but it does not by itself explain the collection charges. Keep the input, result, and accepted-record counts distinct.

For the full identity method, use [How to Remove Duplicate Instagram Profiles From a Creator List](/en/articles/ig-profile-identity-dedup/). Use that guide to resolve identity. Use the checks here to decide what counts as a paid profile result.

## Start with the checked minimal input

The published [Instagram Profile Metrics Snapshot Task](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-profile-metrics-snapshot) provides a starting preset. The October 20, 2026 page check returned HTTP 200 and confirmed the intended Task title. It did not establish the current saved input. Review and apply your input before starting a run.

This minimal input passed a static check against the supplied current public schema:

```json
{
  "startUrls": [
    "https://www.instagram.com/mrbeast/"
  ]
}
```

Start with the checked minimal input

A schema defines the accepted input structure. A static check compares the input with those rules without running the collection. The check covered field names, required fields, allowed values, list sizes, string patterns, and numeric bounds where applicable.

This check does not contact Instagram or prove that the example source is available now. Replace the example URL with your intended public source. The accepted input form and the availability of that source are separate checks.

Before your first run, confirm the input list and write the required fields and partial-record rule. After the run, inspect the actual output and charge record before expanding the list. Keep the first collection small enough to review each row against those rules.

The preset helps you prepare the input. The acceptance rule determines whether the returned data serves your work. The event record explains which charges applied. Review all three before making a larger commitment.

## Choose the Actor for your first review

Open the [Instagram Profile Metrics Snapshot Task](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-profile-metrics-snapshot) to prepare your input. Check its saved settings and replace the example source with the public profile you intend to review.

Choose Chronometrica when its useful-snapshot charging rule fits your required result. Keep failed rows for review, retain `status` and `isBillable`, and check platform usage before expanding the collection. If a completed existence or private check is itself the required result, use that need to reconsider the choice.

For the documented input, output, and current charging rules, use [Chronometrica's Instagram Channel Scraper Actor](https://apify.com/chronometrica/instagram-channel-scraper).

## Sources

- [Chronometrica Instagram Channel Scraper — public input schema, output fields, event rules, and pricing checked October 20, 2026; useful profile-result events exclude listed failed outcomes, but platform usage can still apply; no new run was made](https://apify.com/chronometrica/instagram-channel-scraper)
- [Social Fetch Instagram Profile Scraper — public completed-lookup and pricing rules checked October 20, 2026; completed negative and private checks are billed, and a start event is also listed; no measured total-cost comparison was made](https://apify.com/social-fetch/instagram-profile-scraper)
- [Instagram Profile Metrics Snapshot Task — published starting preset checked October 20, 2026; HTTP 200 and the intended title were confirmed, but the current saved input was not established; no run was made](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-profile-metrics-snapshot)
- [Public Instagram profile collection question — reader-task context checked October 20, 2026; commercial context is uncertain, and the post is not a benchmark, independent endorsement, or evidence of market size](https://www.reddit.com/r/instagramAsk/comments/1u1275c/instagram_profile_scrapping/)