Before changing your restaurant website, record a small set of numbers that connect visits to the actions you care about: completed orders, reservation activity, and visits to useful pages such as the menu. Write down exactly how each number is counted, the dates it covers, and any tracking gaps. That record is your baseline.
A baseline does not need to explain every visitor's behavior. Its job is to give you a fair starting point for deciding whether the new site makes it easier for guests to do business with you. Pair website analytics with order and reservation records so you can spot differences between what the site measures and what actually reaches the restaurant.
Start with business actions and eligible visits
Choose actions that matter to your operation before choosing a dashboard. A takeout-focused restaurant might prioritize completed direct orders. A dining room that depends on bookings might focus on completed reservations. Both may want to know whether guests can find the menu, hours, and location.
Separate a useful action from an indication of interest. A click on an order button shows that someone tried to begin ordering; it does not mean an order was placed. A reservation button click is not a confirmed booking. If a call link is tapped, the analytics event may show the tap, not whether a conversation or reservation followed.
Next, define the denominator for each rate. An eligible visit is a visit included in the population you intend to measure. For example, you could use measured visits to pages with an ordering link as the denominator for an order-start rate. For a sitewide order rate, you might instead use all measured website visits. Either can be useful, but they answer different questions. Do not switch between them when comparing periods.
Also decide what counts as a visit. Your analytics tool may use sessions rather than individual people. One person can produce more than one session, and a session can include multiple page views. If your report counts sessions, label it that way rather than calling the number unique guests.
Ask the people responsible for each part of the setup to help map the journey:
- Website manager: Which pages and buttons are tracked, and what changes are planned?
- Analytics administrator: How are sessions and events defined? Can reports be broken down by page and device?
- Ordering and reservation providers: Where can you see completed transactions or bookings, and can the website journey be measured across their pages?
- Restaurant staff: Which actions lead to work the team can verify, such as an accepted order or a booking in the reservation book?
If you are considering changes to your restaurant website, draw the current path first: landing page, menu or information page, action button, and confirmation. Note where a guest leaves your domain or enters a different system. Those handoffs are common places for counts to stop matching.
Record consent choices and measurement gaps
Your analytics report may not include every visit. Visitors may decline optional tracking, use browser settings that limit it, or move to an ordering page where the original session is no longer connected. Staff traffic and repeated visits can also affect totals. These limits matter most when they change between the baseline and the new-site period.
Record the consent settings in place, which analytics events depend on those settings, and who can change them. Ask your provider how consent affects the reports you use. Ask a qualified adviser about the appropriate treatment of consent for your business; a dashboard setting alone is not a legal assessment.
Keep a short measurement log alongside the numbers. Include the website domain, analytics property or report name, time zone, date range, filters, event names, and whether internal traffic is excluded. Note any changes to the consent banner, ordering link, reservation provider, or domain. If a number cannot be measured reliably, write that down rather than treating a missing event as zero guest activity.
Compare analytics with operational records, but do not expect them to match automatically. An ordering system may count completed orders that cannot be linked to a measured website session. It may also include orders from channels outside the website. Record the source and definition of each total before comparing them. The same principle applies to reservations: a booking log may include phone and walk-in requests as well as online bookings.
For a safe setup check, use a simulated journey or a provider's test environment where available. Check that a menu view and button tap appear as intended without sending a guest message, taking a real payment, or dispatching a courier. Ask the provider how to verify a completion event without creating a real order or booking. Keep test activity out of the baseline where the reporting setup allows it, and note any test records that remain.
Choose comparable dates and check device mix
Pick a baseline period long enough to represent normal business and write down its start and end dates. Whole weeks are often easier to compare because restaurants can have very different weekday and weekend patterns. If the restaurant is new and has limited history, use the data available, label the short period, and avoid treating a small change as a settled trend.
Make a note of events that could affect demand or site behavior: a closure, unusual weather, a menu change, different opening hours, or a large local event. After the new site launches, compare a similar span of days and the same definitions. A launch week may include staff checks and curious repeat visitors, so mark it separately if it is not representative.
Device mix matters because a site can improve for one group while becoming harder to use for another. Record measured mobile and desktop sessions separately, along with any other device category your tool reports. Compare each device's action rate with its own prior rate, not just with the overall rate. If mobile traffic grows as a share of visits, the combined rate can move even when neither device's experience changes.
For a hypothetical baseline, assume a restaurant records 600 eligible sessions over four weeks: 420 mobile and 180 desktop. It records 36 completed orders that can be connected to those sessions, for a sitewide measured order rate of 6%: 36 divided by 600. Assume 21 of the orders came from mobile sessions and 15 from desktop sessions. The mobile rate is 5%, while the desktop rate is about 8.3%.
That difference is a reason to inspect the mobile ordering path, not proof that the design caused it. Guests may use devices differently, and the counts exclude activity the analytics setup cannot connect. The order system's total may be higher or lower depending on its channels and definitions. Keep the device definitions and order connection method unchanged for the later comparison.
Build a baseline worksheet you can reuse
The worksheet below uses the same hypothetical four-week period. Its figures are assumptions, not benchmarks. Each rate uses sessions as its unit; the completed-order rate includes only orders connected to an eligible session. A restaurant can replace these measures with booking measures if reservations are its main goal.
| Measure | Definition | Baseline | Use after launch |
|---|---|---|---|
| Eligible sessions | Measured sessions on the website, using the same filters and time zone | 600 | Check volume and keep the denominator consistent |
| Menu-view sessions | Eligible sessions with at least one menu page view | 390; 65% of 600 | See whether guests reach the menu |
| Order-start sessions | Eligible sessions with at least one order-button click | 90; 15% of 600 | Check interest in starting an order |
| Connected completed orders | Completed orders linked to eligible sessions | 36; 6% of 600 sessions | Compare the measured completion rate |
| Device mix | Eligible sessions grouped by reported device | 420 mobile; 180 desktop | Compare device-specific results as well as the total |
The menu-view and order-start rows count sessions, not total page views or button clicks. The completed-order row counts orders, so its rate assumes no more than one connected completed order per eligible session in this example. If your tool reports multiple orders per session, label the result as orders per session rather than the share of sessions that ordered. Do not subtract the rows as if every menu viewer followed the same path.
Save the worksheet with the measurement log and a copy or export of the underlying reports. Add the operational order total as a separate line if you can isolate website orders, and record how that total differs from connected completions. If booking is more important, use reservation starts and confirmed bookings instead, with a clear denominator and a separate reservation-book total.
Before buying, ask how the new website and online ordering setup will preserve or change these definitions. Can you access the reports? Who controls the analytics account? What happens to measurement when a guest moves to checkout? Use the restaurant website builder comparison to frame other buying questions, and check the domain ownership guide before changing providers.
Next step: Fill in the worksheet for your current site, save the definitions with your reports, and identify one uncertain handoff to investigate. Then ask Fleksa about its restaurant website and verified US availability for your setup.
Frequently asked questions
How long should a restaurant website baseline cover?
Use a representative period that includes whole weeks when possible. Record the dates and unusual events, then compare a similar period after launch. If you only have a short history, label it and treat small differences cautiously.
Should I count order clicks or completed orders?
Record both if you can. Clicks show attempts to start; completed orders show a business outcome. Define how each is counted and keep operational order totals separate from orders connected to measured sessions.
What if some visitors do not appear in analytics?
Document the consent settings and other known gaps. Use ordering and reservation records as separate checks, and avoid presenting measured sessions as a complete count of guests.
