Embedding an Online Ordering Widget Without Losing Attribution
If your “Order Online” button sends people to a page hosted on your ordering provider’s own domain, every one of those orders disappears from your analytics as a handoff to someone else’s site — even though the customer never stopped thinking of it as your restaurant. Embedding the ordering widget inside your own domain instead of linking out to the provider’s domain fixes this, and it’s a decision you make once, not a cost you carry forever.
What Actually Breaks When You Link Out
Analytics tools attribute a conversion to whatever page it happens on. When “Order Online”
is a plain link to provider.com/your-restaurant, the checkout and the confirmation both
happen on the provider’s domain. Your own analytics never sees the sale — it only sees a
visitor leaving. Any channel you’re paying attention to (a Google Business Profile click, an
email campaign, a social post) loses the one number that tells you whether it worked: whether
that visit turned into an order.
Most restaurant owners don’t notice this until they try to answer a simple question — “did last month’s flyer actually bring in orders?” — and realize the data was never being collected in the first place.
The Same Mistake Shows Up Across Restaurant Tech, Not Just Ordering
This isn’t specific to online ordering. Reviewing how independent restaurant websites integrate third-party booking and ordering tools turns up the identical pattern over and over: a site that looks fully custom right up until the one button that actually makes money, which quietly hands the visitor to a different domain. Whether that button is for a table reservation or a food order, the underlying failure is the same piece of web architecture, not a quirk of one industry vertical.
How Embedding Works in Practice
Most ordering platforms offer one of two integration paths:
- An iframe embed. Simple to add, but it can complicate mobile layout, and some providers still redirect out of the iframe to their own domain at the final checkout step — which brings back the exact problem you were trying to avoid.
- A JavaScript widget that mounts into a
<div>on your page. Usually integrates better with analytics, because the ordering flow fires in your page’s own context instead of a separate frame, so events you’re already tracking (page views, add-to-cart, purchase) can see it.
Neither option is automatically the right one — it depends on what the specific provider supports, which is why the checklist below matters more than the marketing page.
What to Check Before You Turn It On
Before adding any ordering widget to a live site, get written answers to these three questions from the provider, not assumptions from their sales page:
- Does checkout stay on your domain, or does it redirect to theirs at any point? “Embedded” is sometimes used loosely — ask specifically about the payment step, not just the menu browsing step.
- Can you fire your own conversion event when an order completes, or does only the provider’s own dashboard see it? If it’s the latter, you’re back to flying blind on which marketing channels are working.
- Does the widget load only on the ordering page, or does its script run sitewide? A third-party script loading on every page costs performance you didn’t budget for — see does an online ordering system work with a custom-built website for what to ask about that specifically.
If You Can’t Embed It Yet
Some providers genuinely only support a hosted page you link out to. If that’s your only option for now, don’t skip attribution entirely: add UTM parameters to the link and ask the provider directly whether they support a webhook or postback that reports completed orders back to your own analytics. It’s a worse setup than embedding, but it’s not the same as tracking nothing.
This is also where the trade-off between marketplaces and direct ordering starts to matter — see online ordering vs. delivery apps for what each path actually costs once fees are on the table.
The Concrete Next Step
Before you sign up with any provider, send them exactly two questions in writing: “Does checkout ever redirect off our domain?” and “Can we fire our own conversion event on order completion?” A provider that can’t answer both clearly is telling you something about how the rest of the integration will go.