The demo on your website is not your venue
Our example menu is embedded in two marketing pages, so it loads in tabs nobody is reading — and then reports its own speed into the same board as the real ordering screens. Two very different things on one list.
There is an example menu on our website. It sits in a phone-shaped frame on two of the marketing pages so a visitor can scroll a real ordering screen without scanning anything, and it runs on invented data — a made-up burger place, a made-up matcha bar.
It is the same code as the real thing. That is the point of it. It is also why, when we built a board listing every screen in the product by load time, the example menu appeared on that board alongside the screens guests actually order from.
And it behaves nothing like them. A guest opens a real menu by scanning a code at a table: phone in hand, screen on, waiting for it. The example menu opens because somebody landed on a marketing page and it happens to be further down. It loads in a tab that might be in the background, behind another tab, on a laptop whose lid is about to close. Nobody is waiting for it, because nobody asked for it.
The general version
Any measurement that mixes a thing people are waiting for with a thing that merely happens near them will mislead you, and it will mislead you in the direction of panic.
Your kitchen has this too. A ticket a guest is sitting in front of and a pre-order placed for 7pm are both "open tickets". One is a customer looking at an empty table; the other is a job scheduled to start later. Average their ages together and you get a board that screams at you every morning about orders nobody is waiting on. Chefs learn to ignore a board that screams, which means they also ignore it on the day something is genuinely late.
Same with delivery platform tickets versus counter tickets. Same with a staff member's clock-in on a delivery day versus a trading day. The number is computed correctly in every case. The list it lands on is what is wrong.
What we did about it
Two things, neither clever. Crawler visits were already kept under their own heading rather than mixed in, because a search engine rendering a page is not a customer reading it. And a reading taken while the tab was not on screen is now discarded rather than recorded, because it measures the tab and not the page.
What we have not done is remove the example menu from the board, and we are not going to. It is a real page, served from production, and if it breaks we want to know. It just needs reading as what it is.
The habit worth stealing is smaller than any of the code: when a report surprises you, before you go looking for the fault, check that every row on it is the same kind of thing.
The example menu itself, along with the register, the kitchen pass and the rest of it, is on the product demos page — the same code the venues run, on invented data, and it says plainly there that the demo cannot take payment.