How to read the new INP grouping in Search Console before closing your December campaign

Growth teams in Brazil have learned to treat Core Web Vitals (CWV) as a prerequisite for paid media investment: a slow page worsens the post-click experience, which weighs on Google Ads' Quality Score and inflates cost per click right during the most expensive period of the year. The problem is that many people read the Search Console Core Web Vitals report as if it were a linear scoreboard, when it's actually a grouping with specific rules. Google's official documentation (Search Console Help, in the article "Core Web Vitals report") makes explicit how this calculation works, and that's where the risk lies in misinterpreting performance drops before closing the December budget.

The group's status is always the worst metric

The central point that goes unnoticed: the report doesn't show the average of your metrics or a consolidated score. It classifies each group of URLs by status (Poor, Need improvement, Good), and the inherited status is that of the worst-rated metric. In the documentation's own words, "the status of a URL group is, by default, the slowest status assigned to it for that device type."

In practice:

• A URL with poor CLS (Poor) but good INP is still labeled Poor.
• A URL with LCP in "Need improvement" but good CLS stays in Need improvement.
• Only URLs with LCP, INP, and CLS simultaneously in the green range make it into Good.

This changes how you read a drop. If the report shows a block of pages falling from Good to Need improvement, don't assume "the whole site got slow." It could be a single metric crossing the threshold. And the reverse is also true: an LCP improvement changes nothing if that group's INP is above the ceiling.

The thresholds that decide the label

The three thresholds are fixed, and it's worth pinning them up before any December diagnosis:

| Metric | Good | Need improvement | Poor | |---|---|---|---| | LCP (Largest Contentful Paint) | ≤ 2.5 s | ≤ 4 s | > 4 s | | INP (Interaction to Next Paint) | ≤ 200 ms | ≤ 500 ms | > 500 ms | | CLS (Cumulative Layout Shift) | ≤ 0.1 | ≤ 0.25 | > 0.25 |

Each value shown in the report is the 75th percentile of real visits over the last 28 days, not the average. The "Group INP" means that 75% of visits to that group's URLs had that value or better. That's why the data is resistant to isolated spikes, but also slow to react: a fix published today only appears consolidated once the 28-day window accumulates enough data.

Why INP is the metric that scares people most during Black Friday and Christmas

INP replaced the old FID (First Input Delay) as the responsiveness metric and measures the time between a user's interaction (click, tap, keypress) and the next screen repaint, considering the worst interaction of the session, discarding outliers. It's sensitive precisely to what happens during traffic spikes: more third-party scripts, more remarketing tags, more A/B tests running on the page, all competing for the browser's main thread.

At year's end, the pattern of Brazilian e-commerce behavior pushes this number up without the team touching a single line of code: more low-end devices, more poor connections, more campaign pixels injected. The documentation describes exactly this scenario in the section "My site changed status but I didn't change anything": a site-scale event, such as a sudden traffic increase or latency variation from an external service, can push pages that were "on the edge" from Good to Need improvement, or from Need improvement to Poor. In other words, you can lose the green status without having deployed anything, just because the mix of users and campaign tags changed.

The blind spot: data by real URL, not canonical

Two technical details of the report tend to cause misreadings in growth meetings:

1. Data is attributed to the real URL, not the canonical one. If your campaigns send traffic to URLs with parameters (?utm_source=..., ?gclid=...), these variations count toward the grouping in Search Console. PageSpeed Insights, on the other hand, strips all parameters and lumps everything into the bare URL. That's why a landing page's PSI number may not match the CWV report.
2. The report groups similar URLs together. A December campaign landing page can be diluted into a larger group of pages with the same framework, or even thrown into an "origin group" (the entire host) when there isn't enough data for privacy reasons. In these cases, the status you see isn't your landing page's, it's the group's.

The documentation itself warns that "the report was not built to determine the status of a specific URL." To diagnose a campaign landing page in isolation, the way to go is running an external test, such as PageSpeed Insights, instead of trying to hunt it down in the report.

How to keep CWV from masking (or inflating) a media decision

The playbook that makes sense for a team using CWV as a budget gate, before locking in the year-end budget:

• Isolate which metric dropped. Don't just look at the group's status; open the issue detail and see which of the three (LCP, INP, CLS) exceeded the threshold. A status drop due to CLS calls for a layout fix; due to INP, it calls for reducing third-party JavaScript. These are different problems and different teams.
• Isolate the effect of your own campaigns. If INP rose alongside the rollout of December tags, the bottleneck may be the media stack, not the product. It's worth measuring INP with and without the campaign scripts in a controlled test before blaming the front end.
• Don't confuse the 28-day window with real time. The report is lagged. A last-minute fix won't reverse the Quality Score in time; plan performance hardening for November, not for campaign week.
• Compare the 75th percentile, not the average. If the decision to pause media relies on an internal RUM average, it may diverge from what Google actually uses. Align the methodology with CrUX's p75, which is the report's source.

When the report doesn't help

The Search Console CWV report isn't meant for debugging a single page, isn't a complete list of indexed URLs, and depends on a minimum traffic volume (URLs without enough data disappear or get aggregated into the origin group). A new site, or a freshly published campaign landing page, simply won't have field data in time. In these cases, the investment gate can't rely on the report: the right approach is to use synthetic testing (PageSpeed Insights, Lighthouse) for new pages and reserve the CWV report for assessing the health of the site as a whole over time. Reading the INP grouping with this distinction in mind is what separates a well-grounded budget decision from a cut made on top of a misread number.