What this shows

Your own last 60 days (articles, pageviews, average SEO score and top performer), your slice of the ClickUp editorial board, unclaimed stories on Story Radar, and your recent drafts.

Where the data comes from

Figures come from the article feed in BigQuery, matched to your byline. Planning comes from ClickUp, desk items and drafts from Firestore.

What it does not tell you

Nothing on this page is site-wide. Every figure is scoped to you, so a quiet week here is not a quiet week for designboom. Until an article carries your byline the stat tiles stay empty rather than reading zero.

What this shows

Your seasonal accounts from Comebacks (brands you own in Salesforce that bought around this point in an earlier year and have not come back yet) and your Case Studies outreach drafts, including any a colleague handed to you.

Where the data comes from

Account ownership is the Salesforce opportunity owner, read from the snapshot Comebacks runs on; the snapshot date is printed with the figures. Drafts are yours because you saved them or were handed them.

What it does not tell you

Nothing here is the whole book. Comebacks itself shows everyone's accounts, because reps cover for each other. If you own no accounts in Salesforce yet, the tiles stay empty rather than reading zero - that is the data, not a fault.

What this shows

Pageviews to date, first-three-day traction and engagement for the newest articles.

Where the data comes from

Publish date and traffic from the article feed (BigQuery).

What it does not tell you

A piece published today is still gathering views, so read these as early signal rather than a final number. Traffic is daily, so the most recent complete day is yesterday.

What this shows

Three answers. Underperformers ranks articles by how far they fell short of what a typical piece in their category earned at the same age. Chapter winners takes the top three of each chapter by that same gap and reports what they measurably shared. Levers asks the site-wide version: does publishing on a Sunday actually cost us. Ranking raw pageviews would only rank age, which the team already knows — so nothing here is a sort.

Where the data comes from

BigQuery article_daily, through /api/whydesk. Expected value is the median cumulative pageviews of an age-matched cohort — same category, published within a trailing 180 days, minimum 30 articles — over each article's first 14 days. Median, not mean: designboom's distribution is right-skewed enough that a mean baseline marks almost every reader submission as failing. The gap is reported in log space, so 2× under is 2× under whether the baseline is 500 or 50,000. Editors are the attributed editor, not the WordPress byline.

What it does not tell you

The expected value is a cohort median, not a prediction: it says "typical for this category at this age", never "this article deserved this". Cohorts control for category and age and for nothing else — not topic, not the news cycle, not whether a piece was picked up elsewhere, so a genuinely niche subject reads as underperforming. Deltas behind fewer than five articles are observations, not findings, and are labeled as such. Time on site is excluded by decision (~34% populated), social joins about 2% of articles, and word count, image count and publish hour are listed in the coverage footer as considered or unavailable, depending on whether the content table has been built. The coverage footer under every view names what was missing. A site-wide traffic move depresses an article and its cohort together and therefore does not show up here at all; that is Smart Insights' job. The roundup builder and the cannibalization pass are specified but not in this version.

What this shows

The publishing schedule, one row per slot: the time, the format, the section, the topic and the editor. A publishing day runs from 08:00 to 08:00 the next morning, so a 01:55 slot belongs to the previous day's schedule.

Where the data comes from

Entered here by the editorial leads. Absence flags come from the Planner, so an absence only has to be logged once.

What it does not tell you

This is the plan, not the record. It does not yet check what actually published against what was scheduled, and ClickUp remains the record of decided work.

What this shows

A draft schedule per editor, the gaps that absences create, and what it costs to cover them.

Where the data comes from

The draft schedule is built from each editor's real output over the last 90 days, with reader submissions counted correctly. Absences are entered here by hand.

What it does not tell you

ClickUp is the record of what has been decided; this plans the days before that, so nothing here is committed work. For editorial leads and admins. It is no longer in the sidebar; open it from the command palette or #/planner.

What this shows

Write time logged by hand against an article URL.

Where the data comes from

Entered on this page. Nothing is measured automatically.

What it does not tell you

Coverage is only as good as what people remember to log, which is why write time is marked beta everywhere it appears. It feeds the editorial write-time field once linked by article URL.

What this is

A writing desk. The article is the document: headline, standfirst and body, saved as you type and reopenable from any browser. The AI is optional throughout — you can write the whole thing yourself, ask it to rewrite one paragraph, or have it draft the piece from a press release.

Where the voice comes from

The house style, drafting brief and fit rubric saved in the Style Guide. Every AI action applies the live version within a minute of a change.

What it does not do

Nothing here publishes and nothing is fact-checked. A rewrite may cut, reorder and re-voice, but is instructed never to introduce a fact that was not already there. That instruction is written into the server-side prompt, so it cannot be switched off from the browser; it is still an instruction to a model, not a check, and the result is a first draft for a human to verify.

What this shows

Stories from the shared source library. Feeds are checked every hour, every day including weekends: busy sources hourly, quiet ones every few hours, broken ones less often until they recover. Refresh checks all of them now. Pick a window to catch up: since your last visit, the last 24 or 48 hours, seven days, the weekend, or your own dates.

Times

Each story carries three times: when the publisher says it ran, when Radar first saw it, and when its headline or summary last changed. Windows count from when Radar first saw a story, so an old article fetched again never shows up as new.

What stays

Anything someone claimed, shortlisted, noted, snoozed or handed to the Article Lab stays listed whatever its age. Untouched stories leave the queue after 30 days and are removed after 180.

What it does not tell you

This is what other publications ran, not what designboom ran. A related designboom article is a match by meaning, not proof that we covered the same story.

What this shows

Pitches from a website, Instagram, a press release, a contributor or an exclusive. Editorial leads and admins review them and plan them in, usually for the next day. An approved pitch becomes a task on the ClickUp editorial board.

Where the data comes from

Entered here and stored against the person who pitched.

What it does not tell you

A planned pitch is not a published article. Planning a day ahead is what makes for stronger stories and a team that can organize itself, but nothing on this page confirms that anything ran.

What this shows

Every capacity-limited designboom product, one row each, against the days of the selected month. Green means free, amber means partly booked, red means full, hatched purple means another product's booking blocks the slot, and plain gray with a dash means the day is inside the production lead time. Click any cell to see exactly what is holding it.

Production lead time

An empty slot is not a sellable slot: it still has to be produced. The standard designboom lab turnaround is 12 working days, so every day before that is shaded as too soon and the “free from” date on each row already accounts for it. It is a minimum, not a quote: a bigger package needs longer. Weekends are excluded from the count, public holidays are not. The 12 working days are pending confirmation on ClickUp from the designboom lab: the banner above the grid says so too, and it should not be quoted to a client as a committed turnaround until the lab confirms.

Where the data comes from

The four ClickUp reservation lists: Editorial & Teaser, Submissions, Banner Campaigns and Paid Social Media. One read is shared by everyone for ten minutes, so the timestamp above tells you exactly how old the numbers are; Refresh forces a live re-read for the whole team. If ClickUp is down you keep seeing the last good read for up to six hours, labeled as such, rather than an error. The capacity limits themselves are the hard-coded rules from the reservation-system spec, not the Google Sheet.

What it does not tell you

It answers whether a slot is free, not whether it is worth selling. Reservations and confirmed bookings both hold a slot. A few products cannot be told apart in ClickUp and are shown merged; admins see every one of them in Notes on the data, under the grid.

What this shows

Prefill the form from a client's web page, email or PDF, drop in one or two source images (every WordPress size is generated for you, crop and fine-tune where needed), generate the Yoast bundle, then assemble a review-ready draft payload. The Tracker tab replaces the Google Sheet: every push logs itself there, deadlines are colored as they approach and pass, and the whole history is searchable.

Where the data comes from

The client sources you supply, plus the tracker records Directories writes as it goes.

What it does not tell you

Directories never publishes, and it does not yet reach WordPress: a push saves the assembled draft here and logs it in the Tracker, and the draft is created in WordPress by hand from the downloaded payload.

What this shows

Paste a requirement in plain language and get back the campaigns that match, with the article, the social posts and what they measured. Pick the ones that fit and it drafts the brief.

Where the data comes from

Every link comes out of our own ClickUp records and every figure out of BigQuery. The model reads your question and writes the summary; it never produces a link or a number.

What it does not tell you

Campaigns run before November 2023 are not in the library, so an empty result means nothing recorded matched, not that nothing comparable was ever done.

The unit is a person, not an RSVP

People sign up with a +1 or a +2, and the form captures those guests as one line of free text with no email addresses. So every RSVP is expanded here into a party of seats: seat 1 is the registrant, the rest are guests with a name and email field that stay empty until somebody fills them at the door. That is what makes the headcount right, and it is why there is a third arrival state — partial, where the registrant came and their guest did not. A single "Attended" checkbox in ClickUp cannot express that.

What is written back to ClickUp

RSVPs only ever flow one way, ClickUp into the newsroom, merged rather than replaced, so a refresh while the form is still filling never wipes a check-in. Going the other way Guest List writes two fields: Attended when anybody in a party arrives, and Checked In with how many of them actually came. Writes are queued and pushed in the background, so ClickUp being slow can never slow down the door.

Door mode is a separate page on purpose

Open /desks/eventdesk/door.html once on the venue wifi before the doors open. That primes its offline cache. After that it runs from a copy of the list held in the browser: search is instant, a check-in is instant, and anything that cannot reach the server queues up and drains when the signal comes back. The header always says whether it is synced, how many changes are waiting, or offline.

Archiving

Archiving freezes a snapshot: the roster, the check-in log and the numbers as they stand. From that moment the event stops reading ClickUp entirely, so the record survives that list being deleted or restructured later. Archived events stay in the picker, read-only, which is what makes one event comparable with the next.

Who can see what

Sales, leaders and admins hold this desk. The CSV downloads are narrower and admin-only, because one file is every attendee's name, email and employer. Email addresses are shown in full in door mode when a row is expanded. Every check-in records who did it and from which device.

Start with Brands

The page opens on Brands because nothing else means anything until you watch a brand. Add the brands you look after; each one is counted across the whole archive straight away. The Feed is the stream of everything we publish, with your brands marked in it.

Where the articles come from

designboom's public RSS feed at designboom.com/feed, polled every 30 minutes. The feed only ever carries the ten most recent posts — about one day of publishing — so this page stores what it pulls and builds an archive rather than reading the feed live. "Refresh feed" pulls it now if you cannot wait for the next poll. Everything before this page was switched on comes from a one-off backfill of the WordPress archive, which is why the oldest article shown may pre-date the first poll.

How a mention is decided

The full article body is searched, not just the headline, and a match has to be a whole word: "Vitra" does not match "vitrine" and "Rado" does not match "Colorado". Add aliases for the other ways a brand is written — B&O for Bang & Olufsen — and each is matched the same way. A brand found in the headline is marked in the accent color, because that usually means the article is about them rather than mentioning them in passing.

Credits, and what counts as one

Click any brand to open its own view: the credit tallies and every article behind them, on one screen. The tiles are filters — click "dedicated articles", "mentions" or "paid articles" to narrow the list under them to just those. Pageviews is a figure rather than a filter. One article that names the brand is one credit, however many times the name appears in it — the same rule print magazines have always used for an editorial credit. Credits split two ways. A dedicated article is one where designboom named the brand in the headline, which is the digital equivalent of a full editorial page given over to them. A mention is the brand named inside the body of a wider story. The window chips filter the tallies and the articles together, so the number and the list can never disagree, and "All time" means as far back as the archive goes — the view says where that starts. The Feed tab shows the newest 60 stored articles; the window chips narrow it only below that.

Adding a brand counts its history, but not instantly

When you add or edit a brand, every article already stored is re-read for it — around 5,700 of them, each a full article body, going back to September 2024. That does not fit in one page load, so the first few seconds happen while you wait and the rest runs in the background: the brand's row says "Counting history" with its progress, the numbers climb as it goes, and you get an email when it is finished. Recent coverage appears immediately; the older years fill in behind it. Editing a brand's name or spellings starts the same count again, because it now matches a different set of articles.

Paid articles, and pageviews

Articles published as part of a campaign are flagged from ClickUp's paid list and are never counted as editorial credits. They are shown, counted and filterable on their own, with the partner name where ClickUp has one, because a credit figure that could quietly include something a brand paid for is useless in the conversation it exists for. Pageviews come from the same traffic table the Performance desk uses, stamped nightly. Our traffic history starts later than the archive does, and the brand view says how many credits have a figure, so anything published before that start shows a dash rather than a number — a dash means we have no figure, where a zero would mean nobody read it, and a partial figure would be worse than either because it would look like an answer while missing the article's launch.

Correcting a credit, and writing to the brand

The matcher reads words and ClickUp keeps the paid list, and both are wrong sometimes: a namesake, a brand in the headline of a round-up that is not about them, a campaign nobody listed. On a brand's view every article has a Not right? control: confirm it, call it a mention or a dedicated article, mark it paid, or say it is not about this brand at all. The tiles and the watchlist count follow the correction, and it is kept per brand and signed with who made it. Write to Vitra (or whichever brand is open) is the outreach card under the tiles, for business developers. It opens the same message panel Case Studies has, pointed at the coverage. You pick which articles to reference and which figures the message may use, add who it is for, pull the company from Apollo, and draft it in your own voice with the links attached from our records. Let the AI do it all does the picking and the lookup for you and drafts in one click; you edit afterwards. The coverage cited is editorial and the message says so; it never offers coverage for sale.

Your brands, and the coverage PDF

The Brands tab opens on the brands you added, with a switch to everyone's and a box to find one by name. Watch three or more and three cards appear above the list: your brands, the ones we mention most, and the ones covered at least three times in the last six months, which are the ones worth writing to. On a brand's own view, Coverage PDF turns the credits into a one-page report in the designboom design system, with the article images and the numbers worth quoting, ready to attach. It carries editorial coverage only and nothing internal.

What it does not tell you

This is designboom's editorial coverage, not the lab's client work — a paid campaign appears here only if it was published as an article. It says nothing about how those articles performed; that is Performance. And the search box scans article bodies live over the window you pick, so it is bounded: put a term on the watchlist to have it counted properly from then on.

What this shows

Every brand with a closed-won designboom deal signed around the selected month in an earlier year, and whether they have booked anything this year. Tier A is the list worth working first: they bought in this window before and have been silent all year. Inside a tier, brands nobody has written to yet come first, then the ones that spent most in this season before. The month dial moves the whole page.

Writing to a brand

Write opens a panel on the right that drafts one email from what the brand booked, the campaigns we made with them (Case Studies), how we covered their work lately (Brand Mentions), and the talking points: what designboom has coming, written by Timo. You can untick any source, pick other talking points, and ask for changes in plain words. Draft in Gmail puts it in your own Drafts and marks the brand as reached out. Nothing is ever sent for you.

Whose brand it is

The Salesforce owner writes to their own accounts. A brand with no owner, or whose owner is no longer on the team, is open to everyone. Anyone else's account is locked; an admin can write on the owner's behalf, and that is logged as an override.

Where the data comes from

Salesforce, every won opportunity with a Designboom product since 2022, as a snapshot pushed in by hand; the date it was taken is printed above the dial, read it before trusting "booked nothing this year". Deals under 1,000 CHF are filtered out. Dates are when a deal was signed: nobody has a contract expiring, these are brands with a habit. "Booked after outreach" appears once a newer snapshot shows a deal signed after the email.

Who sees this

Every BD, leader and admin, since 2026-09-30. Threads carry unreleased pricing and a client's candid reaction to it, so treat them as internal. Only the person who created a page, or an admin, can delete it; everyone can archive.

Two kinds of page

Proposals are the private pages we send to one client. Coverage reports are published from Brand Mentions. Reach overviews, designboom's audience and reach as a page, are listed in Reach Planner. Each tab has cards or a list, a search, filters and a sort, and the address keeps what you picked, so a link opens the same view.

One proposal

Open a proposal to see its key, its page and version history, the reach overview, images, visitors, engagement and comments. Every page a client or reader will see is shown inside a framed preview, exactly as it is sent.

The planner

Pick products from the rate card and a period. Each line shows the forecast the rate card uses and, where the social table has the same channel and format, what that kind of post delivered on average per measured post over that period. The measured figure counts back from the last day in the data and divides by measured posts only.

Reach overviews

The pages we send: the standard one everybody gets, and tailored ones with a client's markets, channels and a forecast. They are the same records Proposals used to list under "Reach overviews"; nothing moved in the database.

What this shows

Add venues by scraping a page, extracting a press release or pasting rows, keep every pin on one controlled schema, then export. Milan Design Week today; Venice and Copenhagen have district lists that still need checking against WordPress before their first guide. The Performance tab pulls the published guide's pageviews.

Where the data comes from

The sources you supply for the pins; pageviews from the article feed. Every partner link is UTM-stamped on export, so a brand can see designboom's referral traffic in their own analytics.

What it does not tell you

This builds the dataset, not the page. Sofia's team writes the intro around the embed, and merging the CSV into the map is a manual step in WordPress. The tool is in the Graveyard since 2026-09-18 and opens from the command palette or #/event-maps.

What this shows

Who is going, when and where, whether it needs overtime, the story you would bring back and the marketing angle.

Where the data comes from

Entered here. The decision is recorded against your pitch.

What it does not tell you

Your assigned reviewer (set per person in the Users panel) or an admin approves or declines, and you get an email either way. Approval here is editorial sign-off only: it books nothing and pays for nothing.

What this shows

Four things. The style guidelines are Sofia's document, which leads everything the AI writes and is kept in step with her Google Doc three times a week; they are not edited here. The codex is the designboom writing document underneath them, held here as rich text: read it, edit it, save a change as a new version and it goes live immediately across the draft writer, SEO and social copy and social tools. Style guide health counts how often what we published in the window broke the countable half of those rules. Suggestions are rule changes proposed from three signals: how editors edit the AI's drafts, how editors correct the fit check, and what the audit keeps finding in published work. Version history keeps every earlier codex one click from live.

Where the data comes from

The active version is stored server-side. The health figures come from a lint that stamps each article as Brand Mentions polls the designboom feed, so they count only rules written down in the codex in so many words: banned words, the structural tells, and the mechanics that are unambiguous. Suggestions are written by the model from real edits and from those counts, never from its own opinion of a piece.

What it does not tell you

A score is a weighted count of rule breaches and nothing else. It says nothing about the angle, the reporting or the connections, which the codex itself says an AI cannot judge. The by-editor table and the editor filter show where the rules are slipping, not who writes well: a compliance count is not a measure of how well somebody writes. The grammar and spelling list comes from a daily AI read of new articles and can be wrong; each line shows the words it flagged. Admins hold this tool; give it to the editor-in-chief and managing editor as an extra tool in Users, since they own the voice. A proposed rule is an observation, not a measured improvement, so nothing applies until someone accepts it.

What this shows

Each item is tagged with who it is for: Everyone, Editors (leads) or Admins.

Where the data comes from

Written by admins on this page, or appended by whoever deployed.

What it does not tell you

You only see the items that apply to your access, so this is your changelog rather than the full one.

What this shows

Every event or activation designboom ran in real life that has a written-up case study on the designboom media hub. The card is the link; it opens the media hub page in a new tab.

Where the data comes from

A list kept by admins on this page (Edit list). Until the first save it shows the two launch case studies, Paris designboom and Room for Dreams.

What it does not tell you

Nothing about the event itself lives here. The numbers, pictures and story are on the media hub page, and whoever that page is shared with can open it; this list only decides what is linked.

What this shows

One row per brand on Brand Mentions. Its tag is the utm_campaign value minted when the brand was added; its website is what a link in the Lab is matched against. Drafts counts the Lab drafts that link to that website, published the ones whose pasted-back published version still links there, and tagged how many of those carry the tag, which says whether the Export button was used or the link was typed into WordPress by hand.

Where the data comes from

Brand Mentions for the brands, tags and websites; the Article Lab's drafts for the links, read from the document as it is saved and from the published version as it is pasted back. Nothing here reads the live site: an article written outside the Lab does not appear.

What it does not tell you

What happened after the click. A UTM tag is read by the brand's analytics, not ours, so this page counts links issued, not visits delivered. Outbound clicks on designboom.com are the next data source for it.

What this shows

Each design is a headline, an optional line and button, and the address it links to. The picture under it changes every day: the newest article header images, one per frame, as an animated GIF in each slot size. The newsletter variant sends readers to the signup page instead.

Where the data comes from

The pictures are the lead images of the newest articles in the designboom feed, or, when Settings say so, a curated set of designboom pictures pasted in by the team, moving on to the next ones each day. The text layer is drawn here, in the site's typefaces, when a design is saved; the server lays it over the day's pictures at 05:45 and on Rebuild now.

What it does not do yet

Put the GIF into the ad slots by itself. Until the site's API for that exists (docs/house-banners-api-spec.md), download each GIF and upload it where the house banners live.

What this shows

Every request from the media kit form on the media hub, newest first, with what happened to it: whether the kit email went out, whether the lead was posted to Salesforce, and how often the person opened their kit. Open a lead to set its status, owner and notes, send the kit again, or delete it for a GDPR request.

Where the data comes from

The form on the media hub posts here. The kit edition follows the country the person picked (CHF for Switzerland and Liechtenstein, GBP for the UK, EUR for the rest of Europe, USD everywhere else); the visitor never sees which. Media kits holds one PDF per edition, and replacing one changes what every new email and every private link sends. Private links are kit links you hand out yourself, without the form.

What it does not do

It cannot tell whether Salesforce created the lead: Web-to-Lead answers the same either way, so Posted means sent. Deleting a lead here does not delete it in Salesforce. Kit opens count every open, including mail scanners that open links on arrival.

What this shows

Every name the loaded feed can attribute an article to, in four groups with a count each: designboom team, designboom lab, past team and not team. A group is what a name currently resolves to, so most people land in one without an entry here at all: any byline ending … I designboom is recognized as staff automatically, the day they first publish, and a bare byline is a guest until somebody says otherwise. Each row still says how it got there - auto → staff, or the list you set it to.

Where the data comes from

This roster, layered on top of the automatic byline-suffix rule.

What it does not tell you

It is a grouped view of the whole feed, but you only need to set the exceptions: people who publish under a bare name, names that should not count as team, and past team whose numbers you want kept but hidden. Setting a name moves it to that group here and re-labels the editor everywhere else; it does not change their articles. The second panel lists roster entries with no article in the window, flat, each row tagged with its group.

What this shows

Everyone who can sign in, in two groups. The second group is read from the Workspace directory, so it is empty until the first sync. People with an assigned role, and people who are simply at @daaily.com and have never been given one — since 9 Sep 2026 those get in on the Team default (Feedback, Image Tool, Brand Mentions, Performance Overview) instead of being turned away. My Page and What's New are still part of that default, but neither is listed in the sidebar any more - both sit in the Graveyard, so a person on the default reaches them only by a direct link. Changing anything on one of those rows assigns them properly. Each row also carries their Google Workspace job title and team, and an activity panel below shows when each person was last here and which sections get opened at all.

Where the data comes from

Sign-in is Google, restricted to @daaily.com. Roles and tool grants are stored by us; names, job titles, teams and whether somebody still works here are mirrored from Google Workspace by the sync button below, which only ever reads. Last seen is stamped by the server on any request, so it counts somebody who opened the app and read a single page. Opens are posted by the app when a section is opened, and cover the newsroom and Lightbox.

What it does not tell you

The role sets which tools they see; open Tool access on a row to grant extras. Tools that come with the role are ticked and locked, so add rather than untick. The sidebar changes on their next page load; the API honors it at once. A row marked asked for a role is somebody who answered the first-login setup and is still on the Team default; open the row and Approve assigns exactly what they asked for. Remove deletes the assignment — for a @daaily.com address that drops them back to the Team default rather than locking them out; Block is what actually revokes. Opens start on 25 Aug 2026 — anything before that is unknown rather than zero — and an open is not time spent.

What this shows

The turnaround we commit to, a scoreboard of who has been reporting (names and tallies only), and your own notes with any reply. Admins additionally see every note, collapsed, with the kind, how urgent it was marked and which page it came from, and can reply and mark it resolved.

Where the data comes from

The Feedback button in the header of every page. Lightbox has its own separate queue and scoreboard; nothing sent there appears here, and nothing sent here appears there.

What it does not tell you

Nobody but an admin can read anybody else's note - the scoreboard carries no message text at all. The person who sent it sees your reply in their notification bell next time they load the app, so a reply is not a message and does not email anyone. Anything that comes back can be reopened. Admins are left off the scoreboard on purpose: the biggest award is for a note that got resolved, and whoever hands that out cannot also be ranked by it.

What this shows

One document per tool: what it is for, how it works step by step, where its data comes from and how to read it, what it connects to, and its limits. Every document ends with the questions people ask about it. Under each document, anyone can post a question, feedback on the text, or an idea for the tool itself; admins reply in the thread.

Where the data comes from

The documents are written by hand from the code and the specs, and live in the repository next to the writing codex. The "Ask the guide" box hands your question and the most relevant documents to Gemini, which may answer only from them. Every question and answer is kept, with whether it could be answered, so the gaps show up.

What it does not tell you

The guide explains mechanics, not your numbers: it cannot look at the data behind a page, so "why did my article drop" is a Hindsight question, not a guide question. An answer is only as current as the document it came from; the date on each document says when it was last checked against the code. If the guide says it does not cover something, believe it, and leave a comment so it can.

What this shows

A CSV upload used to test the reporting path.

Where the data comes from

Whatever file you upload.

What it does not tell you

This is a testing path only. The production route is a direct BigQuery connection, the Connected Sheet to BigQuery table this demo is shaped from, so nothing imported here reaches the live article feed.

What this shows

Thirteen house formats, from the 1800 px header to the Instagram story, plus any custom size you define, each a size-checked JPEG.

Where the data comes from

The source image you upload, or a picture picked from an article link, rendered server-side. Files are kept in the shared library for 60 days and served from an unlisted link that needs no sign-in.

What it does not tell you

A source too small for a given format is rejected for that format and still produces the others, so check the rejects before you use the output. A refused format can be forced with Generate anyway, which will be soft, or extended by a model, which is badged with the share it invented. It generates files; it does not attach anything to a WordPress post.