Overview
The website, the app, and the mini program each keep their own analytics shell. Side-by-side comparison happens in all-platform analytics.
Console menu
The overview group in all-platform analytics has two cross-platform reports:
ConsoleAll-platform analyticsOverviewPlatforms side by side| Item | When it shows | Contents |
|---|---|---|
| Multi-platform overview | At least two of website, native app, and mini program have a source | People after identity resolution, plus the events, screens, and channels that moved most |
| Platforms side by side | Always in the overview group | Users, new users, sessions, events, duration, and errors by platform |
Android plus iOS alone is one app family, so Multi-platform overview stays hidden. App and mini program menus are in App analytics overview and Mini program overview.
Multi-platform overview is forced to person counting, so devices can outnumber people. The gap is the same person on more than one device. It only keeps metrics every platform can share. It does not show pageviews, bounce rate, starts, or versions. On Platforms side by side, the new-user hint is "assigned to the platform where they first appeared." Server events, if you send them separately, are their own platform row. They are not folded into the website.
Where to start
If you already have a website and nothing else, read Migrating web to multi-platform first. Existing hits do not need to be rewritten. To add a mini program, skim the menu in Mini program overview and pick a package in SDK overview. Orders and payments should be sent from the server. See Server-side & merging.
Terms
The platform field, and "a user is new on only one platform," are in Platforms.
Cross-platform frameworks
Event names stay the set in Preset events & properties. Reports stay in app analytics or mini program analytics, split by the platform the build actually runs on.
Three packages
| Framework | Package | What it really depends on |
|---|---|---|
| React Native | @webcount/react-native | A script forwarder. Screens come from the navigation hook as $screen_view |
| Flutter | webcount_flutter | Forwards to the iOS or Android SDK you also installed |
| uni-app | @webcount/uni-app | Mini program targets use the mini program package. App targets use the app core. H5 uses the website script |
React Native expects react-native 0.72 or newer. Flutter expects Dart 3 and Flutter 3.10 or newer, and the host app still needs the native SDK. See Android and iOS. uni-app mini program targets cover WeChat, Alipay, and Douyin only, the same set as Mini program platform differences.
React Native screens come only from the navigation hook you pass in. Native screens are not autocaptured a second time. Flutter screens come from the navigator observer. Everything else equals the native SDK it calls, so do not expect the mini program queue or remote config there. After uni-app picks a core, scene and share fields match Mini program platform differences. Register the app id on the OS or mini program that actually runs. The bridge has no id of its own.
Verify
Open realtime in the matching shell and look for $app_start or $mp_launch. If the plan does not include apps or mini programs, hits are dropped regardless of framework. See Plans & quotas.
Packages that are not shipped
There is no SDK for TV, watch, or desktop, and no separate game-engine or C++ package. If the install wizard shows those names, it marks them as drafts. A report can still group events that arrive with another platform value. That does not mean an installable package exists.
Server-side & merging
Server collection fills in facts the client cannot see: an order, a refund, an identity confirmed after the fact. Their platform is server, and on the side-by-side report they are their own platform row. See Multi-platform overview.
How to send
The five server SDKs are thin wrappers around POST /api/v1/track. The key needs write scope. Fields and limits are in Server events & log import and Server events. Do not confuse that call with the separate log-import endpoint for access logs.
How they meet the client
| Field | Role | If you omit it |
|---|---|---|
insert_id | Idempotency key. A repeat keeps the first copy | Every send is a new row |
session_id | Attach the event to a session that already exists | The event never enters the session table, so session metrics ignore it |
login_id | Bind the event to a signed-in person | A device id or anonymous id may not be the same person |
If the client and the server both send the same fact with the same insert_id, the later copy is dropped. Different keys leave both rows, and the report does not merge them. Generate a stable insert_id on the business side (an order id, not a random value).
The same login id is required on both sides if they should be one person. See Visitors, users & identity. Do not use sessionless server events to explain time per person or session counts. See Sessions.
Limits
Events more than 72 hours off server time are rewritten to the receive time. One request holds at most 1,000 events, and each key has a per-minute cap. A debug query validates without storing. Attribution callbacks use a different URL and are stored as $app_install. Do not reuse that name for orders.
Migrating web to multi-platform
What this is
A project is one identity space and one event table. The website, the app, the mini program, and the server are sources on that project, separated by the platform field, not by a new project each. See Accounts, projects & sources and Platforms.
Why the website can stay
Stored page events keep their original platform. You do not backfill a platform onto old rows, and you do not rotate the site key. The website script, the app SDK, and the mini program SDK can run together. The new client uses its own SDK. Register the app id under ConsoleApp analyticsConfigurationSDK code or ConsoleMini program analyticsConfigurationSDK code and start sending. The old website reports stay in the website shell. Their numbers are not moved because an app shell now exists.
When the side-by-side view appears
Multi-platform overview requires sources in at least two of these families: website, native app, and mini program. Adding Android and iOS without a mini program is still one app family, so that overview stays hidden. Platforms side by side is always in the menu. On the day you add a client, realtime in the new shell shows start events first.
A new user is counted on the platform where they first appeared, so an old website visitor who later opens the app is not new a second time. One person becomes one row in the comparison only after a login id or another identity link. Separate device ids stay separate people. See Visitors, users & identity.
Next steps
Once the new client is live, send orders and payments from the server so each client does not record its own copy. See Server-side & merging.