A panel's built-in reports show what happens after signup: orders, amounts, statuses. They say nothing about what came before — how many people arrived, where from, and where they left without ordering. External analytics cover that part, and they take five minutes to install. Here's what to connect, where the code goes and which reports an owner actually needs.
Why a panel needs external analytics
A panel is an ordinary site with a funnel: visitor, signup, top-up, order. Without analytics you only see the last step and draw conclusions from it, while the problem is almost always earlier.
- Traffic sources. Which channel brings buyers and which brings only visitors. Without that, ad budget is allocated blind.
- Drop-off points. Where people leave: the storefront, signup, the top-up screen, the order form.
- Search queries. What people find you by — a ready-made list of page and article topics.
- Devices. If most orders come from phones, your fix priorities are obvious.
What to connect
Two counters are enough and they don't conflict. Google Analytics is the standard for sources and events; Yandex.Metrica is more useful in Russian-speaking markets with its click maps, session recordings and query reports. Add the webmaster consoles — Search Console and Yandex.Webmaster: they're about indexing rather than visitors, and you need them if you count on search traffic.
Don't install everything you can. Five counters slow the storefront down and still go unread: nobody reviews reports in three systems.
Where the code goes
The tracking snippet lives in the panel settings, in the field for your own head code. Paste it, save, reload the storefront, and the counter appears across the panel including the customer account.
One security detail worth understanding. Injecting your own code is allowed because the panel runs on your own domain: browsers isolate sites by domain, so your scripts physically cannot reach neighbouring panels or their visitors. That's exactly why our tenants live on their own registrable domains rather than shared subdomains — on a shared subdomain someone else's code would be a risk to everyone.
What to set up beyond the snippet
- Goals. At minimum signup, top-up and a placed order. Without goals a channel report shows visits, not money.
- UTM tags on every link. Ads, channel posts, forum signatures. A tag costs a second; without one the channel collapses into "referral traffic".
- Filter your own visits. Your own trips to the admin easily account for half the "traffic" early on.
- A separate property for the panel. Don't mix it with a landing page or another site: different funnels produce mush.
What to check every week
You don't need dozens of reports. Four numbers suffice: unique visitors, how many signed up, how many topped up, how many ordered. Their ratios are your funnel, and the funnel shows immediately where it's narrow.
Typical readings: plenty of visitors and few signups points at the storefront and prices; signups but no top-ups points at payment methods, usually at which ones you offer; top-ups but no orders points at the catalog and the clarity of the order form. Compare phone and desktop conversion separately too — a twofold gap means the mobile version breaks something.
What external analytics won't show
They know nothing about margin, order statuses or refunds. Profit per item, faults per provider, average completion speed — those are the panel's internal reports. The right setup is traffic and funnel outside, money and quality inside, then compare. A channel with cheap traffic often brings customers with a high refund rate, and that only shows up where the two data sources meet.
Wrap-up
Analytics on a panel isn't reporting for its own sake, it's how you stop spending blind. Five minutes in the settings, one evening on goals and tags, and it runs itself. You can try it at no cost: rent here is free while third-party orders stay under a hundred a month, and free at any volume on our own catalog — so your first traffic and funnel data arrive before your first rent invoice.
