@zoho_apptics/apptics-js-sdk 2.0.0-beta → 2.0.0-beta.2

package/README.md

@@ -5,17 +5,17 @@ JavaScript/TypeScript library for [Zoho Apptics](https://www.zoho.com/apptics/)
 ### Prerequisites
 
 - A browser app: Chrome 80+, Edge 80+, Firefox 74+ or Safari 14+.
-- A Browser app registered in the Apptics web console (Quick start → Browser), which gives you its `serviceUrl`, `zak` and `identifier`.
+- A Browser app registered in the Apptics web console (Quick start → Browser), which gives you its `base_url`, `auth_key` and `app_domain`. You also need your app's `appversion`.
 
 The SDK is plain TypeScript with no framework dependency. It works with any bundler (Vite, webpack, Next.js, …) and from a `<script>` tag.
 
 ## Install Apptics
 
 ```bash
-npm install @zoho_apptics/apptics-js-sdk@2.0.0-beta
+npm install @zoho_apptics/apptics-js-sdk@2.0.0-beta.2
 ```
 
-A plain `npm install @zoho_apptics/apptics-js-sdk` still installs 1.0.2, the current `latest`. Upgrading from 1.0.2? `Apptics.init()` takes different config now; see [Upgrading from 1.0.2](#upgrading-from-102).
+A plain `npm install @zoho_apptics/apptics-js-sdk` still installs 1.0.2, the current `latest`. Upgrading from 1.0.2? `Apptics.init()` takes different config now; see [Migrating from 1.0.2 to 2.0.0-beta.2](#migrating-from-102-to-200-beta2).
 
 ## Initialize Apptics
 
@@ -24,71 +24,90 @@ Start Apptics once, as early as your app runs, with the values from the Apptics
 ### With a bundler
 
 ```ts
-import { Apptics, AppticsEvents } from '@zoho_apptics/apptics-js-sdk';
+import { Apptics, AppticsEvent } from '@zoho_apptics/apptics-js-sdk';
 
 // Your web app's Apptics configuration, from the Apptics web console
 const appticsConfig = {
-  serviceUrl: 'YOUR_SERVICE_URL',
-  zak: 'YOUR_TOKEN',
-  identifier: 'YOUR_IDENTIFIER',
+  base_url: 'YOUR_BASE_URL',
+  auth_key: 'YOUR_AUTH_KEY',
+  app_domain: 'YOUR_APP_DOMAIN',
   appversion: 'YOUR_APPVERSION',   // your app's version
 };
 
 // Initialize Apptics. Screens are tracked from the URL from here on, route changes included
 Apptics.init(appticsConfig);
 
-AppticsEvents.addEvent('signup', 'onboarding', { plan: 'pro' });
+AppticsEvent.addEvent('signup', 'onboarding', { plan: 'pro' });
 ```
 
-The config object is **required**, with `serviceUrl`, `zak`, `identifier` and `appversion`: `Apptics.init()` won't start without them, and logs a warning naming whatever is missing.
+The config object is **required**, with `base_url`, `auth_key`, `app_domain` and `appversion`: `Apptics.init()` won't start without them, and logs a warning naming whatever is missing.
 
-`Apptics.init()` returns right away. The SDK finishes starting once its storage has loaded, usually within a few milliseconds. Calls you make before that are queued and run in order, so you don't have to wait. If you need to know when it's running, use `await apptics.ready()`.
+`Apptics.init()` returns right away. The SDK finishes starting once its storage has loaded, usually within a few milliseconds. Calls you make before that are queued and run in order, so you don't have to wait. If you need to know when it's running, use `await Apptics.ready()`.
 
-The SDK's objects carry the Android SDK's names — `Apptics`, `AppticsEvents`, `AppticsScreenTracker`, `AppticsApiTracker`, `AppticsLogger`, `AppticsRemoteConfig` — so code reads the same on every platform. CommonJS works too (`const { Apptics } = require('@zoho_apptics/apptics-js-sdk')`). Importing the SDK is safe during server-side rendering: nothing runs until `Apptics.init()` is called in the browser.
+Every call belongs to an object, named after its feature, so you import only the object: `Apptics.init()`, `AppticsEvent.addEvent()`, `AppticsError.trackError()`, `AppticsFeedback.feedbackFormOpen()`. See [The API at a glance](#the-api-at-a-glance). CommonJS works too (`const { Apptics } = require('@zoho_apptics/apptics-js-sdk')`). Importing the SDK is safe during server-side rendering: nothing runs until `Apptics.init()` is called in the browser.
 
 ### With a `<script>` tag (CDN)
 
-Load the browser build and call `Apptics.init()` after it. One `<script>` tag is all it takes: the build
-loads its own stylesheet (`style.css`, from the same CDN folder) for the feedback form.
+Load the browser build and call `Apptics.init()` after it. One `<script>` tag is all it takes: the feedback
+form's styles are inside the build, so there is no stylesheet to add.
 
 ```html
-<script src="https://cdn.jsdelivr.net/npm/@zoho_apptics/apptics-js-sdk@2.0.0-beta/dist/apptics.min.js"></script>
+<script src="https://static.zohocdn.com/apptics-js-sdk/2.0.0-beta.2/apptics.min.js"></script>
 <script>
   Apptics.init({
-    serviceUrl: 'YOUR_SERVICE_URL',
-    zak: 'YOUR_TOKEN',
-    identifier: 'YOUR_IDENTIFIER',
+    base_url: 'YOUR_BASE_URL',
+    auth_key: 'YOUR_AUTH_KEY',
+    app_domain: 'YOUR_APP_DOMAIN',
     appversion: 'YOUR_APPVERSION',   // your app's version
   });
   // screens are tracked from the URL automatically; events are yours to send
-  AppticsEvents.addEvent('signup', 'onboarding', { plan: 'pro' });
+  AppticsEvent.addEvent('signup', 'onboarding', { plan: 'pro' });
 </script>
 ```
 
-The build defines the same names as globals — `Apptics`, `AppticsEvents`, `AppticsScreenTracker`, `AppticsApiTracker`, `AppticsLogger`, `AppticsRemoteConfig`, `AppticsTrackError`, `AppticsSetUser` — so a page's code reads as it would after an import. Everything, every module included (feedback, heatmaps, remote config), is also on `window.apptics`, including `apptics.DefinedEvents` and `apptics.ApiTrackingBuilder`, which have no global of their own. Define `window.appticsReady = () => { … }` to run code once it's ready.
+The build defines the same objects as globals (`Apptics`, `AppticsEvent`, `AppticsScreen`, `AppticsApi`, `AppticsError`, `AppticsUser`, `AppticsSettings`, `AppticsFeedback`, `AppticsLogger`, `AppticsRemoteConfig`, `AppticsHeatmap`), so a page's code reads as it would after an import. Every module is included (feedback, heatmaps, remote config, the remote logger), and everything is also on `window.apptics`. Define `window.appticsReady = () => { … }` to run code once it's ready.
 
 `Apptics.init()` runs exactly once; a second call logs a warning and returns `false`. Calls that track
 or send something are ignored until `Apptics.init()` has run, and the first such call logs a console
 warning saying so.
 
-**Pin the version** (`@2.0.0-beta`) rather than a tag or range such as `@beta`, so a release can't change what your pages load. See [Loading from a CDN](#loading-from-a-cdn) for module builds, unpkg and subresource integrity.
+Each release has its own folder on the CDN, `https://static.zohocdn.com/apptics-js-sdk/{version}/`, so a page keeps loading the version it names until you change it. See [Loading from a CDN](#loading-from-a-cdn) for module builds and subresource integrity.
+
+### The API at a glance
+
+Each feature's calls are on one object:
+
+| Object | Calls | Entry point |
+|---|---|---|
+| `Apptics` | `init(config)`, `ready()`, `flush()`, `reset()`, `enableDebug()`, `disableDebug()` | main |
+| `AppticsEvent` | `addEvent(eventName, groupName, properties?)`, `addEvent(DefinedEvents.X, properties?)`, `setClickTracking(enabled?)`, `DefinedEvents` | main |
+| `AppticsScreen` | `inScreen(screenName, properties?)` → id, `outScreen(id)`, `setScreenTracking(enabled?)` | main |
+| `AppticsError` | `trackError(error, properties?)`, `setErrorTracking(enabled?)` | main |
+| `AppticsUser` | `setUser(userid, groupid?, properties?)`, `getUser()`, `UserBuilder` | main |
+| `AppticsSettings` | `setTrackingStatus(status)`, `getTrackingStatus()`, the `AP_TRACKING_STATUS` constants | main |
+| `AppticsApi` | `startTrackApi(url, method?)` → id, `endTrackApi(id, responseCode, responseMessage?)`, `configure(config)`, `setApiTracking(enabled?)`, `ApiTrackingBuilder` | main |
+| `AppticsHeatmap` | `setHeatmapTracking(enabled?)` | main |
+| `AppticsLogger` | `verbose(message, properties?)`, `debug(message, properties?)`, `info(message, properties?)`, `warn(message, properties?)`, `error(message, properties?)` | `/remote-logger` |
+| `AppticsFeedback` | `feedbackFormOpen(options?)`, `feedbackFormClose()`, `sendFeedback(options?)`, `addFeedbackLog(message)`, `addDiagnosticsInfo(heading, key, value)`, `setFeedbackTheme(theme)`, the `AP_FEEDBACK_TYPE` constants | `/feedback` |
+| `AppticsRemoteConfig` | `fetchValue(name, callback?, coldFetch?)`, `fetchValues(names?, callback?, coldFetch?)`, `setCustomConditionValue(conditionname, value)` | `/remote-config` |
+
+The `set…Tracking(enabled?)` calls switch each automatic tracker on or off while the page runs
+(see [Turning automatic tracking on and off](#turning-automatic-tracking-on-and-off)).
 
 ### Frameworks
 
-React, Vue, Angular, Svelte, Ember, Solid, jQuery and hand-written JS all start the same way, and every one of them needs only that: the SDK follows the route itself ([automatic screen tracking](#automatic-screen-tracking)). To name screens from your router instead, call `AppticsScreenTracker.inScreen()` from the hook in the last column: a call made as the route changes replaces the automatic view, and `track_screen: false` turns the automatic one off altogether, which is what the recipes in `examples/frameworks` do.
+React, Vue, Angular, Svelte, Ember, Solid, jQuery and hand-written JS all start the same way, and every one of them needs only that: the SDK follows the route itself ([automatic screen tracking](#automatic-screen-tracking)). To name screens from your router instead, call `AppticsScreen.inScreen()` from the hook in the last column: a call made as the route changes replaces the automatic view, and `track_screen: false` turns the automatic one off altogether.
 
 | Framework | Start | Screen on navigation, with `track_screen: false` |
 |---|---|---|
 | React, Remix, Gatsby | `useEffect(() => { Apptics.init(config); }, [])` | `useLocation()` in an effect |
-| Vue 3 | a plugin: `app.use(apptics, { router })` | `router.afterEach(to => AppticsScreenTracker.inScreen(to.path))` |
+| Vue 3 | a plugin: `app.use(apptics, { router })` | `router.afterEach(to => AppticsScreen.inScreen(to.path))` |
 | Angular | an injectable service | `router.events` filtered to `NavigationEnd` |
 | Svelte, SvelteKit | `src/hooks.client.ts`, or `onMount` | `afterNavigate` |
 | Ember | an instance initializer | `router.on('routeDidChange', …)` |
 | Next.js | `'use client'` component in the layout | `usePathname()` in an effect |
 | Nuxt 3 | `plugins/apptics.client.ts` | `useRouter().afterEach(…)` |
-| Plain JS, jQuery | the `<script>` tag itself | `AppticsScreenTracker.inScreen()` where you change view |
-
-**Server-side rendering** (Next, Nuxt, SvelteKit, Remix, Angular Universal): importing the SDK on the server is safe — `Apptics.init()` returns `false` instead of throwing — but it tracks nothing there. Start it from a browser-only hook, as the recipes do. There is no Node/server-side tracking: `engines.node` in `package.json` is the floor for building the package and running its CLI.
+| Plain JS, jQuery | the `<script>` tag itself | `AppticsScreen.inScreen()` where you change view |
 
 ## Error Tracking
 
@@ -97,52 +116,77 @@ Uncaught errors and unhandled promise rejections are tracked automatically, as J
 Report an error your code caught:
 
 ```ts
-import { AppticsTrackError } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsError } from '@zoho_apptics/apptics-js-sdk';
 
 try {
   doSomething();
 } catch (error) {
-  AppticsTrackError({ type: 'error', error });
+  AppticsError.trackError({ type: 'error', error });
 }
 ```
 
-`AppticsTrackError` also accepts `error` and `unhandledrejection` events as they are. Turn the automatic tracking off with `enableGlobalErrorHandler(false)`.
+`AppticsError.trackError` also accepts `error` and `unhandledrejection` events as they are, and properties as a second argument.
+
+To record only the errors you report yourself, turn the automatic tracking off, at start-up or
+later. `AppticsError.trackError()` records either way:
+
+```ts
+Apptics.init({ ...config, track_error: false });   // from the start
+AppticsError.setErrorTracking(false);              // or while the page runs; true turns it back on
+```
 
 React, Vue, Angular, SvelteKit and Ember catch render errors themselves, so those never reach `window.onerror`. Report them from the framework's own error hook:
 
 | Framework | Error hook |
 |---|---|
-| React | an error boundary: `componentDidCatch(error) { AppticsTrackError({ type: 'error', error }); }` |
-| Vue 3, Nuxt 3 | `app.config.errorHandler = (error) => AppticsTrackError({ type: 'error', error })` (Nuxt: `nuxtApp.hook('vue:error', …)`) |
-| Angular | an `ErrorHandler` whose `handleError(error)` calls `AppticsTrackError({ type: 'error', error })`, provided as `{ provide: ErrorHandler, useClass: … }` |
+| React | an error boundary: `componentDidCatch(error) { AppticsError.trackError({ type: 'error', error }); }` |
+| Vue 3, Nuxt 3 | `app.config.errorHandler = (error) => AppticsError.trackError({ type: 'error', error })` (Nuxt: `nuxtApp.hook('vue:error', …)`) |
+| Angular | an `ErrorHandler` whose `handleError(error)` calls `AppticsError.trackError({ type: 'error', error })`, provided as `{ provide: ErrorHandler, useClass: … }` |
 | SvelteKit | `handleError({ error })` in `src/hooks.client.ts` |
-| Ember | `Ember.onerror = (error) => AppticsTrackError({ type: 'error', error })` |
+| Ember | `Ember.onerror = (error) => AppticsError.trackError({ type: 'error', error })` |
 
 ## Event Tracking
 
-Track an event, with an optional group and properties:
+Track an event in a group, with optional properties:
 
 ```ts
-import { AppticsEvents } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsEvent } from '@zoho_apptics/apptics-js-sdk';
 
-AppticsEvents.addEvent('eventName', 'eventGroupName', { propKey: 'propValue' });
+AppticsEvent.addEvent('eventName', 'eventGroupName');
+AppticsEvent.addEvent('eventName', 'eventGroupName', { propKey: 'propValue' });
+```
+
+The group is required. An event without one (left out, `''`, or properties in its place, as in
+`addEvent('eventName', { propKey: 'propValue' })`) is not logged, and the console says so, debug
+or not:
+
+```
+AppticsEvent.addEvent: groupName is required for "eventName": addEvent(eventName, groupName, properties?)
 ```
 
 Event and group names start with a letter, followed by letters, digits or `_`, at most 100
-characters, and may not start with `ap_` or `AP_`, which is reserved for defined events. As on
-Android, an event with an invalid name or group is not logged, and the console says why. A group
-left out is `default`.
+characters, and may not start with `ap_` or `AP_`, which is reserved for defined events. An event
+with an invalid name or group is not logged, and the console says why.
+
+Properties: keys start with a letter, followed by up to 49 letters, digits or `_`, and may not
+start with `ap_`. Values are numbers, booleans or strings of up to 250 characters; anything else
+(an object, an array) is sent as its JSON text. A property that breaks these rules
+is dropped and the event is still logged with the rest. At most 24 properties and 7,666
+characters in all; past that the later ones are dropped. The same rules apply to screen and error
+properties.
 
 ### Defined events
 
-Apptics' ready-made events, as Android's `DefinedEvents`, each with its own `AP_` group. They are
+Apptics' ready-made events, each with its own `AP_` group. They are
 not tracked automatically; log the ones that apply:
 
 ```ts
-import { AppticsEvents, DefinedEvents } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsEvent } from '@zoho_apptics/apptics-js-sdk';
+
+const { DefinedEvents } = AppticsEvent;
 
-AppticsEvents.addEvent(DefinedEvents.AP_USER_LOGIN);
-AppticsEvents.addEvent(DefinedEvents.AP_SEARCH, { results: 12 });
+AppticsEvent.addEvent(DefinedEvents.AP_USER_LOGIN);
+AppticsEvent.addEvent(DefinedEvents.AP_SEARCH, { results: 12 });
 ```
 
 | Group | Events |
@@ -153,9 +197,11 @@ AppticsEvents.addEvent(DefinedEvents.AP_SEARCH, { results: 12 });
 | `AP_OTHERS` | `AP_NETWORK_REACHABILITY_CHANGE`, `AP_NETWORK_BANDWIDTH_CHANGE`, `AP_SWITCH_THEME_LIGHT`, `AP_SWITCH_THEME_DARK`, `AP_SWITCH_THEME_CUSTOM`, `AP_SWITCH_ORIENTATION_LANDSCAPE`, `AP_SWITCH_ORIENTATION_PORTRAIT` |
 | `AP_OS` | `AP_OS_UPDATE`, `AP_OS_UNSUPPORTED` |
 
-With a `<script>` tag it is `apptics.DefinedEvents`.
+With a `<script>` tag it is `AppticsEvent.DefinedEvents` too.
+
+### Click tracking
 
-Clicks can also be tracked from markup, without code:
+Clicks can be tracked from attributes in your markup, with no code:
 
 ```html
 <section apgroupaction="checkout">
@@ -163,127 +209,172 @@ Clicks can also be tracked from markup, without code:
 </section>
 ```
 
-Clicking the button, or anything inside it, tracks `buy_clicked` in group `checkout`.
+Clicking the button, or anything inside it, tracks `buy_clicked` in group `checkout`, the nearest
+`apgroupaction` around it, with the properties in `apeventprops` (JSON). An element with no
+`apgroupaction` around it is not tracked, and the console says the group is missing. The `data-`
+spellings work too (`data-apeventaction`, `data-apgroupaction`, `data-apeventprops`), which React
+and TypeScript accept as they are.
+
+#### Turning click tracking off
+
+`track_click: false` in `Apptics.init()`, or `AppticsEvent.setClickTracking(false)` while the page
+runs, stops click tracking from markup. `AppticsEvent.addEvent()` records either way.
+
+```ts
+Apptics.init({ ...config, track_click: false });   // from the start
+AppticsEvent.setClickTracking(true);               // or switch it later
+```
 
-Properties: keys start with a letter, followed by up to 49 letters, digits or `_`, and may not
-start with `ap_`. Values are numbers, booleans or strings of up to 250 characters; anything else
-(an object, an array) is sent as its JSON text. As on Android, a property that breaks these rules
-is dropped and the event is still logged with the rest. At most 24 properties and 7,666
-characters in all; past that the later ones are dropped. The same rules apply to screen and error
-properties.
 
 ## Screen Tracking
 
 Screens are tracked automatically, from the URL (see [below](#automatic-screen-tracking)). To
-record one yourself — with your own name, or with properties — call `AppticsScreenTracker.inScreen`, as on Android:
+record one yourself, with your own name or with properties, call `AppticsScreen.inScreen`:
 
 ```ts
-import { AppticsScreenTracker } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsScreen } from '@zoho_apptics/apptics-js-sdk';
 
-AppticsScreenTracker.inScreen('checkout');
+AppticsScreen.inScreen('checkout');
 ```
 
 Each screen view records how long it lasted. It ends when the next screen starts, when the page
 is hidden (coming back starts a new view of the same screen), or when its session ends.
-`AppticsScreenTracker.inScreen` returns the view's id; hand it to `AppticsScreenTracker.outScreen` to end the view yourself — a dialog
-that closes without the page changing, say — as Android's `AppticsScreenTracker.outScreen` does:
+`AppticsScreen.inScreen` returns the view's id; hand it to `AppticsScreen.outScreen` to end the view yourself (a dialog
+that closes without the page changing, say):
 
 ```ts
-import { AppticsScreenTracker } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsScreen } from '@zoho_apptics/apptics-js-sdk';
 
-const id = AppticsScreenTracker.inScreen('settings');   // when the screen is shown
-AppticsScreenTracker.outScreen(id);                        // when it is dismissed
+const id = AppticsScreen.inScreen('settings');   // when the screen is shown
+AppticsScreen.outScreen(id);                        // when it is dismissed
 ```
 
-`AppticsScreenTracker.inScreen` returns `''` for a name that isn't a valid screen name.
+`AppticsScreen.inScreen` returns `''` for a name that isn't a valid screen name.
 
-Screen names: up to 99 characters of letters, digits, spaces and `. - _ & / :`. Events, errors,
-feedback and heatmap records are attributed to the current screen: the one `AppticsScreenTracker.inScreen()` last
+Screen names: up to 99 characters of letters, digits, spaces and `. - _ & / : *`. Events, errors,
+feedback and heatmap records are attributed to the current screen: the one `AppticsScreen.inScreen()` last
 named, or else the one automatic tracking named from the URL. A heatmap record always has a
-screen view behind it: with automatic tracking off and no `AppticsScreenTracker.inScreen()` call, the first record
+screen view behind it: with automatic tracking off and no `AppticsScreen.inScreen()` call, the first record
 on a page records a view of the page, named the same way from its path, and a new one when the
 path changes.
 
-An `AppticsScreenTracker.inScreen()` call made during a navigation — from a router hook, say —
+An `AppticsScreen.inScreen()` call made during a navigation, from a router hook for example,
 replaces the automatic view of it, so the navigation counts once, under your name. The automatic view waits
 300 ms for such a call before it is recorded; a call after that is a screen view of its own.
 
 ### Automatic screen tracking
 
-On by default: the SDK records screen views from the URL, with no `AppticsScreenTracker.inScreen()` calls. It records the page the SDK starts on, then every navigation: `history.pushState` / `replaceState`
+On by default: the SDK records screen views from the URL, with no `AppticsScreen.inScreen()` calls. It records the page the SDK starts on, then every navigation: `history.pushState` / `replaceState`
 (React Router, Vue Router, Angular, Next.js and other single-page routers), back and forward, and
 `#/` hash routes. The screen is named by its path, without the query string, so `/search?q=shoes`
 is `/search` and `/#/orders` is `/orders`. Characters a screen name can't hold become `_`, and a
 name stops at 99 characters. A plain `#anchor` and a navigation that lands on the same path are
 not new views.
 
-Paths with ids in them make every record its own screen. To give a route your own name —
-`/orders/123` and `/orders/456` as one `Order detail` — call `AppticsScreenTracker.inScreen()` from your router as
-the route changes: that replaces the automatic view of the navigation.
+Paths with ids in them make every record its own screen. `screen_routes` names them instead. Each
+entry is one of three kinds, tried in order; the first that matches names the screen, and a path
+none matches keeps its own name:
+
+| Entry | Matches | Recorded as |
+|---|---|---|
+| `'/users/{id}/orders'` | a route pattern: `{id}`, `:id` and `*` each match one path segment | the pattern, each variable segment as `*` |
+| `{ equals: '/', name: 'Home' }` | that path exactly (a trailing slash does not matter) | `name` |
+| `{ regex: /^\/orders\/\d+$/, name: 'Order detail' }` | any path the regular expression matches (a `RegExp` or its source as a string) | `name` |
 
-**An app that names its screens from its router** keeps doing so with `AppticsScreenTracker.inScreen()`: a call
+```ts
+Apptics.init({
+  ...config,
+  screen_routes: [
+    { equals: '/', name: 'Home' },
+    { regex: /^\/orders\/\d+$/, name: 'Order detail' },
+    '/users/{id}/{id}/orders',
+    '/products/:sku',
+  ],
+});
+```
+
+| Opened | Recorded as |
+|---|---|
+| `/` | `Home` |
+| `/orders/123?tab=items` | `Order detail` (paths are matched without the query string) |
+| `/users/12/34/orders` | `/users/*/*/orders` |
+| `/products/sku-889` | `/products/*` |
+| `/users/12/34/settings` | `/users/12/34/settings` (no entry matches, so the name is kept) |
+
+An entry that can't be used (no `name`, a regex that does not compile) is left out, and
+`Apptics.init()` says which in the console.
+
+**An app that names its screens from its router** keeps doing so with `AppticsScreen.inScreen()`: a call
 within 300 ms of the navigation replaces the automatic view (see
-[Screen Tracking](#screen-tracking)). To track only the screens you name yourself — screens that
-aren't routes, or hooks that run later than that — turn automatic tracking off:
+[Screen Tracking](#screen-tracking)). To track only the screens you name yourself (screens that
+aren't routes, or hooks that run later than that), turn automatic tracking off:
 
 ```ts
 Apptics.init({ ...config, track_screen: false });
 ```
 
-`reset()` takes the history wrappers off; the `Apptics.init()` it runs puts them back.
+or switch it while the page runs, for a part of the app that names its screens itself:
+
+```ts
+AppticsScreen.setScreenTracking(false);   // only inScreen() calls are recorded
+AppticsScreen.setScreenTracking(true);    // back on: the page as it is now is recorded
+```
+
+`Apptics.reset()` takes the history wrappers off; the `Apptics.init()` it runs puts them back.
 
 ## Track User
 
 Register the signed-in user:
 
 ```ts
-import { AppticsSetUser } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsUser } from '@zoho_apptics/apptics-js-sdk';
 
-AppticsSetUser('user-id', 'customer-group-id');   // the group is optional
+AppticsUser.setUser('user-id', 'customer-group-id');   // the group is optional
 ```
 
-`AppticsSetUser` switches tracking to "with PII" (see [Tracking settings](#tracking-settings)). `getUser()` returns the active user.
+`AppticsUser.setUser` switches tracking to "with PII" (see [Tracking settings](#tracking-settings)). `AppticsUser.getUser()` returns the active user.
 
 ### Track User with properties
 
 ```ts
-import { AppticsSetUser, users } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsUser } from '@zoho_apptics/apptics-js-sdk';
 
-const properties = new users.UserBuilder()
+const properties = new AppticsUser.UserBuilder()
   .setFirstName('Ana')
   .setEmailAddress('ana@zylker.com')
   .setPlanType('pro')
   .setCustomProperties({ team: 'design' })
   .build();
 
-AppticsSetUser('user-id', 'customer-group-id', properties);
+AppticsUser.setUser('user-id', 'customer-group-id', properties);
 ```
 
-The builder also has `setLastName`, `setCompanyName`, `setContactNumber`, `setCountry`, `setRegion`, `setCity`, `setGeoLocation`, `setGender`, `setTimezone`, `setLanguage`, `setEngagementScore` and `setDateOfBirth`. `build()` validates the properties against what the server accepts.
+The builder also has `setLastName`, `setCompanyName`, `setContactNumber`, `setCountry`, `setRegion`, `setCity`, `setGeoLocation`, `setGender`, `setTimezone`, `setLanguage`, `setEngagementScore` and `setDateOfBirth`, and `addStringProperty(key, value)`,
+`addNumberProperty` and `addBooleanProperty` for one custom property at a time. `build()` validates the properties against what the server accepts.
 
 ## Tracking settings
 
 Set what the SDK may track for this visitor:
 
 ```ts
-import { setTrackingStatus, AP_TRACKING_STATUS } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsSettings } from '@zoho_apptics/apptics-js-sdk';
 
-setTrackingStatus(AP_TRACKING_STATUS.USAGE_TRACKING_WITHOUT_PII);
+AppticsSettings.setTrackingStatus(AppticsSettings.AP_TRACKING_STATUS.USAGE_TRACKING_WITHOUT_PII);
 ```
 
-| Status | Value | Meaning |
+| `AppticsSettings.AP_TRACKING_STATUS.` | Value | Meaning |
 |---|---|---|
 | `USAGE_TRACKING_WITH_PII` | 1 | Track, with the user's identity |
 | `USAGE_TRACKING_WITHOUT_PII` | 4 | Track anonymously (the default) |
 | `NO_TRACKING` | -1 | Track nothing |
 
-`getTrackingStatus()` returns the current one.
+`AppticsSettings.getTrackingStatus()` returns the current one.
 
 ### Privacy
 
 - The browser's Do Not Track setting is honoured unless `ignore_do_not_track: true` is passed to `Apptics.init()`.
 - Nothing is tracked for known crawlers.
-- Heatmaps name an element from an attribute the author chose (`data-ap-label`, `aria-label`, `name`, `id`, `title`); its visible text is used only with `USAGE_TRACKING_WITH_PII`.
+- Heatmaps name an element from an attribute the author chose (`data-ap-label`, `apeventaction` or `data-apeventaction`, `aria-label`, `name`, `id`, `title`); its visible text is used only with `USAGE_TRACKING_WITH_PII`.
 
 ## API Tracking
 
@@ -294,44 +385,62 @@ Record the API calls your app makes, for the console's API page. Either let the
 Apptics.init({ ...config, track_api: true });   // record every fetch and XHR call
 ```
 
-`enableApiTracking(on)` switches it later. Which hosts and endpoints are recorded is set with
-[`AppticsApiTracker.configure`](#configuring-api-tracking).
+`AppticsApi.setApiTracking(enabled)` switches it later. Which hosts and endpoints are recorded is set with
+[`AppticsApi.configure`](#configuring-api-tracking).
 
-or record calls yourself with `AppticsApiTracker.startTrackApi` / `endTrackApi`, as on Android — the
+or record calls yourself with `AppticsApi.startTrackApi` / `endTrackApi`. The
 SDK times the call between the two:
 
 ```ts
-import { AppticsApiTracker } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsApi } from '@zoho_apptics/apptics-js-sdk';
 
-const id = AppticsApiTracker.startTrackApi('https://api.example.com/orders/42', 'GET');
+const id = AppticsApi.startTrackApi('https://api.example.com/orders/42', 'GET');
 const response = await fetch('https://api.example.com/orders/42');
-AppticsApiTracker.endTrackApi(id, response.status, response.statusText);
+AppticsApi.endTrackApi(id, response.status, response.statusText);
 ```
 
-Between them, automatic tracking and `AppticsApiTracker.startTrackApi` / `endTrackApi` are the
+Between them, automatic tracking and `AppticsApi.startTrackApi` / `endTrackApi` are the
 two ways a call is recorded.
 
 ### Configuring API tracking
 
-Build the rules with `ApiTrackingBuilder` — as `UserBuilder` builds user properties, and with
-the names of Android's `AppticsApiTracker.configure` — and apply them once, before the requests
-they should cover. It works before `Apptics.init()`:
+Build the rules with `AppticsApi.ApiTrackingBuilder` (as `AppticsUser.UserBuilder` builds user
+properties) and apply them once, before the requests they should cover. It works before
+`Apptics.init()`:
 
 ```ts
-import { ApiTrackingBuilder, AppticsApiTracker } from '@zoho_apptics/apptics-js-sdk';
-
-AppticsApiTracker.configure(new ApiTrackingBuilder()
-  .allowOnlyDomains('api.yourapp.com', 'api.yourapp.in', 'api.yourapp.ae')
-  .groupDomains('api.yourapp.*')
-  .ignoreEndpoint('/health', '/ping', '/internal/**')
-  .addPattern('/v2/catalog/{categoryId}/items/{itemId}')
-  .preserveSegments('v1', 'v2')
+import { AppticsApi } from '@zoho_apptics/apptics-js-sdk';
+
+AppticsApi.configure(new AppticsApi.ApiTrackingBuilder()
+  .allowRegex(/^https:\/\/api\.yourapp\.(com|in|ae)\//)       // only your API hosts
+  .allowEquals('https://auth.yourapp.com/token')               // and this one endpoint
+  .ignoreEquals('https://api.yourapp.com/health')              // never this one
+  .ignoreRegex(/\/internal\//)                                 // nor anything under /internal/
   .build());
 ```
 
+Four rules, two kinds by two: an exact URL (`Equals`) or a regular expression (`Regex`), to allow
+or to ignore. Each is tried on the call's URL as `scheme://host[:port]/path`, without its query
+string or fragment, so one rule can name a host, a path or a single endpoint.
+
+| Builder call | Effect |
+|---|---|
+| `allowEquals(...urls)` | Record these URLs exactly, as `'https://api.yourapp.com/orders'` |
+| `allowRegex(...patterns)` | Record the URLs these regular expressions match, as `/^https:\/\/api\.yourapp\.com\//` |
+| `ignoreEquals(...urls)` | Never record these URLs exactly |
+| `ignoreRegex(...patterns)` | Never record the URLs these regular expressions match |
+
+- **Ignore always wins.** Ignore rules are tried first; then, when there are any allow rules, a call
+  must match one of them. With no rules at all, every call is recorded.
+- **Equals** compares whole URLs: the scheme and host are not case-sensitive, a trailing slash and
+  the default port do not matter, a port that is not the default does. It takes full URLs only.
+- **Regex** takes a `RegExp` or its source as a string, and works with any flags.
+- A URL that is not a full http(s) URL, or a regex that does not compile, is left out and the
+  console says why. A second `AppticsApi.configure()` replaces the first.
+
 The rules apply to every call, the ones `track_api` catches and the ones you report yourself.
 
-**Path normalization**, on by default, so calls group by endpoint rather than by id:
+**Path normalization**, always on, so calls group by endpoint rather than by id:
 
 | Called | Recorded as |
 |---|---|
@@ -340,25 +449,11 @@ The rules apply to every call, the ones `track_api` catches and the ones you rep
 | `DELETE /sessions/eyJhbGciOi….….` | `/sessions/*` (JWT) |
 | `GET /products/search?q=shoes` | `/products/search` (the query string is always removed) |
 
-| Builder call | Effect |
-|---|---|
-| `ignoreDomains(...)` / `allowOnlyDomains(...)` | Never record these hosts / record only these |
-| `allowOnlyTLDs('.com', ...)` / `ignoreTLDs('.local', ...)` | Record only / never hosts ending in these |
-| `ignoreDomainPrefixes('dev.', ...)` / `ignoreDomainSuffixes('.cdn.net', ...)` | Never record hosts starting or ending with these |
-| `groupDomains('api.myapp.*', ...)` | Record `api.myapp.com`, `.in`, `.eu`… as one host, `api.myapp.*` |
-| `ignoreEndpoint('/health', '/internal/*', '/users/{id}/x', '/debug/**')` | Never record these paths: exact, `*` or `{name}` for one segment, `**` at the end for everything under it |
-| `addPattern('/v1/accounts/{accountId}')` | Record a matching path as the pattern, each `{name}` as `*`. Tried before auto-detection |
-| `preserveSegments('v1', '404', ...)` | Never turn these segments into `*` |
-| `autoDetection(false)` | Normalize only `addPattern` matches; record every other path as it is |
-
-An ignore rule always wins over an allow list. A second `AppticsApiTracker.configure()` replaces the
-first.
-
 The SDK's own requests are never recorded, and neither are calls to `localhost` or a bare IP
 address: the server only accepts hostnames with a dot and a letters-only suffix, so the SDK drops
-those calls and says so in the console. `enableApiTracking(false)` removes the wrappers again.
-With a `<script>` tag, `AppticsApiTracker` is a global as it is here, alongside
-`apptics.enableApiTracking()` and `new apptics.ApiTrackingBuilder()`.
+those calls and says so in the console. `AppticsApi.setApiTracking(false)` removes the wrappers again.
+With a `<script>` tag, `AppticsApi` is a global as it is here, `AppticsApi.ApiTrackingBuilder`
+included.
 
 ## Remote Config
 
@@ -367,163 +462,235 @@ Read parameters set in the console. Its own entry point, so apps that don't use
 ```ts
 import { AppticsRemoteConfig } from '@zoho_apptics/apptics-js-sdk/remote-config';
 
-// one value, or several with their defaults, as on Android
-const banner = await AppticsRemoteConfig.fetchValue('bannerText');            // null if there is none
-const values = await AppticsRemoteConfig.fetchValues({ primaryColor: '#0b6e4f', maxItems: '10' });
+const banner = await AppticsRemoteConfig.fetchValue('bannerText');         // null if there is none
+const some = await AppticsRemoteConfig.fetchValues(['primaryColor', 'maxItems']);
+// → { primaryColor: '#0b6e4f', maxItems: '10' }
+const all = await AppticsRemoteConfig.fetchValues();                       // every parameter
+const fresh = await AppticsRemoteConfig.fetchValue('bannerText', true);   // coldFetch: asks the server now
 
-// what this device is for a custom criteria the console defines
-AppticsRemoteConfig.setCustomConditionValue('plan_tier', 'gold');
+// for a custom condition: its name, then this device's values, comma separated
+AppticsRemoteConfig.setCustomConditionValue('is_custom', 'custom_color');
 ```
 
+A name the console doesn't have is `null`.
+
+**How a value is chosen.** The SDK goes through the conditions in the order the console lists them
+(`all_condition`), skipping those that don't apply to the parameter. The first one that matches
+this device gives the parameter's value for it; when none matches, the parameter's default value.
+A condition matches when all of its criteria match this device.
+
 Values are text, as the console stores them: `Number(values.maxItems)`,
 `values.showBanner === 'true'` or `JSON.parse(...)` turn them into what the app needs.
 
 The SDK fetches once on its own when it starts (or when this module is imported after it has),
 so values are this session's without a call of yours.
 
-**Fetching.** `fetchValue` and `fetchValues` reuse a fetch from the last five minutes
-rather than asking the server again, so reading a value on every render costs no requests. Pass
-`coldFetch` (`true` as the last argument) to ask the server regardless; that is limited to three
-calls a minute, and a call past it is answered as a failed fetch. Each also takes a callback,
-as on Android, and returns a Promise either way.
+**Fetching.** The first fetch of each page load asks for the whole rule set, and its answer
+replaces what was stored. After that the SDK keeps the values up to date by itself: every 3
+minutes, and when the tab comes back after 15 seconds or more away, it asks only for what changed
+since its last fetch and merges that into the stored set. `fetchValue` and `fetchValues` answer
+from those values, so reading a value on every render costs no requests. Each also takes a
+callback, and returns a Promise either way. To ask the server now instead, see
+[Cold fetch](#cold-fetch).
 
-**When a fetch fails** (offline, or a server error), they answer with the values fetched before.
-`AppticsRemoteConfig.setFallbackWithOfflineValue(false)` makes them answer with `null` — or the defaults
-you passed to `fetchValues` — instead.
+**When a fetch fails** (offline, or a server error), they answer with the values fetched before;
+with none fetched yet, `null` (and `fetchValues()` answers with no parameters).
 
-**Custom conditions.** A console condition can be on a custom criteria — a key with a list of
-values. `setCustomConditionValue(key, value)` says what this device is for that key, and the
-condition matches when the value is one of the listed ones. Values are kept across visits and
-applied at once, without a fetch; an empty value removes one, and `reset()` clears them. It works
-before `Apptics.init()`.
+**Custom conditions.** `setCustomConditionValue(conditionname, value)` says what this device is
+for the custom condition with that name in the console, with several values comma separated
+(`'gold,platinum'`). The condition matches when one of them is one of the values it lists. The
+stored rules are applied again at once, without a fetch; an empty value removes it. Values are for
+this page, so set them as the app starts; it works before `Apptics.init()`, and `Apptics.reset()`
+clears them.
 
-Conditions on the user — the customer group, for one — are re-applied on their own once
-`AppticsSetUser` has registered the user, so the next read answers for them.
+Conditions on the user, such as the customer group, are re-applied on their own once
+`AppticsUser.setUser` has registered the user, so the next read answers for them.
 
 | Call | Notes |
 |---|---|
-| `fetchValue(name, callback?, coldFetch?)` | One parameter for this session; `null` when the console has none. |
-| `fetchValues({ name: default }, callback?, coldFetch?)` | Several at once; each name gets its default when it has no value. |
-| `setFallbackWithOfflineValue(on)` | Whether a failed fetch answers with the values fetched before (default) or with `null` and defaults. |
-| `setCustomConditionValue(key, value)` | What this device is for a custom criteria; an empty value removes it. |
+| `fetchValue(name, callback?, coldFetch?)` | One parameter for this session; `null` when the console has none. `fetchValue(name, coldFetch)` works too. `coldFetch: true` asks the server now (see [Cold fetch](#cold-fetch)). |
+| `fetchValues(names?, callback?, coldFetch?)` | The parameters named in the list, `null` for a missing one; with no names, every parameter. `fetchValues(callback)`, `fetchValues(names, coldFetch)` and `fetchValues(coldFetch)` work too. |
+| `setCustomConditionValue(conditionname, value)` | This device's values for a custom condition, comma separated (`'gold,platinum'`); an empty value removes them. |
 
 With a `<script>` tag, `AppticsRemoteConfig` is a global as it is here.
 
+### Cold fetch
+
+By default `fetchValue` and `fetchValues` answer from the values the page already has, which the
+SDK keeps up to date every 3 minutes. For a value that must be current now, say right after it was
+changed in the console, or before a step that depends on it, pass `true` as the last argument:
+`fetchValue('bannerText', true)`, `fetchValues(['primaryColor', 'maxItems'], true)`,
+`fetchValues(true)` for every parameter, or after a callback, as in
+`fetchValue('bannerText', render, true)`.
+
+What a cold fetch does:
+
+- It asks the server for the whole rule set now (`getupdates` with `flagtime` 0), whatever the page
+  has already fetched, and the answer **replaces** the stored set, as the first fetch of a page
+  load does. The value is then chosen from it as usual, and the SDK's 3-minute updates go on from
+  there.
+- It waits for start-up, and on a first visit for the device to be registered, before asking:
+  calling it straight after `Apptics.init()` is fine.
+- **At most three cold fetches in any minute**, per page. One past that makes no request and
+  answers from the values the page already has, as `coldFetch: false` would; with
+  `console_log: true`, the console says so.
+- Cold fetches made at the same time share one request.
+- If it fails (offline, or a server error), it answers from the values fetched before, or `null`
+  with none fetched yet, as any fetch does.
+
+`coldFetch` is `false` by default. Use it for the moments that need it, not on every read: each
+one is a request for the whole rule set.
+
 ## Remote Logger
 
-Send your app's log lines to the console's Remote Logger page with `AppticsLogger`, as on
-Android: five levels, each taking a tag and a message. The logger is disabled by default; enable
-it first:
+Send your app's log lines to the console's Remote Logger page with `AppticsLogger`, from its own
+entry point (`@zoho_apptics/apptics-js-sdk/remote-logger`) so apps that don't log don't ship it.
+Nothing is logged on its own: only the lines your app writes, at five levels. A line is recorded as it is written, with no
+switch to turn on first:
 
 ```ts
-import { AppticsLogger } from '@zoho_apptics/apptics-js-sdk';
-
-AppticsLogger.enable();
+import { AppticsLogger } from '@zoho_apptics/apptics-js-sdk/remote-logger';
 
-AppticsLogger.v('Boot', 'Verbose');
-AppticsLogger.d('Boot', 'Debug');
-AppticsLogger.i('Checkout', 'Payment started');
-AppticsLogger.w('Checkout', 'Retrying the payment');
-AppticsLogger.e('Checkout', 'Payment failed', { orderId: 42 }, err);
-
-AppticsLogger.disable();   // stops it again
+AppticsLogger.verbose('Cache warmed');
+AppticsLogger.debug('Cart loaded', { items: 3 });
+AppticsLogger.info('Payment started', { orderId: 42, method: 'card' });
+AppticsLogger.warn('Retrying the payment', { attempt: 2 });
+AppticsLogger.error('Payment failed', err);          // an Error as properties: sent with its stack
 ```
 
 | Call | Level on the Remote Logger page |
 |---|---|
-| `AppticsLogger.v(tag, message, ...details)` | 1, Verbose |
-| `AppticsLogger.d(tag, message, ...details)` | 2, Debug |
-| `AppticsLogger.i(tag, message, ...details)` | 3, Info |
-| `AppticsLogger.w(tag, message, ...details)` | 4, Warning |
-| `AppticsLogger.e(tag, message, ...details)` | 5, Error |
-| `AppticsLogger.enable()` / `AppticsLogger.disable()` / `AppticsLogger.isEnabled()` | Start, stop, and check the logger |
-
-The tag leads the message as `[tag] message`; an empty tag adds nothing. Details are appended to the message: an `Error`
-as its stack, anything else as JSON. Each line records the time it was logged and the function,
-file and line that logged it, even when logged before start-up finishes. Lines are stored before
-they are sent and go out in batches of up to 50: a line survives a failed send and a reload, and
-is removed once the server accepts it. At most 1 MB of lines waits at once, oldest dropped first,
-as on Android, and a line is trimmed to 10,000 characters. Nothing is recorded while the server
-has the remote logger switched off, or while tracking is off. `AppticsLogger.disable()` stops it.
-
-Unlike Android, which uploads at the next cold start or on a schedule, lines go out about a
-second after they're logged: a browser tab can close at any moment, and waiting would lose them.
-
-To see the lines in the browser console as well while you develop — Android's `showLogs` —
-pass `show_logs: true` to `Apptics.init()`. It prints each line at its level (`console.debug`, `info`,
-`warn`, `error`), with objects left expandable, whether or not the remote logger is enabled.
-`console_log` is a different switch: it logs the SDK's own activity, not your lines.
-
-### SDK diagnostics
-
-The SDK also reports its own failures to the same page — an event refused for a bad name, a batch
-that never left, a session that couldn't open — tagged with the module it happened in (`Session`,
-`Screen`, `Event`, `API`, `Properties`). It answers "this app reports no data, what is the SDK
-doing out there?" and carries no app data. It is off by default and separate from `AppticsLogger`:
+| `AppticsLogger.verbose(message, properties?)` | 1, Verbose |
+| `AppticsLogger.debug(message, properties?)` | 2, Debug |
+| `AppticsLogger.info(message, properties?)` | 3, Info |
+| `AppticsLogger.warn(message, properties?)` | 4, Warning |
+| `AppticsLogger.error(message, properties?)` | 5, Error |
+
+`properties` is appended to the message: an object as JSON (`Payment started {"orderId":42,"method":"card"}`),
+an `Error` as its stack. Each line records the time it was logged and the function, file and line
+that logged it, even when logged before start-up finishes. Lines are stored before they are sent
+and go out in batches of up to 50: a line survives a failed send and a reload, and is removed once
+the server accepts it. At most 1 MB of lines waits at once, oldest dropped first,
+and a line is trimmed to 10,000 characters. Nothing is recorded while the server has the remote
+logger switched off for the app, or while tracking is off.
+
+Lines go out about a second after they're logged: a browser tab can close at any moment, and waiting would lose them.
+
+## In-App Feedback
+
+The feedback form is its own entry point, so apps that don't use it don't download it. Its
+`AppticsFeedback` has every feedback call: the form, sending without it, and the log and
+diagnostics calls. With a `<script>` tag it is the `AppticsFeedback` global.
+
+### Show feedback screen
 
 ```ts
-Apptics.init({ ...config, remote_log: true });   // turn the SDK's own reports on
+import { AppticsFeedback } from '@zoho_apptics/apptics-js-sdk/feedback';
+
+AppticsFeedback.feedbackFormOpen();     // show the form
+AppticsFeedback.feedbackFormClose();    // close it from your own code, when needed
 ```
 
-## In-App Feedback
+`feedbackFormOpen` takes one options object, which fills the form in for the visitor. Every key is
+optional:
 
-The feedback form is its own entry point, so apps that don't use it don't download it. With a
-`<script>` tag it is already on `window.apptics`.
+```ts
+AppticsFeedback.feedbackFormOpen({
+  type: AppticsFeedback.AP_FEEDBACK_TYPE.BUG,  // the tab it opens on: BUG, FEEDBACK, HELP or REPORT
+  message: 'The checkout button does nothing', // text already in the description
+  includeLog: true,                            // start with the log toggle on
+  includeDiagnostics: true,                    // start with the diagnostics toggle on
+  attachments: [screenshotFile],               // files already attached (a FileList or File[])
+  logFiles: [appLogFile],                      // log files already attached
+  isAnonymous: false,                          // true starts the user picker on Anonymous
+});
+```
 
-### Show feedback screen
+Passing values one after another, as `feedbackFormOpen(type, message)`, opens the form with its
+defaults and a console warning.
+
+The form brings its own styles, with the npm package and the CDN builds alike: the first
+`feedbackFormOpen()` adds them to the page, so there is no stylesheet to import or link.
+
+**Theme:** the form is `light`, `dark`, or `auto` (the default), which follows the visitor's system setting:
 
 ```ts
-import { feedbackOpen, feedbackClose } from '@zoho_apptics/apptics-js-sdk/feedback';
-import '@zoho_apptics/apptics-js-sdk/style.css';
+Apptics.init({ ...config, feedback_theme: 'dark' });
+```
 
-feedbackOpen();     // show the form
-feedbackClose();    // close it from your own code, when needed
+`auto` follows the operating system, not the page. A page with its own light and dark modes tells
+the form which one it shows, whenever that changes; a form that is open is restyled at once:
+
+```ts
+AppticsFeedback.setFeedbackTheme(isDark ? 'dark' : 'light');
+```
+
+The colors are CSS variables on the form, so a page can restyle it without any SDK option. Override them
+where the form is shown, for example to set a brand color:
+
+```css
+.zasdk-modal { --zasdk-primary-color: #0b5d8f; }
 ```
 
-With a bundler, import `style.css` as above. The CDN builds (`apptics.min.js` and
-`feedback.esm.min.js`) load it themselves.
+The main ones are `--zasdk-background-color`, `--zasdk-text-color`, `--zasdk-border-color`,
+`--zasdk-input-background`, `--zasdk-primary-color` (the Send button), `--zasdk-button-text-color`,
+`--zasdk-link-color` and `--zasdk-shadow`.
+
+The form is a modal dialog for keyboards and screen readers: it takes focus when it opens, Escape or
+the close control (with Enter or Space) closes it, and it honours `prefers-reduced-motion`.
 
-The form offers Bug, Feedback, Help and Report, with up to 5 attachments (10 MB total). It offers
-screen recording when the page also loads Zoho Quartz and `Apptics.init()` was given `DC`,
-`quartz_workspace_key` and `quartz_department_key` (see [Configuration](#configuration)).
-Otherwise — or with any of them set to `-` — the recording checkbox and its label are not shown.
+The form offers Feedback (selected by default), Bug, Help and Report, with up to 5 attachments (10 MB total).
 
 ### Send Feedback/Bug Report programmatically
 
 ```ts
-import { sendFeedback } from '@zoho_apptics/apptics-js-sdk/feedback';
-import { AP_FEEDBACK_TYPE } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsFeedback } from '@zoho_apptics/apptics-js-sdk/feedback';
 
 try {
-  await sendFeedback(AP_FEEDBACK_TYPE.BUG, 'Checkout is broken');
+  await AppticsFeedback.sendFeedback({
+    type: AppticsFeedback.AP_FEEDBACK_TYPE.BUG,  // BUG (0), FEEDBACK (1, the default), HELP (2), REPORT (3)
+    message: 'Checkout is broken',
+    attachments: [screenshotFile],               // at most 5, 10 MB in all
+    includeLog: true,                            // the addFeedbackLog() lines
+    includeDiagnostics: true,                    // the addDiagnosticsInfo() entries and the device details
+    isAnonymous: false,                          // true sends it from nobody
+  });
   // sent
 } catch (err) {
   // not sent: the SDK hasn't started (no Apptics.init()), the browser is offline, or the server refused it
 }
 ```
 
-`sendFeedback(type?, message?, attachments?, logFiles?, includeDyninfo?, includeLog?)` returns a
-Promise that resolves once the feedback is sent and rejects when it wasn't. `type` is
-`AP_FEEDBACK_TYPE.BUG` (0), `FEEDBACK` (1), `HELP` (2) or `REPORT` (3).
+`AppticsFeedback.sendFeedback(options?)` takes `type`, `message`, `attachments`, `logFiles`,
+`includeDiagnostics`, `includeLog` and `isAnonymous`, all optional. It is sent from the user
+`AppticsUser.setUser` set, or from nobody with `isAnonymous: true`. It returns a Promise that resolves once the
+feedback is sent and rejects when it wasn't. Passing values one after another, as
+`sendFeedback(type, message)`, rejects rather than send an empty report.
+
+Feedback is sent even when tracking is off (`NO_TRACKING`): the visitor is choosing to send it.
+Only the feedback goes; nothing else is tracked.
 
 ### Attach logs and diagnostics with Feedback
 
 ```ts
-import { addFeedbackLog, addDiagnosticsInfo } from '@zoho_apptics/apptics-js-sdk';
+import { AppticsFeedback } from '@zoho_apptics/apptics-js-sdk/feedback';
 
-addFeedbackLog('token refresh failed, retrying');       // one timestamped line
-addDiagnosticsInfo('Auth', 'scheme', 'oauth');          // grouped key/value
-addDiagnosticsInfo('Auth', 'expiry', 3600);
+AppticsFeedback.addFeedbackLog('token refresh failed, retrying');       // one timestamped line
+AppticsFeedback.addDiagnosticsInfo('Auth', 'scheme', 'oauth');          // grouped key/value
+AppticsFeedback.addDiagnosticsInfo('Auth', 'expiry', 3600);
 ```
 
-Both are on the main entry point, so recording context costs nothing in bundle size for apps that
-never open the form. Nothing is sent as it happens: entries wait in storage until feedback is sent,
+`addDiagnosticsInfo` needs all three: a heading, a key and a value (`0` and `false` count). An
+entry without one is not recorded, and the console says why.
+
+Both calls are on the `/feedback` entry's `AppticsFeedback`, which is where every feedback call
+lives; the main entry point has no `AppticsFeedback`. Nothing is sent as it happens: entries wait in storage until feedback is sent,
 and then travel with it as two text files.
 
 | File | Holds | Sent when |
 |---|---|---|
 | `feedbacklog.txt` | `addFeedbackLog` lines, in order, each prefixed with its ISO timestamp | There are lines, unless `includeLog` is `false` |
-| `dyninfo.txt` | `addDiagnosticsInfo` entries as `[heading]` blocks, then a `[Device Info]` block | There are diagnostics, or `includeDyninfo` is `true` |
+| `dyninfo.txt` | `addDiagnosticsInfo` entries as `[heading]` blocks, then a `[Device Info]` block | There are diagnostics, or `includeDiagnostics` is `true` |
 
 Only the entries a submission actually carried are removed once the server has them, so anything
 recorded while a submission is in flight waits for the next one. Entries older than
@@ -532,37 +699,35 @@ message is truncated at 10,000 characters, and neither file is sent above 2 MB.
 
 ## Heatmaps
 
-Records where people click and how far they scroll, for the console's heatmaps. Its own entry
-point, so an app that doesn't import it ships none of the capture code.
+Records where people click and how far they scroll, for the console's heatmaps. It is on the
+main entry point and off until you turn it on.
 
 ```ts
-import { Apptics } from '@zoho_apptics/apptics-js-sdk';
-import { enableHeatmap } from '@zoho_apptics/apptics-js-sdk/heatmap';
+import { Apptics, AppticsHeatmap } from '@zoho_apptics/apptics-js-sdk';
 
 Apptics.init({ ...config, track_heatmap: true });
-// or turn it on later: enableHeatmap(true)
+// or turn it on later: AppticsHeatmap.setHeatmapTracking(true)
 ```
 
-Importing the module is what makes `track_heatmap` do anything — the flag on its own has nothing
-to switch on. With a `<script>` tag it's already there as `apptics.enableHeatmap()`.
+`track_heatmap: true` in `Apptics.init()` starts capture with the SDK. With a `<script>` tag it's
+`AppticsHeatmap.setHeatmapTracking()` on the `AppticsHeatmap` global.
 
 | Call | Notes |
 |---|---|
-| `enableHeatmap(on?)` | Starts or stops capture. |
+| `AppticsHeatmap.setHeatmapTracking(enabled?)` | Starts or stops capture; `enabled` defaults to `true`. |
 
 Heatmap records go out with the rest of the stored data: on the flush timer, or when you call
-`flush()`.
+`Apptics.flush()`.
 
 A click gives coordinates, normalized position, a label for the element, and whether it was
 clickable, repeated in frustration (`is_rage_click`) or changed nothing (`is_dead_click`).
-Scrolling is coalesced into one record per gesture — direction, duration, velocity and how far
+Scrolling is coalesced into one record per gesture: direction, duration, velocity and how far
 down the page it left you. At most `heatmap_max_per_session` records per visit (default 500),
 then capture pauses.
 
 ## Debugging
 
-Two tools, both off by default: debug mode, which you follow in the Apptics web console, and
-console logs in the browser.
+Debug mode is off by default; you follow it in the Apptics web console.
 
 ### Debug mode
 
@@ -575,98 +740,100 @@ link to the server's logs for that request.
 Apptics.init({ ...config, debug: true });   // start in debug mode
 
 // or turn it on and off at any time
-import { enableDebug, disableDebug } from '@zoho_apptics/apptics-js-sdk';
-
-enableDebug();    // turn debug mode on
-disableDebug();   // and off again
+Apptics.enableDebug();    // turn debug mode on
+Apptics.disableDebug();   // and off again
 ```
 
-`enableDebug()` and `disableDebug()` don't need `Apptics.init()`: call it before `Apptics.init()`, while the SDK starts or at any
+`Apptics.enableDebug()` and `Apptics.disableDebug()` don't need `Apptics.init()`: call it before `Apptics.init()`, while the SDK starts or at any
 time after, and it takes effect at once. What the app chooses this way holds for the rest of the
-page's life, over `debug` in `Apptics.init()` and through `reset()`, so a page whose config turns
-debug mode on can still switch it off with `disableDebug()`. With a `<script>` tag they are
-`apptics.enableDebug()` and `apptics.disableDebug()`.
+page's life, over `debug` in `Apptics.init()` and through `Apptics.reset()`, so a page whose config turns
+debug mode on can still switch it off with `Apptics.disableDebug()`. With a `<script>` tag they are
+the same calls on the `Apptics` global.
 
 Debug mode changes where payloads go, not what is in them. It switches itself off after an hour
 with nothing tracked, so a forgotten tab stops tracing on its own.
 
 | Key / call | Default | Notes |
 |---|---|---|
-| `debug` | `false` | Start in debug mode, unless the app has already called `enableDebug()` or `disableDebug()`. |
-| `enableDebug()` / `disableDebug()` | | Turn debug mode on or off, with or without `Apptics.init()`. |
+| `debug` | `false` | Start in debug mode, unless the app has already called `Apptics.enableDebug()` or `Apptics.disableDebug()`. |
+| `Apptics.enableDebug()` / `Apptics.disableDebug()` | | Turn debug mode on or off, with or without `Apptics.init()`. |
 | `device_name` | unset | Names this device in the debug stream, so testers on the same build can tell their requests apart. Without it, while debug mode is on, a name is made from the browser and OS. |
 
-### Console logs
-
-Log the SDK's activity — what it tracks, stores and sends, and the trace of each debug-mode
-request — to the browser console:
-
-```ts
-Apptics.init({ ...config, console_log: true });
-```
-
 ## Configuration
 
 Everything `Apptics.init(config)` accepts.
 
 | Key | Required | Description |
 |---|---|---|
-| `serviceUrl` | yes | The Apptics host every request goes to, from the Apptics web console (a trailing slash is ignored) |
-| `zak` | yes | The app's token, from the Apptics web console |
-| `identifier` | yes | The app identifier registered in the Apptics web console |
+| `base_url` | yes | The Apptics host every request goes to, from the Apptics web console (a trailing slash is ignored) |
+| `auth_key` | yes | The app's auth key, from the Apptics web console |
+| `app_domain` | yes | The app's domain registered in the Apptics web console, e.g. `com.zylker.web` |
 | `appversion` | yes | Your app's version, e.g. `2.4.0`. No default: everything the SDK reports is tied to the build it came from. Changing it registers the new version |
-| `debug` | | Debug mode: follow requests in the Apptics web console (see [Debugging](#debugging)) |
-| `console_log` | | Log the SDK's activity to the browser console |
-| `ignore_do_not_track` | | Track even when the browser sends Do Not Track |
-| `remote_log` | | `true` makes the SDK report its own failures (see [SDK diagnostics](#sdk-diagnostics)). Off by default |
-| `track_session` | | `false` records no sessions, while events, screens and the rest still are — Android's `automaticSessionsTrackingStatus = false`. On by default |
-| `show_logs` | | Also print the app's `AppticsLogger` lines to the browser console, like Android's `showLogs` (see [Remote Logger](#remote-logger)) |
-| `track_api` | | Record the app's own fetch and XHR calls. Off by default; which hosts and endpoints, through `AppticsApiTracker.configure` (see [API Tracking](#api-tracking)) |
-| `track_heatmap`, `heatmap_max_per_session` | | Record clicks and scrolls (see [Heatmaps](#heatmaps)) |
+| `debug` | | Debug mode: follow requests in the Apptics web console (see [Debugging](#debugging)). Off by default |
+| `ignore_do_not_track` | | Track even when the browser sends Do Not Track. Off by default |
+| `track_api` | | Record the app's own fetch and XHR calls. Off by default; which hosts and endpoints, through `AppticsApi.configure` (see [API Tracking](#api-tracking)) |
+| `track_heatmap` | | Record clicks and scrolls (see [Heatmaps](#heatmaps)). Off by default |
+| `heatmap_max_per_session` | | Most heatmap records one visit may produce: 500 by default, 0 to 10000. Capture pauses past it |
 | `track_screen` | | Record a screen view for every navigation, named by its path. On by default; `false` turns it off (see [Automatic screen tracking](#automatic-screen-tracking)) |
+| `track_error` | | Record uncaught errors and unhandled promise rejections. On by default; `false` turns it off (see [Error Tracking](#error-tracking)) |
+| `track_click` | | Record clicks on elements tagged `apeventaction`. On by default; `false` turns it off (see [Click tracking](#click-tracking)) |
+| `screen_routes` | | How automatic screen tracking names a path: route patterns (`'/users/{id}/orders'`), `{ equals, name }` and `{ regex, name }` rules, tried in order (see [Automatic screen tracking](#automatic-screen-tracking)) |
+| `feedback_theme` | | The feedback form's theme: `'light'`, `'dark'` or `'auto'` (the default, which follows the visitor's system setting). See [Show feedback screen](#show-feedback-screen) |
 | `device_name` | | Names this device in debug mode (see [Debugging](#debugging)) |
-| `DC`, `quartz_workspace_key`, `quartz_department_key` | | Enable Quartz screen recording in the feedback form (`DC`: US, EU, IN, AU, CN, CA, JP, SA, AE; `-` disables). The recording checkbox is shown only when all three are set and the page has loaded Quartz |
 
-The older snippet names are still accepted: `base_domain` for `serviceUrl` and `token` for `zak`.
+The earlier names still work, with a console warning naming the key to use: `serviceUrl` and
+`base_domain` for `base_url`, `zak` and `token` for `auth_key`, and `identifier` for `app_domain`.
 `aaid`, `zsoid` and `projectID` are no longer needed, and are ignored if passed.
 
-### Timing
-
-Data is stored first and sent on a timer, so these control how often the SDK talks to the server. All are optional; a value outside its range is ignored with a warning and the default is used.
+**Changing `base_url`, `app_domain` or `auth_key`.** What the SDK stores in a browser belongs to
+the app it was registered with. When a page starts with a different `base_url`, `app_domain` or
+`auth_key` from the stored data's, the SDK clears all of it, unsent data included, and starts as on
+a first visit: the app version and the device are registered again. Only a short fingerprint of
+`auth_key` is stored, not the key itself.
 
-| Key | Default | Range | Description |
-|---|---|---|---|
-| `batch_flush_interval` | `30000` | 1000 – 3600000 | How often stored data is sent, in milliseconds |
-| `getupdates_interval` | `120000` | 10000 – 86400000 | How often the server's tracking settings are checked, in milliseconds; the server can ask for a longer wait |
-| `batch_size` | `50` | 1 – 500 | Most items in one request (also capped at 1 MB) |
-| `batch_request_timeout` | `7` | 1 – 30 | Days an unsent item is kept before it is dropped |
-| `inactiveduration` | `30` | 1 – 1440 | Idle minutes that end a session |
-| `min_session_duration` | `5000` | 0 – 60000 | Milliseconds a visit must last before its session is recorded; anything tracked sooner records it at once. `0` turns the wait off |
+`Apptics.flush()` sends at most once every 15 seconds, however often it is called: a call sooner
+than that sends nothing, and what is stored goes with the next send.
 
-Data is also sent when you call `flush()`, when the page is hidden, when the tab closes, and when the browser comes back online — the interval is the floor, not the only trigger.
+### Turning automatic tracking on and off
 
-## API reference
+Each tracker the SDK runs on its own has a config key, read when `Apptics.init()` runs, and a call
+to switch it while the page runs. The call takes `true` or `false`; with no argument it means
+`true`.
 
-| Call | Notes |
-|---|---|
-| `Apptics.init(config)` | Starts the SDK. Returns `true` when start-up has begun. |
-| `ready()` | Promise that resolves `true` once the SDK is running (`false` if it can't start). |
-| `AppticsEvents.addEvent(name, group?, props?)` / `AppticsEvents.addEvent(DefinedEvents.X, props?)` / `DefinedEvents` | See [Event Tracking](#event-tracking). |
-| `AppticsScreenTracker.inScreen(name, props?)` → id / `AppticsScreenTracker.outScreen(id)` | See [Screen Tracking](#screen-tracking). |
-| `AppticsTrackError(event, props?)` / `enableGlobalErrorHandler(on)` | See [Error Tracking](#error-tracking). |
-| `AppticsSetUser(userid, groupid?, props?)` / `getUser()` / `users.UserBuilder` | See [Track User](#track-user). |
-| `setTrackingStatus(status)` / `getTrackingStatus()` | See [Tracking settings](#tracking-settings). |
-| `AppticsApiTracker.startTrackApi(url, method?)` / `endTrackApi(id, code, message?)` / `configure(rules)` / `ApiTrackingBuilder` / `enableApiTracking(on?)` | See [API Tracking](#api-tracking). |
-| `AppticsLogger.enable()` / `disable()` / `isEnabled()` / `v / d / i / w / e(tag, message, …)` | See [Remote Logger](#remote-logger). |
-| `AppticsRemoteConfig.fetchValue` / `fetchValues` / `setCustomConditionValue` / `setFallbackWithOfflineValue` | From `/remote-config`; see [Remote Config](#remote-config). |
-| `addFeedbackLog(message)` / `addDiagnosticsInfo(heading, key, value?)` | See [Attach logs and diagnostics](#attach-logs-and-diagnostics-with-feedback). |
-| `flush()` | Send stored data now (engagement, errors and heatmap records); it's otherwise sent every 30 s (see [Timing](#timing)). |
-| `enableDebug()` / `disableDebug()` | See [Debugging](#debugging). |
-| `reset()` | Clear stored identity, queued data and remote config values, then start again. |
-
-Entry points: `@zoho_apptics/apptics-js-sdk` (everything above), `/feedback`, `/remote-config`
-(see [Remote Config](#remote-config)), `/heatmap` and `/style.css`. Types ship with the package:
-`import type { AppticsConfig, TrackingStatus } from '@zoho_apptics/apptics-js-sdk'`.
+| Tracker | Default | Config key | Call |
+|---|---|---|---|
+| Screen views from the URL | on | `track_screen` | `AppticsScreen.setScreenTracking(enabled)` |
+| Uncaught errors and unhandled rejections | on | `track_error` | `AppticsError.setErrorTracking(enabled)` |
+| Clicks on tagged elements | on | `track_click` | `AppticsEvent.setClickTracking(enabled)` |
+| The app's fetch and XHR calls | off | `track_api` | `AppticsApi.setApiTracking(enabled)` |
+| Clicks and scrolls for heatmaps | off | `track_heatmap` | `AppticsHeatmap.setHeatmapTracking(enabled)` |
+
+- The config key decides at start-up. A call made before `Apptics.init()` is replaced by it, and
+  `Apptics.reset()` goes back to the config too.
+- The calls you make yourself (`addEvent`, `inScreen`, `trackError`, `startTrackApi`) record
+  whichever way a switch is set.
+- To stop all tracking for a visitor, use
+  `AppticsSettings.setTrackingStatus(AppticsSettings.AP_TRACKING_STATUS.NO_TRACKING)` instead (see
+  [Tracking settings](#tracking-settings)).
+
+The 2.0.0-beta.1 names of three of these calls still work, with a console warning naming the one to
+use: `AppticsApi.enableApiTracking`, `AppticsError.trackGlobalErrorHandler` and
+`AppticsHeatmap.trackHeatmap`.
+
+### Sessions
+
+A session starts with the visit and goes on while the user comes back to the tab within
+`inactiveduration` minutes (30 by default).
+
+- When the tab goes inactive (hidden, minimised, or its window loses focus to another one), that
+  moment is the session's last active time. Moving focus into an iframe on the page does not count.
+- Back within `inactiveduration`, the same session goes on.
+- Not back by then, the session ends at its last active time and is sent, so the time away is not
+  counted. Coming back later starts a new session.
+- A tab closed while inactive ends its session at its last active time too, not when it closed; a
+  tab closed while in use ends it then.
+- While another tab of the site is still on the session, a tab that goes inactive or closes only
+  leaves it: the last one ends it.
 
 ## Loading from a CDN
 
@@ -674,35 +841,38 @@ For `<script type="module">`, load the minified ESM build (a few requests instea
 
 ```html
 <script type="module">
-  import { Apptics, AppticsEvents } from 'https://cdn.jsdelivr.net/npm/@zoho_apptics/apptics-js-sdk@2.0.0-beta/dist/apptics.esm.min.js';
-  // The feedback form is a separate file, so pages without it don't download it
-  import { feedbackOpen } from 'https://cdn.jsdelivr.net/npm/@zoho_apptics/apptics-js-sdk@2.0.0-beta/dist/feedback.esm.min.js';
+  import { Apptics, AppticsEvent } from 'https://static.zohocdn.com/apptics-js-sdk/2.0.0-beta.2/apptics.esm.min.js';
+  // Feedback, remote config and the remote logger are files of their own, so a page downloads
+  // only the ones it imports
+  import { AppticsFeedback } from 'https://static.zohocdn.com/apptics-js-sdk/2.0.0-beta.2/feedback.esm.min.js';
+  import { AppticsRemoteConfig } from 'https://static.zohocdn.com/apptics-js-sdk/2.0.0-beta.2/remoteconfig.esm.min.js';
+  import { AppticsLogger } from 'https://static.zohocdn.com/apptics-js-sdk/2.0.0-beta.2/remotelogger.esm.min.js';
 
   Apptics.init({
-    serviceUrl: 'YOUR_SERVICE_URL',
-    zak: 'YOUR_TOKEN',
-    identifier: 'YOUR_IDENTIFIER',
+    base_url: 'YOUR_BASE_URL',
+    auth_key: 'YOUR_AUTH_KEY',
+    app_domain: 'YOUR_APP_DOMAIN',
     appversion: 'YOUR_APPVERSION',   // your app's version
   });
   // screens are tracked from the URL automatically
-  AppticsEvents.addEvent('signup', 'onboarding', { plan: 'pro' });
+  AppticsEvent.addEvent('signup', 'onboarding', { plan: 'pro' });
 </script>
 ```
 
 | File | For | Size (gzipped) |
 |---|---|---|
-| `dist/apptics.min.js` | `<script>` pages; sets `window.apptics`, includes every module | ~39 kB |
-| `dist/apptics.esm.min.js` | `<script type="module">`; analytics only (with the `dist/chunks/` files it imports) | ~27 kB |
-| `dist/feedback.esm.min.js` | the feedback form, for module pages | ~11 kB more |
-| `dist/heatmap.esm.min.js` | heatmap capture, for module pages | ~3 kB more |
-| `dist/style.css` | the feedback form's styles; the CDN builds load it themselves | ~3 kB |
+| `apptics.min.js` | `<script>` pages; sets `window.apptics`, includes every module | ~53 kB |
+| `apptics.esm.min.js` | `<script type="module">`; the main entry (with the `chunks/` files it imports) | ~32 kB |
+| `feedback.esm.min.js` | `AppticsFeedback`, the feedback form, for module pages | ~17 kB more |
+| `remoteconfig.esm.min.js` | `AppticsRemoteConfig`, for module pages | ~7 kB more |
+| `remotelogger.esm.min.js` | `AppticsLogger`, for module pages | ~1 kB more |
 
-The module files share one copy of the SDK through `dist/chunks/`, so load them all from the same version and path.
+The module files share one copy of the SDK through the `chunks/` folder beside them, so load them all from the same version's folder.
 
-unpkg works the same way: `https://unpkg.com/@zoho_apptics/apptics-js-sdk@2.0.0-beta/dist/apptics.min.js`. Add `defer` if you don't need the SDK before the page renders. For a subresource-integrity hash:
+Every release is in a folder of its own, `https://static.zohocdn.com/apptics-js-sdk/{version}/`, holding `apptics.min.js`, `apptics.esm.min.js`, `feedback.esm.min.js`, `remoteconfig.esm.min.js`, `remotelogger.esm.min.js`, `chunks/` and the source maps. Add `defer` if you don't need the SDK before the page renders. For a subresource-integrity hash:
 
 ```bash
-curl -s https://cdn.jsdelivr.net/npm/@zoho_apptics/apptics-js-sdk@2.0.0-beta/dist/apptics.min.js \
+curl -s https://static.zohocdn.com/apptics-js-sdk/2.0.0-beta.2/apptics.min.js \
   | openssl dgst -sha384 -binary | openssl base64 -A
 ```
 
@@ -710,51 +880,67 @@ curl -s https://cdn.jsdelivr.net/npm/@zoho_apptics/apptics-js-sdk@2.0.0-beta/dis
 <script src="…/apptics.min.js" integrity="sha384-…" crossorigin="anonymous"></script>
 ```
 
-## Upgrading from 1.0.2
+## Migrating from 1.0.2 to 2.0.0-beta.2
 
 ### What you need to change
 
-- **The calls have the Android SDK's names.** Rename them everywhere, router hooks included: a
+- **Every call is on the object of its feature.** Rename them everywhere, router hooks included: a
   call to an old name left in place throws.
 
-  | 1.0.2 | Now |
+  | 1.0.2 | 2.0.0-beta.2 |
   |---|---|
   | `apptics.init(config)` | `Apptics.init(config)` |
-  | `apptics.trackEvent(name, group, props)` | `AppticsEvents.addEvent(name, group, props)` |
-  | `apptics.trackScreen(name, props)` | `AppticsScreenTracker.inScreen(name, props)`, which also returns the view's id for `AppticsScreenTracker.outScreen(id)` |
-  | `apptics.trackError(event, props)` | `AppticsTrackError(event, props)` |
-  | `apptics.setUser(userid, groupid, props)` | `AppticsSetUser(userid, groupid, props)` |
-
-  The rest — `setTrackingStatus`, `getUser`, `flush`, `reset`, the feedback form — keep their names.
-
-- **`Apptics.init()` takes new config.** Pass `serviceUrl`, `zak`, `identifier` and `appversion`, all required. The SDK gets `aaid` and the portal and project ids from the server itself, so `aaid`/`aaID`, `zsoid` and `projectID` are no longer needed and are ignored if passed. Without a required key, `Apptics.init()` logs which one is missing and returns `false`.
-- **`appversion` is required.** 1.0.2 quietly defaulted it to `1.0`, which attributed every session, error and crash to a version that was never shipped. Pass your real build version.
-- **npm users can import the SDK.** 1.0.2 exported nothing, so it only worked alongside the console snippet. Now:
+  | `apptics.trackEvent(name, group, props)` | `AppticsEvent.addEvent(eventName, groupName, properties)` |
+  | `apptics.trackScreen(name, props)` | `AppticsScreen.inScreen(screenName, properties)`, which also returns the view's id for `AppticsScreen.outScreen(id)` |
+  | `apptics.trackError(event, props)` | `AppticsError.trackError(error, properties)` |
+  | `apptics.enableGlobalErrorHandler(on)` | `AppticsError.setErrorTracking(enabled)`, or `track_error` in `Apptics.init()` |
+  | `apptics.setUser(userid, groupid, props)` | `AppticsUser.setUser(userid, groupid, properties)` |
+  | `apptics.getUser()`, `new users.UserBuilder()` | `AppticsUser.getUser()`, `new AppticsUser.UserBuilder()` |
+  | `apptics.setTrackingStatus(s)`, `getTrackingStatus()` | `AppticsSettings.setTrackingStatus(status)`, `AppticsSettings.getTrackingStatus()` |
+  | `apptics.flush()`, `reset()`, `ready()` | `Apptics.flush()`, `Apptics.reset()`, `Apptics.ready()` |
+  | `apptics.feedbackOpen()`, `feedbackClose()` | `AppticsFeedback.feedbackFormOpen(options)`, `AppticsFeedback.feedbackFormClose()` |
+  | `apptics.sendFeedback(type, message, …)` | `AppticsFeedback.sendFeedback({ type, message, … })`: one options object |
+  | `apptics.addFeedbackLog()`, `addDiagnosticsInfo()` | `AppticsFeedback.addFeedbackLog(message)`, `AppticsFeedback.addDiagnosticsInfo(heading, key, value)` |
+
+- **`Apptics.init()` takes new config.** Pass `base_url`, `auth_key`, `app_domain` and `appversion`, all
+  required (1.0.2's `base_domain` and `token` still work, with a warning). The SDK gets `aaid` and the portal and project ids from the server itself, so
+  `aaid`/`aaID`, `zsoid` and `projectID` are no longer needed and are ignored if passed. Without a
+  required key, `Apptics.init()` logs which one is missing and returns `false`.
+- **Every event needs a group.** 1.0.2 filed an event with no group under `default`; now it is
+  not logged, and the console says the group is missing. Pass one to every
+  `AppticsEvent.addEvent(eventName, groupName, properties?)`, and put an `apgroupaction` around
+  every element tracked with `apeventaction`. Defined events bring their own.
+- **`appversion` is required.** 1.0.2 quietly defaulted it to `1.0`, which attributed every session,
+  error and crash to a version that was never shipped. Pass your real build version.
+- **npm users can import the SDK.** 1.0.2 exported nothing, so it only worked alongside the console
+  snippet. Now:
 
   ```ts
   import { Apptics } from '@zoho_apptics/apptics-js-sdk';
-  Apptics.init({ serviceUrl, zak, identifier, appversion });
+  Apptics.init({ base_url, auth_key, app_domain, appversion });
   ```
 
-- **The feedback form is its own entry point for npm users:** `import { feedbackOpen } from '@zoho_apptics/apptics-js-sdk/feedback'`, plus `import '@zoho_apptics/apptics-js-sdk/style.css'`. `addFeedbackLog()` and `addDiagnosticsInfo()` are on the main entry point. The `<script>` build still has everything on `window.apptics`.
+- **The optional modules are their own entry points for npm users**, so an app ships only what it
+  uses: `AppticsFeedback` from `/feedback` (every feedback call, logs and diagnostics included; the
+  form adds its own styles), `AppticsRemoteConfig` from `/remote-config` and `AppticsLogger` from
+  `/remote-logger`. The `<script>` build has everything, as globals and on `window.apptics`.
 
 ### Behaviour you may notice
 
-- **`debug: true` now turns on debug mode** (requests followed in the Apptics web console). In 1.0.2 it logged to the browser console; that is `console_log: true` now.
-- When the Apptics server tells the SDK to stop tracking an app version, it stops; 1.0.2 ignored that signal.
-- `ignore_do_not_track: true` now ignores the browser's Do Not Track setting; in 1.0.2 it disabled tracking.
-- `mute()` and `unmute()` are gone. To stop tracking, use `setTrackingStatus(AP_TRACKING_STATUS.NO_TRACKING)`; unlike `mute()`, it is stored across visits.
-- **Screens are tracked automatically**, from the URL, including single-page route changes. An `AppticsScreenTracker.inScreen()` called from your router replaces the automatic view of that navigation, so nothing is counted twice; `track_screen: false` turns automatic tracking off. Each screen view now records how long it lasted.
-- **Events and properties follow the Android rules**: an event with an invalid group is not logged (a missing group is still `default`), names and keys may not start with `ap_`, and a bad property is dropped on its own rather than taking the others with it. Booleans arrive as Boolean, and `1` / `0` as Number.
-- Calling `Apptics.init()` a second time is ignored; use `reset()` to start over.
-- `Apptics.init()` still returns at once, but start-up finishes a few milliseconds later, once storage loads, so `window.appticsReady()` fires slightly later than in 1.0.2. Calls made in between are queued and replayed; `await apptics.ready()` waits for it.
-- `sendFeedback()` returns a Promise and takes `includeLog` as a sixth argument. `includeLog` and `includeDyninfo` are three-way: `true` always sends that file, `false` never does, and leaving it unset sends it when something is stored. The form's own log and diagnostics toggles and its data viewer are gone.
+- **`debug: true` now turns on debug mode** (requests followed in the Apptics web console). In 1.0.2 it logged to the browser console.
+- When the Apptics server tells the SDK to stop tracking an app version, it stops; 1.0.2 ignored that signal. Events, screens, sessions, API calls and errors each follow their own switch in the Apptics console, so turning one off leaves the others on.
+- `ignore_do_not_track: true` now ignores the browser's Do Not Track setting; in 1.0.2 it disabled tracking. Do Not Track is decided on every visit and never stored.
+- `mute()` and `unmute()` are gone. To stop tracking, use `AppticsSettings.setTrackingStatus(AppticsSettings.AP_TRACKING_STATUS.NO_TRACKING)`; unlike `mute()`, it is stored across visits. Feedback is still sent with tracking off.
+- **Screens are tracked automatically**, from the URL, including single-page route changes. An `AppticsScreen.inScreen()` called from your router replaces the automatic view of that navigation, so nothing is counted twice; `track_screen: false` turns automatic tracking off, and `screen_routes` names paths. Each screen view now records how long it lasted.
+- **Events and properties are checked**: an event with a missing or invalid group is not logged, names and keys may not start with `ap_`, and a bad property is dropped on its own rather than taking the others with it. Booleans arrive as Boolean, and `1` / `0` as Number. An invalid name is said in the console.
+- Calling `Apptics.init()` a second time is ignored; use `Apptics.reset()` to start over.
+- `Apptics.init()` still returns at once, but start-up finishes a few milliseconds later, once storage loads, so `window.appticsReady()` fires slightly later than in 1.0.2. Calls made in between are queued and replayed; `await Apptics.ready()` waits for it. A first visit with no network starts once the browser is back online.
+- `AppticsFeedback.sendFeedback()` returns a Promise. `includeLog` and `includeDiagnostics` are three-way: `true` always sends that file, `false` never does, and leaving it unset sends it when something is stored.
 - `dyninfo.txt` carries the diagnostics entries and a `[Device Info]` block. Stored feedback logs and diagnostics are capped at 1,000 entries and 10,000 characters per message.
-- The feedback form works without the Quartz script; the screen-recording option is hidden instead.
-- Clicks tracked with `apeventaction` no longer need jQuery.
+- Clicks tracked with `apeventaction` (or `data-apeventaction`) no longer need jQuery.
 - Data moves from localStorage to IndexedDB on the first visit (device identity, consent, unsent events, feedback log entries), and the old keys are removed. Where IndexedDB is unavailable, the SDK keeps using localStorage.
 - Queued data is sent when the page is hidden or closed, using `pagehide` / `visibilitychange` instead of `beforeunload`.
-- New, and off until you use them: heatmaps, remote config, API tracking, the app logger, and the SDK's own failure reports to the Remote Logger page (`remote_log: true`). Remote config, once imported, fetches its values on start-up.
+- New, and off until you use them: heatmaps (`AppticsHeatmap.setHeatmapTracking()`), remote config, API tracking and the remote logger (`AppticsLogger`). Remote config, once imported, fetches its values on start-up.
 
 ## License