After a redesign, check that your important pages and guest actions still appear in analytics under the conditions you expect. A working Order button is not enough: the destination, event name, consent setting, and reported result may all have changed. Record what you tested and what remains unresolved before comparing the new site with the old one.
Start with the actions that matter to your restaurant: viewing the menu, starting an order, reaching an order confirmation, requesting a reservation, or tapping to call. You do not need to track every tap. You do need a clear definition of each action you plan to use in a decision.
Map old URLs and actions to the new site
Make a short list of the old pages and actions alongside their new equivalents. Ask the website provider or developer for the old and new URLs, the analytics event names, and any redirects. Ask whoever manages ordering and reservations where guests go after clicking a button and what counts as a completed action. Your marketing or analytics contact can explain how those actions appear in reports.
For example, the old menu may have lived at /menu, while the new menu is on the home page. A report filtered to the old path may now show a drop even when guests are still reading the menu. Similarly, an Order button might now lead to a separate ordering site. A click on that button shows interest; it does not prove an order was placed.
For each priority action, write down:
- The old page or event and its new equivalent.
- The destination after the click, including whether it moves to another domain.
- The business meaning: a page view, a button click, a submitted request, or a confirmed transaction.
- The person responsible for the website, destination system, and report.
Check redirects by opening important old addresses and seeing where they land. A redirect can help a guest reach the right place, but it does not by itself establish that your reports group the old and new pages as intended. Review the final URL and the report filter separately.
If you kept an existing site and added an online ordering link, include both sides of that handoff. Ask whether the ordering provider can share completion data and how it can be reconciled with website reports. Do not assume two systems use the same definition of an order.
Test events under the right consent conditions
Run a small, controlled check on a phone and a desktop browser. Use the analytics platform's event inspection or debug tools if available, and coordinate with the person who manages the tag setup. First confirm which consent choices the site offers and how the measurement setup is intended to respond to each choice. A qualified adviser can help with questions about consent and legal requirements.
Use a fresh browser session for each consent scenario so that a previous choice does not carry over unnoticed. For each scenario, record the device, browser, consent choice, action, expected result, and observed result. Check both the immediate diagnostic view and the normal report later; processing delays and report filters can make their timing different.
Keep practice actions simulated. Use a test environment or a provider-approved test method that cannot charge a card, send a guest message, or dispatch a courier. If there is no safe way to simulate an order confirmation or reservation submission, leave that check open and ask the provider how it can be verified. Do not manufacture a completed order by treating a button click as one.
For a consent choice that is intended to allow measurement, check whether one action produces the expected event once. Then repeat with a choice that is intended to restrict measurement and check the behavior against the configured policy. An absent event may be correct in that second case. Unexpected events, missing events, and duplicate events all deserve investigation.
Also check the handoff to ordering or reservations. Does a guest return to a confirmation page on the website, or remain on a separate domain? Does the analytics setup record a new visit at the handoff? Ask the provider how the journey is connected, if at all. A test that confirms the button works does not establish that the completed journey is attributed correctly.
Compare report definitions before comparing periods
Look beyond the labels in your dashboard. Two reports called “orders” may measure different things: one may count clicks to an ordering page, while another counts confirmed orders in the ordering system. Compare the event, the filter, the date range, the time zone, and whether the report counts events or people. Check whether canceled or failed transactions are included when reviewing order-system totals.
Hypothetical example: Before a redesign, a restaurant's report counted 40 clicks on its Order button in a week. Afterward, a report labeled “orders” shows 24 confirmed orders in a week. Those figures are not comparable measures. The first is an intention signal; the second is a completion measure. The difference of 16 does not show that 16 orders were lost.
The owner should first find a consistent measure for both periods. If the old system also recorded confirmed orders, compare those totals using the same date boundaries and status rules. If it did not, start a new confirmed-order series at the point the new measurement is verified. Keep the old click series labeled separately rather than presenting the two as a trend.
Even a matching event name needs a closer look. “Menu view” might previously have meant opening a dedicated page and now mean scrolling to a menu section. Those actions can produce different counts without a change in guest interest. Write the definition next to the metric so the next person reading the dashboard understands what it represents.
Changes in consent choices, browsers, reporting filters, or the availability of completion data can also affect what appears in a report. Analytics is useful for spotting patterns, but it may not account for every guest action. Use ordering or reservation records alongside website reports when making an operational decision, and note where their definitions differ.
Keep a post-redesign event verification log
The log is a working record, not just a launch-day checklist. Give every important action an owner and a status. The hypothetical entries below show how to separate a passed simulated check from an unresolved completion check. “Passed” means the stated test produced the expected observation; it does not mean every device or guest journey has been verified.
| Action and expected result | Test conditions | Observed result and status | Owner and next step |
|---|---|---|---|
| Menu view: new menu page appears in the page report | Phone browser; measurement allowed | New page view visible; passed | Analytics contact: update the old path filter |
| Order click: one outbound click event appears | Desktop browser; measurement allowed; no checkout | Two click events visible; open | Website provider: inspect duplicate tagging and retest |
| Order confirmation: one completed-order event appears | Safe simulation method not yet available | Not tested; open | Ordering provider: supply a safe test method |
| Menu view: measurement follows the restricted-consent setting | Fresh phone session; measurement restricted | No analytics event visible; passed against the intended setting | Analytics contact: retain the setting and test record |
The duplicate click in this example is not a reason to double reported interest. Until it is fixed and retested, flag that metric as unreliable. The untested confirmation is a different gap: there is no basis yet to say whether it works or fails. Keep those statuses separate.
Add the test date, exact URLs and event names to your own log, along with the version or deployment involved. When a provider makes a change, record what changed and repeat the same safe scenario. Note the resolution date and the first period for which you consider the metric usable. If a report combines reliable and unreliable dates, label the break rather than silently comparing the whole period.
Schedule another check after a new menu layout, booking button, domain change, or ordering-provider change. You can use the domain ownership guide to identify who can make domain changes, and the restaurant website builder comparison to frame questions for a website provider.
Next step: Pick your three most important guest actions, put them in a verification log, and assign each open check to the person who can resolve it. If you are evaluating a new restaurant website, ask Fleksa about US availability and how your intended ordering and measurement setup would be handled.
Frequently asked questions
Should I compare traffic immediately after the redesign?
Review the numbers, but verify page paths, event definitions, consent behavior, and reporting filters before treating a change as a business trend. Mark any dates affected by unresolved tracking gaps.
Does an Order button click count as an order?
No. It records an attempt to reach ordering, not a completed purchase. Use a confirmed-order measure from the ordering system when available, and check its status and date rules.
How can I check a confirmation without creating a real order?
Ask the provider for a test environment or approved simulation that cannot charge a card, send a guest message, or dispatch a courier. If none is available, record the confirmation event as untested until a safe method is agreed.
