# How to Report Paid and Organic Facebook Results Without Double Counting

Use the owner’s Ads Manager, Insights or other authorized reports to report paid and organic Facebook results. Check the content identities, metric definitions and dates before you connect records. Keep current public post counts in a separate section. A public count cannot give you a paid and organic split. Do not subtract paid results from a public count to infer organic reach.

Your finished report should show three separate groups of supported facts: paid results, organic results and dated public observations. Connect these groups through checked post identities. Combine values only when their definitions support the calculation. Keep missing facts and unresolved differences visible.

The method below is a proposed reporting process. The supplied evidence includes public documentation, not a completed report or a tested collection run.

## 1. Define the question before you collect numbers

Start with the owner’s reporting question. Does the reader need paid delivery, organic delivery or public response? Paid delivery concerns distribution through advertising. Organic delivery concerns distribution that the owner source labels organic. Public response concerns the counts visible on a public post.

These are separate requested facts. The supplied [public question about organic and paid analytics, retrieved August 11, 2026; one question record](https://www.reddit.com/r/AskMarketing/comments/1on84z9/facebook_linkedin_organic_paid_analytics/) also names both delivery types. Its excerpt concerns LinkedIn paid tracking. It does not establish a Facebook product limitation or show how common the need is.

Write a short report specification:

1. Name the business question.
2. List each requested metric, meaning each quantity you need to measure.
3. Set the reporting period and time zone.
4. List the posts and ads included in the report.
5. Name the source needed for each requested fact.
6. State whether the result counts actions, records or people.

For example, “paid interactions during the reporting period” and “public likes observed today” are different requests. An interaction is an action under the source’s saved definition. A like is one specific public counter. Neither label gives you a count of distinct people.

Use the source’s exact metric label throughout the report. Do not shorten several different labels to “engagement” and then treat them as equal.

## 2. Start with the owner’s available reports

Inventory the Ads Manager, Insights and other authorized files that the owner can provide. Use the files that actually exist. This method does not promise a particular export option, menu path or historical record.

For each file, save its name and record what it covers:

1. Copy the exact metric labels and their available definitions.
2. Record the selected account, campaign, ad or post filters.
3. Record the start date, end date and time zone.
4. Record attribution settings if present. These settings describe how the report assigns results to an ad or reporting period.
5. Identify the row unit: what one row represents.
6. Note missing definitions, incomplete coverage and unavailable fields.

The row unit matters. One row might represent an ad, a post or an account total. Adding an account total to the ad rows that contribute to it can count the same result again.

Keep the original files so another reader can check the reported numbers. Do not replace their labels with assumed equivalents.

If the paid report is missing, mark the paid result as missing. If an organic definition is unclear, mark the definition as unresolved. A public collection tool cannot supply an absent owner delivery metric.

A recorded zero has a different meaning. Use zero only when a valid source explicitly records zero for the requested metric and scope. Scope means the content, accounts, dates and filters that a value covers.

## 3. Build a source register

A source register is a table that connects each reported value to its evidence. Build it before you calculate totals. Keep the source value beside its exact label and scope.

Use these fields as a starting point:

| Field | What to save |
| --- | --- |
| `source_record` | A reference to the source file and original row or total |
| `source_metric` | The exact metric label from that source |
| `content_id` | The checked post identity, or a missing value if unresolved |
| `ad_id` | The ad identity when available |
| `period` | The measurement start and end dates, when applicable |
| `scope` | Delivery type, account, filters and row unit |
| `observation_time` | When a public reading was taken, or unknown if unavailable |
| `precision` | Whether the number is exact, rounded or of unknown precision |
| `completeness_note` | Missing fields, partial coverage and other limits |

Also save the numeric value, source file name, time zone and any attribution settings. Keep source definitions with the register. These are proposed report fields, not a claim that the collection tool produces this table.

Do not use one date field for different purposes. A reporting period tells you which interval an owner result covers. An observation time tells you when you read a public counter. The file download time does not replace either one.

Preserve missing values when you import files. A blank, an unavailable metric and a recorded zero must remain distinct. If a file gives no time zone, record that gap instead of choosing one silently.

Keep rounded values marked as rounded. More decimal places in a spreadsheet do not make the source more precise.

## 4. Connect ads to posts without copying post totals

A content identity is the identifier for a specific post. An ad identity identifies an advertising record. Keep them as different keys. A key is a value used to find and connect records.

Use three tables:

1. An ad table, with each retained ad record and its owner-source reference.
2. A post table, with one checked record for each public post identity.
3. A mapping table, with the proven connections between ads and posts.

A mapping table lets several ads point to one post without making several copies of that post’s public count.

Connect an ad to a post only when an owner record or a checked source link proves the relation. Similar text, matching pictures or nearby dates alone do not establish the connection. Leave an unproven relation unresolved.

A join is an operation that connects matching records from tables. When two ads connect to one post, a joined view can show the post’s public value twice. This can be useful for inspection, but it is unsafe as a source for a public total.

Calculate public totals from the distinct post records at the selected observation time. Distinct means each checked post identity appears once. Calculate ad results from the compatible owner records. Do not remove a valid ad record merely because it shares a post with another ad.

Also check whether an owner file already includes summary rows. Keep a summary separate from the detail rows used to produce it.

## 5. Add a public snapshot only when it helps

A snapshot is a reading taken at a specific time. Public snapshots can add context to the owner report, but they do not replace it.

The [Facebook Metrics Scraper contract, checked October 25, 2026; documented fields, no runtime test](https://api.apify.com/v2/acts/chronometrica~facebook-metrics-scraper/builds/default) documents public counters and content identities. It does not supply an owner paid and organic delivery split, reach or spend. Reach is a measure of the audience reached under a source’s definition. Public action counts do not establish that audience.

For a proposed check of one known public post, use this small input:

```json
{"maxItems":1,"mode":"knownUrls","startUrls":["https://www.facebook.com/reel/2645452435840671"]}
```

5. Add a public snapshot only when it helps

Replace the sample Facebook URL with the public content URL you have checked. The sample is not evidence about your campaign. `knownUrls` selects direct content URLs through `startUrls`. `maxItems` limits the number of metric rows. The supplied input has a valid documented shape; no run was made for this guide. Facebook Stories URLs are not supported by the checked contract.

For each collected public reading, retain:

1. `contentId` and `contentUrl` to identify the content.
2. The available counters, with their original names.
3. `contentMetricStatus`, which records each counter’s status, precision and source details.
4. `status` and `statusReason`, which describe the row’s collection result.
5. `scrapedAt`, which records the observation time.

A number alone is insufficient. Read its status and precision before you use it. Keep an unavailable counter missing. Do not turn it into zero.

The input schema says `includeFailedRows` defaults to false. Under that setting, failed, invalid and no-public-metric rows are counted in the run summary but are not added to the dataset. Compare your requested content list with the available results. An absent dataset row does not prove a post had no activity.

The tool collects public data. You must build the mapping, source register and reconciliation report separately. Reconciliation means checking whether source results can be compared or combined.

## 6. Check compatibility before you do arithmetic

Two numbers can look related and still answer different questions. Check compatibility before you compare, add or subtract them.

| Check | Question to answer |
| --- | --- |
| Identity | Do the values refer to the same checked content? |
| Metric | Do their exact labels and definitions match? |
| Unit | Do they count the same kind of action or audience? |
| Window | Do they cover compatible dates and time zones? |
| Scope | Do their accounts, delivery labels and filters match the question? |
| Precision | Are they exact, rounded or unknown? |
| Coverage | Are all required records present? |
| Overlap | Can the same action or person occur in both values? |

An owner period metric covers a defined interval. A cumulative public counter is the total shown at the observation time. The public total can include activity outside the owner reporting period. Checking both on the same day does not make their windows equal.

Keep reach separate from action counts. Even if you have paid reach and organic reach, the audiences can overlap. Do not add them and call the result unique people. Do not subtract one from a public action counter to invent the other.

A public count also does not establish whether a post received paid support. Use owner evidence for that question.

If you need a public response rate, use the separate [guide to Facebook engagement rate without admin access](/en/articles/facebook-post-performance-public-data/). It covers a different calculation. Keep that calculation outside this delivery reconciliation.

If you need changes between public readings, use the [guide to Facebook post metric history](/en/articles/facebook-post-metrics-history/). A current snapshot cannot supply a missed past reading or a paid and organic split.

## 7. Work through one careful example

Original fiction; no actual campaign results. This example shows record handling and source limits. It does not describe a collection run.

Two ad rows, AD1 and AD2, map to one public post, P1. The available sources support three facts:

| Source | Supported value | Unit and scope |
| --- | --- | --- |
| Owner paid report | 40 | Paid period interactions under its saved definition |
| Owner organic report | 70 | Organic period interactions under its saved definition |
| Current public P1 snapshot | 100 | Public cumulative likes at the observation time |

Keep two ad records, one post record and two mapping links. The paid source supports a reported value of 40. The example does not supply a split of those interactions between AD1 and AD2. Do not invent that split or copy 40 into both ad rows as their individual result.

Now consider the public count. A joined display might show P1 beside AD1 and again beside AD2. Summing that display would give:

100 likes + 100 likes = 200 likes.

That arithmetic repeats the same post observation. The public section must show 100 likes once for P1.

The paid and organic interaction labels also differ from the public-like label. Subtracting the numbers gives:

100 − 40 = 60 numerically.

It does not give 60 organic likes. The calculation mixes cumulative public likes with paid period interactions.

Likewise, 40 + 70 = 110 numerically, but the supplied definitions do not establish a valid combined interaction result. Nor does 110 need to equal P1’s 100 public likes. They are different source facts.

The supported decision is to report 40 paid period interactions, 70 organic period interactions and 100 public cumulative likes separately. Request compatible definitions and windows before you attempt a combined result.

## 8. Present separate results and an unresolved-items log

Build the report around the facts each source supports. Each section should state its source, metric, period or observation time, scope and completeness.

The paid section contains compatible owner paid results. The organic section contains compatible owner organic results. The public section contains each selected post observation once. Label public values as public counts, not organic results.

Show unresolved differences in a reconciliation log:

| Issue | Current decision | Next evidence needed |
| --- | --- | --- |
| Paid source is absent | Mark paid result missing | An authorized owner report for the requested scope |
| Ad-to-post relation is unproven | Leave the relation unresolved | An owner record or checked source link |
| Interaction definitions differ | Keep values separate | Exact definitions for both metrics |
| Owner period and public window differ | Show separate results | Evidence for a compatible comparison |
| Public counter is unavailable | Keep the value missing | A valid reading with its status |
| Public value is rounded | Keep the precision note | A more precise source if the decision requires it |

A difference alone does not prove a delay, error or missing activity. Record what differs and what evidence would resolve it. If the required evidence remains unavailable, keep the limitation in the report.

Do not force the three sections to agree through an adjustment row. An unexplained adjustment hides the evidence gap.

## 9. Check the complete report before release

Accept the report only after these checks pass:

1. Every displayed value traces to an original source record.
2. Every combined total uses compatible units, periods and scope.
3. Every ad-to-post link has evidence.
4. Each public post observation contributes once to its public total.
5. Ad detail rows and owner summary rows do not duplicate results.
6. Missing values remain distinct from recorded zeros.
7. Rounded values retain their precision limits.
8. Counts of actions are not described as counts of people.
9. Missing paid or organic facts remain visible.
10. Each unresolved issue states the next evidence needed.

These checks support a report whose values can be checked against their sources. They do not establish sales attribution, advertising return or a universal performance benchmark.

The next decision depends on the unresolved item. Request owner evidence for a missing delivery fact. Check a source link for an uncertain identity. Keep separate results when definitions remain incompatible.

## Put the method into use

Start with the owner’s available files. Define the requested paid and organic facts, save their source labels, and prove the ad-to-post connections. Build the separate report sections before you attempt a combined result.

If a current public reading helps, use the [Chronometrica Facebook Metrics Scraper, documented contract checked October 25, 2026; no run verified](https://apify.com/chronometrica/facebook-metrics-scraper) for that limited collection step. Preserve the content identity, observation time, metric status and precision. Then add the reading once to the public section. Keep the owner reports as the evidence for delivery type.

## Sources

- [Facebook Metrics Scraper default build 1.1.26 and supplied README evidence, checked October 25, 2026; static input and output documentation, no runtime test](https://api.apify.com/v2/acts/chronometrica~facebook-metrics-scraper/builds/default)
- [Facebook Metrics Scraper public product page, supplied evidence checked October 25, 2026; documented public collection fit, no paid or organic delivery split](https://apify.com/chronometrica/facebook-metrics-scraper)
- [Facebook + LinkedIn Organic & Paid Analytics, retrieved August 11, 2026; one public question, excerpt concerns LinkedIn, no demand estimate](https://www.reddit.com/r/AskMarketing/comments/1on84z9/facebook_linkedin_organic_paid_analytics/)