Documentation
Coming from another tool
Reading the reports
Count what matters
Machine access
Your old numbers, in the same charts.
Imports from GA4, Plausible, and Umami write into the same daily layer Kehai counts into: one series, each day naming the tool that measured it, and no badge wall between your past and your present.
One model, not a second museum
An import from GA4, Plausible, or Umami writes your old tool's daily history into the same layer Kehai counts into. There is no imported chart, no imported metric, and no badge on every number: an imported day reads like any other day, in the same tiles and the same lists, because you are moving your history, not filing it in a second place.
Two rules keep that honest:
- Counted always wins a day. An imported figure appears only on a day Kehai measured nothing, so no single number ever mixes instruments. The day the tag goes on uses Kehai's available measurements, without filling earlier hours from an imported total.
- Every day names its origin. The summary says whether a range is counted, imported, or mixed, and how many days went each way, so the methodology line under a chart states the split rather than hiding it.
Running two tools in parallel during the switch is ordinary, not a problem: where imported sources overlap, one source wins each day, chosen by the broadest metric set, and the others stay visible in the provenance rather than being added on top.
The three external importers
Settings, Imports walks each one. All three arrive at the same day-grain layer:
| Source | How it identifies a visitor | Worth knowing |
|---|---|---|
| GA4 | Cookie-scoped ID, counted approximately | Its counts are estimates by design, and the import records when a day was also sampled or thresholded, so a difference against counted days has a stated reason |
| Plausible | A daily hash, much like Kehai's own | The closest cousin: exact within its own definition |
| Umami | Website-scoped visitor identity | Its hourly and event data is a wall clock and is read as one |
Old conversions can keep their history too: an imported outcome maps onto a goal you already have and becomes that goal's earlier days, origin on every row.
A Kehai site archive uses Settings, Your data. Import the exported NDJSON file into an existing site to restore supported configuration and retained datasets, including raw Kehai measurements. Goals and their mappings, funnels, saved views, and link configurations travel with the data. Raw rows preserve their recorded identifiers and origin; older visit relationships are not recalculated.
The destination keeps its domain, aliases, public ID, and retention. Accounts, passwords, API keys, and connection credentials are not restored. Blocking rules return inactive, and tracked and shared links return revoked without activating old public URLs. The result lists applied and skipped records with explanations. Exports describes the file's scope.
If an archive import stops or its response is lost, choose the exact same file again. Kehai resumes missing rows and reuses confirmed settings. Reading a completed file again makes no changes and shows its earlier result. The upload must finish before restoration starts; a partial restore is not rolled back. A renamed file is still the same file, but edited or newly exported files are separate imports and may overlap existing data. Rows outside the destination retention window are skipped. Erasing measurements stops earlier interrupted imports from resuming; use a new export if you later choose to restore them.
What each import asks for
| Source | Have in hand |
|---|---|
| Plausible | An API key, from Settings and then API keys in Plausible. It is long lived, so one key covers an import of any length. This reads plausible.io only, and names your site by its domain |
| Umami Cloud | An API key: sign in at cloud.umami.is, click your profile, open Settings and then API keys, create one |
| Umami, your own server | The instance address, the website, and a Umami username with a password. Your own Umami issues no API keys, so Kehai signs in, trades the password for a token, and stores the password nowhere. Make a separate read-only Umami user rather than handing over an administrator, and note that an account with two-factor sign-in cannot mint a token this way |
| GA4 | Nothing typed: connect the Google account with at least Viewer on the property, and the connection covers the hours a long import takes. A pasted OAuth token works too, but expires after about an hour, which is exactly why connecting exists |
A pasted key or token is used for the run and nothing else: it is sealed with the site until the run ends, then deleted. A connected Google account is different, because it exists so that a long import can keep going: it stays connected until you disconnect it on the Imports screen or Google revokes it.
The run, step by step
- Settings, Imports: pick the source and fill in the table above.
- Test connection. A pass answers with evidence rather than a green tick: how far back the source holds data, which time zone the property reports in, what it saw yesterday.
- Map outcomes. What the source calls a conversion, read from the source itself, pointed at your goals. Mapping lives beside the data, so changing it later takes effect on the next read without importing again.
- Choose breakdowns. All are on by default, because the ones left out are the reports that read as a site with no traffic. Fewer means a faster import.
- Start. The first piece runs while you watch, so a wrong property or time zone is reported to your face. The rest continues on the server and reports under Runs; one import per source runs at a time.
Days, time zones, and retention
A day is the one unit that crosses tools safely, so the import is day-grained and each vendor is held to its own time zone declaration: GA4 names its property's zone and is checked against it, Plausible's is verified where it can be, and a mismatch is said out loud rather than passed over. Your site's retention applies to imported days exactly as to counted ones: a plan keeping two years keeps two, whatever you imported.
What deliberately does not import
- Range-level unique visitors. Adding 30 daily unique counts does not produce a monthly one, in any tool. Kehai stores visitor days, whose sum is honest, and imports the same. A vendor's monthly unique number would exist only for the past and read as missing data everywhere else. Coming from GA4 has the longer answer.
- Raw events from external tools. The three external importers read daily aggregates, such as 1,204 pageviews for a date, rather than recreating 1,204 events with their properties. Those imported days answer totals and the dimensions supplied, one at a time. The screens say so when a filter cannot reach an imported day, and site exclusion rules are admitted as not applied there rather than silently skipped. This limit does not apply to raw rows restored from a Kehai site archive.