Three translucent post cards with clocks and bars connect to one comparison grid against soft purple, blue, and pink gradients.

Chronometrica publishes the owned Actor compared here. An Actor is a hosted collection program. A Task is a saved input preset for an Actor.

The choice starts with your post list. Do you already know which posts belong in the report? A fixed list calls for one collection method. A report that must first find posts calls for another. Make that choice before you calculate an engagement rate.

Start with the Page reporting need

A reader in r/marketing asked how to calculate Facebook Page engagement rates without an admin or analyst role. That is a request for public Page analysis. It does not specify whether the reader already has the post list. That missing detail changes the tool choice. The post shows a reporting need. It is not a product endorsement or a product test. Reader question.

You might have a campaign sheet with approved post links. Your task is then to collect public counters for those exact posts. You might instead know only the Page and reporting dates. Your first task is then to find the posts that belong in the report.

Both tasks can lead to an engagement report. But they need different inputs and different checks. A tool can finish collection without giving you all the data your calculation needs.

Write the reporting need in one sentence before you choose. For a fixed list, state that you need the required public counters for the listed posts on each report date. If you must first find the posts, include that step in your collection plan.

Public data also sets a firm limit. These public collection routes do not supply admin reach, impressions, clicks, or a unique audience count. Public counters do not establish sales. A new collection does not recover past snapshots. If your report requires those values, this tool choice does not solve that need.

Compare the collection job

Chronometrica accepts known content URLs directly. Its checked public contract includes `contentMetricStatus`, plus precision and source labels. These help you check metric availability before you use a value. The supported advantage is the direct known-content workflow. It does not establish better accuracy or access. Chronometrica public contract.

Apify Facebook Posts Scraper documents Page-feed collection with newer and older date bounds. Apify public contract.

Compare the collection job
Decision pointChronometrica Facebook Metrics ScraperApify Facebook Posts Scraper
Required inputKnown content URLs in `startUrls`, with `mode` set to `knownUrls`Page feed and date bounds
Required output unitA result checked against a requested URLDiscovered posts
Missing-data ruleInspect `contentMetricStatus`; keep unknown valuesCheck fields; keep unknowns
Needed fieldsRequired counters, status, precision, and source labelsConfirm required counters and metadata
Main limitA resolved URL can still lack a required counterResults still need acceptance checks
Condition that changes the choiceThe job becomes finding posts within datesA fixed post list

The table gives a selection rule and a review rule. It does not establish that an undocumented feature is absent. Confirm any field that matters to your report before you depend on it. Chronometrica documentation, Apify documentation.

For a fixed list, the smaller input requirement is useful. You supply the content you mean to measure. This removes the need to define a discovery step for that job. It does not remove the need to check each result.

Define an acceptable result before collection

A completed run and a usable reporting row are different things. A URL can resolve to public content while a required counter remains unavailable. The number of submitted URLs therefore cannot prove that the report is complete.

Start with the counters your report needs. Name each one. Then decide what you will do if one is missing or has limited precision. Do this before you see the results. Otherwise, you might change the rule to suit whichever values appear.

Use three questions for each requested post:

  1. Does the returned content match the requested post?
  2. Is each required counter available, with enough precision for the report?
  3. Can you keep the value's status and source information with the observation?

For Chronometrica, inspect `contentMetricStatus` and the supplied precision and source labels. This article does not specify undocumented status values or field structures. Use the documented output when you build the check. Chronometrica Actor documentation.

Precision describes how much detail a value provides. A rounded counter must not become an exact count in your report. A source label records where the value came from. Keep those labels when you move data into a sheet or another system.

An unknown value must stay unknown. Do not replace it with zero. Zero states that the known count is zero. An unknown value states that you do not have a usable count. Those meanings lead to different conclusions.

Also separate collection acceptance from calculation acceptance. You may keep a result because it correctly identifies the post. You may still exclude it from a calculation because a required counter is missing. Record the reason. A reviewer can then see what you collected and which observations support the calculation.

Keep the post list fixed between observations

A fixed list makes repeated observations easier to interpret. You can ask what changed on the same posts between two collection times. If the list changes with the counters, the report has two changes to explain.

Keep a master list of the intended public URLs. Give each URL a place in your report. Store the collection time for each observation. These are reporting practices. They are not claims about automatic Actor output fields.

Do not remove a post from the master list because its counter is missing on one date. Keep the requested post visible. Record why you cannot use the observation. Otherwise, the report can appear complete after you remove the incomplete rows.

The same rule applies when you compare dates. A counter available on the first date and missing on the second does not show a fall to zero. It shows that the second observation lacks the value needed for that comparison.

A fixed list also limits the report's scope. It answers questions about the selected posts. It does not prove that you captured every post published by a Page during the period. If complete period coverage is required, review the collection choice before you present the report.

For the full calculation method, use How to Calculate Facebook Engagement Rate Without Admin Access. Choose the collector here. Then apply one stated calculation rule to the accepted data.

Check the decision with a fictional example

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

An analyst has eight known campaign post URLs. The campaign report must follow those same eight posts on each report date. The analyst needs public counters for each post. The report must also show where a required counter is missing.

Chronometrica fits this input need. The analyst can submit the content URLs directly and inspect metric status, precision, and source labels. That is the checked reason for the recommendation. It does not depend on a claim about speed, price, or comparative accuracy. Chronometrica Actor.

The analyst first writes down the required counters. They keep all eight URLs in the report list. After collection, they check each result against its requested post. They then review the required metrics. A post with an unavailable counter stays visible, with that counter recorded as unknown.

Eight requested URLs do not promise eight useful rows. Even a successful resolution can lack a required metric. The analyst must count usable observations separately from requested URLs and explain any gap.

Now change the assignment. The report requires all recent Page posts within stated dates. The original eight links no longer define the job. This is the condition that changes the recommendation to the Page-feed route. Apify Facebook Posts Scraper.

The reporting question remains public Page engagement analysis. Only the input need has changed. The analyst still has to check whether the collected values can support the intended calculation.

Run a small acceptance check

An acceptance check determines whether a result meets your report's stated requirements. Use a small check before you collect the full list. Its purpose is to find a mismatch between your needs and the available data. It is not a performance test of the two products.

  1. Write the input set. List the known public URLs. If discovery is required, state the Page and dates instead. Make the intended scope clear.
  2. Write the required counters. Separate values required for the calculation from useful extra details. State how missing or limited-precision values affect acceptance.
  3. Collect a small sample. Check content identity, required counters, metric status, precision, and source information. Keep unknown values as unknown.
  4. Save the observation details. Keep the requested URL list and collection time. Record which results passed the calculation rule and why others did not.
  5. Review the input need. If the report now requires discovery within dates, change the collection plan before you expand the work.

Choose sample posts that matter to your actual report. A sample that omits the content types you need may fail to show an important limit. A small sample also cannot establish broad reliability or comparative performance.

After the check, record your decision. You may be able to proceed with the full list. You may need to revise the report's required metrics. You may need to stop because public data cannot answer the question. Do not silently change the acceptance rule to make every row pass.

If video measures are involved, check that each term matches the report question. Views, plays, and reach must not become interchangeable labels. See Facebook Video Views, Plays, and Reach before you combine those measures.

Start from the Task, then apply the intended input

The public Facebook Engagement Metrics Tracker Task provides a starting preset. The supplied page check found the intended Task page and returned HTTP 200, a successful web response. That check did not establish its current saved input. Apply the intended input before you run it. Open the Task.

The following minimal input passed an input-shape check against the saved public schema. A schema defines accepted fields and values. An input-shape check checks the input against those rules. It does not collect Facebook data or prove that the sample source is available now.

json
{
  "mode": "knownUrls",
  "startUrls": [
    "https://www.facebook.com/reel/2645452435840671"
  ]
}
Start from the Task, then apply the intended input

Replace the sample URL with your intended public content URL. For a fixed list, keep `mode` set to `knownUrls`. Put the intended content URLs in `startUrls`. The checked schema accepts direct content links for posts, reels, watch pages, videos, and photos. Facebook Stories URLs are not accepted. Chronometrica input schema.

Review the resulting metrics before you expand collection. The example input is a starting point. It does not promise that the sample content remains available or exposes the counters you need.

Sources & further reading

By Chronometrica · Updated

Back to top ↑