The DigitalShyft client portal added OpenAI Ads reporting, Core Web Vitals measured from a real page render, site audits that read every written page instead of a 25-page sample, and landing-page performance on the Search tab. Every client account has them now, whether or not the underlying platform is connected yet.
ChatGPT advertising now reports beside Google, Meta and LinkedIn
OpenAI opened advertising inside ChatGPT, and a fourth ad platform is exactly the kind of thing that quietly ends up in a separate tab nobody opens. So it went where the other three already are: spend, impressions, clicks, click-through rate, cost per click and CPM, with a daily chart, on the same Ads tab as Google, Meta and LinkedIn.
That matters more than the platform count. The question worth answering is never "how did OpenAI Ads do" — it is "which of these four produced the cheapest qualified lead this month", and you cannot ask that across four browser tabs and three export formats.
A note on honesty: OpenAI reports differently from the others. It omits zero-valued metrics from its responses entirely rather than returning them as zero, and it names the column after the segment type rather than the segment. Reading it wrong produces plausible-looking numbers, which is worse than an error, so we verified the figures against the platform before shipping.
Where the budget actually went
Every ad platform now breaks its delivery down as a share of impressions, along whichever axes its own API reports: device and network on Google, placement, platform and audience on Meta, device, country and product on OpenAI, and the professional make-up of who saw them on LinkedIn. Not a table of everything — the split that tells you whether the spend went where you meant it to go.
This is the difference between knowing a campaign cost $158 and knowing that 95% of its impressions went to mobile. The first is accounting. The second changes what you build next.
Speed, measured the way a visitor meets it
The portal used to report server response time and call it "Speed". Server response time is a real number and it is not the one that matters: a server can answer in 90 milliseconds and still leave a visitor looking at a blank screen for four seconds while fonts, scripts and images resolve.
It now measures Core Web Vitals from an actual render — largest contentful paint, cumulative layout shift, first contentful paint, total blocking time and speed index — with the thresholds printed beside each one, so "2.9s" arrives with "good is under 2.5s" next to it rather than requiring you to know the benchmark.
Nine measures across every page sampled, tracked over time like everything else. Speed is not a one-off audit line; it drifts every time someone adds a plugin.
Audits that read the pages you can actually rewrite
The old audit spread its budget evenly across a site’s sitemap sections. That sounds fair and is not. On one client site a 40-page budget bought 14 of their 75 real pages and 13 of their 603 blog posts — sixty-one pages someone had written on purpose, and could edit tomorrow, had never once been audited. The report still said "25 pages sampled of 488" as though that were a survey.
It now takes every section but the largest in full — the service, location and about pages — and samples the largest, which is almost always the blog. The blog sample is evenly strided rather than the first N, because sitemaps are usually newest-first and taking the head would audit one recent month and call it the archive.
The findings name the pages, too. "12 pages missing a meta description" is a statistic; the list of which twelve is a morning’s work.
The rest of it
Landing pages joined queries on the Search tab, so you can see which pages earn the clicks rather than only which searches do. Our own content queue reflows into cards on a phone, which means a deliverable gets approved and sent while someone is standing in a car park rather than waiting for them to be back at a desk. A handoff tracker shows the status of work moving between teams where the client can see it, rather than in a project tool they do not have a login for.
There is a separate intake for website builds, because a design and e-commerce engagement needs different answers from an analytics one, and asking a client for a GA4 property ID when they came for a new site is a good way to look like you were not listening.
And the portal now notices when its own data goes quiet. If a sync stops writing, an alert fires rather than a chart quietly flatlining at zero and everyone assuming a bad week. That one exists because a pipeline did stop, for three days, and nothing said so.
Why one dashboard rather than nine
Thirteen platforms feed the portal now — analytics, search, four ad networks, session behaviour, rankings, speed, email, social, accounting, and our own audit engine. Eighty-one distinct measures, a thousand series with history behind them.
The reason to put them in one place is not tidiness. It is that every one of those platforms has its own idea of what a session or a conversion is, and until they are normalised into a single shape nobody — human or otherwise — can reason across them. That is the whole point: one schema an assistant can read end to end, so the question "what should we do next month" gets answered from all the evidence at once instead of one tab at a time.