Analytics screens are usually written to look complete. This one is going to be described honestly instead, because a dashboard that implies a measurement it does not actually make is worse than no dashboard: people plan against it, report from it, and find out in a meeting that the number meant something else entirely.

So the structure of this guide is deliberate. First, what the screen contains and how its controls behave. Second, which of those numbers are real today. Third, how to get genuine value out of the parts that are real, which is more than it sounds.

The layout

The analytics screen has four layers, top to bottom.

A filter row at the top: a pill group for the date range — 4 weeks, 8 weeks or 12 weeks — and a dropdown for the platform, defaulting to All platforms.

A row of three KPI cards: total engagement, posts published, and a third headline figure that summarises the period. Each animates its count up from zero when the page loads, which is a visual convention rather than an indication that the data is being computed live in front of you.

Two charts side by side: posts per week, and an engagement trend described as likes plus comments plus shares across all channels.

A breakdown below: best-performing week, and followers by platform as a bar comparison.

Everything on the page is filtered by the two controls at the top, and both controls work the same way regardless of which number you are looking at.

How the filters actually behave

The range pills are a client-side slice. The page fetches the full trend from the server once, then keeps the last 4, 8 or 12 weeks of it depending on which pill is active. That has two useful consequences: switching ranges is instant, because nothing is refetched, and the same underlying data backs all three, so a week that appears in the 4-week view is the same week that appears at the right edge of the 12-week view.

The platform dropdown filters both the summary and the trend by network. Its options are populated from the platforms present in your trend data, so it lists what you have actually published to rather than all fifteen platforms PostHub supports. Choosing a platform narrows every card and chart to that network; switching back to All platforms restores the aggregate.

One subtlety: because the range is a slice of fetched data, changing the platform does not change how many weeks are fetched. If you have been publishing for three weeks, the 12-week view shows three weeks and then stops. Empty space on the right of a chart is history you do not have, not a period where nothing happened.

What is real

Posts published is real, and it is the most trustworthy number on the page. It counts posts that reached published status, scoped to your account and to the platform filter. If the card says 34, thirty-four posts went out.

Posts per week is real for the same reason: it is a grouping of your own publishing history by week, filtered by the controls above it. This chart answers the only question a scheduling tool is uniquely positioned to answer — are we actually shipping?

Best performing week, as it relates to volume, is real. As it relates to engagement, see the next section: it is computed from engagement values that are not yet populated, so a "best week" derived from engagement will simply be empty until they are.

Your own post history — which posts, on which platforms, at what times, with what status — is real everywhere it appears, including in the queue, the calendar and the post detail pages.

What is not real yet

Total engagement, likes, comments and shares are recorded as zeros. When a post publishes successfully, an analytics row is created for it with zero values across the engagement fields, and this build does not yet run the job that goes back to each platform to collect the numbers afterwards. The result is that the engagement cards read zero, the engagement trend is a flat line, and best-performing-week has nothing to rank.

Followers by platform is in the same state. The connected-account record stores a follower count, and for accounts connected through the normal flows that value starts at zero and is not refreshed from the platform.

This is not a display bug that will be fixed by refreshing or by connecting a different account. It is a data source that has not been wired up yet, and the honest way to handle it is to say so rather than to leave a zero on screen that looks like a measured result.

The distinction matters most in a reporting context. A screenshot of this dashboard today tells a colleague that engagement is zero, which is not true — engagement exists, it simply is not being collected. If you are reporting to someone this week, report on publishing volume and use the platform's own native analytics for engagement; they are the source of truth for those numbers regardless of what any aggregator shows.

What to do with the numbers that are real

A dashboard with one reliable axis still tells you something important, because cadence is the variable a scheduling tool controls directly.

Are we posting at all? Posts per week with a flat line at zero is the single most actionable chart in the product. Not because zero is bad, but because it is unambiguous: nothing went out. Compare that against the intention you set when you built the calendar and the gap is immediately visible.

Is the rhythm consistent? A spike of twelve posts in one week followed by two weeks of nothing is a different problem from a steady four a week, even though both average out the same over a month. The weekly view makes the shape visible, and the shape is what an audience experiences.

Where are the gaps? Filter to a single platform and look at its line. A network you intended to post to three times a week showing a bar every other week is a scheduling failure, not a performance problem, and the fix belongs in the calendar.

What is the ratio of drafts to published? If drafts accumulate while published stays flat, the bottleneck is review or scheduling rather than writing. The queue's status filters give you this in one click and are a better tool for it than the analytics page, but the effect shows up here as a flat published line.

Is the platform mix what you planned? The platform filter is the quickest way to check. If the plan was 40 per cent LinkedIn and the filtered counts say something else, you have found a deviation while there is still time in the month to correct it.

That is a genuinely useful set of questions, and none of them requires an engagement number.

Using the range control properly

The three ranges answer three different questions and picking the wrong one produces a confident wrong answer.

4 weeks is the operating view. It is recent enough that the data reflects what you changed, and long enough to smooth out a single quiet week. Use it when you are deciding what to schedule next.

8 weeks is the default and the right one for a fortnightly review. It shows whether a change you made two months ago stuck, which is about the shortest period over which a content habit can be said to have held or not.

12 weeks is the planning view. Use it when you are deciding whether the overall approach is working — not whether this week's post did well, but whether a quarter of publishing produced a rhythm you can sustain.

A common mistake is reading the 4-week view as a trend. Four weeks of a slowly changing habit is noise; four weeks of a spiky one is a single decision repeated. If you find yourself drawing a conclusion from the shortest range, widen it and see whether the conclusion survives.

Where to get the engagement numbers today

Until the sync lands, three sources cover the gap, in descending order of usefulness.

The platform's own analytics, opened per network. Instagram's insights, LinkedIn's analytics, X's analytics, YouTube Studio. Each is authoritative for its own data and each takes about a minute per network.

The post-level links on your published posts. Where a platform returns the URL of what it created, the post detail carries it, so you can open the real post and see its real counters.

Native screenshots in whatever document you report from, labelled with the platform and the date. This is the least elegant option and the most defensible one in a meeting, because it carries its own provenance.

The comparison of these three against the dashboard is exactly what the metrics guide in this journal covers in depth — which numbers map to outcomes and which flatter them. The short version: reach and engagement from the platform are measured, and any number you have not seen in the platform's own interface should be treated as unverified.

What the sync will add

When the metrics job is connected, the same screen gains three things without changing its layout.

Engagement rows stop being written as zeros and start being updated from each platform on a schedule, so the engagement cards, the trend chart and best-performing-week become live.

Follower counts on connected accounts start being refreshed, so the followers-by-platform bars gain real heights and the platform comparison becomes meaningful.

Historical posts get backfilled for the period the APIs allow, which means the charts become more than a record of the last few days.

The design intent is that the screen does not change shape, only fills in — so the habit of opening it weekly is worth building now, before there is more on it.

A weekly routine that works today

Five minutes, once a week, using only what is real.

Open analytics on the 4-week range and read posts-per-week. Did the week just ended produce what you scheduled? If not, find out why by looking at the queue's failed filter before assuming it was a writing problem.

Switch the platform dropdown to each network you publish to and note which lines are flat. A flat line on a network you intended to use is a scheduling gap.

Open the calendar for the coming week and check that something is actually scheduled on the days it should be. The analytics page can only describe the past; the calendar is where you fix the future.

Look at drafts in the queue. Anything that has been a draft for more than a week is either going to be written or going to be deleted — decide which, because an ever-growing draft pile is the most common cause of a flat published line.

Record one sentence about what you changed. That note is what turns next week's chart into a comparison rather than a fresh number.

Questions this screen cannot answer

It is worth being explicit about the boundary, so that nobody reaches for a chart that is not there.

It cannot tell you which post performed best, because engagement is not populated.

It cannot tell you how many people saw anything, because impressions are not populated.

It cannot tell you whether your follower count is growing, because follower counts are not refreshed.

It cannot compare this quarter with last quarter if you have only been publishing for three weeks, because there is no data before that.

It cannot attribute a sale or a signup to a post, because nothing in this build joins publishing to outcomes. If you need that, you need a tracked link in the post and analytics on the destination — which is a measurement discipline rather than a dashboard feature.

Knowing what a tool cannot tell you is as operationally valuable as knowing what it can, because it stops you from making a decision in a vacuum and later blaming the chart.

When something looks wrong

The page shows an error banner. The trend or summary request failed. Reload; if it persists, the API is returning an error and the message in the banner names it.

All numbers are zero and you expected activity. Check the platform filter first — a filter left on a network you do not publish to empties everything. Then check the range: a 4-week window with no posts in it is possible if you have just started.

A platform is missing from the dropdown. The options come from the trend data, so a network with no published posts has no option. Publish something there first.

The numbers disagree with the queue. They should not — both read the same posts — but the range and platform filters are the usual explanation. Set analytics to All platforms and 12 weeks and compare against the queue's published filter; if they still disagree, that is worth reporting with both screenshots attached.

Where every number comes from

It is easier to trust a number — and to spot a wrong one — when you know the path it travelled. Every figure on this page has a short and explainable journey.

Posts published starts as a row in the posts table with a status of published. The status only changes when the publish operation returns a success, so a post that failed on every network never increments this count. Filtering to a platform re-runs the same query with an additional condition on the network, which is why the filtered total always adds up correctly across the individual platforms.

Posts per week takes that same set of rows and groups them by week, using the time the post was published rather than the time it was drafted or scheduled. This distinction matters more than it sounds: a post written on Sunday and published on Monday belongs to Monday's week. If you batch-write at the weekend and schedule across the following week, the chart reflects the publishing week, which is the one that matters for cadence.

Engagement is stored per post in an analytics row that is created at publish time with zero values. Those zeros are what the cards read today. When the metrics job connects, it will find rows where the collected fields are still zero or stale and update them in place — the chart is not rebuilt from scratch, it is filled in.

Followers live on the connected-account record. That value is written when the connection is authorised and refreshed only by the metrics job. Until it runs, the bars reflect whatever was captured at connection time, which for a fresh account is zero.

Knowing this explains three behaviours that otherwise look like bugs. A platform with no published posts contributes nothing to the chart because there are no rows to group. Switching ranges does not refetch because the grouping happens after the fetch, on the client. And a post that is edited after publishing does not change its position on the chart, because the chart keys off publish time, not edit time.

Four shapes of line and what each one means

Once you accept that only volume is measured, the posts-per-week chart becomes surprisingly diagnostic. Four patterns account for almost everything you will see.

A flat line at zero across all platforms. Nothing is publishing. The cause is almost always upstream of analytics: nothing was scheduled, the scheduler is not running, or every scheduled post failed. Check the queue's scheduled filter first — if the queue is empty, analytics is telling you the truth about an empty calendar, and the fix belongs in day five of the first-week guide.

A line that rises then stops dead. The classic pattern after an enthusiastic start. Something changed in week three: the batch session stopped happening, or a connected account expired and every post since has been failing silently in the queue. The queue's failed filter resolves this ambiguity in one click.

One platform flat while others move. You are publishing, but one network has quietly dropped out of the plan. Filter to that platform and look at its most recent posts. If they are failing, it is a connection problem. If there are simply none, it is a scheduling gap — the calendar has no entries for that network.

A steady line that still feels too low. Volume is fine, so the problem is not cadence. Either the cadence was set too low to begin with — three a week is not twelve a week, whatever the plan said — or the posts are going out but not doing anything, which is an engagement question the platform's own analytics must answer.

The value of separating these four is that they have four different owners. Zero is an operations problem, a stop is a habit problem, a flat platform is a connection or calendar problem, and a steady-but-low line is a strategy problem. Analytics that cannot distinguish them invites you to fix the wrong one.

Comparing this dashboard with platform-native analytics

Sooner or later somebody puts the two side by side and the numbers disagree. They usually disagree correctly, because they are measuring different things.

Native analytics counts everything the platform saw — every impression, every like including ones from people who do not follow you, every view from the moment of publication. This dashboard counts what PostHub knows: what it published, and eventually what the platform reports back for those specific posts.

Windows differ. Most native tools report on a rolling period that starts at midnight in the platform's own timezone or the account's configured timezone. This dashboard buckets by calendar week on your server's clock. A post published at 11:50 pm can land in different buckets in the two systems.

Coverage differs. Native analytics covers every post on the account, including anything published by hand, from the mobile app, or by a colleague. This dashboard covers only what went through PostHub. If half your publishing is manual, the two will never agree on volume.

Definitions differ. Reach on one network is accounts that saw the content; impressions on another is total deliveries, which counts the same account twice. Engagement on one includes shares and saves; on another it stops at likes and comments. Engagement rate has at least four common denominators — followers, reach, impressions, and accounts engaged — and two dashboards using different denominators can both be right.

The practical rule: use this dashboard for what you published and when, use native analytics for how it performed, and never present the two as the same measurement. If a report needs engagement, take it from the platform and say which platform and which window it came from.

Computing engagement rate by hand while the sync is pending

If you must report engagement this month, compute it yourself from the platform's numbers rather than leaving a zero on the page. The formulas that survive scrutiny are the short ones.

Per-post engagement rate against reach. Add likes, comments, shares and saves for the post, divide by the reach of that post, multiply by one hundred. Reach is the better denominator because it measures the people who could have reacted, not the people who follow you.

Per-post engagement rate against followers. The same numerator divided by follower count at the time of posting. This is the number many agencies ask for, and it is the one most likely to flatter a small account with a large following — or to punish a large account whose post was shown to a fraction of its audience.

Weekly account engagement rate. Total engagement across the week's posts divided by total reach across the same posts. Aggregating first and dividing second is the version least distorted by one outlier post.

Pick one formula, write it in the report's footnote, and use it every month. The most common reporting failure is not a wrong number, it is a number whose definition changed between slides.

For the deeper version of this — which metrics map to business outcomes and which only map to vanity — the metrics guide in this journal covers it in detail.

Screen by screen: which page answers which question

Analytics is one of six places where a question about your account can be answered, and using the wrong one wastes time.

Should this go out today? The queue. Filter to scheduled and read today's list. The queue is the operational truth about what is pending, what went out, and what failed.

What is planned for next week? The calendar. It is the only screen that shows intent rather than history, and the only one where you can see three empty days at a glance.

Why did a post not publish? The post detail, opened from the queue. The error text is there, per platform, in full — not summarised into a status colour.

Can I publish this right now? The composer, where the character counter and the cost chip respond as you type. Nothing else in the product validates content in real time.

Which platform is connected correctly? Connected accounts, plus the config check. Analytics says nothing about connection health; a platform can be disconnected and still appear as an option in the dropdown.

How much have we published? Analytics, on the 12-week range with no platform filter. That is the only screen that aggregates history rather than showing it as a list.

A useful habit: when a question comes in from a client or a manager, name the screen that answers it before answering. Half of all reporting friction is someone reading a number from a screen that measures something else.

A monthly report built entirely from real numbers

You can produce a defensible one-page report today without a single placeholder value. The structure that works:

Period and cadence. The date range, then posts published, then the weekly average. One line: "Published 14 posts between 1 and 28 September, an average of 3.5 per week." Every figure here is measured.

Platform mix. The same total broken down by network, as counts and as percentages. If the plan called for 40 per cent on one network and the actual was 22 per cent, say so. Deviations you name yourself are findings; deviations someone else discovers are surprises.

Consistency. The busiest week and the quietest week, in numbers. A month with a range of one to seven is a different month from one with a range of four to five, even at the same total. This is the sentence most reports omit and the one that explains the most.

What was learned. One or two sentences tied to something you changed during the period. Not a metric — a statement. "We moved the blog post from Monday to Wednesday and volume held." This is the line that makes the next month's report useful rather than repetitive.

Known gaps. One sentence stating that engagement and follower metrics are pending the metrics sync and that engagement figures in this report come from the platform's own interfaces, named per platform. Stating the gap converts a weakness into a method note, and it protects you when someone asks why the numbers moved later.

That is four sentences of data and three of context. It fits on one page, every figure in it can be defended, and it takes about fifteen minutes a month to produce.

Accessibility and performance notes

The count-up animation on the KPI cards and the fade-in on the charts are there because a dashboard that jumps from blank to full is harder to read than one that lands. The numbers themselves are not being calculated during the animation — the final value is already known, and the animation interpolates towards it.

The page shows skeleton placeholders while the trend request is in flight, so an empty screen never looks like a zero. If you see skeletons that never resolve, the request is failing rather than slow, and the error banner will name the failure once it is reported.

The range pills and platform select are native controls with visible focus states, so the whole page can be operated from the keyboard. If a control appears to do nothing, check whether the request failed first — a filter that changes without a corresponding data change is the tell.

Questions worth asking before you change anything

A dashboard invites action, and most of the actions it invites early on are wrong. Before you adjust the calendar based on what you have read here, three tests:

Is the sample big enough? Four weeks of a three-post-a-week habit is twelve posts. Twelve posts cannot tell you whether a topic works. It can tell you whether the habit holds, which is the question worth asking at that stage.

Did something else change at the same time? A new product, a seasonal shift, a platform algorithm update. If three things moved at once, the chart cannot attribute the change, and acting on it will usually make things worse rather than better.

Is the gap in publishing or in results? Volume problems are fixed in the calendar. Performance problems are fixed in the content. They look similar from a distance and require completely different fixes, and this screen is specifically built to tell them apart.

Change one thing at a time, give it a full range's worth of data, and write down what you changed. The note you leave for next month's reading is the difference between a chart you look at and a chart you learn from.

How fresh the numbers are

Analytics pages are read as if they were live, and this one has a specific freshness model worth knowing.

Posts published updates as it happens. The count comes from the posts table, which changes the moment a publish succeeds. If you publish something and refresh, the number moves — there is no batch job standing between the event and the chart.

Weekly buckets are stable once the week is over. A post belongs to the week in which it was published, so last week's bar does not move when you publish today. The current week's bar, by contrast, will keep growing until the week ends, which makes it a poor thing to compare against a completed week. Compare like with like: last week against the week before, not this week against either.

Engagement and follower figures are as stale as the last sync — which, today, is to say they are placeholders rather than measurements. When the metrics job connects, that freshness becomes a real property with a real interval, and the page will be worth reading twice a day rather than once a week.

Filtering does not refetch. Switching between 4, 8 and 12 weeks and between platforms re-reads the same fetched dataset, so the numbers will not shift underneath you while you compare. The one thing that does cause a change is reloading the page, which fetches again and picks up anything published in between.

The practical rule: if you are about to quote a number from this screen, reload first so that the quote reflects the current state, and say which range and platform filter you had selected. Two numbers from the same page with different filters are different measurements, and most reporting confusion comes from the second one being unlabeled.

The short version

Posts published and posts per week are real and are the numbers worth planning against today. Engagement and follower figures are placeholders until the metrics sync is connected, so treat them as pending rather than as measured, and use the platform's own analytics for reporting in the meantime. Use the range pills for operating, reviewing and planning respectively, use the platform filter to find the networks that have gone quiet, and use the calendar — not the chart — to fix what you find.