Start free

Traffic & Summary

Web-menu traffic from Google Analytics plus a compact order/kitchen summary

7 min read Open this screen in the demo
On this page 12

Website Traffic and Sales Summary

The Statistics section is a quick look at who visits your web menu and how, plus a compact summary of sales and kitchen. Traffic data comes from Google Analytics and is refreshed by a background job on the server (no "live" API calls), so the section opens instantly.

Open: Admin Panel → Statistics. Data is shown for one selected location; use the location selector when you have several.

The section can be tailored to you: the ⚙️ gear in the header hides tabs and "Traffic" blocks you don't need, sets the default tab and period (7 / 30 / 90 days or 12 months) and the kitchen lateness threshold (5 to 120 minutes). There are ready-made presets too — "simple", for instance, leaves only the "Orders" tab. A hidden tab disappears from the section header; you cannot switch all of them off at once.

"Traffic" tab#

Google Analytics data on visits to the web menu:

  • KPIs: sessions, active users, page views, average session duration — compared with the previous period over 7 and over 28 days (these two windows are fixed; the period switcher at the top applies to the other tabs);
  • daily trend (sessions);
  • channels and devices;
  • traffic sources, countries, cities, languages;
  • a sessions heatmap by hour and weekday — handy for planning promos and content;
  • top pages;
  • a conversion funnel: menu opened → dish viewed → added to cart → checkout started → order placed;
  • top dishes by views (from view and add-to-cart events).

"Orders" tab#

A compact sales summary from the same data as the Finance section:

  • revenue, order count, average check;
  • a revenue trend;
  • top dishes by revenue and by quantity.

This is a "quick slice" — for detailed reports go to Analytics and Finance.

"Kitchen" tab#

Kitchen speed metrics:

  • average accept, cook and full-ticket time, % late (with a configurable threshold);
  • a trend and heatmap of times by hour/weekday;
  • Slowest dishes to cook and Wasted prep (items cancelled after cooking had already started).

% late compares the full ticket cycle with the common Late threshold, not an individual dish’s standard cooking time.

Promised vs actual compares order readiness with the time promised at checkout, which is visible to the guest and kitchen. An order is ready when its last dish is ready. The block shows the share ready on time and the average delay of late orders only, helping you check whether guest promises are met. Only orders with a saved promised time are included; dine-in, aggregator and older orders may have none. An empty block does not mean every order was on time.

By station and time distribution#

The "By station" block splits the kitchen into stations: each station gets its own row with the number of dishes and orders, average cooking time and time to serve, the share of dishes over the late threshold, the number of returns and a time-spread strip. A dish belongs to the station whose kitchen-screen preset takes its menu category (KDS → "Stations"). Lines of one group (for example, two grills) count as one station. Dishes from categories no station takes go to the fallback "other" station, or, if there is none, to the "No station" row. Stations are fixed by their setup at the moment an order entered the statistics: if you change the presets, past orders stay on their old stations.

Below the table is the line of returns and resends to the kitchen:

  • returned to the kitchen — how many times a cook put an already-ready dish back into work ("Recall" on the kitchen screen);
  • resent to the kitchen — how many orders the POS sent to the kitchen again ("Resend to kitchen" when a ticket got lost).

The "Time distribution" block shows how many dishes fit into 0–5, 5–10, 10–15, 15–20 and over 20 minutes. The switch chooses what to count: time to serve or cooking only. Cancelled dishes are not counted.

Kitchen data appears automatically as soon as staff start accepting, cooking and serving tickets on the KDS or in orders — no setup required. It is collected by the platform’s analytical database, available in both clouds, including cenaly.ru.

"Risky operations" tab#

A feed of risky actions at the POS, attributed to a cashier: voiding an item already sent to the kitchen, cancelling an order, editing a bill after the pre-check was printed, refunds, manual discounts and price overrides, opening the cash drawer without a sale, reprinting a receipt already handed to the guest (the classic way to swap a guest's receipt) and a cash discrepancy at shift close. The full table with explanations is in Loss control.

What you see:

  • the number of events and the amount at risk for the period — discounts, refunds, voided items and totals of cancelled orders;
  • breakdowns by cashier and by operation type;
  • the feed itself with time, amount, details and who approved the operation.

This is a conversation tool rather than a punishment tool: an outlier among cashiers is visible immediately. Events arrive from the POS within a couple of minutes — see also PIN roles and approvals.

On top of this feed run the loss-control rules: void series, discount spree, cash discrepancy, consumption above norm, purchase price spike and a log mismatch. They turn the feed into a short "what to look at" list, feed the "Cash risks" block in Work chat → Needs a decision → the “Under control” tab, and optionally e-mail the owner.

Rule thresholds open from the ⚙️ gear in the section header, the "Alert thresholds" item: it switches to the "Risky operations" tab and expands the collapsed thresholds block for you (the item is visible to the owner and the manager). Details — Loss control.

"Store search" tab#

What shoppers look for on your storefront, in their own words:

  • top queries for the period;
  • zero-result queries (a dedicated filter) — a direct list of what your catalog is missing or what is named differently from the way people search;
  • how many product cards were opened and added to the cart after a query — counted within a search session (5 minutes after the query);
  • CSV export.

Any Statistics tab can be downloaded as a whole with ⬇ XLSX, ⬇ PDF and 🖨 in the header, and a view with its tab, period and location can be saved to ★ My reports. See Finance.

The report is aggregated: no visitor identifiers are stored. If too many distinct queries pile up over a month, the rarest ones are left out — and the report says so.

"Pouring" tab#

A preview of draft-beverage control for bars: a “tap → product → serving size” mapping and a comparison of poured versus sold. The framework is in place, but the “poured” figures are demo data for now — real volume will arrive once tap flow meters are connected through Cenaly Hardware Bridge. “Sold” is real data from orders.

A "poured ≠ sold" gap is the same loss topic as the "Risky operations" tab: see Loss control.

FAQ#

Why isn't the data "real-time"?#

Traffic is collected by a background job from Google Analytics, so the section opens fast and doesn't depend on API limits. Collection runs every six hours; the first data typically appears within 24 hours of connection.

The section is empty — what should I do?#

Data appears once the GA collection job runs (usually within 24 hours of connecting) or once the location has processed its first orders and tickets.

How is this different from "Analytics"?#

"Statistics" gives website traffic and a compact overview; "Analytics" gives detailed sales reports, ABC analysis and margins.

Reports & controls
Guest demo menu Start free