From 700749876a6a3910f2f8a1d9073be9d708117c27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matu=CC=81s=CC=8C=20Tomlein?= <matus.tomlein@gmail.com>
Date: Tue, 17 Dec 2024 17:01:03 +0100
Subject: [PATCH 1/9] React native tracker docs updates WIP

---
 .../global-context/index.md                   | 247 +++++++++
 .../custom-tracking-using-schemas/index.md    |  34 --
 .../introduction/index.md                     | 510 ++++++------------
 .../previous-version/index.md                 |   4 +
 .../migrating-from-v2-x-to-v4/index.md        |  22 +
 .../advanced-usage/index.md                   |  57 ++
 .../anonymous-tracking/index.md               |  77 +++
 .../client-side-properties/index.md           | 185 +++++++
 .../custom-tracking-using-schemas/index.md    | 116 ++++
 .../expo/index.md                             |   0
 .../hybrid-apps/index.md                      |  23 +
 .../index.md                                  |  17 +
 .../introduction/index.md                     | 432 +++++++++++++++
 .../quick-start-guide/index.md                | 153 ++++++
 .../exception-tracking/index.md               |   0
 .../tracking-events/index.md                  | 419 ++++++++++++++
 .../installation-tracking/index.md            |  31 ++
 .../lifecycle-tracking/index.md               |  35 ++
 .../platform-and-application-context/index.md | 144 +++++
 .../tracking-events/screen-tracking/index.md  | 107 ++++
 .../tracking-events/session-tracking/index.md | 130 +++++
 .../quick-start-guide/index.md                | 140 +----
 .../tracking-events/index.md                  |  43 +-
 23 files changed, 2391 insertions(+), 535 deletions(-)
 create mode 100644 docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/advanced-usage/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/custom-tracking-using-schemas/index.md
 rename docs/sources/trackers/react-native-tracker/{ => previous-version/react-native-tracker-v2-reference}/expo/index.md (100%)
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/hybrid-apps/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/introduction/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/quick-start-guide/index.md
 rename docs/sources/trackers/react-native-tracker/{ => previous-version/react-native-tracker-v2-reference}/tracking-events/exception-tracking/index.md (100%)
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/installation-tracking/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/lifecycle-tracking/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/platform-and-application-context/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/screen-tracking/index.md
 create mode 100644 docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/session-tracking/index.md

diff --git a/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md b/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md
new file mode 100644
index 0000000000..951597287c
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md
@@ -0,0 +1,247 @@
+---
+title: "Declarative entities with Global Context"
+date: "2022-08-30"
+sidebar_position: 20
+---
+
+# Declarative entities with Global Context
+
+**Global context** lets you define your own contexts once (e.g. on tracker initialization) and then have this context sent with every single event subsequently recorded in the app. This saves having to manually build and send the context array with every single event fired.
+
+Here is an example that adds a global context entity to all subsequently tracked events:
+
+```typescript
+// Create a context entity and add it to global context
+let contextEntity = {
+  schema: 'iglu:com.acme/user_context/jsonschema/1-0-0',
+  data: { userid: 1234, name: 'John Doe' }
+};
+tracker.addGlobalContexts([contextEntity]);
+
+// The global context will be added to this screen view event as well
+tracker.trackScreenViewEvent({ name: 'my-screen-name' });
+```
+
+You may not want to add the same context entity to all tracked events. There are several ways to make global context dynamic:
+
+1. Using a **[context generator](#context-generators)** that generates context entities on the fly when events are sent.
+2. Using **[filter functions](#filter-functions)** that filter which events to add global context entities to.
+3. Using **[rulesets](#rulesets)** that define rules which types of events to accept or reject when generating global context entities.
+
+### Context generators
+
+Generating context on-the-fly is accomplished with **context generators**. A context generator is a callback that will be evaluated with an optional argument that contains useful information.
+
+A sample context generator that conditionally generates a context entity could look like this:
+
+```javascript
+const contextGenerator = (args) => {
+    if (args.eventType == 'pv') {
+        return {
+            schema: 'iglu:com.acme.marketing/some_event/jsonschema/1-0-0',
+            data: { test: 1 },
+        };
+    }
+};
+tracker.addGlobalContexts([contextGenerator]);
+```
+
+The optional input is an associative array that contains three elements:
+
+- `event` : self-describing JSON
+- `eventType` : string
+- `eventSchema` : string (schema URI)
+
+Keep in mind that the arguments `eventType` and `eventSchema` are data found in `event`. `eventType` and `eventSchema` are provided for convenience, so that simple tasks don't require users to search through the event payload.
+
+#### `eventType`
+
+This argument is a string taken from the event payload field, `e`.
+
+`eventType` takes the following values:
+
+| Type                           | `e`       |
+|--------------------------------|-----------|
+| Screen view tracking           | ue        |
+| Pageview tracking              | pv        |
+| Custom structured event        | se        |
+| Custom self describing event   | ue        |
+
+Further information about the event payload can be found in the [tracker protocol documentation](/docs/sources/trackers/snowplow-tracker-protocol/index.md).
+
+#### `eventSchema`
+
+Users should be aware of the behavior of the argument `eventSchema`. Since 'first-class events' (e.g. structured events, transactions, pageviews, etc.) lack a proper schema (their event type is determined by the `e` field), callbacks will be provided the upper-level schema that defines the payload of all events:
+
+`iglu:com.snowplowanalytics.snowplow/payload_data/jsonschema/1-0-4`
+
+For self describing events, `eventSchema` will be the schema that describes the self describing event, not the event payload. Again, this behavior isn't necessarily uniform, but provides more utility to differentiate events.
+
+### Conditional context providers
+
+We can augment context primitives by allowing them to be sent conditionally. While it's possible to define this functionality within context generators (with conditional logic), conditional context providers simplify common ways of sending contexts that follow certain rules.
+
+The general form is an array of two objects:
+
+`[conditional part, context primitive or [array of primitives]]`
+
+The conditional part is standardized into two options:
+
+- a filter function
+- a schema ruleset
+
+### Filter functions
+
+Filter functions take the standard callback arguments defined for context generators, but instead of returning a Self Describing JSON, return a boolean value. As should be expected: `true` will attach the context part, `false` will not attach the context part.
+
+### Example
+
+```javascript
+// A filter that will only attach contexts to structured events
+function structuredEventFilter(args) {
+  return args['eventType'] === 'se';
+}
+var globalContextDefinition = [structuredEventFilter, contextEntityToBeAdded];
+tracker.addGlobalContexts([globalContextDefinition]);
+```
+
+### Rulesets
+
+Rulesets define when to attach context primitives based on the event schema. This follows the standard behavior for all callbacks (the schema used to evaluate is the same provided in `eventSchema`, namely the payload schema for "first-class events" and otherwise the schema found within the self describing event).
+
+Here's the specific structure of a ruleset, it's an object with certain optional rules that take the form of fields, each holding an array of strings:
+
+```json
+{
+    accept: [],
+    reject: []
+}
+```
+
+Some examples, take note that wild-card matching URI path components is defined with an asterisk, `*`, in place of the component:
+
+```javascript
+// Only attaches contexts to this one schema
+var ruleSetAcceptOne = {
+  accept: ['iglu:com.mailchimp/cleaned_email/jsonschema/1-0-0']
+};
+
+// Only attaches contexts to these schemas
+var ruleSetAcceptTwo = {
+  accept: ['iglu:com.mailchimp/cleaned_email/jsonschema/1-0-0',
+  'iglu:com.mailchimp/subscribe/jsonschema/1-0-0']
+};
+
+// Only attaches contexts to schemas with mailchimp vendor
+var ruleSetAcceptVendor = {
+  accept: ['iglu:com.mailchimp/*/jsonschema/*-*-*']
+};
+
+// Only attaches contexts to schemas that aren't mailchimp vendor
+var ruleSetRejectVendor = {
+  reject: ['iglu:com.mailchimp/*/jsonschema/*-*-*']
+};
+
+// Only attach to Snowplow first class events
+var ruleSet = {
+  accept: ['iglu:com.snowplowanalytics.snowplow/payload_data/jsonschema/1-0-4']
+};
+```
+
+You can add a global context entity with a ruleset as follows:
+
+```javascript
+var globalContextDefinition = [ruleSet, contextEntityToAdd];
+tracker.addGlobalContexts([globalContextDefinition]);
+```
+
+### Rule requirements
+
+All rules and schemas follow a standard form:
+
+`protocol:vendor/event_name/format/version`
+
+And rules must meet some requirements to be considered valid:
+
+- Two parts are invariant: protocol and format. They are always `iglu` and `jsonschema` respectively.
+  - Wildcards can therefore be used only in `vendor`, `event_name` and `version`.
+- Version matching must be specified like so: `*-*-*`, where any part of the versioning can be defined, e.g. `1-*-*`, but only sequential parts are to be wildcarded, e.g. `1-*-1` is invalid but `1-*-*` is valid.
+- Vendors require the first two "larger parts":
+  - `com.acme.*`
+- Vendors cannot be defined with non-wildcarded parts between wildcarded parts:
+  - `com.acme.*.marketing.*` is invalid
+  - `com.acme.*.*` is valid
+
+### Named global entities
+
+From version 4 onwards, you can alternatively supply the definitions as a mapping object.
+This associates each global entity with a "name" or "tag" that can be used to reference it in future calls.
+
+For example, in the below we associate a global entity definition with the name `example`, and can then update or remove it by name in later calls.
+
+```javascript
+// add the entity defined by `globalContextDefinition` with the name "example"
+var globalContextDefinition = [ruleSet, contextEntityToAdd];
+tracker.addGlobalContexts({ example: globalContextDefinition });
+
+// update the global entity named "example"; this replaces the entity from `globalContextDefinition`
+var globalContextDefinition2 = [ruleSet, differentContextEntity];
+tracker.addGlobalContexts({ example: globalContextDefinition2 });
+
+// remove the global entity named "example"; it will no longer appear on subsequent events
+tracker.removeGlobalContexts(["example"]);
+```
+
+Names can be whatever makes sense to you, but each name can only be associated with a single entity definition at a time (additions with the same name will replace the previous value).
+The value for the named entity can be the same as unnamed global entities defined with the array method, including generator functions, filter functions, and rulesets and are processed equivalently.
+
+### Global contexts methods
+
+These are the standard methods to add and remove global context entities:
+
+#### `addGlobalContexts`
+To add global contexts:
+
+```javascript
+// unnamed global entities
+tracker.addGlobalContexts([array of global contexts]);
+
+// named global entities
+tracker.addGlobalContexts({
+  name: globalContext1,
+  name2: globalContext2,
+});
+```
+
+#### `removeGlobalContexts`
+
+To remove a global context:
+
+```javascript
+// unnamed global entities
+tracker.removeGlobalContexts([array of global contexts])
+
+// named global entities
+tracker.removeGlobalContexts(["name", "name2"]) // array of entity names
+```
+
+Unnamed global context entities are removed by doing a JSON match of the context to be removed with the added context. So the objects have to be the same in order for them to be matched.
+
+For example:
+
+```javascript
+var entity = {
+  schema: 'iglu:com.acme.marketing/some_event/jsonschema/1-0-0',
+  data: { test: 1 },
+};
+tracker.addGlobalContexts([entity]); // add a global context
+tracker.removeGlobalContexts([entity]); // remove the global context
+```
+
+#### `clearGlobalContexts`
+
+To remove all named and unnamed global context entities:
+
+```javascript
+tracker.clearGlobalContexts();
+```
diff --git a/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md b/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md
index ddf0d74522..73b7032635 100644
--- a/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md
+++ b/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md
@@ -80,37 +80,3 @@ tracker.trackScreenViewEvent(
 ```
 
 It is also possible to add custom contexts globally, so that they are applied to all events within an application. For more information, see the Global Contexts section below.
-
-## Global Contexts
-
-As mentioned in the GCConfiguration section, you can set global contexts when initializing the tracker.
-
-However, as the user journey evolves, you may need to remove or add global contexts at runtime.
-
-### Removing Global Contexts
-
-A set of global contexts is identified by its tag, which was set when the global contexts was added, either as part of tracker initial configuration or manually (see below).
-
-To remove the global contexts associated with a tag, you can use the `removeGlobalContexts` tracker method, which takes as argument the tag. For example:
-
-```typescript
-tracker.removeGlobalContexts('my-old-tag');
-```
-
-### Adding Global Contexts
-
-Similarly, you can add global contexts at runtime using the `addGlobalContexts` tracker method. This method takes as argument the GlobalContext to add.
-
-For example:
-
-```typescript
-tracker.addGlobalContexts({
-    tag: 'my-new-tag',
-    globalContexts: [
-        {
-            schema: 'iglu:com.snowplowanalytics.snowplow/ad_impression/jsonschema/1-0-0',
-            data: {impressionId: 'my-ad-impression-id'},
-        },
-    ]
-});
-```
diff --git a/docs/sources/trackers/react-native-tracker/introduction/index.md b/docs/sources/trackers/react-native-tracker/introduction/index.md
index b11534387f..4224ee6215 100644
--- a/docs/sources/trackers/react-native-tracker/introduction/index.md
+++ b/docs/sources/trackers/react-native-tracker/introduction/index.md
@@ -8,392 +8,194 @@ sidebar_position: 10
 import {versions} from '@site/src/componentVersions';
 ```
 
-The Snowplow React Native Tracker is a module which imports the [Mobile Native Snowplow Trackers](/docs/sources/trackers/mobile-trackers/index.md) as native modules, available for use in React Native projects. More specifically it is built upon the [Mobile Native Trackers v5](/docs/sources/trackers/mobile-trackers/index.md), so as to leverage their tracking capabilities, API and configuration parameters.
+The Snowplow React Native Tracker is purely implemented in JavaScript/TypeScript without the use of native iOS/Android modules. This enables it to support all these platforms and frameworks:
+
+- React Native for mobile and Web
+- Expo Go and managed workflow
 
 <p>The current version is {versions.reactNativeTracker}.</p>
 
 ## Initializing a tracker
 
-The React Native Tracker can be configured with a set of configuration objects. Once you import the module into your app, the `createTracker` function can be used to setup a tracker, which is identified internally by its namespace.
-
-The `createTracker` function can be used to create multiple instances of the tracker in the same app. If you call it using a namespace already used, it will reconfigure the tracker with the same namespace. If you call it with a different namespace, the tracker will create a new independent tracker.
-
-## Configuring the tracker
-
-The configuration objects that are used to initialize a tracker are:
-
-- `NetworkConfiguration`: **Required**. Configures the network connection with the Snowplow collector.
-- `TrackerConfiguration`: **Optional**. Configures the general behavior of the tracker.
-- `SessionConfiguration`: **Optional**. Configures the session behavior.
-- `EmitterConfiguration`: **Optional**. Configures the way the tracker sends events to the collector.
-- `SubjectConfiguration`: **Optional**. Specifies details to send with events about the user and the platform.
-- `GdprConfiguration`: **Optional**. Configures the GDPR context.
-- `GlobalContextsConfiguration`: **Optional**. Configures the GlobalContexts feature.
-
-### NetworkConfiguration
-
-Represents the network communication configuration allowing the tracker to be able to send events to the Snowplow collector.
-
-Its type definition is:
-
-```typescript
-interface NetworkConfiguration {
-  /**
-   * The collector endpoint
-   *  - if the protocol is not included it defaults to https
-   */
-  endpoint: string;
-
-  /**
-   * The Http Method to use when sending events to the collector
-   * @defaultValue 'post'
-   */
-  method?: HttpMethod;
-}
-```
-
-- **endpoint**: (**Required**). URL of the collector that is going to receive the events tracked by the tracker. The URL can include the schema/protocol (e.g.: `http://collector-url.com`). In case the URL doesn’t include the schema/protocol, the HTTPS protocol is automatically selected.
-- **method**: The method used to send the requests (`'get'` or `'post'`). Default is `'post'`.
-
-### TrackerConfiguration
+The React Native Tracker can be configured with a set of configuration objects. Once you import the module into your app, the `newTracker` function can be used to setup a tracker, which is identified internally by its namespace.
 
-Represents the configuration of the tracker and the core tracker properties. The TrackerConfiguration can be used to setup the tracker behavior indicating what should be tracked in terms of automatic tracking and contexts/entities to attach to the events.
-
-Its type definition is:
+The `newTracker` function can be used to create multiple instances of the tracker in the same app. If you call it using a namespace already used, it will reconfigure the tracker with the same namespace. If you call it with a different namespace, the tracker will create a new independent tracker.
 
 ```typescript
-interface TrackerConfiguration {
-  /**
-   * Identifier of the app.
-   */
-  appId?: string;
-  /**
-   * The device platform the tracker runs on.
-   * @defaultValue 'mob'
-   */
-  devicePlatform?: DevicePlatform;
-  /**
-   * Whether payload JSON data should be base64 encoded.
-   * @defaultValue true
-   */
-  base64Encoding?: boolean;
-  /**
-   * The log level of tracker logs.
-   * @defaultValue 'off'
-   */
-  logLevel?: LogLevel;
-  /**
-   * Whether application context is attached to tracked events.
-   * @defaultValue true
-   */
-  applicationContext?: boolean;
-  /**
-   * Whether platform context is attached to tracked events.
-   * @defaultValue true
-   */
-  platformContext?: boolean;
-  /**
-   * Whether geo-location context is attached to tracked events.
-   * @defaultValue false
-   */
-  geoLocationContext?: boolean;
-  /**
-   * Whether session context is attached to tracked events.
-   * @defaultValue true
-   */
-  sessionContext?: boolean;
-  /**
-   * Whether screen context is attached to tracked events.
-   * @defaultValue true
-   */
-  screenContext?: boolean;
-  /**
-   * Whether enable automatic tracking of ScreenView events from the native side.
-   * Only tracking UIKit views on iOS and Activity on Android are supported.
-   * For tracking React Native views, see the tracker docs for manual and auto-tracking options.
-   * @defaultValue false
-   */
-  screenViewAutotracking?: boolean;
-  /**
-   * Whether enable automatic tracking of background and foreground transitions.
-   * @defaultValue false
-   */
-  lifecycleAutotracking?: boolean;
-  /**
-   * Whether enable automatic tracking of install event.
-   * @defaultValue true
-   */
-  installAutotracking?: boolean;
-  /**
-   * Whether enable crash reporting.
-   * @defaultValue true
-   */
-  exceptionAutotracking?: boolean;
-  /**
-   * Whether enable diagnostic reporting.
-   * @defaultValue false
-   */
-  diagnosticAutotracking?: boolean;
-}
-```
-
-- **appId**: Identifier of the app.
-- **devicePlatform**: The device platform the app runs on. Default value: `'mob'`. Allowed platform values are:
-    
-    - `'mob'`: Mobile/Tablet
-    - `'web'`: Web(including mobile web)
-    - `'pc'`: Desktop/Laptop/Netbook
-    
-    - `'srv'`: Server-side app
-    - `'app'`: General app
-    - `'tv'`: Connected TV
-    - `'cnsl'`: Games Console
-    - `'iot'`: Internet of things
-
-- **base64encoding**: It indicates whether the JSON data in the payload should be base64 encoded. Default value: `true`.
-- **logLevel**: The log level of tracker logs. Default value: `'off'`. Allowed logLevel values are:
-    - `'off'`
-    - `'error'`
-    - `'debug'`
-    - `'verbose'`
-- **sessionContext**: Whether session context is sent with all the tracked events. Default value: `true`.
-- **applicationContext**: Whether application context is sent with all the tracked events. Default value: `true`.
-- **platformContext**: Whether mobile/platform context is sent with all the tracked events. Default value: `true`.
-- **geoLocationContext**: Whether geo-location context is sent with all the tracked events. Default value: `false`.
-- **screenContext**: Whether screen context is sent with all the tracked events. Default value: `true`.
-- **screenViewAutotracking**: Whether automatic tracking of ScreenView events from the native side (from UIKit on iOS or Activity on Android) is enabled. Default value: `false`.
-- **lifecycleAutotracking**: Whether automatic tracking of background and foreground transitions is enabled. Default value: `false`.
-- **installAutotracking**: Whether automatic tracking of install event is enabled. Default value: `true`.
-- **exceptionAutotracking**: Whether crash reporting is enabled. Default value: `false`.
-
-### SessionConfiguration
-
-Represents the configuration of the Session context which gets attached to each event tracked and changes based on the timeout set for the inactivity of app when in foreground or background.
-
-Session data is maintained for the life of the application being installed on a device. Essentially it will update if it is not accessed within a configurable timeout.
-
-Its type definition is:
-
-```typescript
-interface SessionConfiguration {
-  /**
-   * The amount of time in seconds before the session id is updated while the app is in the foreground
-   * @defaultValue 1800
-   */
-  foregroundTimeout: number;
-  /**
-   * The amount of time in seconds before the session id is updated while the app is in the background
-   * @defaultValue 1800
-   */
-  backgroundTimeout: number;
-}
-```
-
-- **foregroundTimeout**: The amount of time in seconds that can elapse before the session id is updated while the app is in the foreground. Default value: `1800`
-- **backgroundTimeout**: The amount of time in seconds that can elapse before the session id is updated while the app is in the background. Default value: `1800`
-
-### EmitterConfiguration
+import { newTracker } from '@snowplow/react-native-tracker';
 
-Represents the tracker configuration from the emission perspective. It can be used to setup details about how the tracker should treat the events once they have been processed but not yet sent.
-
-Its type definition is:
-
-```typescript
-interface EmitterConfiguration {
-  /**
-   * The buffer option for post requests.
-   * @defaultValue 'single'
-   */
-  bufferOption?: BufferOption;
-
-  /**
-   * Maximum number of events collected from the EventStore to be sent in a request.
-   * @defaultValue 150
-   */
-  emitRange?: number;
-
-  /**
-   *Maximum number of threads working in parallel in the tracker to send requests.
-   * @defaultValue 15
-   */
-  threadPoolSize?: number;
-
-  /**
-   * Maximum amount of bytes allowed to be sent in a payload in a POST request.
-   * @defaultValue 40000
-   */
-  byteLimitPost?: number;
-
-  /**
-   * Maximum amount of bytes allowed to be sent in a payload in a GET request.
-   * @defaultValue 40000
-   */
-  byteLimitGet?: number;
-}
+const tracker = newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+});
 ```
 
-- **bufferOption**: Sets the emitter's buffer behavior concerning whether the events should be sent instantly or after the buffer has reached it’s limit. Default value: `'single'`. Allowed bufferOption values are:
-    - `'single'`: Sends events instantly.
-    - `'default'`: (Affects only POST method). Sets buffer limit to 10 events.
-    - `'large'`: (Affects only POST method). Sets buffer limit to 25 events.
-- **emitRange**: Maximum number of events collected to be sent in a request. Default value: `150`
-- **threadPoolSize**: Maximum number of threads working in parallel in the tracker to send requests. Default value: `15`
-- **byteLimitGet**: Maximum amount of bytes allowed to be sent in a payload in a GET request. Default value: `40000`
-- **byteLimitPost**: Maximum amount of bytes allowed to be sent in a payload in a POST request. Default value: `40000`
-
-### SubjectConfiguration
-
-Represents the configuration of the subject. The SubjectConfiguration can be used to provide the basic information about the user.
+## Configuring the tracker
 
-Its type definition is:
+The `newTracker` provides a wide range of optional configuration options that let you configure the autotracking functionality of the tracker, specify how requests to the collector should be constructed and much more.
+The following snippet shows an overview of all the options and their meaning:
 
 ```typescript
-interface SubjectConfiguration {
-  /**
-   * user id
-   */
-  userId?: string | null;
-  /**
-   * network user id (UUIDv4)
-   */
-  networkUserId?: string | null;
-  /**
-   * domain user id
-   */
-  domainUserId?: string | null;
-  /**
-   * The custom user-agent. It overrides the user-agent used by default.
-   */
-  useragent?: string | null;
-  /**
-   * IP address
-   */
-  ipAddress?: string | null;
-  /**
-   * The timezone label
-   */
-  timezone?: string | null;
-  /**
-   * The language set in the device
-   */
-  language?: string | null;
-  /**
-   * The screen resolution
-   */
-  screenResolution?: ScreenSize | null;
-  /**
-   * The screen viewport size
-   */
-  screenViewport?: ScreenSize | null;
-  /**
-   * color depth (integer)
-   */
-  colorDepth?: number | null;
-}
+const tracker = newTracker(
+    // Network configuration:
+    // Represents the network communication configuration allowing the tracker to be able to send events to the Snowplow collector.
+
+    // URL of the collector that is going to receive the events tracked by the tracker. The URL can include the schema/protocol (e.g.: `http://collector-url.com`). In case the URL doesn’t include the schema/protocol, the HTTPS protocol is automatically selected.
+    endpoint: COLLECTOR_URL,
+    // HTTP method to use for the requests ('get' or 'post')
+    eventMethod: 'post',
+    // A custom path which will be added to the endpoint URL to specify the complete URL of the collector when paired with the POST method.
+    postPath: 'com.snowplowanalytics.snowplow/tp2',
+    // Custom headers for HTTP requests to the Collector
+    customHeaders: {},
+
+    // Tracker configuration:
+    // Represents the configuration of the tracker and the core tracker properties indicating what should be tracked in terms of automatic tracking and contexts/entities to attach to the events.
+
+    // Identifies the tracker instance
+    namespace: "sp1",
+    // Identifies the application
+    appId: 'my-app-id',
+    // Version of the application (e.g., semver or git commit hash)
+    appVersion: '1.0.0', 
+    // Build number of the application
+    appBuild: '1',
+    // Platform of the device, allowed options are:
+    // - `'mob'`: Mobile/Tablet
+    // - `'web'`: Web(including mobile web)
+    // - `'pc'`: Desktop/Laptop/Netbook
+    // - `'srv'`: Server-side app
+    // - `'app'`: General app
+    // - `'tv'`: Connected TV
+    // - `'cnsl'`: Games Console
+    // - `'iot'`: Internet of things
+    devicePlatform: 'mob',
+    // Whether to base64 encode self-describing event and entity data
+    encodeBase64: false,
+    // Tracks a deep link entity with the first screen view following a deep link received event
+    deepLinkContext: true,
+    // Tracks a screen entity referring to the last screen view event
+    screenContext: true,
+    // Tracks foreground, background events and a lifecycle entity with the app state
+    lifecycleAutotracking: true,
+    // Tracks an install event on the first start
+    installAutotracking: false,
+    // Tracks screen_end event and screen_summary entity with information about the screen activity
+    screenEngagementAutotracking: true,
+
+    // Platform context configuration:
+    // Tracks an entity with information about the device
+    platformContext: true,
+    // Chooses which optional properties of the platform context to track
+    platformContextProperties: [
+        PlatformContextProperty.Carrier,
+        PlatformContextProperty.Language
+    ],
+    // Provides custom functions to retrieve the platform context information
+    platformContextRetriever: {
+        getAppAvailableMemory: () => Promise.resolve(1024),
+    },
+
+    // Tracker plugins – An array of plugins to be used by the tracker
+    plugins: [SnowplowEcommercePlugin()],
+
+    // Session configuration:
+    // Represents the configuration of the Session context which gets attached to each event tracked and changes based on the timeout set for the inactivity of app when in foreground or background.
+
+    // Whether to track session information
+    sessionContext: true,
+    // Timeout for the session when app is in foreground
+    foregroundSessionTimeout: 1800,
+    // Timeout for the session when app is in background
+    backgroundSessionTimeout: 1800,
+
+    // Emitter configuration:
+    // Represents the tracker configuration from the emission perspective. It can be used to setup details about how the tracker should treat the events once they have been processed but not yet sent.
+
+    // Number of events to buffer before making a request to collector
+    bufferSize: 1,
+    // Max size of POST requests
+    maxPostBytes: 40000,
+    // Max size of GET requests
+    maxGetBytes: 40000,
+    // Whether to anonymise server-side user identifiers including the `network_userid` and `user_ipaddress`
+    serverAnonymization: false,
+    // The maximum amount of events that will be buffered in the event store
+    maxEventStoreSize: 1000,
+    // Whether to use AsyncStorage for event store persistence or an in-memory event store
+    useAsyncStorageForEventStore: true,
+
+    // Subject configuration:
+    // Represents the configuration of the subject. The SubjectConfiguration can be used to provide the basic information about the user.
+
+    // The custom user identifier. Commonly used for user self-identification – for example after sign in
+    userId: 'my-user-id',
+    // Override the `network_userid` field assigned by collector. Should contain a valid UUID4 string.
+    networkUserId: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+    // Populates the `domain_userid` field, which is a user identifier generated and tracked by the JavaScript tracker on Web. Should contain a valid UUID4 string.
+    domainUserId: '7cdd5ea8-b0f5-47ea-a8bb-5ec8e98cdbd6',
+    // The custom useragent. It populates the `useragent` field.
+    useragent: 'some-useragent-string',
+    // The IP address of the user. It populates the `user_ipaddress` field.
+    ipAddress: '123.45.67.89',
+    // The current timezone label. Populates the `os_timezone` field.
+    timezone: 'Europe/London',
+    // The language set in the device.
+    language: 'en',
+    // The screen resolution. The screen resolution size can be set as an array of [width, height]. Populates the event fields `dvce_screenwidth` and `dvce_screenheight`.
+    screenResolution: [123, 456],
+    // The screen viewport. The screen viewport size can be set as an array of [width, height]. Populates the event fields `br_viewwidth` and `br_viewheight`.
+    screenViewport: [123, 456],
+    // The color depth. Populates the `br_colordepth` field.
+    colorDepth: 20,
+);
 ```
 
-- **userId**: The custom user identifier. Commonly used for user self-identification – for example after sign in.
-- **networkUserId**: Populates the `network_userid` field. Typically used to link native tracking to in-app browser events tracked using the [JavaScript Tracker](/docs/sources/trackers/javascript-trackers/web-tracker/index.md). Normally one would retrieve the network userid from the browser and pass it to the app. Should contain a valid UUID4 string.
-- **domainUserId**: Populates the `domain_userid` field. Typically used to link native tracking to in-app browser events tracked using the [JavaScript Tracker](/docs/sources/trackers/javascript-trackers/web-tracker/index.md). Normally one would retrieve the domain userid from the browser and pass it to the app. Should contain a valid UUID4 string.
-- **useragent**: The custom useragent. It populates the `useragent` field.
-- **ipAddress**: The IP address of the user. It populates the `user_ipaddress` field.
-- **timezone** (set by the tracker): The current timezone label. Populates the `os_timezone` field.
-- **language** (set by the tracker): The language set in the device.
-- **screenResolution** (set by the tracker): The screen resolution. The screen resolution size can be set as an array of [width, height]. Populates the event fields `dvce_screenwidth` and `dvce_screenheight`.
-- **screenViewport**: The screen viewport. The screen viewport size can be set as an array of [width, height]. Populates the event fields `br_viewwidth` and `br_viewheight`.
-- **colorDepth**: The color depth. Populates the `br_colordepth` field.
-
-Information about the subject can also be set at runtime. In the "Setting the subject" section below, you can find out more about the available tracker methods to do so.
-
-### GdprConfiguration
-
-It represents the GDPR configuration of the tracker, and if set, the tracker will have the respective GDPR context attached to all events.
-
-Its type definition is:
-
-```typescript
-export interface GdprConfiguration {
-  /**
-   * Basis for processing
-   */
-  basisForProcessing: Basis;
-  /**
-   * ID of a GDPR basis document.
-   */
-  documentId: string;
-  /**
-   * Version of the document.
-   */
-  documentVersion: string;
-  /**
-   * Description of the document.
-   */
-  documentDescription: string;
-}
-```
+To learn more about the specific parts of the configuration and autotracked information, see:
 
-- **basisForProcessing**: Required. Represents the basis for processing according to GDPR. Allowed values for `basisForProcessing` are:
-    - `'consent'`
-    - `'contract'`
-    - `'legal_obligation'`
-    - `'legitimate_interests'`
-    - `'public_task'`
-    - `'vital_interests'`
-- **documentId**: Required. The GDPR document id.
-- **documentVersion**: Required. The GDPR document version.
-- **documentDescription**: Required. The GDPR document description.
+- [Platform and application context entities.](/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md)
+- [Session tracking.](/docs/sources/trackers/react-native-tracker/tracking-events/session-tracking/index.md)
+- [App lifecycle tracking.](/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md)
+- [Screen tracking.](/docs/sources/trackers/react-native-tracker/tracking-events/screen-tracking/index.md)
+- [Installation tracking.](/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md)
 
-### GlobalContextsConfiguration
+## Tracker methods
 
-It represents the static Global Contexts which will be attached to all events. Each GlobalContext is identified by a tag and an array of custom contexts.
+### Tracking Events
 
-The relevant type definitions are:
+The React Native Tracker can track a range of out-of-the-box events. As an example, the following snippet tracks a screen view event:
 
-```typescript
-export interface GlobalContext {
-  /**
-   * tag
-   */
-  tag: string,
-  /**
-   * contexts
-   */
-  globalContexts: SelfDescribing[]
-}
-
-/**
- * Global Contexts configuration
- */
-export type GCConfiguration = GlobalContext[];
+```ts
+tracker.trackScreenViewEvent({
+    name: 'my-screen-name',
+    id: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+    type: 'carousel',
+    transitionType: 'basic'
+});
 ```
 
-Global Contexts can also be set (added or removed) at runtime. In the [Adding or removing global contexts](/docs/sources/trackers/react-native-tracker/introduction/index.md#adding-or-removing-global-contexts) section below, you can find out more about the available tracker methods to do so.
+The available events are:
 
-## Tracker methods
-
-### Tracking Events
-
-The React Native Tracker can track the out-of-the-box events as the Mobile Native iOS and Android trackers. The available track methods are:
-
-- **trackSelfDescribingEvent**
-- **trackStructuredEvent**
-- **trackEcommerceTransactionEvent**
-- **trackScreenViewEvent**
-- **trackTimingEvent**
-- **trackConsentGrantedEvent**
-- **trackConsentWithdrawnEvent**
-- **trackPageViewEvent**
+- [Self-describing events.](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md)
+- [Structured events.](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#tracking-structured-events)
+- [Screen view events.](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#tracking-screen-view-events)
+- [Page view events.](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#tracking-page-view-events)
+- [Timing events.](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#tracking-timing-events)
 
 You can find out about all available track methods with details and examples in the [Tracking events](/docs/sources/trackers/react-native-tracker/tracking-events/index.md) section that follows.
 
 ### Adding or removing global contexts
 
-Each set of global contexts is identified by a tag. Through the tag it is possible to add or remove GlobalContexts at runtime. The tracker methods to do so are:
+Global context lets you define your own context entities once and then have them sent with every single event subsequently recorded in the app.
+This saves having to manually build and send the context array with every single event fired and enables you to add entities to autotracked events.
+
+The tracker methods to do so are:
 
 - **addGlobalContexts**
 - **removeGlobalContexts**
+- **clearGlobalContexts**
 
-You can find out more information and examples about how to add or remove global contexts [here](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#global-contexts).
+You can find out more information and examples about how to add or remove global contexts [here](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md).
 
 ### Setting the Subject
 
@@ -412,7 +214,7 @@ It is possible to change subject data at runtime, as the user journey evolves. O
 
 Alternatively, you can use the **setSubjectData** method to provide a new SubjectConfiguration.
 
-You can find out more on how to use the tracker's methods to set the subject information at runtime in the corresponding [Tracking events section](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#setting-the-subject-data).
+You can find out more on how to use the tracker's methods to [set the subject information at runtime here](/docs/sources/trackers/react-native-tracker/client-side-properties/index.md).
 
 ### Getting session context data from the tracker
 
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/index.md b/docs/sources/trackers/react-native-tracker/previous-version/index.md
index c96489853b..189446403e 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/index.md
@@ -6,4 +6,8 @@ sidebar_custom_props:
   outdated: true
 ---
 
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
 
+<DocCardList />
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md b/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
new file mode 100644
index 0000000000..07865c3a17
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
@@ -0,0 +1,22 @@
+---
+title: "Migrating from v2 to v4"
+sidebar_position: 90
+---
+
+
+## Configuration
+
+- User anonymization not available
+- GDPR configuration not available
+- No autotracked application context
+- No geoLocationContext
+- No exceptionAutotracking
+- No diagnosticAutotracking
+- No screen view autotracking
+- No `logLevel`
+- Platform context - less autotracked information
+- `newTracker` instead fo `createTracker`
+  - Rename `method` to `eventMethod`
+  - Rename `requestHeaders` to `customHeaders`
+  - Rename `base64Encoding` to `encodeBase64`
+  - Global contexts moved from configuration
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/advanced-usage/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/advanced-usage/index.md
new file mode 100644
index 0000000000..40d81078be
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/advanced-usage/index.md
@@ -0,0 +1,57 @@
+---
+title: "Advanced usage"
+date: "2021-08-09"
+sidebar_position: 40
+---
+
+## Removing a tracker at runtime
+
+As also mentioned in Introduction, besides the `createTracker` function, the React Native Tracker also provides two functions that allow you to remove a tracker (or all of them) at runtime.
+
+### removeTracker
+
+As each tracker is identified by its namespace, in order to remove a tracker at runtime, you need to pass its namespace to the `removeTracker` function.
+
+For example, assuming an existing tracker with namespace `sp1` :
+
+```javascript
+import { createTracker, removeTracker } from '@snowplow/react-native-tracker';
+
+// ...
+
+removeTracker('sp1');
+```
+
+### removeAllTrackers
+
+The function removeAllTrackers, which accepts no arguments, will remove all trackers created in your app.
+
+```javascript
+import { removeAllTrackers } from '@snowplow/react-native-tracker';
+
+removeAllTrackers();
+```
+
+## Accessing the tracker from native code
+
+Since the Snowplow React Native Tracker is a wrapper around the native trackers for iOS and Android, it is possible to access the underlying iOS and Android trackers in native iOS and Android code. This allows you to:
+
+1. Instantiate a new tracker instance either in React Native or iOS/Android native code.
+2. Track events using the same tracker instance from both React Native code as well as iOS/Android native code.
+
+This is a better approach than creating a separate tracker instance for React Native and for native code because it enables all the events to share the same user and session identifiers.
+
+As an example, we have implemented this setup in [a simple demo app](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid). The app does the following:
+
+1. [Adds a dependency](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/package.json#L3) for the React Native tracker.
+2. [Creates a tracker instance](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/App.tsx#L5) in the React Native code.
+3. [Tracks a screen view event](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/App.tsx#L9) in the React Native code.
+4. [Adds the Android tracker as a dependency](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/android/app/build.gradle#L182-L183) in the Android app.
+5. [Periodically tracks an event](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/android/app/src/main/java/com/snowplowanalytics/reactnativedemohybrid/MainActivity.java#L29-L37) from the Android native code.
+6. [Periodically tracks an event](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/ios/snowplowreactnativedemohybrid/main.m#L9-L15) from the iOS native code.
+
+When accessing the native tracker APIs in Swift, Objective-C, Java, or Kotlin, refer to the documentation for the [mobile trackers](/docs/sources/trackers/mobile-trackers/index.md).
+
+:::note
+Please note that in Android, you will need to add a dependency for the Android tracker to your `build.gradle` inside the Android codebase within your React Native app. Follow the instructions in the [mobile tracker documentation](/docs/sources/trackers/mobile-trackers/index.md). Make sure that you include the same version of the Android tracker as used by the React Native tracker.
+:::
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md
new file mode 100644
index 0000000000..7103e077bb
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md
@@ -0,0 +1,77 @@
+---
+title: "Anonymous Tracking"
+date: "2022-08-30"
+sidebar_position: 25
+---
+
+# Anonymous Tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+:::info
+
+This feature is available since v1.3.
+
+:::
+
+```mdx-code-block
+import AnonymousTrackingSharedBlock from "@site/docs/reusable/anonymous-tracking-mobile/_index.md"
+
+<AnonymousTrackingSharedBlock/>
+```
+There are several levels to the anonymisation depending on which of the three categories are affected:
+
+## 1. Full client-side anonymisation
+
+In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymisation:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {endpoint: COLLECTOR_URL},
+    {
+        trackerConfig: {
+            sessionContext: false, // Session context entity won't be added to events
+            userAnonymisation: true // User identifiers in Platform context (IDFA and IDFV) will be anonymised
+        }
+    }
+);
+```
+
+## 2. Client-side anonymisation with session tracking
+
+This setting disables client-side user identifiers but tracks session information. In practice, this means that events track the Session context entity but the `userId` property is a null UUID (`00000000-0000-0000-0000-000000000000`). In case Platform context is enabled, the IDFA identifiers will not be present.
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {endpoint: COLLECTOR_URL},
+    {
+        trackerConfig: {
+            sessionContext: true, // Session context is tracked with the session ID
+            userAnonymisation: true // User identifiers in Session and Platform context are anonymised
+        }
+    }
+);
+```
+
+## 3. Server-side anonymisation
+
+Server-side anonymisation affects user identifiers set server-side. In particular, these are the `network_userid` property set in server-side cookie and the user IP address. You can anonymise the properties using the `serverAnonymisation` flag in `EmitterConfiguration`:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {endpoint: COLLECTOR_URL},
+    {
+        emitterConfig: {
+            serverAnonymisation: true
+        }
+    }
+);
+```
+
+Setting the flag will add a `SP-Anonymous` HTTP header to requests sent to the Snowplow collector. The Snowplow pipeline will take care of anonymising the identifiers.
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md
new file mode 100644
index 0000000000..4697f11b27
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md
@@ -0,0 +1,185 @@
+---
+title: "Tracking specific client-side properties"
+date: "2022-08-30"
+sidebar_position: 23
+---
+
+# Tracking specific client-side properties
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+An event describes a single, transient activity. The context in which that event occurs - the relatively persistent environment - is also incredibly valuable data. 
+
+The tracker allows to add a persistent set of information through the `SubjectConfiguration` which represents the basic information about the user and the app which will be attached on all the events as context entity.
+
+- **userId** = null: The custom user identifier.
+    
+- **useragent** = null: The custom user-agent. It overrides the user-agent used by default.
+    
+- **ipAddress** = null: The IP address (not automatically set).
+    
+- **timezone** (set by the tracker): The current timezone label.
+    
+- **language** (set by the tracker): The language set in the device.
+    
+- **screenResolution** (set by the tracker): The screen resolution.
+    
+- **screenViewPort** = null: The screen viewport.
+    
+- **colorDepth** = null: The color depth.
+
+
+The fields tracked using `SubjectConfiguration` are relevant in client-side tracking. Some are set automatically in all events during enrichment, even when no _subject_  is added. These properties are marked with `*` below, and discussed below. Timezone, marked with `**`, is only set when a `Subject` is tracked with the event.
+
+Add these fields to an event using `Subject`:
+
+| Property         | Field in raw event | Column(s) in enriched event         |
+|------------------|--------------------|-------------------------------------|
+| userId           | uid                | user_id                             |
+| ipAddress*       | ip                 | user_ipaddress                      |
+| timezone**       | tz                 | os_timezone                         |
+| language         | lang               | br_lang                             |
+| useragent*       | ua                 | useragent                           |
+| viewport         | vp                 | br_viewheight, br_viewwidth         |
+| screenResolution | res                | dvce_screenheight, dvce_screenwidth |
+| colorDepth       | cd                 | br_colordepth                       |
+| networkUserId*   | tnuid              | network_userid                      |
+
+
+As always, be aware of privacy when tracking [personal identifiable information](https://snowplow.io/blog/2020/09/06/user-identification-and-privacy/) such as email addresses or IP addresses.
+The tracker provides anonymous tracking functionality to mask certain user identifiers. Refer to the [section on anonymous tracking to learn more](../anonymous-tracking/index.md).
+
+## Overriding autogenerated event properties
+
+All enriched Snowplow events contain values for `user_ipaddress`, `useragent`, and `network_userid`. 
+
+The `user_ipaddress` is automatically added to all enriched events (unless [anonymous tracking with server anonymisation](../anonymous-tracking/index.md) is enabled). To manually override this, use a `Subject` and set an `ipAddress` string; use an empty string to prevent IP address tracking. Alternatively, use the [IP anonymization enrichment](/docs/pipeline/enrichments/available-enrichments/ip-anonymization-enrichment/index.md).
+
+The `useragent` is also automatically added but it can be overriden on configuration. Snowplow pipelines provide multiple useragent-parsing [enrichments](/docs/pipeline/enrichments/available-enrichments/index.md). To manually override the detected useragent, use a `Subject` and set a `useragent` string.
+
+The `network_userid` is the cookie value for the event collector's third-party cookie. The cookie is named `sp` (or `micro` for Snowplow Micro pipelines). To override the collector cookie’s value with your own generated ID, use a `Subject` object and set `networkUserId`.
+
+The `network_userid` is stored in the tracker and it's kept the same until the app is deleted or the collector endpoint is changed or the cookie is expired. It is not assigned to events if anonymous tracking with server anonymisation is enabled.
+
+## Setting the subject configuration
+
+The client-side properties can be set during tracker initialization using the `subjectConfig` configuration:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+    {
+        subjectConfig: {
+            userId: 'my-user-id',
+        },
+    }
+);
+```
+
+See the the full [list of options in the configuration section](/docs/sources/trackers/react-native-tracker/introduction/index.md#subjectconfiguration).
+
+### Setting the subject data in a tracker instance
+
+It is also possible to set or change the subject properties at runtime, using the `set..` methods of the React Native Tracker. The available methods are:
+
+1. `setUserId`
+
+With this method you can set the userId to a new string. To unset the userId, pass a null value as an argument.
+
+```typescript
+tracker.setUserId('newUser');
+```
+
+2. `setNetworkUserId`
+
+With this method you can set the `network_userid` to a new string(UUIDv4). To unset, pass a null value as an argument.
+
+```typescript
+tracker.setNetworkUserId('44df44bc-8844-4067-9a89-f83c4fe1e62f');
+```
+
+3. `setDomainUserId`
+
+With this method you can set the `domain_userid` to a new string(UUIDv4). To unset, pass a null value as an argument.
+
+```typescript
+tracker.setDomainUserId('0526be47-32cb-44b2-a9e6-fefeaa5ec6fa');
+```
+
+4. `setIpAddress`
+
+With this method you can set the `user_ipaddress` to a new string. To unset, pass a null value as an argument.
+
+```typescript
+tracker.setIpAddress('123.45.67.89');
+```
+
+5. `setUseragent`
+
+With this method you can set the `useragent` to a new string. To unset, pass a null value as an argument.
+
+```typescript
+tracker.setUseragent('some-useragent-string');
+```
+
+6. `setTimezone`
+
+With this method you can set the `os_timezone` to a new string. To unset, pass a null value as an argument.
+
+```typescript
+tracker.setTimezone('Africa/Cairo');
+```
+
+7. `setLanguage`
+
+With this method you can set the `br_lang` to a new string. To unset, pass a null value as an argument.
+
+```typescript
+tracker.setLanguage('fr');
+```
+
+8. `setScreenResolution`
+
+With this method you can set the `dvce_screenwidth` and `dvce_screenheight` fields to new integer values. The argument to this method is an array that represents the ScreenSize as `[width, height]`. For example:
+
+```typescript
+tracker.setScreenResolution([123, 456]);
+```
+
+9. `setScreenViewport`
+
+With this method you can set the `br_viewwidth` and `br_viewheight` fields to new integer values. The argument to this method is an array that represents the ScreenSize as `[width, height]`. For example:
+
+```typescript
+tracker.setScreenViewport([123, 456]);
+```
+
+10. `setColorDepth`
+
+With this method you can set the `br_colordepth` to a new value. For example:
+
+```typescript
+tracker.setColorDepth(20);
+```
+
+Finally, there is an extra "wrapper" method to set may subject properties at once:
+
+- `setSubjectData`
+
+This method accepts as an argument a SubjectConfiguration, with the new values as needed. For example:
+
+```typescript
+tracker.setSubjectData({
+    userId: 'tester',
+    domainUserId: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+    language: 'es',
+    colorDepth: 50,
+    screenResolution: [300, 300],
+});
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/custom-tracking-using-schemas/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/custom-tracking-using-schemas/index.md
new file mode 100644
index 0000000000..ddf0d74522
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/custom-tracking-using-schemas/index.md
@@ -0,0 +1,116 @@
+---
+title: "Custom event tracking"
+date: "2021-08-06"
+sidebar_position: 21
+---
+
+Self-describing (self-referential) JSON schemas are at the core of Snowplow tracking. Read more about them [here](/docs/fundamentals/schemas/index.md). They allow you to track completely customised data, and are also used internally throughout Snowplow pipelines.
+
+In all our trackers, self-describing JSON are used in two places. One is in the `SelfDescribing` event type that wraps custom self-describing JSONs for sending. The second use is to attach entities to any tracked event.
+The entities can describe the context in which the event happen or provide extra information to better describe the event.
+
+## Tracking self-describing events
+
+```mdx-code-block
+import DefineCustomEvent from "@site/docs/reusable/define-custom-event/_index.md"
+
+<DefineCustomEvent/>
+```
+
+A Self Describing event is a [self-describing JSON](http://snowplowanalytics.com/blog/2014/05/15/introducing-self-describing-jsons/).
+
+**Required properties**
+
+- `schema`: (string) – A valid Iglu schema path. This must point to the location of the custom event’s schema, of the format: `iglu:{vendor}/{name}/{format}/{version}`.
+- `data`: (object) – The custom data for your event. This data must conform to the schema specified in the `schema` argument, or the event will fail validation and become a [failed event](/docs/fundamentals/failed-events/index.md).
+
+To track a custom self-describing event, use the `trackSelfDescribingEvent` method of the tracker.
+
+For example, to track a link-click event, which is one whose schema is already published in [Iglu Central](https://github.com/snowplow/iglu-central):
+
+```typescript
+tracker.trackSelfDescribingEvent({
+    schema: 'iglu:com.snowplowanalytics.snowplow/link_click/jsonschema/1-0-1',
+    data: {targetUrl: 'http://a-target-url.com'}
+});
+```
+
+### Tracking a custom entity
+
+```mdx-code-block
+import DefineCustomEntity from "@site/docs/reusable/define-custom-entity/_index.md"
+
+<DefineCustomEntity/>
+```
+
+Custom contexts can be optionally added as an extra argument to any of the Tracker’s `track..()` methods.
+
+**Note:** Even if only one custom context is being attached to an event, it still needs to be wrapped in an array. Also an empty array is acceptable, which will attach no entities to the event.
+
+For example, a custom context to describe a screen could be:
+
+```typescript
+const myScreenContext: EventContext = {
+    schema: 'iglu:com.example/screen/jsonschema/1-2-1',
+    data: {
+        screenType: 'test',
+        lastUpdated: '2021-06-11'
+    }
+};
+```
+
+Another example custom context to describe a user on a screen could be:
+
+```typescript
+const myUserEntity: EventContext = {
+    schema: 'iglu:com.example/user/jsonschema/2-0-0',
+    data: {
+        userType: 'tester'
+    }
+};
+```
+
+Then, to track, for example, a screenViewEvent with both of these contexts attached:
+
+```typescript
+tracker.trackScreenViewEvent(
+   { name: 'myScreenName' },
+   [ myScreenContext, myUserEntity ]
+);
+```
+
+It is also possible to add custom contexts globally, so that they are applied to all events within an application. For more information, see the Global Contexts section below.
+
+## Global Contexts
+
+As mentioned in the GCConfiguration section, you can set global contexts when initializing the tracker.
+
+However, as the user journey evolves, you may need to remove or add global contexts at runtime.
+
+### Removing Global Contexts
+
+A set of global contexts is identified by its tag, which was set when the global contexts was added, either as part of tracker initial configuration or manually (see below).
+
+To remove the global contexts associated with a tag, you can use the `removeGlobalContexts` tracker method, which takes as argument the tag. For example:
+
+```typescript
+tracker.removeGlobalContexts('my-old-tag');
+```
+
+### Adding Global Contexts
+
+Similarly, you can add global contexts at runtime using the `addGlobalContexts` tracker method. This method takes as argument the GlobalContext to add.
+
+For example:
+
+```typescript
+tracker.addGlobalContexts({
+    tag: 'my-new-tag',
+    globalContexts: [
+        {
+            schema: 'iglu:com.snowplowanalytics.snowplow/ad_impression/jsonschema/1-0-0',
+            data: {impressionId: 'my-ad-impression-id'},
+        },
+    ]
+});
+```
diff --git a/docs/sources/trackers/react-native-tracker/expo/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/expo/index.md
similarity index 100%
rename from docs/sources/trackers/react-native-tracker/expo/index.md
rename to docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/expo/index.md
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/hybrid-apps/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/hybrid-apps/index.md
new file mode 100644
index 0000000000..28e010d883
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/hybrid-apps/index.md
@@ -0,0 +1,23 @@
+---
+title: "Hybrid Apps"
+date: "2022-08-30"
+sidebar_position: 70
+---
+
+# Hybrid Apps
+
+:::info
+
+This feature is available since v1.3.
+
+:::
+
+Hybrid apps are mobile apps that in addition to a React Native interface, provide part of the UI through an embedded Web view. Snowplow events are tracked from both the React Native code as well as the Web view. Our goal is to have both events tracked from both places to share the same session and appear as tracked with the same tracker.
+
+## WebView Tracker
+
+This use case is supported by implementing the [Snowplow WebView tracker](../../../../webview-tracker/index.md) in the Web view in your app. The WebView tracker is able to pass events to the React Native tracker which sends them to the collector.
+
+## Mobile & Hybrid Accelerator
+
+Please refer to the [Snowplow Hybrid Apps Tracking accelerator](https://docs.snowplow.io/accelerators/hybrid) for a step-by-step guide how to set up tracking in hybrid apps.
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md
new file mode 100644
index 0000000000..860621d955
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md
@@ -0,0 +1,17 @@
+---
+title: "React Native Tracker v2 reference"
+date: "2020-07-09"
+sidebar_position: 290
+---
+
+```mdx-code-block
+import Badges from '@site/src/components/Badges';
+
+<Badges badgeType="Actively Maintained"></Badges>&nbsp;<Badges badgeType="React Native Tracker Release"></Badges>&nbsp;<Badges badgeType="Snowplow Tracker React Native Release"></Badges>
+```
+
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/introduction/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/introduction/index.md
new file mode 100644
index 0000000000..b11534387f
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/introduction/index.md
@@ -0,0 +1,432 @@
+---
+title: "Introduction and configuration"
+date: "2021-08-06"
+sidebar_position: 10
+---
+
+```mdx-code-block
+import {versions} from '@site/src/componentVersions';
+```
+
+The Snowplow React Native Tracker is a module which imports the [Mobile Native Snowplow Trackers](/docs/sources/trackers/mobile-trackers/index.md) as native modules, available for use in React Native projects. More specifically it is built upon the [Mobile Native Trackers v5](/docs/sources/trackers/mobile-trackers/index.md), so as to leverage their tracking capabilities, API and configuration parameters.
+
+<p>The current version is {versions.reactNativeTracker}.</p>
+
+## Initializing a tracker
+
+The React Native Tracker can be configured with a set of configuration objects. Once you import the module into your app, the `createTracker` function can be used to setup a tracker, which is identified internally by its namespace.
+
+The `createTracker` function can be used to create multiple instances of the tracker in the same app. If you call it using a namespace already used, it will reconfigure the tracker with the same namespace. If you call it with a different namespace, the tracker will create a new independent tracker.
+
+## Configuring the tracker
+
+The configuration objects that are used to initialize a tracker are:
+
+- `NetworkConfiguration`: **Required**. Configures the network connection with the Snowplow collector.
+- `TrackerConfiguration`: **Optional**. Configures the general behavior of the tracker.
+- `SessionConfiguration`: **Optional**. Configures the session behavior.
+- `EmitterConfiguration`: **Optional**. Configures the way the tracker sends events to the collector.
+- `SubjectConfiguration`: **Optional**. Specifies details to send with events about the user and the platform.
+- `GdprConfiguration`: **Optional**. Configures the GDPR context.
+- `GlobalContextsConfiguration`: **Optional**. Configures the GlobalContexts feature.
+
+### NetworkConfiguration
+
+Represents the network communication configuration allowing the tracker to be able to send events to the Snowplow collector.
+
+Its type definition is:
+
+```typescript
+interface NetworkConfiguration {
+  /**
+   * The collector endpoint
+   *  - if the protocol is not included it defaults to https
+   */
+  endpoint: string;
+
+  /**
+   * The Http Method to use when sending events to the collector
+   * @defaultValue 'post'
+   */
+  method?: HttpMethod;
+}
+```
+
+- **endpoint**: (**Required**). URL of the collector that is going to receive the events tracked by the tracker. The URL can include the schema/protocol (e.g.: `http://collector-url.com`). In case the URL doesn’t include the schema/protocol, the HTTPS protocol is automatically selected.
+- **method**: The method used to send the requests (`'get'` or `'post'`). Default is `'post'`.
+
+### TrackerConfiguration
+
+Represents the configuration of the tracker and the core tracker properties. The TrackerConfiguration can be used to setup the tracker behavior indicating what should be tracked in terms of automatic tracking and contexts/entities to attach to the events.
+
+Its type definition is:
+
+```typescript
+interface TrackerConfiguration {
+  /**
+   * Identifier of the app.
+   */
+  appId?: string;
+  /**
+   * The device platform the tracker runs on.
+   * @defaultValue 'mob'
+   */
+  devicePlatform?: DevicePlatform;
+  /**
+   * Whether payload JSON data should be base64 encoded.
+   * @defaultValue true
+   */
+  base64Encoding?: boolean;
+  /**
+   * The log level of tracker logs.
+   * @defaultValue 'off'
+   */
+  logLevel?: LogLevel;
+  /**
+   * Whether application context is attached to tracked events.
+   * @defaultValue true
+   */
+  applicationContext?: boolean;
+  /**
+   * Whether platform context is attached to tracked events.
+   * @defaultValue true
+   */
+  platformContext?: boolean;
+  /**
+   * Whether geo-location context is attached to tracked events.
+   * @defaultValue false
+   */
+  geoLocationContext?: boolean;
+  /**
+   * Whether session context is attached to tracked events.
+   * @defaultValue true
+   */
+  sessionContext?: boolean;
+  /**
+   * Whether screen context is attached to tracked events.
+   * @defaultValue true
+   */
+  screenContext?: boolean;
+  /**
+   * Whether enable automatic tracking of ScreenView events from the native side.
+   * Only tracking UIKit views on iOS and Activity on Android are supported.
+   * For tracking React Native views, see the tracker docs for manual and auto-tracking options.
+   * @defaultValue false
+   */
+  screenViewAutotracking?: boolean;
+  /**
+   * Whether enable automatic tracking of background and foreground transitions.
+   * @defaultValue false
+   */
+  lifecycleAutotracking?: boolean;
+  /**
+   * Whether enable automatic tracking of install event.
+   * @defaultValue true
+   */
+  installAutotracking?: boolean;
+  /**
+   * Whether enable crash reporting.
+   * @defaultValue true
+   */
+  exceptionAutotracking?: boolean;
+  /**
+   * Whether enable diagnostic reporting.
+   * @defaultValue false
+   */
+  diagnosticAutotracking?: boolean;
+}
+```
+
+- **appId**: Identifier of the app.
+- **devicePlatform**: The device platform the app runs on. Default value: `'mob'`. Allowed platform values are:
+    
+    - `'mob'`: Mobile/Tablet
+    - `'web'`: Web(including mobile web)
+    - `'pc'`: Desktop/Laptop/Netbook
+    
+    - `'srv'`: Server-side app
+    - `'app'`: General app
+    - `'tv'`: Connected TV
+    - `'cnsl'`: Games Console
+    - `'iot'`: Internet of things
+
+- **base64encoding**: It indicates whether the JSON data in the payload should be base64 encoded. Default value: `true`.
+- **logLevel**: The log level of tracker logs. Default value: `'off'`. Allowed logLevel values are:
+    - `'off'`
+    - `'error'`
+    - `'debug'`
+    - `'verbose'`
+- **sessionContext**: Whether session context is sent with all the tracked events. Default value: `true`.
+- **applicationContext**: Whether application context is sent with all the tracked events. Default value: `true`.
+- **platformContext**: Whether mobile/platform context is sent with all the tracked events. Default value: `true`.
+- **geoLocationContext**: Whether geo-location context is sent with all the tracked events. Default value: `false`.
+- **screenContext**: Whether screen context is sent with all the tracked events. Default value: `true`.
+- **screenViewAutotracking**: Whether automatic tracking of ScreenView events from the native side (from UIKit on iOS or Activity on Android) is enabled. Default value: `false`.
+- **lifecycleAutotracking**: Whether automatic tracking of background and foreground transitions is enabled. Default value: `false`.
+- **installAutotracking**: Whether automatic tracking of install event is enabled. Default value: `true`.
+- **exceptionAutotracking**: Whether crash reporting is enabled. Default value: `false`.
+
+### SessionConfiguration
+
+Represents the configuration of the Session context which gets attached to each event tracked and changes based on the timeout set for the inactivity of app when in foreground or background.
+
+Session data is maintained for the life of the application being installed on a device. Essentially it will update if it is not accessed within a configurable timeout.
+
+Its type definition is:
+
+```typescript
+interface SessionConfiguration {
+  /**
+   * The amount of time in seconds before the session id is updated while the app is in the foreground
+   * @defaultValue 1800
+   */
+  foregroundTimeout: number;
+  /**
+   * The amount of time in seconds before the session id is updated while the app is in the background
+   * @defaultValue 1800
+   */
+  backgroundTimeout: number;
+}
+```
+
+- **foregroundTimeout**: The amount of time in seconds that can elapse before the session id is updated while the app is in the foreground. Default value: `1800`
+- **backgroundTimeout**: The amount of time in seconds that can elapse before the session id is updated while the app is in the background. Default value: `1800`
+
+### EmitterConfiguration
+
+Represents the tracker configuration from the emission perspective. It can be used to setup details about how the tracker should treat the events once they have been processed but not yet sent.
+
+Its type definition is:
+
+```typescript
+interface EmitterConfiguration {
+  /**
+   * The buffer option for post requests.
+   * @defaultValue 'single'
+   */
+  bufferOption?: BufferOption;
+
+  /**
+   * Maximum number of events collected from the EventStore to be sent in a request.
+   * @defaultValue 150
+   */
+  emitRange?: number;
+
+  /**
+   *Maximum number of threads working in parallel in the tracker to send requests.
+   * @defaultValue 15
+   */
+  threadPoolSize?: number;
+
+  /**
+   * Maximum amount of bytes allowed to be sent in a payload in a POST request.
+   * @defaultValue 40000
+   */
+  byteLimitPost?: number;
+
+  /**
+   * Maximum amount of bytes allowed to be sent in a payload in a GET request.
+   * @defaultValue 40000
+   */
+  byteLimitGet?: number;
+}
+```
+
+- **bufferOption**: Sets the emitter's buffer behavior concerning whether the events should be sent instantly or after the buffer has reached it’s limit. Default value: `'single'`. Allowed bufferOption values are:
+    - `'single'`: Sends events instantly.
+    - `'default'`: (Affects only POST method). Sets buffer limit to 10 events.
+    - `'large'`: (Affects only POST method). Sets buffer limit to 25 events.
+- **emitRange**: Maximum number of events collected to be sent in a request. Default value: `150`
+- **threadPoolSize**: Maximum number of threads working in parallel in the tracker to send requests. Default value: `15`
+- **byteLimitGet**: Maximum amount of bytes allowed to be sent in a payload in a GET request. Default value: `40000`
+- **byteLimitPost**: Maximum amount of bytes allowed to be sent in a payload in a POST request. Default value: `40000`
+
+### SubjectConfiguration
+
+Represents the configuration of the subject. The SubjectConfiguration can be used to provide the basic information about the user.
+
+Its type definition is:
+
+```typescript
+interface SubjectConfiguration {
+  /**
+   * user id
+   */
+  userId?: string | null;
+  /**
+   * network user id (UUIDv4)
+   */
+  networkUserId?: string | null;
+  /**
+   * domain user id
+   */
+  domainUserId?: string | null;
+  /**
+   * The custom user-agent. It overrides the user-agent used by default.
+   */
+  useragent?: string | null;
+  /**
+   * IP address
+   */
+  ipAddress?: string | null;
+  /**
+   * The timezone label
+   */
+  timezone?: string | null;
+  /**
+   * The language set in the device
+   */
+  language?: string | null;
+  /**
+   * The screen resolution
+   */
+  screenResolution?: ScreenSize | null;
+  /**
+   * The screen viewport size
+   */
+  screenViewport?: ScreenSize | null;
+  /**
+   * color depth (integer)
+   */
+  colorDepth?: number | null;
+}
+```
+
+- **userId**: The custom user identifier. Commonly used for user self-identification – for example after sign in.
+- **networkUserId**: Populates the `network_userid` field. Typically used to link native tracking to in-app browser events tracked using the [JavaScript Tracker](/docs/sources/trackers/javascript-trackers/web-tracker/index.md). Normally one would retrieve the network userid from the browser and pass it to the app. Should contain a valid UUID4 string.
+- **domainUserId**: Populates the `domain_userid` field. Typically used to link native tracking to in-app browser events tracked using the [JavaScript Tracker](/docs/sources/trackers/javascript-trackers/web-tracker/index.md). Normally one would retrieve the domain userid from the browser and pass it to the app. Should contain a valid UUID4 string.
+- **useragent**: The custom useragent. It populates the `useragent` field.
+- **ipAddress**: The IP address of the user. It populates the `user_ipaddress` field.
+- **timezone** (set by the tracker): The current timezone label. Populates the `os_timezone` field.
+- **language** (set by the tracker): The language set in the device.
+- **screenResolution** (set by the tracker): The screen resolution. The screen resolution size can be set as an array of [width, height]. Populates the event fields `dvce_screenwidth` and `dvce_screenheight`.
+- **screenViewport**: The screen viewport. The screen viewport size can be set as an array of [width, height]. Populates the event fields `br_viewwidth` and `br_viewheight`.
+- **colorDepth**: The color depth. Populates the `br_colordepth` field.
+
+Information about the subject can also be set at runtime. In the "Setting the subject" section below, you can find out more about the available tracker methods to do so.
+
+### GdprConfiguration
+
+It represents the GDPR configuration of the tracker, and if set, the tracker will have the respective GDPR context attached to all events.
+
+Its type definition is:
+
+```typescript
+export interface GdprConfiguration {
+  /**
+   * Basis for processing
+   */
+  basisForProcessing: Basis;
+  /**
+   * ID of a GDPR basis document.
+   */
+  documentId: string;
+  /**
+   * Version of the document.
+   */
+  documentVersion: string;
+  /**
+   * Description of the document.
+   */
+  documentDescription: string;
+}
+```
+
+- **basisForProcessing**: Required. Represents the basis for processing according to GDPR. Allowed values for `basisForProcessing` are:
+    - `'consent'`
+    - `'contract'`
+    - `'legal_obligation'`
+    - `'legitimate_interests'`
+    - `'public_task'`
+    - `'vital_interests'`
+- **documentId**: Required. The GDPR document id.
+- **documentVersion**: Required. The GDPR document version.
+- **documentDescription**: Required. The GDPR document description.
+
+### GlobalContextsConfiguration
+
+It represents the static Global Contexts which will be attached to all events. Each GlobalContext is identified by a tag and an array of custom contexts.
+
+The relevant type definitions are:
+
+```typescript
+export interface GlobalContext {
+  /**
+   * tag
+   */
+  tag: string,
+  /**
+   * contexts
+   */
+  globalContexts: SelfDescribing[]
+}
+
+/**
+ * Global Contexts configuration
+ */
+export type GCConfiguration = GlobalContext[];
+```
+
+Global Contexts can also be set (added or removed) at runtime. In the [Adding or removing global contexts](/docs/sources/trackers/react-native-tracker/introduction/index.md#adding-or-removing-global-contexts) section below, you can find out more about the available tracker methods to do so.
+
+## Tracker methods
+
+### Tracking Events
+
+The React Native Tracker can track the out-of-the-box events as the Mobile Native iOS and Android trackers. The available track methods are:
+
+- **trackSelfDescribingEvent**
+- **trackStructuredEvent**
+- **trackEcommerceTransactionEvent**
+- **trackScreenViewEvent**
+- **trackTimingEvent**
+- **trackConsentGrantedEvent**
+- **trackConsentWithdrawnEvent**
+- **trackPageViewEvent**
+
+You can find out about all available track methods with details and examples in the [Tracking events](/docs/sources/trackers/react-native-tracker/tracking-events/index.md) section that follows.
+
+### Adding or removing global contexts
+
+Each set of global contexts is identified by a tag. Through the tag it is possible to add or remove GlobalContexts at runtime. The tracker methods to do so are:
+
+- **addGlobalContexts**
+- **removeGlobalContexts**
+
+You can find out more information and examples about how to add or remove global contexts [here](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#global-contexts).
+
+### Setting the Subject
+
+It is possible to change subject data at runtime, as the user journey evolves. Once initialized, the React Native tracker provides the methods to do so for each subject property:
+
+- **setUserId**
+- **setNetworkUserId**
+- **setDomainUserId**
+- **setIpAddress**
+- **setUseragent**
+- **setTimezone**
+- **setLanguage**
+- **setScreenResolution**
+- **setScreenViewport**
+- **setColorDepth**
+
+Alternatively, you can use the **setSubjectData** method to provide a new SubjectConfiguration.
+
+You can find out more on how to use the tracker's methods to set the subject information at runtime in the corresponding [Tracking events section](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#setting-the-subject-data).
+
+### Getting session context data from the tracker
+
+You can also get back session data from the tracker at runtime, that may be useful for your tracking and data modeling design. The available methods are:
+
+- **getSessionUserId**: To get the session user identifier.
+- **getSessionId**: To get the session identifier.
+- **getSessionIndex**: To get the session index.
+- **getIsInBackground**: To get whether the app is currently in background state or not.
+- **getBackgroundIndex**: To get the number of background transitions in the current session.
+- **getForegroundIndex**: To get the number of foreground transitions in the current session.
+
+You can find out more on how to use the tracker's methods to get session data at runtime in the corresponding [Advanced Usage section](/docs/sources/trackers/react-native-tracker/advanced-usage/index.md#getting-session-data-from-the-tracker).
+
+## Removing a tracker
+
+The React Native Tracker API also provides functions to remove a tracker or remove all trackers at runtime. You can find out how in the [Advanced Usage section](/docs/sources/trackers/react-native-tracker/advanced-usage/index.md#removing-a-tracker-at-runtime) of the React Native Tracker.
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/quick-start-guide/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/quick-start-guide/index.md
new file mode 100644
index 0000000000..e79a5b0ae3
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/quick-start-guide/index.md
@@ -0,0 +1,153 @@
+---
+title: "Quick start guide"
+date: "2021-08-06"
+sidebar_position: 0
+---
+
+[![Tracker Maintenance Classification](https://img.shields.io/static/v1?style=flat&label=Snowplow&message=Actively%20Maintained&color=6638b8&labelColor=9ba0aa&logo=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAAeFBMVEVMaXGXANeYANeXANZbAJmXANeUANSQAM+XANeMAMpaAJhZAJeZANiXANaXANaOAM2WANVnAKWXANZ9ALtmAKVaAJmXANZaAJlXAJZdAJxaAJlZAJdbAJlbAJmQAM+UANKZANhhAJ+EAL+BAL9oAKZnAKVjAKF1ALNBd8J1AAAAKHRSTlMAa1hWXyteBTQJIEwRgUh2JjJon21wcBgNfmc+JlOBQjwezWF2l5dXzkW3/wAAAHpJREFUeNokhQOCA1EAxTL85hi7dXv/E5YPCYBq5DeN4pcqV1XbtW/xTVMIMAZE0cBHEaZhBmIQwCFofeprPUHqjmD/+7peztd62dWQRkvrQayXkn01f/gWp2CrxfjY7rcZ5V7DEMDQgmEozFpZqLUYDsNwOqbnMLwPAJEwCopZxKttAAAAAElFTkSuQmCC)](/docs/sources/trackers/tracker-maintenance-classification/index.md)
+[![Latest tracker version](https://img.shields.io/npm/v/@snowplow/react-native-tracker)](https://www.npmjs.com/package/@snowplow/react-native-tracker)
+[![Supported React Native versions](https://img.shields.io/npm/dependency-version/@snowplow/react-native-tracker/peer/react-native)](https://www.npmjs.com/package/@snowplow/react-native-tracker)
+
+In order to start sending events using the Snowplow React Native Tracker, the following steps are involved:
+
+## Installation
+
+To install the tracker, add it as a dependency to your React Native app:
+
+```bash
+npm install --save @snowplow/react-native-tracker
+```
+
+You will also need to add the FMDB dependency to you `ios/Podfile` (unless using Expo Go) with `modular_headers` enabled. Add this line to the end of the file:
+
+```rb
+pod 'FMDB', :modular_headers => true
+```
+
+## Instrumentation
+
+Next, in your app create a new tracker using the `createTracker` method. As a minimal example:
+
+```typescript
+import { createTracker } from '@snowplow/react-native-tracker';
+
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+);
+```
+
+The `createTracker` function takes as arguments:
+
+1. **Required**: The tracker namespace, which identifies each tracker
+2. **Required**: The Network configuration
+3. _Optional_: The Tracker Controller configuration
+
+The optional Tracker Controller configuration has as type definition:
+
+```typescript
+interface TrackerControllerConfiguration {
+  trackerConfig?: TrackerConfiguration,
+  sessionConfig?: SessionConfiguration,
+  emitterConfig?: EmitterConfiguration,
+  subjectConfig?: SubjectConfiguration,
+  gdprConfig?: GdprConfiguration,
+  gcConfig?: GCConfiguration
+}
+```
+
+In other words, it provides a way for a fine grained tracker configuration.
+
+As an example to create a tracker with all configurations provided (wherever applicable, the default values are shown):
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+      method: 'post',
+      customPostPath: 'com.snowplowanalytics.snowplow/tp2', // A custom path which will be added to the endpoint URL to specify the complete URL of the collector when paired with the POST method.
+      requestHeaders: {} // Custom headers for HTTP requests to the Collector
+    },
+    {
+        trackerConfig: {
+            appId: 'my-app-id',
+            devicePlatform: 'mob',
+            base64Encoding: true,
+            logLevel: 'off',
+            applicationContext: true,
+            platformContext: true,
+            geoLocationContext: false,
+            sessionContext: true,
+            deepLinkContext: true,
+            screenContext: true,
+            screenViewAutotracking: true,
+            lifecycleAutotracking: false,
+            installAutotracking: true,
+            exceptionAutotracking: true,
+            diagnosticAutotracking: false,
+            userAnonymisation: false // Whether to anonymise client-side user identifiers in session and platform context entities
+        },
+        sessionConfig: {
+            foregroundTimeout: 1800,
+            backgroundTimeout: 1800
+        },
+        emitterConfig: {
+            bufferOption: 'single',
+            emitRange: 150,
+            threadPoolSize: 15,
+            byteLimitPost: 40000,
+            byteLimitGet: 40000,
+            serverAnonymisation: false // Whether to anonymise server-side user identifiers including the `network_userid` and `user_ipaddress`
+        },
+        subjectConfig: {
+            userId: 'my-user-id',
+            networkUserId: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+            domainUserId: '7cdd5ea8-b0f5-47ea-a8bb-5ec8e98cdbd6',
+            useragent: 'some-useragent-string',
+            ipAddress: '123.45.67.89',
+            timezone: 'Europe/London',
+            language: 'en',
+            screenResolution: [123, 456],
+            screenViewport: [123, 456],
+            colorDepth: 20
+        },
+        gdprConfig: {
+            basisForProcessing: 'consent',
+            documentId: 'my-gdpr-doc-id',
+            documentVersion: '1.0.0',
+            documentDescription: 'my gdpr document description'
+        },
+        gcConfig: [
+            {
+                tag: 'my-first-gc-tag',
+                globalContexts: [
+                    {
+                        schema: 'my-gc-schema-01',
+                        data: {gcData: 'some data'}
+                    },
+                    {
+                        schema: 'my-gc-schema-02'
+                        data: {moreGCData: 'some more data'}
+                    },
+                ]
+            },
+            {
+                tag: 'another-gc-tag',
+                globalContexts: [
+                    {
+                        schema: 'my-gc-schema-03'
+                        data: {gcProp: 'some value'}
+                    },
+                ]
+            }
+        ]
+    }
+);
+```
+
+## Track events
+
+Once the tracker is initialized, you can use the tracker methods to track events, about which you can find out more in the following Tracking events section.
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/exception-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/exception-tracking/index.md
similarity index 100%
rename from docs/sources/trackers/react-native-tracker/tracking-events/exception-tracking/index.md
rename to docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/exception-tracking/index.md
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/index.md
new file mode 100644
index 0000000000..33d32ff2bd
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/index.md
@@ -0,0 +1,419 @@
+---
+title: "Tracking out-of-the-box events"
+date: "2021-08-06"
+sidebar_position: 20
+---
+
+The React Native tracker captures two types of out-of-the-box events, automatically captured and manual events.
+
+## Auto-tracked events and entities
+
+Many of the automatic tracking options available on iOS and Android are also available in React Native – these can be enabled or disabled in the TrackerConfiguration passed to `createTracker` as part of the TrackerController configuration object:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+    {
+        trackerConfig: {
+            // auto-tracked events:
+            screenViewAutotracking: false, // only iOS UIKit or Android Activity screens
+            lifecycleAutotracking: false,
+            installAutotracking: true,
+            exceptionAutotracking: true, // only errors in native app code
+            diagnosticAutotracking: false,
+
+            // auto-tracked context entities:
+            applicationContext: true,
+            platformContext: true,
+            geoLocationContext: false,
+            sessionContext: true,
+            deepLinkContext: true,
+            screenContext: true,
+        },
+    }
+);
+```
+
+The automatically captured data are:
+
+* [**Platform and Application Context Tracking**](./platform-and-application-context/index.md): Captures contextual information about the device and the app.
+* [**Session Tracking**](./session-tracking/index.md): Captures the session which helps to keep track of the user activity in the app.
+* [**App Lifecycle Tracking**](./lifecycle-tracking/index.md): Captures application lifecycle state changes (foreground/background transitions).
+* [**Screen View Tracking**](./screen-tracking/index.md): Captures each time a new “screen” is loaded.
+* [**Exception Tracking**](./exception-tracking/index.md): Captures any unhandled exceptions within the application.
+* [**Installation Tracking**](./installation-tracking/index.md): Captures an install event which occurs the first time an application is opened.
+
+## Manually-tracked events
+
+All tracker's `track` methods take two arguments: An object of key-value pairs for the event’s properties, and an optional array of [custom event contexts](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md).
+
+### Tracking structured events
+
+Our philosophy in creating Snowplow is that users should capture important consumer interactions and design suitable data structures for this data capture. You can read more about that philosophy [here](/docs/data-product-studio/index.md). Using `trackSelfDescribingEvent` captures these interactions with custom schemas, as desribed above.
+
+However, as part of a Snowplow implementation there may be interactons where custom Self Describing events are perhaps too complex or unwarranted. They are then candidates to track using `trackStructuredEvent`, if none of the other event-specific methods outlined below are appropriate.
+
+For example:
+
+```typescript
+tracker.trackStructuredEvent({
+  category: 'my-category',
+  action: 'my-action',
+  label: 'my-label',
+  property: 'my-property',
+  value: 50.00
+});
+```
+
+**Required properties**
+
+- `category`: The name you supply for the group of objects you want to track e.g. ‘media’, ‘ecomm’
+- `action`: A string which defines the type of user interaction for the web object e.g. ‘play-video’, ‘add-to-basket’
+
+**Optional properties**
+
+- `label`: (string) - identifies the specific object being actioned e.g. ID of the video being played, or the SKU or the product added-to-basket
+- `property`: (string) - describes the object or the action performed on it. This might be the quantity of an item added to basket
+- `value`: (number) - quantifies or further describes the user action. This might be the price of an item added-to-basket, or the starting time of the video where play was just pressed
+
+#### Timing
+
+Use the `trackTimingEvent` tracker method to track user timing events such as how long resources take to load.
+
+For example:
+
+```typescript
+tracker.trackTimingEvent({
+    category: 'timing-category',
+    variable: 'timing-variable',
+    timing: 5,
+    label: 'optional-label'
+});
+```
+
+**Required properties**
+
+- `category`: (string) - Defines the timing category
+- `variable`: (string) - Define the timing variable measured
+- `timing`: (number) - Represent the time
+
+**Optional properties**
+
+- `label`: An optional string to further identify the timing event
+
+### Tracking screen view events
+
+Track the user viewing a screen within the application.
+
+To track a ScreenViewEvent, use the `trackScreenViewEvent` tracker method. For example:
+
+```typescript
+tracker.trackScreenViewEvent({
+    name: 'my-screen-name',
+    id: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+    type: 'carousel',
+    transitionType: 'basic'
+});
+```
+
+The tracker will automatically assign references to the previously tracked screen view event in the `previousName`, `previousId`, and `previousType` properties.
+
+**Required properties**
+
+- `name`: (string) - The name of the screen viewed
+
+**Optional properties**
+
+- `id`: (string) - The id(UUID) of screen that was viewed
+- `type`: (string) - The type of screen that was viewed
+- `previousName`: (string) - The name of the previous screen that was viewed (assigned automatically)
+- `previousId`: (string) - The id(UUID) of the previous screen that was viewed (assigned automatically)
+- `previousType`: (string) - The type of screen that was viewed (assigned automatically)
+- `transitionType`: (string) - The type of transition that led to the screen being viewed
+
+### Tracking page view events
+
+Track a page view event with the `trackPageViewEvent()` method. Typically this is uncommon in apps, but is sometimes used where fitting data into an existing page views model is required. To track page views from an in-app browser, it is advisable to use the javascript tracker in-browser.
+
+An example:
+
+```typescript
+tracker.trackPageViewEvent({
+  pageUrl: 'https://my-url.com',
+  pageTitle: 'My page title',
+  referrer: 'http://some-other-url.com'
+});
+```
+
+Required properties
+
+- `pageUrl`: (string) – Page Url for the page view event. Must be a valid url.
+
+Optional properties
+
+- `pageTitle`: (string) – Page Title for the page view event.
+- `referrer`: (string) – Url for the referring page to the page view event. Must be a vaild url.
+
+### Tracking consent granted events
+
+Use the `trackConsentGrantedEvent` method to track a user opting into data collection. A consent document context will be attached to the event using the `id` and `version` arguments supplied.
+
+For example:
+
+```typescript
+tracker.trackConsentGrantedEvent({
+    expiry: '2022-01-01T00:00:00Z',
+    documentId: 'doc-id',
+    version: '1.2',
+    name: 'doc-name',
+    documentDescription: 'consent doc description'
+});
+```
+
+**Required properties**
+
+- `expiry`: (string) - The expiry (date-time string, e.g.: '2022-01-01T00:00:00Z')
+- `documentId`: (string) - The consent document id
+- `version`: (string) - The consent document version
+
+**Optional properties**
+
+- `name`: (string) - The consent document name
+- `documentDescription`: (string) - The consent document description
+
+### Tracking consent withdrawn events
+
+Use the `trackConsentWithdrawnEvent` method to track a user withdrawing consent for data collection. A consent document context will be attached to the event using the `id` and `version` arguments supplied. To specify that a user opts out of all data collection, `all` should be set to `true`.
+
+For example:
+
+```typescript
+tracker.trackConsentWithdrawnEvent({
+    all: true,
+    documentId: 'doc-id',
+    version: '1.2',
+    name: 'doc-name',
+    documentDescription: 'consent doc description'
+});
+```
+
+**Required properties**
+
+- `all`: (boolean) - Whether user opts out of all data collection
+- `documentId`: (string) - The consent document id
+- `version`: (string) - The consent document version
+
+**Optional properties**
+
+- `name`: (string) - The consent document name
+- `documentDescription`: (string) - The consent document description
+
+### Tracking ecommerce transaction events
+
+Modelled on Google Analytics ecommerce tracking capability, an ecommerce-transaction event can be tracked as follows:
+
+1. **Create a EcommerceTransaction event object**. This will be the object that is loaded with all the properties relevant to the specific transaction that is being tracked including all the items (see `EcommerceItem` right below) in the order, the prices of the items, the price of shipping and the `order_id`.
+2. **Track the transaction** using the `trackEcommerceTransaction` method.
+
+The procedured outlined above will result in the following events being tracked:
+
+1. An EcommerceTransaction event
+2. As many as EcommerceItem events as the items passed to the EcommerceTransaction object, that will also inherit the `orderId` from the parent transaction event
+
+#### EcommerceItem
+
+More specifically, to start with, the properties of an `EcommerceItem` are:
+
+**Required properties**
+
+- `sku`: (string) - The item sku
+- `price`: (number) - The item price
+- `quantity`: (number) - The quantity purchased
+
+**Optional properties**
+
+- `name`: (string) - The item name
+- `category`: (string) - The item category
+- `currency`: (string) - The item currency
+
+For example:
+
+```typescript
+const ecomItem: EcommerceItem = {
+    sku: 'DD44',
+    name: 'T-Shirt',
+    category: 'Green Medium',
+    price: 15,
+    quantity: 1,
+    currency: 'USD'
+};
+```
+
+#### EcommerceTransaction
+
+An ecommerce transaction object has the following properties:
+
+**Required properties**
+
+- `orderId`: (string) - The order ID of the transaction
+- `totalValue`: (number) - The total value of the transaction
+- `items`: (array of `EcommerceItem`) - The ecommerce items purchased in the transaction.
+
+**Optional properties**
+
+- `affiliation`: (string)
+- `taxValue`: (number)
+- `shipping`: (number)
+- `city`: (string)
+- `state`: (string)
+- `country`: (string)
+- `currency`: (string)
+
+```typescript
+const ecomTransaction: EcommerceTransactionProps = {
+    orderId: '1234',
+    totalValue: 15,
+    items: [ ecomItem ],
+    affiliation: 'Womens Apparel',
+    taxValue: 1.5,
+    shipping: 2.99,
+    city: 'San Jose',
+    state: 'California',
+    country: 'USA',
+    currency: 'USD'
+};
+```
+
+#### `trackEcommerceTransaction`
+
+Then, to track the ecommerce transaction as described in the above examples:
+
+```typescript
+tracker.trackEcommerceTransactionEvent(ecomTransaction);
+```
+
+### Tracking deep link received events
+
+The Deep Link is received by the mobile operating system and passed to the related app. Our React Native tracker can't automatically track the Deep Link, but we provide an out-of-the-box event that can be used by the developer to manually track it as soon as the Deep Link is received in the app.
+
+It will be the duty of the tracker to automatically attach the information of the Deep Link to the first Screen View tracked.
+
+In practice, when the app receives a Deep Link the developer can track it through the `trackDeepLinkReceivedEvent` endpoint:
+
+```typescript
+tracker.trackDeepLinkReceivedEvent({
+    url: 'https://deeplink.com',
+    referrer: 'http://refr.com',
+});
+```
+
+Please refer to the [Linking API](https://reactnative.dev/docs/linking) in React Native for information on how to retrieve the linked URLs.
+
+The tracker keeps memory of the tracked Deep Link event and will attach a Deep Link entity to the first ScreenView tracked in the tracker. This is helpful during the analysis of the data because it will be clear the relation between the content visualized by the user (ScreenView event) and source (DeepLink entity) that originated that visualisation.
+
+This behavior is enabled by default but it can be disabled using the `deepLinkContext` boolean property when passing `trackerConfig` to `createTracker`:
+
+```typescript
+const tracker = createTracker(
+    namespace, networkConfig,
+    {
+        trackerConfig: {
+            deepLinkContext: false
+        }
+    }
+);
+```
+
+The Deep Link Received event can be used in pair with a campaign-attribution-enrichment appropriately enabled in the Snowplow pipeline. It works exactly like for Page View events in the web/JS tracker. When the user taps on an advertising banner or a marketing email or message, it can trigger the launch of the app through the Deep Linking feature. The referral from the advertising campaigns, websites, or other source can be composed by UTM parameters used to attribute the user activity back to the campaign. The Campaign Attribution Enrichment can parse the DeepLinkReceived event extracting the UTM parameters in the deep link url.
+
+Required properties
+
+- `url`: (string) – URL in the received deep-link
+
+Optional properties
+
+- `referrer`: (string) – Referrer URL, source of this deep-link
+
+### Tracking push and local notification events
+
+Push Notifications are a cornerstone of the user experience on mobile. A Push Notification is a message (like an SMS or a mobile alert) that can quickly show information to the user even if an app is closed or the phone is in stand-by. Push Notifications can be used in many different ways: they can notify of a new message in a chat, rather than informing of a news or just notify of an achievement in a fitness app.
+
+To track an event when a push (or local) notification is used, it is possible to use the `trackMessageNotificationEvent` endpoint:
+
+```typescript
+tracker.trackMessageNotificationEvent({
+    title: 'title',
+    body: 'body',
+    trigger: 'push',
+    action: 'action',
+    attachments: [
+        {
+            identifier: 'att_id',
+            type: 'att_type',
+            url: 'http://att.url',
+        },
+    ],
+    bodyLocArgs: ['bodyArg1', 'bodyArg2'],
+    bodyLocKey: 'bodyKey',
+    category: 'category',
+    contentAvailable: true,
+    group: 'group',
+    icon: 'icon',
+    notificationCount: 3,
+    notificationTimestamp: '2022-02-02T15:17:42.767Z',
+    sound: 'chime.mp3',
+    subtitle: 'subtitle1',
+    tag: 'tag',
+    threadIdentifier: 'threadIdentifier',
+    titleLocArgs: ['titleArg1', 'titleArg2'],
+    titleLocKey: 'titleKey',
+});
+```
+
+Required properties
+
+- `title`: (string) – The notification's title.
+- `body`: (string) – The notification's body.
+- `trigger`: (string) – The trigger that raised the notification message. Must be one of: push, location, calendar, timeInterval, other.
+
+Optional properties
+
+- `action`: (string) – The action associated with the notification.
+- `attachments`: (array of `MessageNotificationAttachmentProps`) – Attachments added to the notification (they can be part of the data object).
+- `bodyLocArgs` (array of string) - Variable string values to be used in place of the format specifiers in bodyLocArgs to use to localize the body text to the user's current localization.
+- `bodyLocKey`: (string) – The key to the body string in the app's string resources to use to localize the body text to the user's current localization.
+- `category`: (string) – The category associated to the notification.
+- `contentAvailable`: (boolean) – The application is notified of the delivery of the notification if it's in the foreground or background, the app will be woken up (iOS only).
+- `group`: (string) – The group which this notification is part of.
+- `icon`: (string) – The icon associated to the notification (Android only).
+- `notificationCount`: (integer) – The number of items this notification represent.
+- `notificationTimestamp`: (string) – The time when the event of the notification occurred.
+- `sound`: (string) – The sound played when the device receives the notification.
+- `subtitle`: (string) – The notification's subtitle. (iOS only)
+- `tag`: (string) – An identifier similar to 'group' but usable for different purposes (Android only).
+- `threadIdentifier`: (string) – An identifier similar to 'group' but usable for different purposes (iOS only).
+- `titleLocArgs`: (array of string) – Variable string values to be used in place of the format specifiers in titleLocArgs to use to localize the title text to the user's current localization.
+- `titleLocKey`: (string) – The key to the title string in the app's string resources to use to localize the title text to the user's current localization.
+
+#### MessageNotificationAttachmentProps
+
+Attachment object that identifies an attachment in the Message Notification event.
+
+**Required properties**
+
+- `identifier`: (string) – Attachment identifier.
+- `type`: (string) – Attachment type.
+- `url`: (string) – Attachment URL.
+
+For example:
+
+```typescript
+const attachment: MessageNotificationAttachmentProps = {
+    identifier: 'id',
+    type: 'type',
+    url: 'http://att.url',
+};
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/installation-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/installation-tracking/index.md
new file mode 100644
index 0000000000..9d4289cc2c
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/installation-tracking/index.md
@@ -0,0 +1,31 @@
+---
+title: "Installation tracking"
+sidebar_position: 60
+---
+
+# Installation tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+Installation tracking tracks an install event which occurs the first time an application is opened. The tracker will record when it's first been installed, so deleting and reinstalling an app will trigger another install event.
+
+If installation autotracking is not enabled, the tracker will still keep track of when the app was first installed, so that when enabled, the tracker will send the recorded install event with a timestamp reflecting when it was first installed.
+
+The installation autotracking is enabled by default. It can be set in `TrackerConfiguration` like in the example below:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+    {
+        trackerConfig: {
+            installAutotracking: true,
+        },
+    }
+);
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/lifecycle-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/lifecycle-tracking/index.md
new file mode 100644
index 0000000000..8e3f3a3860
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/lifecycle-tracking/index.md
@@ -0,0 +1,35 @@
+---
+title: "App lifecycle tracking"
+sidebar_position: 30
+---
+
+# App lifecycle tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+The tracker can capture application lifecycle state changes. In particular, when the app changes state from foreground to background and vice versa.
+
+The lifecycle tracking is disabled by default. It can be enabled in `TrackerConfiguration` like in the example below:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+    {
+        trackerConfig: {
+            lifecycleAutotracking: true,
+        },
+    }
+);
+```
+
+Once enabled, the tracker will automatically track a [`Background` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#background-event) when the app is moved to background and a [`Foreground` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#foreground-event) when the app moves back to foreground (becomes visible in the screen).
+
+The tracker attaches a [`LifecycleEntity`](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#lifecycle-context-entity) to all the events tracked by the tracker reporting if the app was visible (foreground state) when the event was tracked.
+
+The `LifecycleEntity` value is conditioned by the internal state of the tracker only. To make an example, if the app is in foreground state but the developer tracks a `Background` event intentionally, it would force the generation of a `LifecycleEntity` that mark the app as non visible, even if it's actually visible in the device.
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/platform-and-application-context/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/platform-and-application-context/index.md
new file mode 100644
index 0000000000..65d71ee5b7
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/platform-and-application-context/index.md
@@ -0,0 +1,144 @@
+---
+title: "Platform and application data tracking"
+sidebar_position: 10
+---
+
+# Platform and application data tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+Platform and application data tracking features capture information about the device and the app.
+
+They are enabled by default. But the setting can be changed through `TrackerConfiguration` like in the example below:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+    {
+        trackerConfig: {
+            applicationContext: true,
+            platformContext: true,
+        },
+    }
+);
+```
+
+## Application context
+
+The [application context entity](https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.mobile/application/jsonschema/1-0-0) contains two properties:
+
+| Property | Type | Description | Required in schema |
+| --- | --- | --- | --- |
+| `version` | String | Version number of the application e.g 1.1.0 | Yes |
+| `build` | String | Build name of the application e.g s9f2k2d or 1.1.0 beta | Yes |
+
+## Platform context
+
+The [platform context entity](https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.snowplow/mobile_context/jsonschema/1-0-3) contains the following properties:
+
+| Property | Type | Description | Required in schema |
+| --- | --- | --- | --- |
+| `osType` | String | Type of the operating system (e.g., "ios", "tvos", "watchos", "osx", "android") | Yes |
+| `osVersion` | String | Version of the mobile operating system. | Yes |
+| `deviceManufacturer` | String | Device vendor. | Yes |
+| `deviceModel` | String | Model of the device. | Yes |
+| `carrier` | String | Carrier of the SIM inserted in the device. | No |
+| `networkType` | String | One of: "mobile", "wifi", "offline" | No |
+| `networkTechnology` | String | Radio access technology that the device is using. | No |
+| `openIdfa` | String | Deprecated property. | No |
+| `appleIdfa` | String | Advertising identifier on iOS. | No |
+| `appleIdfv` | String | UUID [identifier for vendors](https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor) on iOS. | No |
+| `androidIdfa` | String | Advertising identifier on Android. | No |
+| `physicalMemory` | Integer | Total physical system memory in bytes | No |
+| `systemAvailableMemory` | Integer | Available memory on the system in bytes (Android only) | No |
+| `appAvailableMemory` | Integer | Amount of memory in bytes available to the current app (iOS only) | No |
+| `batteryLevel` | Integer | Remaining battery level as an integer percentage of total battery capacity | No |
+| `batteryState` | String | Battery state for the device. One of: "unplugged", "charging", "full". | No |
+| `lowPowerMode` | Boolean | A Boolean indicating whether Low Power Mode is enabled (iOS only) | No |
+| `availableStorage` | Integer | Bytes of storage remaining | No |
+| `totalStorage` | Integer | Total size of storage in bytes | No |
+| `isPortrait` | Boolean | A Boolean indicating whether the device orientation is portrait (either upright or upside down) | No |
+| `resolution` | String | Screen resolution in pixels. Arrives in the form of WIDTHxHEIGHT (e.g., 1200x900). Doesn't change when device orientation changes | No |
+| `scale` | Number | Scale factor used to convert logical coordinates to device coordinates of the screen (uses UIScreen.scale on iOS and DisplayMetrics.density on Android) | No |
+| `language` | String | System language currently used on the device (ISO 639) | No |
+| `appSetId` | String | Android vendor ID scoped to the set of apps published under the same Google Play developer account (see https://developer.android.com/training/articles/app-set-id) | No |
+| `appSetIdScope` | String (either "app" or "developer") | Scope of the `appSetId`. Can be scoped to the app or to a developer account on an app store (all apps from the same developer on the same device will have the same ID) | No |
+
+### Identifier for Advertisers (IDFA/AAID)
+
+The IDFA advertising identifiers are only added to the platform context if you fulfill the following requirements.
+Otherwise, their values will be NULL.
+
+<Tabs groupId="platform" queryString>
+  <TabItem value="ios" label="iOS">
+
+To track the IDFA identifier on iOS, you will need to initialize the tracker in native iOS (Swift or Objective-C) code. This is necessary because you will need to retrieve the ID from the `ASIdentifierManager` and pass it when creating the tracker in native code. Unfortunately, we can't provide this option in React Native since it would make the tracker library dependent on the API which would cause issues for apps that don't require it.
+
+Please [follow the documentation for the iOS tracker](/docs/sources/trackers/mobile-trackers/installation-and-set-up/ios-tracker/index.md) to call the `Snowplow.createTracker()` function inside the `application(_:didFinishLaunchingWithOptions:)` method. Make sure to pass the `TrackerConfiguration.advertisingIdentifierRetriever` callback that retrieves the ID as [described here](/docs/sources/trackers/mobile-trackers/tracking-events/platform-and-application-context/index.md?platform=ios#identifier-for-advertisers-idfaaaid).
+
+  </TabItem>
+  <TabItem value="android" label="Android">
+
+The AAID (Android Advertising ID) is a unique user-resettable identifier, which uniquely identifies a particular user for advertising use cases, such as ad personalization. The tracker allows retrieval of the AAID, sending it as property `androidIdfa`.
+
+For privacy purposes the user can reset the identifier at any moment.
+In that case the tracker will report a new AAID, despite the device and user being the same as before.
+Also, the user can "Opt out of Ads Personalisation" from the Android settings menu.
+In that case the tracker will report an empty string in place of the AAID.
+
+If you want to track the AAID, you need to add the Google Mobile Ads library to your app.
+If it isn’t included, the tracker will not send the AAID with the events.
+
+The Google Mobile Ads can be imported in the `dependencies` section of the `build.gradle` adding:
+
+```gradle
+dependencies {
+    ...
+    implementation 'com.google.android.gms:play-services-ads:19.0.0'
+    ...
+}
+```
+
+The Google Mobile Ads SDK v.17.0.0 introduced some [changes](https://ads-developers.googleblog.com/2018/10/announcing-v1700-of-android-google.html) requiring a tag in the `androidManifest.xml` explained below.
+
+#### Manifest tag for AdMob publishers
+
+AdMob publishers have to add the AdMob app ID in the `AndroidManifest.xml` file:
+
+```xml
+<manifest>
+    <application>
+        <!-- TODO: Replace with your real AdMob app ID -->
+        <meta-data
+            android:name="com.google.android.gms.ads.APPLICATION_ID"
+            android:value="ca-app-pub-################~##########"/>
+    </application>
+</manifest>
+```
+
+Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly".
+
+#### Manifest tag for Google Ad Manager publishers
+
+Publishers using Google Ad Manager have to declare the app an "Ad Manager app" in the `AndroidManifest.xml` file:
+
+```xml
+<manifest>
+    <application>
+        <meta-data
+            android:name="com.google.android.gms.ads.AD_MANAGER_APP"
+            android:value="true"/>
+    </application>
+</manifest>
+```
+
+Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly".
+
+  </TabItem>
+</Tabs>
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/screen-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/screen-tracking/index.md
new file mode 100644
index 0000000000..70c159dcc8
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/screen-tracking/index.md
@@ -0,0 +1,107 @@
+---
+title: "Screen view tracking"
+sidebar_position: 40
+---
+
+# Screen view tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+Screen view tracking captures screen changes within the app.
+
+## Tracking screen views in React Navigation
+
+If you are using the [React Navigation](https://reactnavigation.org/) library for navigation in your app, you can implement automatic screen view tracking by adding a callback to your `NavigationContainer`.
+The steps are explained [in the documentation for React Navigation](https://reactnavigation.org/docs/screen-tracking/).
+
+## Tracking screen views in React Native Navigation
+
+When using the [React Native Navigation](https://wix.github.io/react-native-navigation/docs/before-you-start/) library for navigation in your app, you can automatically track screen views by registering a listener when your component appears on screen.
+Use the `Navigation.events().registerComponentDidAppearListener` callback to subscribe the listener and track screen views as [documented here](https://wix.github.io/react-native-navigation/api/events/#componentdidappear).
+
+
+## Tracking screen views in iOS UIKit and Android Activity views
+
+The screen view tracking for UIKit views is disabled by default. It can be set in `TrackerConfiguration` like in the example below:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    {
+      endpoint: COLLECTOR_URL,
+    },
+    {
+        trackerConfig: {
+            screenViewAutotracking: true,
+        },
+    }
+);
+```
+
+Using method swizzling in the `ViewController` class, the tracker automatically detects when screens are loaded (triggered by viewDidAppear in a ViewController) and tracks events that include information about the current and previous view controllers.
+
+Using the Android `Application.ActivityLifecycleCallbacks` interface, the tracker automatically detects when Activities are loaded and tracks events that include information about the current and previous Activity.
+
+## Screen view event and screen context entity
+
+Automatic screen view tracking tracks two pieces of information:
+
+- The tracker automatically tracks each screen change using a `ScreenView` event.
+- If the `TrackerConfiguration.screenContext` property is enabled, the tracker attaches a [`Screen` entity](http://iglucentral.com/schemas/com.snowplowanalytics.mobile/screen/jsonschema/1-0-0) to all the events tracked by the tracker reporting the last (and probably current) screen visible on device when the event was tracked.
+
+The `Screen` entity is conditioned by the internal state of the tracker only. To make an example, if the developer manually tracks a `ScreenView` event, all the following events will have a `Screen` entity attached reporting the same information as the last tracked ScreenView event, even if it was manually tracked and the app is in a different screen.
+
+Indeed, disabling the `screenViewAutotracking` only, the tracker can still attach `Screen` entities automatically based only to the manual tracking of `ScreenView` events, and vice versa.
+
+## Screen engagement tracking
+
+Screen engagement tracking is a feature that enables tracking the user activity on the screen.
+This consists of the time spent and the amount of content viewed on the screen.
+
+Concretely, it consists of the following metrics:
+
+1. Time spent on screen while the app was in foreground (tracked automatically).
+2. Time spent on screen while the app was in background (tracked automatically).
+3. Number of list items scrolled out of all list items (requires some manual tracking).
+4. Scroll depth in pixels (requires some manual tracking).
+
+This information is attached using a [`screen_summary` context entity](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/page-activity-tracking/index.md#screen-summary-entity) to the following events:
+
+1. [`screen_end` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/page-activity-tracking/index.md#screen-end-event) that is automatically tracked before a new screen view event.
+2. [`application_background` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#background-event).
+3. [`application_foreground` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#foreground-event).
+
+Screen engagement tracking is enabled by default, but can be configured using the `TrackerConfiguration.screenEngagementAutotracking` option.
+
+For a demo of how mobile screen engagement tracking works in action, **[please visit this demo](https://snowplow-incubator.github.io/mobile-screen-engagement-demo/)**.
+
+#### Updating list item view and scroll depth information
+
+To update the list item viewed and scroll depth information tracked in the screen summary entity, you can track the `ListItemView` and `ScrollChanged` events with this information.
+When tracked, the tracker won't send these events individually to the collector, but will process the information into the next `screen_summary` entity and discard the events.
+You may want to track the events every time a new list item is viewed on the screen, or whenever the scroll position changes.
+
+To update the list items viewed information:
+
+```js
+tracker.trackListItemViewEvent({
+    index: 1,
+    itemsCount: 10,
+});
+```
+
+To update the scroll depth information:
+
+```js
+tracker.trackScrollChangedEvent({
+    yOffset: 10,
+    xOffset: 20,
+    viewHeight: 100,
+    viewWidth: 200,
+    contentHeight: 300,
+    contentWidth: 400,
+});
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/session-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/session-tracking/index.md
new file mode 100644
index 0000000000..f0d3def4f4
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/tracking-events/session-tracking/index.md
@@ -0,0 +1,130 @@
+---
+title: "Session tracking"
+sidebar_position: 20
+---
+
+# Session tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+Session tracking captures the session which helps to keep track of the user activity in the app.
+
+Client session tracking is enabled by default. It can be set through the `TrackerConfiguration` as explained below.
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    { endpoint: COLLECTOR_URL },
+    {
+        trackerConfig: {
+            sessionContext: true,
+        },
+    }
+);
+```
+
+When enabled, the tracker appends a [`client_session` entity](https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.snowplow/client_session/jsonschema/1-0-2) to each event it sends and it maintains this session information as long as the application is installed on the device.
+
+Sessions correspond to tracked user activity. A session expires when no tracking events have occurred for the amount of time defined in a timeout (by default 30 minutes). The session timeout check is executed for each event tracked. If the gap between two consecutive events is longer than the timeout the session is renewed. There are two timeouts since a session can timeout in the foreground (while the app is visible) or in the background (when the app has been suspended, but not closed).
+
+The timeouts for the session can be configured in the `SessionConfiguration` like in the example below:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    { endpoint: COLLECTOR_URL },
+    {
+        sessionConfig: {
+            foregroundTimeout: 1800, // seconds
+            backgroundTimeout: 1800 // seconds
+        },
+    }
+);
+```
+
+The lifecycle events (`Foreground` and `Background` events) have a role in the session expiration. The lifecycle events can be enabled as explained in [App Lifecycle Tracking](../lifecycle-tracking/index.md). Once enabled they will be fired automatically when the app moves from foreground state to background state and vice versa.
+
+When the app moves from foreground to background, the `Background` event is fired. If session tracking is enabled, the session entity will be attached to the event checking the session expiration using the foreground timeout.
+When the app moves from background to foreground, the `Foreground` event is fired. If session tracking is enabled, the session entity will be attached to the event checking the session expiration using the background timeout.
+
+For instance, with this configuration:
+
+```typescript
+const tracker = createTracker(
+    'appTracker',
+    { endpoint: COLLECTOR_URL },
+    {
+        sessionConfig: {
+            foregroundTimeout: 360, // seconds
+            backgroundTimeout: 15 // seconds
+        },
+    }
+);
+```
+
+the session would expire if the app is in background for more than 15 seconds, like in this example:
+
+```text
+time: 0s - ScreenView event - foreground timeout session check - session 1
+time: 3s - Background event - foreground timeout session check (3 < 360) - session 1
+time: 30s - Foreground event - background timeout session check (30 > 15) - session 2
+```
+
+In the above example, the `Foreground` event triggers a new session because the time spent in background (without tracked events) is bigger than the background timeout for the session.
+
+## Getting session data from the tracker
+
+The React Native tracker has implemented callbacks that enable you to get session data back from the tracker at runtime. The way to do so is by using a tracker's `get..` methods. As with all tracker methods, these callbacks are also asynchronous, and they return a Promise that resolves to the respective value (or `undefined`) when fulfilled.
+
+The available methods, are:
+
+### getSessionUserId
+
+This method returns a promise that resolves to the identifier (string UUIDv4) for the user of the session.
+
+```javascript
+const sessionUserId = await tracker.getSessionUserId();
+```
+
+### getSessionId
+
+This method returns a promise that resolves to the identifier (string UUIDv4) for the session.
+
+```javascript
+const sessionId = await tracker.getSessionId();
+```
+
+### getSessionIndex
+
+This method returns a promise to resolve to the index (number) of the current session for this user.
+
+```javascript
+const sessionIdx = await tracker.getSessionIndex();
+```
+
+### getIsInBackground
+
+This method returns a promise to resolve to whether (boolean) the app is currently in background.
+
+```javascript
+const isInBackground = await tracker.getIsInBackground();
+```
+
+### getBackgroundIndex
+
+This method returns a promise to resolve to the number of background transitions in the current session.
+
+```javascript
+const bgIndex = await tracker.getBackgroundIndex();
+```
+
+### getForegroundIndex
+
+This method returns a promise to resolve to the number of foreground transitions in the current session.
+
+```javascript
+const fgIndex = await tracker.getForegroundIndex();
+```
diff --git a/docs/sources/trackers/react-native-tracker/quick-start-guide/index.md b/docs/sources/trackers/react-native-tracker/quick-start-guide/index.md
index e79a5b0ae3..13a3be7361 100644
--- a/docs/sources/trackers/react-native-tracker/quick-start-guide/index.md
+++ b/docs/sources/trackers/react-native-tracker/quick-start-guide/index.md
@@ -18,136 +18,34 @@ To install the tracker, add it as a dependency to your React Native app:
 npm install --save @snowplow/react-native-tracker
 ```
 
-You will also need to add the FMDB dependency to you `ios/Podfile` (unless using Expo Go) with `modular_headers` enabled. Add this line to the end of the file:
-
-```rb
-pod 'FMDB', :modular_headers => true
-```
-
 ## Instrumentation
 
-Next, in your app create a new tracker using the `createTracker` method. As a minimal example:
+Next, in your app create a new tracker using the `newTracker` method. As a minimal example:
 
 ```typescript
-import { createTracker } from '@snowplow/react-native-tracker';
+import { newTracker } from '@snowplow/react-native-tracker';
 
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-);
+const tracker = newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+});
 ```
 
-The `createTracker` function takes as arguments:
-
-1. **Required**: The tracker namespace, which identifies each tracker
-2. **Required**: The Network configuration
-3. _Optional_: The Tracker Controller configuration
+The `newTracker` function takes the tracker configuration as the only argument. There are two required properties within the configuration:
 
-The optional Tracker Controller configuration has as type definition:
-
-```typescript
-interface TrackerControllerConfiguration {
-  trackerConfig?: TrackerConfiguration,
-  sessionConfig?: SessionConfiguration,
-  emitterConfig?: EmitterConfiguration,
-  subjectConfig?: SubjectConfiguration,
-  gdprConfig?: GdprConfiguration,
-  gcConfig?: GCConfiguration
-}
-```
-
-In other words, it provides a way for a fine grained tracker configuration.
-
-As an example to create a tracker with all configurations provided (wherever applicable, the default values are shown):
-
-```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-      method: 'post',
-      customPostPath: 'com.snowplowanalytics.snowplow/tp2', // A custom path which will be added to the endpoint URL to specify the complete URL of the collector when paired with the POST method.
-      requestHeaders: {} // Custom headers for HTTP requests to the Collector
-    },
-    {
-        trackerConfig: {
-            appId: 'my-app-id',
-            devicePlatform: 'mob',
-            base64Encoding: true,
-            logLevel: 'off',
-            applicationContext: true,
-            platformContext: true,
-            geoLocationContext: false,
-            sessionContext: true,
-            deepLinkContext: true,
-            screenContext: true,
-            screenViewAutotracking: true,
-            lifecycleAutotracking: false,
-            installAutotracking: true,
-            exceptionAutotracking: true,
-            diagnosticAutotracking: false,
-            userAnonymisation: false // Whether to anonymise client-side user identifiers in session and platform context entities
-        },
-        sessionConfig: {
-            foregroundTimeout: 1800,
-            backgroundTimeout: 1800
-        },
-        emitterConfig: {
-            bufferOption: 'single',
-            emitRange: 150,
-            threadPoolSize: 15,
-            byteLimitPost: 40000,
-            byteLimitGet: 40000,
-            serverAnonymisation: false // Whether to anonymise server-side user identifiers including the `network_userid` and `user_ipaddress`
-        },
-        subjectConfig: {
-            userId: 'my-user-id',
-            networkUserId: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
-            domainUserId: '7cdd5ea8-b0f5-47ea-a8bb-5ec8e98cdbd6',
-            useragent: 'some-useragent-string',
-            ipAddress: '123.45.67.89',
-            timezone: 'Europe/London',
-            language: 'en',
-            screenResolution: [123, 456],
-            screenViewport: [123, 456],
-            colorDepth: 20
-        },
-        gdprConfig: {
-            basisForProcessing: 'consent',
-            documentId: 'my-gdpr-doc-id',
-            documentVersion: '1.0.0',
-            documentDescription: 'my gdpr document description'
-        },
-        gcConfig: [
-            {
-                tag: 'my-first-gc-tag',
-                globalContexts: [
-                    {
-                        schema: 'my-gc-schema-01',
-                        data: {gcData: 'some data'}
-                    },
-                    {
-                        schema: 'my-gc-schema-02'
-                        data: {moreGCData: 'some more data'}
-                    },
-                ]
-            },
-            {
-                tag: 'another-gc-tag',
-                globalContexts: [
-                    {
-                        schema: 'my-gc-schema-03'
-                        data: {gcProp: 'some value'}
-                    },
-                ]
-            }
-        ]
-    }
-);
-```
+1. The tracker namespace, which identifies each tracker instance.
+2. The collector URL endpoint.
 
 ## Track events
 
 Once the tracker is initialized, you can use the tracker methods to track events, about which you can find out more in the following Tracking events section.
+As an example, you can track a screen view event like this:
+
+```ts
+tracker.trackScreenViewEvent({
+    name: 'my-screen-name',
+    id: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+    type: 'carousel',
+    transitionType: 'basic'
+});
+```
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/index.md
index 33d32ff2bd..399df6fcaa 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/index.md
@@ -11,29 +11,21 @@ The React Native tracker captures two types of out-of-the-box events, automatica
 Many of the automatic tracking options available on iOS and Android are also available in React Native – these can be enabled or disabled in the TrackerConfiguration passed to `createTracker` as part of the TrackerController configuration object:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-    {
-        trackerConfig: {
-            // auto-tracked events:
-            screenViewAutotracking: false, // only iOS UIKit or Android Activity screens
-            lifecycleAutotracking: false,
-            installAutotracking: true,
-            exceptionAutotracking: true, // only errors in native app code
-            diagnosticAutotracking: false,
-
-            // auto-tracked context entities:
-            applicationContext: true,
-            platformContext: true,
-            geoLocationContext: false,
-            sessionContext: true,
-            deepLinkContext: true,
-            screenContext: true,
-        },
-    }
+const tracker = newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+
+    // auto-tracked events:
+    lifecycleAutotracking: false,
+    installAutotracking: true,
+    screenEngagementAutotracking: true,
+
+    // auto-tracked context entities:
+    applicationContext: true,
+    platformContext: true,
+    sessionContext: true,
+    deepLinkContext: true,
+    screenContext: true,
 );
 ```
 
@@ -42,8 +34,7 @@ The automatically captured data are:
 * [**Platform and Application Context Tracking**](./platform-and-application-context/index.md): Captures contextual information about the device and the app.
 * [**Session Tracking**](./session-tracking/index.md): Captures the session which helps to keep track of the user activity in the app.
 * [**App Lifecycle Tracking**](./lifecycle-tracking/index.md): Captures application lifecycle state changes (foreground/background transitions).
-* [**Screen View Tracking**](./screen-tracking/index.md): Captures each time a new “screen” is loaded.
-* [**Exception Tracking**](./exception-tracking/index.md): Captures any unhandled exceptions within the application.
+* [**Screen View and Engagement Tracking**](./screen-tracking/index.md): Captures each time a new “screen” is loaded.
 * [**Installation Tracking**](./installation-tracking/index.md): Captures an install event which occurs the first time an application is opened.
 
 ## Manually-tracked events
@@ -79,7 +70,7 @@ tracker.trackStructuredEvent({
 - `property`: (string) - describes the object or the action performed on it. This might be the quantity of an item added to basket
 - `value`: (number) - quantifies or further describes the user action. This might be the price of an item added-to-basket, or the starting time of the video where play was just pressed
 
-#### Timing
+### Tracking timing events
 
 Use the `trackTimingEvent` tracker method to track user timing events such as how long resources take to load.
 

From de019b6fdaf58b7e6db035348991b1649998e34f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matu=CC=81s=CC=8C=20Tomlein?= <matus.tomlein@gmail.com>
Date: Thu, 2 Jan 2025 17:13:11 +0100
Subject: [PATCH 2/9] Additional React Native tracker docs updates

---
 .../advanced-usage/index.md                   |  28 +---
 .../anonymous-tracking/index.md               |  52 +++---
 .../client-side-properties/index.md           |  21 +--
 .../introduction/index.md                     |   6 +-
 .../previous-version/index.md                 |   4 +-
 .../migrating-from-v2-x-to-v4/index.md        |  73 +++++++--
 .../index.md                                  |   2 +
 .../index.md                                  |   2 +
 .../tracking-events/index.md                  |   2 +-
 .../installation-tracking/index.md            |  16 +-
 .../lifecycle-tracking/index.md               |  18 +--
 .../platform-and-application-context/index.md | 152 +++++++-----------
 .../tracking-events/screen-tracking/index.md  |  55 ++++---
 .../tracking-events/session-tracking/index.md |  50 +++---
 src/componentVersions.js                      |   4 +-
 15 files changed, 212 insertions(+), 273 deletions(-)

diff --git a/docs/sources/trackers/react-native-tracker/advanced-usage/index.md b/docs/sources/trackers/react-native-tracker/advanced-usage/index.md
index 40d81078be..c8ebb6c378 100644
--- a/docs/sources/trackers/react-native-tracker/advanced-usage/index.md
+++ b/docs/sources/trackers/react-native-tracker/advanced-usage/index.md
@@ -6,7 +6,7 @@ sidebar_position: 40
 
 ## Removing a tracker at runtime
 
-As also mentioned in Introduction, besides the `createTracker` function, the React Native Tracker also provides two functions that allow you to remove a tracker (or all of them) at runtime.
+As also mentioned in Introduction, besides the `newTracker` function, the React Native Tracker also provides two functions that allow you to remove a tracker (or all of them) at runtime.
 
 ### removeTracker
 
@@ -15,7 +15,7 @@ As each tracker is identified by its namespace, in order to remove a tracker at
 For example, assuming an existing tracker with namespace `sp1` :
 
 ```javascript
-import { createTracker, removeTracker } from '@snowplow/react-native-tracker';
+import { newTracker, removeTracker } from '@snowplow/react-native-tracker';
 
 // ...
 
@@ -31,27 +31,3 @@ import { removeAllTrackers } from '@snowplow/react-native-tracker';
 
 removeAllTrackers();
 ```
-
-## Accessing the tracker from native code
-
-Since the Snowplow React Native Tracker is a wrapper around the native trackers for iOS and Android, it is possible to access the underlying iOS and Android trackers in native iOS and Android code. This allows you to:
-
-1. Instantiate a new tracker instance either in React Native or iOS/Android native code.
-2. Track events using the same tracker instance from both React Native code as well as iOS/Android native code.
-
-This is a better approach than creating a separate tracker instance for React Native and for native code because it enables all the events to share the same user and session identifiers.
-
-As an example, we have implemented this setup in [a simple demo app](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid). The app does the following:
-
-1. [Adds a dependency](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/package.json#L3) for the React Native tracker.
-2. [Creates a tracker instance](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/App.tsx#L5) in the React Native code.
-3. [Tracks a screen view event](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/App.tsx#L9) in the React Native code.
-4. [Adds the Android tracker as a dependency](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/android/app/build.gradle#L182-L183) in the Android app.
-5. [Periodically tracks an event](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/android/app/src/main/java/com/snowplowanalytics/reactnativedemohybrid/MainActivity.java#L29-L37) from the Android native code.
-6. [Periodically tracks an event](https://github.com/snowplow-incubator/snowplow-react-native-demo-hybrid/blob/main/ios/snowplowreactnativedemohybrid/main.m#L9-L15) from the iOS native code.
-
-When accessing the native tracker APIs in Swift, Objective-C, Java, or Kotlin, refer to the documentation for the [mobile trackers](/docs/sources/trackers/mobile-trackers/index.md).
-
-:::note
-Please note that in Android, you will need to add a dependency for the Android tracker to your `build.gradle` inside the Android codebase within your React Native app. Follow the instructions in the [mobile tracker documentation](/docs/sources/trackers/mobile-trackers/index.md). Make sure that you include the same version of the Android tracker as used by the React Native tracker.
-:::
diff --git a/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md b/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
index 7103e077bb..1047f15461 100644
--- a/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
@@ -22,6 +22,9 @@ import AnonymousTrackingSharedBlock from "@site/docs/reusable/anonymous-tracking
 
 <AnonymousTrackingSharedBlock/>
 ```
+
+Version 4 of the React Native tracker does not yet provide full support for client-side anonymisation, but this is something we plan to introduce in the upcoming versions.
+
 There are several levels to the anonymisation depending on which of the three categories are affected:
 
 ## 1. Full client-side anonymisation
@@ -29,49 +32,36 @@ There are several levels to the anonymisation depending on which of the three ca
 In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymisation:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {endpoint: COLLECTOR_URL},
-    {
-        trackerConfig: {
-            sessionContext: false, // Session context entity won't be added to events
-            userAnonymisation: true // User identifiers in Platform context (IDFA and IDFV) will be anonymised
-        }
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    sessionContext: false, // Session context entity won't be added to events
+});
 ```
 
+:::warning Subject and platform context properties not anonymised
+The version 4 does not yet automatically anonymise the `userId` in the Subject and the IDFA and other identifiers in the platform context entity.
+These need to be removed manually.
+:::
+
 ## 2. Client-side anonymisation with session tracking
 
 This setting disables client-side user identifiers but tracks session information. In practice, this means that events track the Session context entity but the `userId` property is a null UUID (`00000000-0000-0000-0000-000000000000`). In case Platform context is enabled, the IDFA identifiers will not be present.
 
-```typescript
-const tracker = createTracker(
-    'appTracker',
-    {endpoint: COLLECTOR_URL},
-    {
-        trackerConfig: {
-            sessionContext: true, // Session context is tracked with the session ID
-            userAnonymisation: true // User identifiers in Session and Platform context are anonymised
-        }
-    }
-);
-```
+:::warning Not yet available
+This option is not yet available in the version 4 of the React Native tracker.
+:::
 
 ## 3. Server-side anonymisation
 
 Server-side anonymisation affects user identifiers set server-side. In particular, these are the `network_userid` property set in server-side cookie and the user IP address. You can anonymise the properties using the `serverAnonymisation` flag in `EmitterConfiguration`:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {endpoint: COLLECTOR_URL},
-    {
-        emitterConfig: {
-            serverAnonymisation: true
-        }
-    }
-);
+const tracker = await newTracker(
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    serverAnonymization: true,
+});
 ```
 
 Setting the flag will add a `SP-Anonymous` HTTP header to requests sent to the Snowplow collector. The Snowplow pipeline will take care of anonymising the identifiers.
diff --git a/docs/sources/trackers/react-native-tracker/client-side-properties/index.md b/docs/sources/trackers/react-native-tracker/client-side-properties/index.md
index 4697f11b27..64413a09e3 100644
--- a/docs/sources/trackers/react-native-tracker/client-side-properties/index.md
+++ b/docs/sources/trackers/react-native-tracker/client-side-properties/index.md
@@ -66,23 +66,18 @@ The `network_userid` is stored in the tracker and it's kept the same until the a
 
 ## Setting the subject configuration
 
-The client-side properties can be set during tracker initialization using the `subjectConfig` configuration:
+The client-side properties can be set during tracker initialization using the `newTracker` configuration:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-    {
-        subjectConfig: {
-            userId: 'my-user-id',
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    // pass the subject properties:
+    userId: 'my-user-id',
+});
 ```
 
-See the the full [list of options in the configuration section](/docs/sources/trackers/react-native-tracker/introduction/index.md#subjectconfiguration).
+See the the full [list of options in the configuration section](/docs/sources/trackers/react-native-tracker/introduction/index.md#configuring-the-tracker).
 
 ### Setting the subject data in a tracker instance
 
diff --git a/docs/sources/trackers/react-native-tracker/introduction/index.md b/docs/sources/trackers/react-native-tracker/introduction/index.md
index 4224ee6215..7490fa676a 100644
--- a/docs/sources/trackers/react-native-tracker/introduction/index.md
+++ b/docs/sources/trackers/react-native-tracker/introduction/index.md
@@ -36,7 +36,7 @@ The `newTracker` provides a wide range of optional configuration options that le
 The following snippet shows an overview of all the options and their meaning:
 
 ```typescript
-const tracker = newTracker(
+const tracker = newTracker({
     // Network configuration:
     // Represents the network communication configuration allowing the tracker to be able to send events to the Snowplow collector.
 
@@ -148,7 +148,7 @@ const tracker = newTracker(
     screenViewport: [123, 456],
     // The color depth. Populates the `br_colordepth` field.
     colorDepth: 20,
-);
+});
 ```
 
 To learn more about the specific parts of the configuration and autotracked information, see:
@@ -195,7 +195,7 @@ The tracker methods to do so are:
 - **removeGlobalContexts**
 - **clearGlobalContexts**
 
-You can find out more information and examples about how to add or remove global contexts [here](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md).
+You can find out more information and examples about [how to add or remove global contexts here](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md).
 
 ### Setting the Subject
 
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/index.md b/docs/sources/trackers/react-native-tracker/previous-version/index.md
index 189446403e..a69556f4d0 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/index.md
@@ -1,9 +1,7 @@
 ---
 title: "Previous versions"
 date: "2021-08-09"
-sidebar_position: 50
-sidebar_custom_props:
-  outdated: true
+sidebar_position: 100
 ---
 
 ```mdx-code-block
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md b/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
index 07865c3a17..541ec2052c 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
@@ -3,20 +3,61 @@ title: "Migrating from v2 to v4"
 sidebar_position: 90
 ---
 
+Version 4 of the React Native tracker brings a significant rearchitecture of the tracker, which is now JavaScript-only instead of building on top of the iOS and Android native trackers.
+This brings support for new platforms (Web, Expo Go) and new features (JS tracker plugins, improved global context), but also brings some limitations.
 
-## Configuration
-
-- User anonymization not available
-- GDPR configuration not available
-- No autotracked application context
-- No geoLocationContext
-- No exceptionAutotracking
-- No diagnosticAutotracking
-- No screen view autotracking
-- No `logLevel`
-- Platform context - less autotracked information
-- `newTracker` instead fo `createTracker`
-  - Rename `method` to `eventMethod`
-  - Rename `requestHeaders` to `customHeaders`
-  - Rename `base64Encoding` to `encodeBase64`
-  - Global contexts moved from configuration
+### Initialize tracker instance using `newTracker` instead of `createTracker`
+
+The method for creating a new tracker instance has been changed to `newTracker`.
+This is not just a rename, but a change in the structure of it's parameters, which are now more in line with the rest of our JavaScript trackers.
+
+You can review the [documentation page](/docs/sources/trackers/react-native-tracker/introduction/index.md) for the current set of configuration options.
+
+The parameters are now provided in a flattened object instead of separated under categories.
+Some have also been renamed:
+
+- `method` to `eventMethod`
+- `requestHeaders` to `customHeaders`
+- `base64Encoding` to `encodeBase64`
+- `serverAnonymisation` to `serverAnonymization`
+- `customPostPath` to `postPath`
+
+The `logLevel` parameter has been removed. Also global context configuration has been moved outside of the configuration, see [the global context docs page](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md).
+
+### User anonymization not available yet
+
+The `userAnonymisation` configuration option has been removed. We will reintroduce it in the upcoming versions of the React Native tracker.
+
+The session context entity can still be removed using the `sessionContext` option and one can disable the user identifiers in the platform context and subject properties individually. Read more about the options [in the documentation here](/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md).
+
+### GDPR configuration not available
+
+We have deprecated and removed the GPDR configuration. As a more up-to-date replacement, one can make use of the [consent plugins available for the JavaScript tracker](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/consent-gdpr/index.md).
+
+### Application context is not tracked automatically
+
+The application context entity with the current app version and build number is not tracked automatically anymore, but the version information can be provided in the `newTracker` call in which case the tracker will track this entity with events.
+Read more [in the documentation here](/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md).
+
+### Removed geolocation context entity
+
+The geolocation context entity is no longer available to be tracked by the tracker.
+You may track it manually using global context and [the geolocation schema](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/geolocation/index.md#geolocation-context-entity-tracked-in-apps).
+
+### Removed exception and diagnostic autotracking
+
+The exception and diagnostic autotracking features have been deprecated and removed.
+
+### Removed screen view autotracking for UIKit and Android Activities
+
+Screen view autotracking for iOS UIKit and Android Activity views has been deprecated and removed as it is not relevant in most React Native apps.
+See the [documentation for screen view tracking options](/docs/sources/trackers/react-native-tracker/tracking-events/screen-tracking/index.md).
+
+### Less autotracked information in the platform context entity
+
+There are fewer automatically tracked properties in the platform context entity, but it's possible to provide values for them manually.
+Refer to [the documentation to learn more](/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md).
+
+### Not possible to access from native code
+
+Since the tracker is now purely implemented in JavaScript, it is no longer possible to access it from mobile native iOS or Android code.
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v0-reference/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v0-reference/index.md
index 2588377817..398c634e25 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v0-reference/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v0-reference/index.md
@@ -2,6 +2,8 @@
 title: "React Native Tracker v0 reference"
 date: "2021-08-09"
 sidebar_position: 300
+sidebar_custom_props:
+  outdated: true
 ---
 
 This documentation page is about a previous version of the React Native tracker. [Go to the latest docs](/docs/sources/trackers/react-native-tracker/index.md).
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md
index 860621d955..170279a3e7 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/index.md
@@ -2,6 +2,8 @@
 title: "React Native Tracker v2 reference"
 date: "2020-07-09"
 sidebar_position: 290
+sidebar_custom_props:
+  outdated: true
 ---
 
 ```mdx-code-block
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/index.md
index 399df6fcaa..06bd7c05fd 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/index.md
@@ -8,7 +8,7 @@ The React Native tracker captures two types of out-of-the-box events, automatica
 
 ## Auto-tracked events and entities
 
-Many of the automatic tracking options available on iOS and Android are also available in React Native – these can be enabled or disabled in the TrackerConfiguration passed to `createTracker` as part of the TrackerController configuration object:
+Many of the automatic tracking options available on iOS and Android are also available in React Native – these can be enabled or disabled in the TrackerConfiguration passed to `newTracker` as part of the TrackerController configuration object:
 
 ```typescript
 const tracker = newTracker({
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md
index 9d4289cc2c..863036eca1 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md
@@ -17,15 +17,9 @@ If installation autotracking is not enabled, the tracker will still keep track o
 The installation autotracking is enabled by default. It can be set in `TrackerConfiguration` like in the example below:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-    {
-        trackerConfig: {
-            installAutotracking: true,
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    installAutotracking: true, // disabled by default
+});
 ```
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md
index 8e3f3a3860..b9f88ecd13 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md
@@ -12,20 +12,14 @@ import TabItem from '@theme/TabItem';
 
 The tracker can capture application lifecycle state changes. In particular, when the app changes state from foreground to background and vice versa.
 
-The lifecycle tracking is disabled by default. It can be enabled in `TrackerConfiguration` like in the example below:
+The lifecycle tracking is disabled by default. It can be enabled using the `lifecycleAutotracking` option like in the example below:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-    {
-        trackerConfig: {
-            lifecycleAutotracking: true,
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    lifecycleAutotracking: true, // enabled by default
+});
 ```
 
 Once enabled, the tracker will automatically track a [`Background` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#background-event) when the app is moved to background and a [`Foreground` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#foreground-event) when the app moves back to foreground (becomes visible in the screen).
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md
index 65d71ee5b7..1ccabcb898 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/platform-and-application-context/index.md
@@ -12,35 +12,47 @@ import TabItem from '@theme/TabItem';
 
 Platform and application data tracking features capture information about the device and the app.
 
-They are enabled by default. But the setting can be changed through `TrackerConfiguration` like in the example below:
+They can be configured through `TrackerConfiguration` like in the example below:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-    {
-        trackerConfig: {
-            applicationContext: true,
-            platformContext: true,
-        },
-    }
-);
+const tracker = await newTracker({
+  namespace: 'appTracker',
+  endpoint: COLLECTOR_URL,
+
+  // application information
+  appId: 'my-app-id',
+  appVersion: '1.0.0',
+  appBuild: '1',
+
+  platformContext: true, // enabled by default
+});
 ```
 
-## Application context
+## Application information
 
-The [application context entity](https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.mobile/application/jsonschema/1-0-0) contains two properties:
+### App ID
 
-| Property | Type | Description | Required in schema |
-| --- | --- | --- | --- |
-| `version` | String | Version number of the application e.g 1.1.0 | Yes |
-| `build` | String | Build name of the application e.g s9f2k2d or 1.1.0 beta | Yes |
+Set the application ID using the `appId` field of the tracker configuration object.
+This will be attached to every event the tracker fires.
+The information will be available in the `app_id` column of the events table.
+
+### App version and build number
+
+To track the application version, you can pass it using the `appVersion` configuration option.
+The version of can be a semver-like structure (e.g 1.1.0) or a Git commit SHA hash.
+
+Additionally, you can track the build name of the application (e.g., `s9f2k2d` or `1.1.0 beta`) using the `build` option.
+
+Depending on whether `build` property is configured, the information will be tracked in a context entity using either of these schemas:
+
+1. If only `appVersion` is configured, [the Web `application` entity is used](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/app-information/index.md#application-context-entity-on-web-apps).
+2. If both `appVersion` and `build` are configured, [the mobile `application` entity is used](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/app-information/index.md#application-context-entity-on-mobile-apps).
 
 ## Platform context
 
-The [platform context entity](https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.snowplow/mobile_context/jsonschema/1-0-3) contains the following properties:
+The [platform context entity](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/device-and-browser/index.md#mobile-context) contains information about the user's device.
+
+By default only the following properties are tracked automatically:
 
 | Property | Type | Description | Required in schema |
 | --- | --- | --- | --- |
@@ -48,6 +60,30 @@ The [platform context entity](https://github.com/snowplow/iglu-central/blob/mast
 | `osVersion` | String | Version of the mobile operating system. | Yes |
 | `deviceManufacturer` | String | Device vendor. | Yes |
 | `deviceModel` | String | Model of the device. | Yes |
+| `language` | String | System language currently used on the device (ISO 639) | No |
+| `resolution` | String | Screen resolution in pixels. Arrives in the form of WIDTHxHEIGHT (e.g., 1200x900). Doesn't change when device orientation changes | No |
+| `scale` | Number | Scale factor used to convert logical coordinates to device coordinates of the screen (uses UIScreen.scale on iOS and DisplayMetrics.density on Android) | No |
+
+The platform context entity can be used to track more information.
+However, you will need to pass it manually using callback functions.
+
+```ts
+const tracker = await newTracker({
+  namespace: "sp1",
+  endpoint: "http://example.com",
+  // provide custom getters for the platform context properties
+  platformContextRetriever: {
+    getAppleIdfv: async () => "apple-idfv",
+    getAppSetId: async () => "app-set-id",
+    getAvailableStorage: async () => 1000,
+  }
+});
+```
+
+The following table lists all the extra properties that can be set:
+
+| Property | Type | Description | Required in schema |
+| --- | --- | --- | --- |
 | `carrier` | String | Carrier of the SIM inserted in the device. | No |
 | `networkType` | String | One of: "mobile", "wifi", "offline" | No |
 | `networkTechnology` | String | Radio access technology that the device is using. | No |
@@ -64,81 +100,5 @@ The [platform context entity](https://github.com/snowplow/iglu-central/blob/mast
 | `availableStorage` | Integer | Bytes of storage remaining | No |
 | `totalStorage` | Integer | Total size of storage in bytes | No |
 | `isPortrait` | Boolean | A Boolean indicating whether the device orientation is portrait (either upright or upside down) | No |
-| `resolution` | String | Screen resolution in pixels. Arrives in the form of WIDTHxHEIGHT (e.g., 1200x900). Doesn't change when device orientation changes | No |
-| `scale` | Number | Scale factor used to convert logical coordinates to device coordinates of the screen (uses UIScreen.scale on iOS and DisplayMetrics.density on Android) | No |
-| `language` | String | System language currently used on the device (ISO 639) | No |
 | `appSetId` | String | Android vendor ID scoped to the set of apps published under the same Google Play developer account (see https://developer.android.com/training/articles/app-set-id) | No |
 | `appSetIdScope` | String (either "app" or "developer") | Scope of the `appSetId`. Can be scoped to the app or to a developer account on an app store (all apps from the same developer on the same device will have the same ID) | No |
-
-### Identifier for Advertisers (IDFA/AAID)
-
-The IDFA advertising identifiers are only added to the platform context if you fulfill the following requirements.
-Otherwise, their values will be NULL.
-
-<Tabs groupId="platform" queryString>
-  <TabItem value="ios" label="iOS">
-
-To track the IDFA identifier on iOS, you will need to initialize the tracker in native iOS (Swift or Objective-C) code. This is necessary because you will need to retrieve the ID from the `ASIdentifierManager` and pass it when creating the tracker in native code. Unfortunately, we can't provide this option in React Native since it would make the tracker library dependent on the API which would cause issues for apps that don't require it.
-
-Please [follow the documentation for the iOS tracker](/docs/sources/trackers/mobile-trackers/installation-and-set-up/ios-tracker/index.md) to call the `Snowplow.createTracker()` function inside the `application(_:didFinishLaunchingWithOptions:)` method. Make sure to pass the `TrackerConfiguration.advertisingIdentifierRetriever` callback that retrieves the ID as [described here](/docs/sources/trackers/mobile-trackers/tracking-events/platform-and-application-context/index.md?platform=ios#identifier-for-advertisers-idfaaaid).
-
-  </TabItem>
-  <TabItem value="android" label="Android">
-
-The AAID (Android Advertising ID) is a unique user-resettable identifier, which uniquely identifies a particular user for advertising use cases, such as ad personalization. The tracker allows retrieval of the AAID, sending it as property `androidIdfa`.
-
-For privacy purposes the user can reset the identifier at any moment.
-In that case the tracker will report a new AAID, despite the device and user being the same as before.
-Also, the user can "Opt out of Ads Personalisation" from the Android settings menu.
-In that case the tracker will report an empty string in place of the AAID.
-
-If you want to track the AAID, you need to add the Google Mobile Ads library to your app.
-If it isn’t included, the tracker will not send the AAID with the events.
-
-The Google Mobile Ads can be imported in the `dependencies` section of the `build.gradle` adding:
-
-```gradle
-dependencies {
-    ...
-    implementation 'com.google.android.gms:play-services-ads:19.0.0'
-    ...
-}
-```
-
-The Google Mobile Ads SDK v.17.0.0 introduced some [changes](https://ads-developers.googleblog.com/2018/10/announcing-v1700-of-android-google.html) requiring a tag in the `androidManifest.xml` explained below.
-
-#### Manifest tag for AdMob publishers
-
-AdMob publishers have to add the AdMob app ID in the `AndroidManifest.xml` file:
-
-```xml
-<manifest>
-    <application>
-        <!-- TODO: Replace with your real AdMob app ID -->
-        <meta-data
-            android:name="com.google.android.gms.ads.APPLICATION_ID"
-            android:value="ca-app-pub-################~##########"/>
-    </application>
-</manifest>
-```
-
-Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly".
-
-#### Manifest tag for Google Ad Manager publishers
-
-Publishers using Google Ad Manager have to declare the app an "Ad Manager app" in the `AndroidManifest.xml` file:
-
-```xml
-<manifest>
-    <application>
-        <meta-data
-            android:name="com.google.android.gms.ads.AD_MANAGER_APP"
-            android:value="true"/>
-    </application>
-</manifest>
-```
-
-Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly".
-
-  </TabItem>
-</Tabs>
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/screen-tracking/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/screen-tracking/index.md
index 70c159dcc8..fd1397492d 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/screen-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/screen-tracking/index.md
@@ -12,6 +12,17 @@ import TabItem from '@theme/TabItem';
 
 Screen view tracking captures screen changes within the app.
 
+To track a ScreenViewEvent, use the `trackScreenViewEvent` tracker method [as explained here](/docs/sources/trackers/react-native-tracker/tracking-events/index.md#tracking-screen-view-events). For example:
+
+```typescript
+tracker.trackScreenViewEvent({
+    name: 'my-screen-name',
+    id: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e',
+    type: 'carousel',
+    transitionType: 'basic'
+});
+```
+
 ## Tracking screen views in React Navigation
 
 If you are using the [React Navigation](https://reactnavigation.org/) library for navigation in your app, you can implement automatic screen view tracking by adding a callback to your `NavigationContainer`.
@@ -22,42 +33,30 @@ The steps are explained [in the documentation for React Navigation](https://reac
 When using the [React Native Navigation](https://wix.github.io/react-native-navigation/docs/before-you-start/) library for navigation in your app, you can automatically track screen views by registering a listener when your component appears on screen.
 Use the `Navigation.events().registerComponentDidAppearListener` callback to subscribe the listener and track screen views as [documented here](https://wix.github.io/react-native-navigation/api/events/#componentdidappear).
 
-
-## Tracking screen views in iOS UIKit and Android Activity views
-
-The screen view tracking for UIKit views is disabled by default. It can be set in `TrackerConfiguration` like in the example below:
+## Screen context entity
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    {
-      endpoint: COLLECTOR_URL,
-    },
-    {
-        trackerConfig: {
-            screenViewAutotracking: true,
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    screenContext: true, // enabled by default
+});
 ```
 
-Using method swizzling in the `ViewController` class, the tracker automatically detects when screens are loaded (triggered by viewDidAppear in a ViewController) and tracks events that include information about the current and previous view controllers.
-
-Using the Android `Application.ActivityLifecycleCallbacks` interface, the tracker automatically detects when Activities are loaded and tracks events that include information about the current and previous Activity.
+If the `screenContext` property is enabled, the tracker attaches a [`Screen` entity](http://iglucentral.com/schemas/com.snowplowanalytics.mobile/screen/jsonschema/1-0-0) to all the events tracked by the tracker reporting the last (and probably current) screen visible on device when the event was tracked.
 
-## Screen view event and screen context entity
-
-Automatic screen view tracking tracks two pieces of information:
-
-- The tracker automatically tracks each screen change using a `ScreenView` event.
-- If the `TrackerConfiguration.screenContext` property is enabled, the tracker attaches a [`Screen` entity](http://iglucentral.com/schemas/com.snowplowanalytics.mobile/screen/jsonschema/1-0-0) to all the events tracked by the tracker reporting the last (and probably current) screen visible on device when the event was tracked.
-
-The `Screen` entity is conditioned by the internal state of the tracker only. To make an example, if the developer manually tracks a `ScreenView` event, all the following events will have a `Screen` entity attached reporting the same information as the last tracked ScreenView event, even if it was manually tracked and the app is in a different screen.
-
-Indeed, disabling the `screenViewAutotracking` only, the tracker can still attach `Screen` entities automatically based only to the manual tracking of `ScreenView` events, and vice versa.
+The `Screen` entity is conditioned by the internal state of the tracker only. To make an example, if the developer manually tracks a `ScreenView` event, all the following events will have a `Screen` entity attached reporting the same information as the last tracked ScreenView event.
 
 ## Screen engagement tracking
 
+```typescript
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    screenEngagementAutotracking: true, // enabled by default
+});
+```
+
 Screen engagement tracking is a feature that enables tracking the user activity on the screen.
 This consists of the time spent and the amount of content viewed on the screen.
 
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/session-tracking/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/session-tracking/index.md
index f0d3def4f4..dfc07e1b50 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/session-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/session-tracking/index.md
@@ -12,37 +12,29 @@ import TabItem from '@theme/TabItem';
 
 Session tracking captures the session which helps to keep track of the user activity in the app.
 
-Client session tracking is enabled by default. It can be set through the `TrackerConfiguration` as explained below.
+Client session tracking is enabled by default. It can be set using the `sessionContext` option as explained below.
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    { endpoint: COLLECTOR_URL },
-    {
-        trackerConfig: {
-            sessionContext: true,
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    sessionContext: true,
+});
 ```
 
 When enabled, the tracker appends a [`client_session` entity](https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.snowplow/client_session/jsonschema/1-0-2) to each event it sends and it maintains this session information as long as the application is installed on the device.
 
 Sessions correspond to tracked user activity. A session expires when no tracking events have occurred for the amount of time defined in a timeout (by default 30 minutes). The session timeout check is executed for each event tracked. If the gap between two consecutive events is longer than the timeout the session is renewed. There are two timeouts since a session can timeout in the foreground (while the app is visible) or in the background (when the app has been suspended, but not closed).
 
-The timeouts for the session can be configured in the `SessionConfiguration` like in the example below:
+The timeouts for the session can be configured like in the example below:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    { endpoint: COLLECTOR_URL },
-    {
-        sessionConfig: {
-            foregroundTimeout: 1800, // seconds
-            backgroundTimeout: 1800 // seconds
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    foregroundSessionTimeout: 1800, // seconds
+    backgroundSessionTimeout: 1800 // seconds
+});
 ```
 
 The lifecycle events (`Foreground` and `Background` events) have a role in the session expiration. The lifecycle events can be enabled as explained in [App Lifecycle Tracking](../lifecycle-tracking/index.md). Once enabled they will be fired automatically when the app moves from foreground state to background state and vice versa.
@@ -53,16 +45,12 @@ When the app moves from background to foreground, the `Foreground` event is fire
 For instance, with this configuration:
 
 ```typescript
-const tracker = createTracker(
-    'appTracker',
-    { endpoint: COLLECTOR_URL },
-    {
-        sessionConfig: {
-            foregroundTimeout: 360, // seconds
-            backgroundTimeout: 15 // seconds
-        },
-    }
-);
+const tracker = await newTracker({
+    namespace: 'appTracker',
+    endpoint: COLLECTOR_URL,
+    foregroundSessionTimeout: 360, // seconds
+    backgroundSessionTimeout: 15 // seconds
+});
 ```
 
 the session would expire if the app is in background for more than 15 seconds, like in this example:
diff --git a/src/componentVersions.js b/src/componentVersions.js
index 5ca150c564..cfc0c126de 100644
--- a/src/componentVersions.js
+++ b/src/componentVersions.js
@@ -8,12 +8,12 @@ export const versions = {
   googleAmpTracker: '1.1.0',
   iosTracker: '6.0.8',
   javaTracker: '2.1.0',
-  javaScriptTracker: '4.1.0',
+  javaScriptTracker: '4.2.0',
   luaTracker: '0.2.0',
   phpTracker: '0.8.0',
   pixelTracker: '0.3.0',
   pythonTracker: '1.0.3',
-  reactNativeTracker: '2.1.1',
+  reactNativeTracker: '4.2.0',
   rokuTracker: '0.2.0',
   rubyTracker: '0.8.0',
   rustTracker: '0.2.0',

From d89e08e595d15849d27b34d55ffdc46a11c107da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matu=CC=81s=CC=8C=20Tomlein?= <matus.tomlein@gmail.com>
Date: Fri, 3 Jan 2025 13:10:35 +0100
Subject: [PATCH 3/9] Add docs for the screen view tracking browser plugin

---
 .../web-tracker/plugins/index.md              |   1 +
 .../tracking-events/screen-views/index.md     | 306 ++++++++++++++++++
 2 files changed, 307 insertions(+)
 create mode 100644 docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md

diff --git a/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md b/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md
index 09e09ce202..d35ca4f4bb 100644
--- a/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md
+++ b/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md
@@ -47,6 +47,7 @@ If you are using the JavaScript tracker with the full `sp.js` and your plugin is
 | Site*                                                                                                                                                       | Events              | Manual               | ✅       | ❌            | `browser-plugin-site-tracking`                 |
 | [Timezone](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/timezone-geolocation/index.md)            | Other               | Automatic            | ❌       | ❌            | `browser-plugin-timezone`                      |
 | [Web vitals](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/web-vitals/index.md)                    | Events              | Automatic            | ✅       | ❌            | `browser-plugin-web-vitals`                    |
+| [Screen views](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md)                    | Events              | Combination            | ❌       | ❌            | `browser-plugin-screen-tracking`                    |
 
 *The site tracking plugin provides events for [site search](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/site-search/index.md), [social media interactions](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/social-media/index.md), and [timing](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/timings/generic/index.md).
 
diff --git a/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md b/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md
new file mode 100644
index 0000000000..63d3aa4c1b
--- /dev/null
+++ b/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md
@@ -0,0 +1,306 @@
+---
+title: "Screen views"
+sidebar_position: 60
+---
+
+# Screen view tracking
+
+```mdx-code-block
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+```
+
+Screen view tracking is the recommended way to track users opening a screen in mobile apps.
+They are the default option for tracking views in our mobile trackers (iOS, Android, React Native, Flutter).
+On Web, [we recommend using page views](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/page-views/index.md) to track users visiting a page.
+However, using the screen view tracking plugin is also an option on Web if you prefer this data model.
+
+:::note
+The plugin is available from Version 4.2 of the tracker.
+:::
+
+## Install plugin
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+| Tracker Distribution | Included |
+|----------------------|----------|
+| `sp.js`              | ✅        |
+| `sp.lite.js`         | ❌        |
+
+**Download:**
+
+<table>
+  <tbody>
+    <tr>
+      <td>Download from GitHub Releases (Recommended)</td>
+      <td>
+        <a href="https://github.com/snowplow/snowplow-javascript-tracker/releases">Github Releases (plugins.umd.zip)</a>
+      </td>
+    </tr>
+    <tr>
+      <td>Available on jsDelivr</td>
+      <td>
+        <a href="https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-screen-tracking@latest/dist/index.umd.min.js">jsDelivr</a> (latest)
+      </td>
+    </tr>
+    <tr>
+      <td>Available on unpkg</td>
+      <td>
+        <a href="https://unpkg.com/@snowplow/browser-plugin-screen-tracking@latest/dist/index.umd.min.js">unpkg</a> (latest)
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+- `npm install @snowplow/browser-plugin-screen-tracking`
+- `yarn add @snowplow/browser-plugin-screen-tracking`
+- `pnpm add @snowplow/browser-plugin-screen-tracking`
+
+</TabItem>
+</Tabs>
+
+In order to make use of the plugin, you will need to register it with the tracker:
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+```javascript
+window.snowplow(
+    'addPlugin',
+    'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-button-click-tracking@latest/dist/index.umd.min.js',
+    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin']
+);
+```
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+```javascript
+import { ScreenTrackingPlugin } from '@snowplow/browser-plugin-screen-tracking';
+
+newTracker('sp1', '{{collector_url}}', {
+   appId: 'my-app-id',
+   plugins: [
+    ScreenTrackingPlugin()
+   ],
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+## Track a screen view event
+
+To track a screen view event, use the `trackScreenView` function.
+This will track a self-describing event with [the schema described here](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/page-and-screen-view-events/index.md#screen-view-events).
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+```javascript
+window.snowplow(
+  'trackScreenView',
+  {
+    name: 'my-screen-name',
+    id: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e', // generated automatically if not provided
+    type: 'carousel', // optional
+    transitionType: 'basic', // optional
+  }
+);
+```
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+```javascript
+import { trackScreenView } from '@snowplow/browser-plugin-screen-tracking';
+
+trackScreenView({
+  name: 'my-screen-name',
+  id: '5d79770b-015b-4af8-8c91-b2ed6faf4b1e', // generated automatically if not provided
+  type: 'carousel', // optional
+  transitionType: 'basic', // optional
+});
+```
+
+</TabItem>
+</Tabs>
+
+## Screen context entity
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+```javascript
+window.snowplow(
+    'addPlugin',
+    'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-button-click-tracking@latest/dist/index.umd.min.js',
+    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin']
+    [
+      {
+        screenContext: true, // enabled by default
+      }
+    ]
+);
+```
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+```javascript
+import { ScreenTrackingPlugin, trackScreenView } from '@snowplow/browser-plugin-screen-tracking';
+
+newTracker('sp1', '{{collector_url}}', {
+   appId: 'my-app-id',
+   plugins: [
+    ScreenTrackingPlugin({
+      screenContext: true, // enabled by default
+    })
+   ],
+});
+```
+
+</TabItem>
+</Tabs>
+
+If the `screenContext` property is enabled, the tracker attaches a [`Screen` entity](http://iglucentral.com/schemas/com.snowplowanalytics.mobile/screen/jsonschema/1-0-0) to all the events tracked by the tracker reporting the last (and probably current) screen visible on device when the event was tracked.
+
+The `Screen` entity is conditioned by the internal state of the tracker only. To make an example, if the developer manually tracks a `ScreenView` event, all the following events will have a `Screen` entity attached reporting the same information as the last tracked ScreenView event.
+
+## Screen engagement tracking
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+```javascript
+window.snowplow(
+    'addPlugin',
+    'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-button-click-tracking@latest/dist/index.umd.min.js',
+    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin']
+    [
+      {
+        screenEngagementAutotracking: true, // enabled by default
+      }
+    ]
+);
+```
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+```javascript
+import { ScreenTrackingPlugin, trackScreenView } from '@snowplow/browser-plugin-screen-tracking';
+
+newTracker('sp1', '{{collector_url}}', {
+   appId: 'my-app-id',
+   plugins: [
+    ScreenTrackingPlugin({
+      screenEngagementAutotracking: true, // enabled by default
+    })
+   ],
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+Screen engagement tracking is a feature that enables tracking the user activity on the screen.
+This consists of the time spent and the amount of content viewed on the screen.
+
+Concretely, it consists of the following metrics:
+
+1. Time spent on screen while the app was in foreground (tracked automatically).
+2. Time spent on screen while the app was in background (tracked automatically).
+3. Number of list items scrolled out of all list items (requires some manual tracking).
+4. Scroll depth in pixels (requires some manual tracking).
+
+This information is attached using a [`screen_summary` context entity](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/page-activity-tracking/index.md#screen-summary-entity) to the following events:
+
+1. [`screen_end` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/page-activity-tracking/index.md#screen-end-event) that is automatically tracked before a new screen view event.
+2. [`application_background` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#background-event).
+3. [`application_foreground` event](/docs/sources/trackers/snowplow-tracker-protocol/ootb-data/mobile-lifecycle-events/index.md#foreground-event).
+
+Screen engagement tracking is enabled by default, but can be configured using the `screenEngagementAutotracking` option when initializing the plugin.
+
+For a demo of how mobile screen engagement tracking works in action, **[please visit this demo](https://snowplow-incubator.github.io/mobile-screen-engagement-demo/)**.
+
+#### Updating list item view and scroll depth information
+
+To update the list item viewed and scroll depth information tracked in the screen summary entity, you can track the `ListItemView` and `ScrollChanged` events with this information.
+When tracked, the tracker won't send these events individually to the collector, but will process the information into the next `screen_summary` entity and discard the events.
+You may want to track the events every time a new list item is viewed on the screen, or whenever the scroll position changes.
+
+To update the list items viewed information:
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+```javascript
+window.snowplow(
+  'trackListItemView',
+  {
+    index: 1,
+    itemsCount: 10,
+  }
+);
+```
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+```javascript
+import { trackListItemView } from '@snowplow/browser-plugin-screen-tracking';
+
+trackListItemView({
+  index: 1,
+  itemsCount: 10,
+});
+```
+
+</TabItem>
+</Tabs>
+
+To update the scroll depth information:
+
+<Tabs groupId="platform" queryString>
+<TabItem value="js" label="JavaScript (tag)" default>
+
+```javascript
+window.snowplow(
+  'trackScrollChanged',
+  {
+    yOffset: 10,
+    xOffset: 20,
+    viewHeight: 100,
+    viewWidth: 200,
+    contentHeight: 300,
+    contentWidth: 400,
+  }
+);
+```
+
+</TabItem>
+<TabItem value="browser" label="Browser (npm)">
+
+```javascript
+import { trackScrollChanged } from '@snowplow/browser-plugin-screen-tracking';
+
+trackScrollChanged({
+  yOffset: 10,
+  xOffset: 20,
+  viewHeight: 100,
+  viewWidth: 200,
+  contentHeight: 300,
+  contentWidth: 400,
+});
+```
+
+</TabItem>
+</Tabs>

From 7f634f555b8a5df9104a72d8a1b22b4d31d02f7a Mon Sep 17 00:00:00 2001
From: Matus Tomlein <matus.tomlein@gmail.com>
Date: Wed, 8 Jan 2025 16:07:05 +0100
Subject: [PATCH 4/9] Apply suggestions from code review

Co-authored-by: Miranda Wilson <miranda@snowplow.io>
---
 .../tracking-events/screen-views/index.md          | 14 +++++++-------
 .../react-native-tracker/advanced-usage/index.md   |  2 +-
 .../migrating-from-v2-x-to-v4/index.md             |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md b/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md
index 63d3aa4c1b..7ce699d6be 100644
--- a/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md
+++ b/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md
@@ -72,7 +72,7 @@ In order to make use of the plugin, you will need to register it with the tracke
 ```javascript
 window.snowplow(
     'addPlugin',
-    'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-button-click-tracking@latest/dist/index.umd.min.js',
+    'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-screen-tracking@latest/dist/index.umd.min.js',
     ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin']
 );
 ```
@@ -141,7 +141,7 @@ trackScreenView({
 window.snowplow(
     'addPlugin',
     'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-button-click-tracking@latest/dist/index.umd.min.js',
-    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin']
+    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin'],
     [
       {
         screenContext: true, // enabled by default
@@ -154,7 +154,7 @@ window.snowplow(
 <TabItem value="browser" label="Browser (npm)">
 
 ```javascript
-import { ScreenTrackingPlugin, trackScreenView } from '@snowplow/browser-plugin-screen-tracking';
+import { ScreenTrackingPlugin } from '@snowplow/browser-plugin-screen-tracking';
 
 newTracker('sp1', '{{collector_url}}', {
    appId: 'my-app-id',
@@ -171,7 +171,7 @@ newTracker('sp1', '{{collector_url}}', {
 
 If the `screenContext` property is enabled, the tracker attaches a [`Screen` entity](http://iglucentral.com/schemas/com.snowplowanalytics.mobile/screen/jsonschema/1-0-0) to all the events tracked by the tracker reporting the last (and probably current) screen visible on device when the event was tracked.
 
-The `Screen` entity is conditioned by the internal state of the tracker only. To make an example, if the developer manually tracks a `ScreenView` event, all the following events will have a `Screen` entity attached reporting the same information as the last tracked ScreenView event.
+The `Screen` entity is based off the internal state of the tracker only. To make an example, if the developer manually tracks a `ScreenView` event, all the following events will have a `Screen` entity attached reporting the same information as the last tracked ScreenView event.
 
 ## Screen engagement tracking
 
@@ -182,7 +182,7 @@ The `Screen` entity is conditioned by the internal state of the tracker only. To
 window.snowplow(
     'addPlugin',
     'https://cdn.jsdelivr.net/npm/@snowplow/browser-plugin-button-click-tracking@latest/dist/index.umd.min.js',
-    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin']
+    ['snowplowScreenTrackingPlugin', 'ScreenTrackingPlugin'],
     [
       {
         screenEngagementAutotracking: true, // enabled by default
@@ -195,7 +195,7 @@ window.snowplow(
 <TabItem value="browser" label="Browser (npm)">
 
 ```javascript
-import { ScreenTrackingPlugin, trackScreenView } from '@snowplow/browser-plugin-screen-tracking';
+import { ScreenTrackingPlugin } from '@snowplow/browser-plugin-screen-tracking';
 
 newTracker('sp1', '{{collector_url}}', {
    appId: 'my-app-id',
@@ -231,7 +231,7 @@ Screen engagement tracking is enabled by default, but can be configured using th
 
 For a demo of how mobile screen engagement tracking works in action, **[please visit this demo](https://snowplow-incubator.github.io/mobile-screen-engagement-demo/)**.
 
-#### Updating list item view and scroll depth information
+### Updating list item view and scroll depth information
 
 To update the list item viewed and scroll depth information tracked in the screen summary entity, you can track the `ListItemView` and `ScrollChanged` events with this information.
 When tracked, the tracker won't send these events individually to the collector, but will process the information into the next `screen_summary` entity and discard the events.
diff --git a/docs/sources/trackers/react-native-tracker/advanced-usage/index.md b/docs/sources/trackers/react-native-tracker/advanced-usage/index.md
index c8ebb6c378..dac8810331 100644
--- a/docs/sources/trackers/react-native-tracker/advanced-usage/index.md
+++ b/docs/sources/trackers/react-native-tracker/advanced-usage/index.md
@@ -6,7 +6,7 @@ sidebar_position: 40
 
 ## Removing a tracker at runtime
 
-As also mentioned in Introduction, besides the `newTracker` function, the React Native Tracker also provides two functions that allow you to remove a tracker (or all of them) at runtime.
+The React Native tracker provides two functions that allow you to remove a tracker (or all of them) at runtime.
 
 ### removeTracker
 
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md b/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
index 541ec2052c..ab3a14e167 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
@@ -9,7 +9,7 @@ This brings support for new platforms (Web, Expo Go) and new features (JS tracke
 ### Initialize tracker instance using `newTracker` instead of `createTracker`
 
 The method for creating a new tracker instance has been changed to `newTracker`.
-This is not just a rename, but a change in the structure of it's parameters, which are now more in line with the rest of our JavaScript trackers.
+This is not just a rename, but a change in the structure of its parameters, which are now more in line with the rest of our JavaScript trackers.
 
 You can review the [documentation page](/docs/sources/trackers/react-native-tracker/introduction/index.md) for the current set of configuration options.
 

From 95701f2398e9e7df583b618fd5c9d7da325d99ce Mon Sep 17 00:00:00 2001
From: Matus Tomlein <matus.tomlein@gmail.com>
Date: Wed, 8 Jan 2025 16:07:37 +0100
Subject: [PATCH 5/9] Update
 docs/sources/trackers/react-native-tracker/introduction/index.md

Co-authored-by: Miranda Wilson <miranda@snowplow.io>
---
 .../sources/trackers/react-native-tracker/introduction/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/sources/trackers/react-native-tracker/introduction/index.md b/docs/sources/trackers/react-native-tracker/introduction/index.md
index 7490fa676a..21bbd073c1 100644
--- a/docs/sources/trackers/react-native-tracker/introduction/index.md
+++ b/docs/sources/trackers/react-native-tracker/introduction/index.md
@@ -11,7 +11,7 @@ import {versions} from '@site/src/componentVersions';
 The Snowplow React Native Tracker is purely implemented in JavaScript/TypeScript without the use of native iOS/Android modules. This enables it to support all these platforms and frameworks:
 
 - React Native for mobile and Web
-- Expo Go and managed workflow
+- Expo bare and managed workflow
 
 <p>The current version is {versions.reactNativeTracker}.</p>
 

From 728ae882b7137594a9072993e629c7315a8cb01f Mon Sep 17 00:00:00 2001
From: Matus Tomlein <matus.tomlein@gmail.com>
Date: Wed, 8 Jan 2025 16:07:55 +0100
Subject: [PATCH 6/9] Update
 docs/sources/trackers/react-native-tracker/introduction/index.md

Co-authored-by: Miranda Wilson <miranda@snowplow.io>
---
 .../sources/trackers/react-native-tracker/introduction/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/sources/trackers/react-native-tracker/introduction/index.md b/docs/sources/trackers/react-native-tracker/introduction/index.md
index 21bbd073c1..a77e359b6b 100644
--- a/docs/sources/trackers/react-native-tracker/introduction/index.md
+++ b/docs/sources/trackers/react-native-tracker/introduction/index.md
@@ -161,7 +161,7 @@ To learn more about the specific parts of the configuration and autotracked info
 
 ## Tracker methods
 
-### Tracking Events
+### Tracking events
 
 The React Native Tracker can track a range of out-of-the-box events. As an example, the following snippet tracks a screen view event:
 

From 989e83b24a9f5c4f1aa07ec4e69d160e389df94b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matu=CC=81s=CC=8C=20Tomlein?= <matus.tomlein@gmail.com>
Date: Wed, 8 Jan 2025 16:14:40 +0100
Subject: [PATCH 7/9] Reorder plugin list

---
 .../trackers/javascript-trackers/web-tracker/plugins/index.md   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md b/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md
index d35ca4f4bb..636e777547 100644
--- a/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md
+++ b/docs/sources/trackers/javascript-trackers/web-tracker/plugins/index.md
@@ -44,10 +44,10 @@ If you are using the JavaScript tracker with the full `sp.js` and your plugin is
 | [Performance navigation timing](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/timings/index.md)    | Entities            | Automatic            | ✅       | ❌            | `browser-plugin-performance-navigation-timing` |
 | [Performance timing (original)](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/timings/index.md)    | Entities            | Automatic            | ❌       | ❌            | `browser-plugin-performance-timing`            |
 | [Privacy Sandbox](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/privacy-sandbox/index.md)          | Entities            | Automatic            | ❌       | ❌            | `browser-plugin-privacy-sandbox`               |
+| [Screen views](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md)                    | Events              | Combination            | ❌       | ❌            | `browser-plugin-screen-tracking`                    |
 | Site*                                                                                                                                                       | Events              | Manual               | ✅       | ❌            | `browser-plugin-site-tracking`                 |
 | [Timezone](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/timezone-geolocation/index.md)            | Other               | Automatic            | ❌       | ❌            | `browser-plugin-timezone`                      |
 | [Web vitals](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/web-vitals/index.md)                    | Events              | Automatic            | ✅       | ❌            | `browser-plugin-web-vitals`                    |
-| [Screen views](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/screen-views/index.md)                    | Events              | Combination            | ❌       | ❌            | `browser-plugin-screen-tracking`                    |
 
 *The site tracking plugin provides events for [site search](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/site-search/index.md), [social media interactions](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/social-media/index.md), and [timing](/docs/sources/trackers/javascript-trackers/web-tracker/tracking-events/timings/generic/index.md).
 

From 145bbef7ec5dd7de20d9496e868af07e4800d8d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matu=CC=81s=CC=8C=20Tomlein?= <matus.tomlein@gmail.com>
Date: Wed, 8 Jan 2025 16:14:59 +0100
Subject: [PATCH 8/9] Use american anonymization spelling

---
 .../anonymous-tracking/index.md                    | 14 +++++++-------
 .../client-side-properties/index.md                |  4 ++--
 .../anonymous-tracking/index.md                    | 12 ++++++------
 .../client-side-properties/index.md                |  4 ++--
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md b/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
index 1047f15461..b6ddaf40ad 100644
--- a/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
@@ -23,13 +23,13 @@ import AnonymousTrackingSharedBlock from "@site/docs/reusable/anonymous-tracking
 <AnonymousTrackingSharedBlock/>
 ```
 
-Version 4 of the React Native tracker does not yet provide full support for client-side anonymisation, but this is something we plan to introduce in the upcoming versions.
+Version 4 of the React Native tracker does not yet provide full support for client-side anonymization, but this is something we plan to introduce in the upcoming versions.
 
-There are several levels to the anonymisation depending on which of the three categories are affected:
+There are several levels to the anonymization depending on which of the three categories are affected:
 
-## 1. Full client-side anonymisation
+## 1. Full client-side anonymization
 
-In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymisation:
+In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymization:
 
 ```typescript
 const tracker = await newTracker({
@@ -44,7 +44,7 @@ The version 4 does not yet automatically anonymise the `userId` in the Subject a
 These need to be removed manually.
 :::
 
-## 2. Client-side anonymisation with session tracking
+## 2. Client-side anonymization with session tracking
 
 This setting disables client-side user identifiers but tracks session information. In practice, this means that events track the Session context entity but the `userId` property is a null UUID (`00000000-0000-0000-0000-000000000000`). In case Platform context is enabled, the IDFA identifiers will not be present.
 
@@ -52,9 +52,9 @@ This setting disables client-side user identifiers but tracks session informatio
 This option is not yet available in the version 4 of the React Native tracker.
 :::
 
-## 3. Server-side anonymisation
+## 3. Server-side anonymization
 
-Server-side anonymisation affects user identifiers set server-side. In particular, these are the `network_userid` property set in server-side cookie and the user IP address. You can anonymise the properties using the `serverAnonymisation` flag in `EmitterConfiguration`:
+Server-side anonymization affects user identifiers set server-side. In particular, these are the `network_userid` property set in server-side cookie and the user IP address. You can anonymise the properties using the `serverAnonymisation` flag in `EmitterConfiguration`:
 
 ```typescript
 const tracker = await newTracker(
diff --git a/docs/sources/trackers/react-native-tracker/client-side-properties/index.md b/docs/sources/trackers/react-native-tracker/client-side-properties/index.md
index 64413a09e3..b29a255ab0 100644
--- a/docs/sources/trackers/react-native-tracker/client-side-properties/index.md
+++ b/docs/sources/trackers/react-native-tracker/client-side-properties/index.md
@@ -56,13 +56,13 @@ The tracker provides anonymous tracking functionality to mask certain user ident
 
 All enriched Snowplow events contain values for `user_ipaddress`, `useragent`, and `network_userid`. 
 
-The `user_ipaddress` is automatically added to all enriched events (unless [anonymous tracking with server anonymisation](../anonymous-tracking/index.md) is enabled). To manually override this, use a `Subject` and set an `ipAddress` string; use an empty string to prevent IP address tracking. Alternatively, use the [IP anonymization enrichment](/docs/pipeline/enrichments/available-enrichments/ip-anonymization-enrichment/index.md).
+The `user_ipaddress` is automatically added to all enriched events (unless [anonymous tracking with server anonymization](../anonymous-tracking/index.md) is enabled). To manually override this, use a `Subject` and set an `ipAddress` string; use an empty string to prevent IP address tracking. Alternatively, use the [IP anonymization enrichment](/docs/pipeline/enrichments/available-enrichments/ip-anonymization-enrichment/index.md).
 
 The `useragent` is also automatically added but it can be overriden on configuration. Snowplow pipelines provide multiple useragent-parsing [enrichments](/docs/pipeline/enrichments/available-enrichments/index.md). To manually override the detected useragent, use a `Subject` and set a `useragent` string.
 
 The `network_userid` is the cookie value for the event collector's third-party cookie. The cookie is named `sp` (or `micro` for Snowplow Micro pipelines). To override the collector cookie’s value with your own generated ID, use a `Subject` object and set `networkUserId`.
 
-The `network_userid` is stored in the tracker and it's kept the same until the app is deleted or the collector endpoint is changed or the cookie is expired. It is not assigned to events if anonymous tracking with server anonymisation is enabled.
+The `network_userid` is stored in the tracker and it's kept the same until the app is deleted or the collector endpoint is changed or the cookie is expired. It is not assigned to events if anonymous tracking with server anonymization is enabled.
 
 ## Setting the subject configuration
 
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md
index 7103e077bb..11dc7cc615 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/anonymous-tracking/index.md
@@ -22,11 +22,11 @@ import AnonymousTrackingSharedBlock from "@site/docs/reusable/anonymous-tracking
 
 <AnonymousTrackingSharedBlock/>
 ```
-There are several levels to the anonymisation depending on which of the three categories are affected:
+There are several levels to the anonymization depending on which of the three categories are affected:
 
-## 1. Full client-side anonymisation
+## 1. Full client-side anonymization
 
-In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymisation:
+In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymization:
 
 ```typescript
 const tracker = createTracker(
@@ -41,7 +41,7 @@ const tracker = createTracker(
 );
 ```
 
-## 2. Client-side anonymisation with session tracking
+## 2. Client-side anonymization with session tracking
 
 This setting disables client-side user identifiers but tracks session information. In practice, this means that events track the Session context entity but the `userId` property is a null UUID (`00000000-0000-0000-0000-000000000000`). In case Platform context is enabled, the IDFA identifiers will not be present.
 
@@ -58,9 +58,9 @@ const tracker = createTracker(
 );
 ```
 
-## 3. Server-side anonymisation
+## 3. Server-side anonymization
 
-Server-side anonymisation affects user identifiers set server-side. In particular, these are the `network_userid` property set in server-side cookie and the user IP address. You can anonymise the properties using the `serverAnonymisation` flag in `EmitterConfiguration`:
+Server-side anonymization affects user identifiers set server-side. In particular, these are the `network_userid` property set in server-side cookie and the user IP address. You can anonymise the properties using the `serverAnonymisation` flag in `EmitterConfiguration`:
 
 ```typescript
 const tracker = createTracker(
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md
index 4697f11b27..111253c78a 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/react-native-tracker-v2-reference/client-side-properties/index.md
@@ -56,13 +56,13 @@ The tracker provides anonymous tracking functionality to mask certain user ident
 
 All enriched Snowplow events contain values for `user_ipaddress`, `useragent`, and `network_userid`. 
 
-The `user_ipaddress` is automatically added to all enriched events (unless [anonymous tracking with server anonymisation](../anonymous-tracking/index.md) is enabled). To manually override this, use a `Subject` and set an `ipAddress` string; use an empty string to prevent IP address tracking. Alternatively, use the [IP anonymization enrichment](/docs/pipeline/enrichments/available-enrichments/ip-anonymization-enrichment/index.md).
+The `user_ipaddress` is automatically added to all enriched events (unless [anonymous tracking with server anonymization](../anonymous-tracking/index.md) is enabled). To manually override this, use a `Subject` and set an `ipAddress` string; use an empty string to prevent IP address tracking. Alternatively, use the [IP anonymization enrichment](/docs/pipeline/enrichments/available-enrichments/ip-anonymization-enrichment/index.md).
 
 The `useragent` is also automatically added but it can be overriden on configuration. Snowplow pipelines provide multiple useragent-parsing [enrichments](/docs/pipeline/enrichments/available-enrichments/index.md). To manually override the detected useragent, use a `Subject` and set a `useragent` string.
 
 The `network_userid` is the cookie value for the event collector's third-party cookie. The cookie is named `sp` (or `micro` for Snowplow Micro pipelines). To override the collector cookie’s value with your own generated ID, use a `Subject` object and set `networkUserId`.
 
-The `network_userid` is stored in the tracker and it's kept the same until the app is deleted or the collector endpoint is changed or the cookie is expired. It is not assigned to events if anonymous tracking with server anonymisation is enabled.
+The `network_userid` is stored in the tracker and it's kept the same until the app is deleted or the collector endpoint is changed or the cookie is expired. It is not assigned to events if anonymous tracking with server anonymization is enabled.
 
 ## Setting the subject configuration
 

From fb5918ddd933c7da4fc4ce4c75279a3fd99bc586 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matu=CC=81s=CC=8C=20Tomlein?= <matus.tomlein@gmail.com>
Date: Wed, 8 Jan 2025 16:25:42 +0100
Subject: [PATCH 9/9] Changes based on review

---
 .../anonymous-tracking/index.md               |   6 +-
 .../custom-tracking-using-schemas/index.md    |   2 +-
 .../migration-guides/index.md                 |  10 ++
 .../migrating-from-v0-x-to-v1/index.md        |   0
 .../migrating-from-v1-x-to-v2/index.md        |   0
 .../migrating-from-v2-x-to-v4/index.md        |   0
 .../previous-version/index.md                 |   2 +
 .../tracking-events/index.md                  | 108 +++++++++---------
 .../installation-tracking/index.md            |   2 +-
 .../lifecycle-tracking/index.md               |   2 +-
 10 files changed, 73 insertions(+), 59 deletions(-)
 create mode 100644 docs/sources/trackers/react-native-tracker/migration-guides/index.md
 rename docs/sources/trackers/react-native-tracker/{previous-version => migration-guides}/migrating-from-v0-x-to-v1/index.md (100%)
 rename docs/sources/trackers/react-native-tracker/{previous-version => migration-guides}/migrating-from-v1-x-to-v2/index.md (100%)
 rename docs/sources/trackers/react-native-tracker/{previous-version => migration-guides}/migrating-from-v2-x-to-v4/index.md (100%)

diff --git a/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md b/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
index b6ddaf40ad..65d7c9c4f8 100644
--- a/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/anonymous-tracking/index.md
@@ -17,14 +17,16 @@ This feature is available since v1.3.
 
 :::
 
+:::note
+Version 4 of the React Native tracker does not yet provide full support for client-side anonymization, but this is something we plan to introduce in the upcoming versions.
+:::
+
 ```mdx-code-block
 import AnonymousTrackingSharedBlock from "@site/docs/reusable/anonymous-tracking-mobile/_index.md"
 
 <AnonymousTrackingSharedBlock/>
 ```
 
-Version 4 of the React Native tracker does not yet provide full support for client-side anonymization, but this is something we plan to introduce in the upcoming versions.
-
 There are several levels to the anonymization depending on which of the three categories are affected:
 
 ## 1. Full client-side anonymization
diff --git a/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md b/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md
index 73b7032635..9c419fb97d 100644
--- a/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md
+++ b/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md
@@ -79,4 +79,4 @@ tracker.trackScreenViewEvent(
 );
 ```
 
-It is also possible to add custom contexts globally, so that they are applied to all events within an application. For more information, see the Global Contexts section below.
+It is also possible to add custom contexts globally, so that they are applied to all events within an application. For more information, see [the Global Contexts section](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/global-context/index.md).
diff --git a/docs/sources/trackers/react-native-tracker/migration-guides/index.md b/docs/sources/trackers/react-native-tracker/migration-guides/index.md
new file mode 100644
index 0000000000..3a34ce9a4f
--- /dev/null
+++ b/docs/sources/trackers/react-native-tracker/migration-guides/index.md
@@ -0,0 +1,10 @@
+---
+title: "Migration guides"
+sidebar_position: 90
+---
+
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />
+```
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v0-x-to-v1/index.md b/docs/sources/trackers/react-native-tracker/migration-guides/migrating-from-v0-x-to-v1/index.md
similarity index 100%
rename from docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v0-x-to-v1/index.md
rename to docs/sources/trackers/react-native-tracker/migration-guides/migrating-from-v0-x-to-v1/index.md
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v1-x-to-v2/index.md b/docs/sources/trackers/react-native-tracker/migration-guides/migrating-from-v1-x-to-v2/index.md
similarity index 100%
rename from docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v1-x-to-v2/index.md
rename to docs/sources/trackers/react-native-tracker/migration-guides/migrating-from-v1-x-to-v2/index.md
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md b/docs/sources/trackers/react-native-tracker/migration-guides/migrating-from-v2-x-to-v4/index.md
similarity index 100%
rename from docs/sources/trackers/react-native-tracker/previous-version/migrating-from-v2-x-to-v4/index.md
rename to docs/sources/trackers/react-native-tracker/migration-guides/migrating-from-v2-x-to-v4/index.md
diff --git a/docs/sources/trackers/react-native-tracker/previous-version/index.md b/docs/sources/trackers/react-native-tracker/previous-version/index.md
index a69556f4d0..b65dad8f33 100644
--- a/docs/sources/trackers/react-native-tracker/previous-version/index.md
+++ b/docs/sources/trackers/react-native-tracker/previous-version/index.md
@@ -2,6 +2,8 @@
 title: "Previous versions"
 date: "2021-08-09"
 sidebar_position: 100
+sidebar_custom_props:
+  outdated: true
 ---
 
 ```mdx-code-block
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/index.md
index 06bd7c05fd..0f0c0e0a41 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/index.md
@@ -41,60 +41,6 @@ The automatically captured data are:
 
 All tracker's `track` methods take two arguments: An object of key-value pairs for the event’s properties, and an optional array of [custom event contexts](/docs/sources/trackers/react-native-tracker/custom-tracking-using-schemas/index.md).
 
-### Tracking structured events
-
-Our philosophy in creating Snowplow is that users should capture important consumer interactions and design suitable data structures for this data capture. You can read more about that philosophy [here](/docs/data-product-studio/index.md). Using `trackSelfDescribingEvent` captures these interactions with custom schemas, as desribed above.
-
-However, as part of a Snowplow implementation there may be interactons where custom Self Describing events are perhaps too complex or unwarranted. They are then candidates to track using `trackStructuredEvent`, if none of the other event-specific methods outlined below are appropriate.
-
-For example:
-
-```typescript
-tracker.trackStructuredEvent({
-  category: 'my-category',
-  action: 'my-action',
-  label: 'my-label',
-  property: 'my-property',
-  value: 50.00
-});
-```
-
-**Required properties**
-
-- `category`: The name you supply for the group of objects you want to track e.g. ‘media’, ‘ecomm’
-- `action`: A string which defines the type of user interaction for the web object e.g. ‘play-video’, ‘add-to-basket’
-
-**Optional properties**
-
-- `label`: (string) - identifies the specific object being actioned e.g. ID of the video being played, or the SKU or the product added-to-basket
-- `property`: (string) - describes the object or the action performed on it. This might be the quantity of an item added to basket
-- `value`: (number) - quantifies or further describes the user action. This might be the price of an item added-to-basket, or the starting time of the video where play was just pressed
-
-### Tracking timing events
-
-Use the `trackTimingEvent` tracker method to track user timing events such as how long resources take to load.
-
-For example:
-
-```typescript
-tracker.trackTimingEvent({
-    category: 'timing-category',
-    variable: 'timing-variable',
-    timing: 5,
-    label: 'optional-label'
-});
-```
-
-**Required properties**
-
-- `category`: (string) - Defines the timing category
-- `variable`: (string) - Define the timing variable measured
-- `timing`: (number) - Represent the time
-
-**Optional properties**
-
-- `label`: An optional string to further identify the timing event
-
 ### Tracking screen view events
 
 Track the user viewing a screen within the application.
@@ -148,6 +94,31 @@ Optional properties
 - `pageTitle`: (string) – Page Title for the page view event.
 - `referrer`: (string) – Url for the referring page to the page view event. Must be a vaild url.
 
+### Tracking timing events
+
+Use the `trackTimingEvent` tracker method to track user timing events such as how long resources take to load.
+
+For example:
+
+```typescript
+tracker.trackTimingEvent({
+    category: 'timing-category',
+    variable: 'timing-variable',
+    timing: 5,
+    label: 'optional-label'
+});
+```
+
+**Required properties**
+
+- `category`: (string) - Defines the timing category
+- `variable`: (string) - Define the timing variable measured
+- `timing`: (number) - Represent the time
+
+**Optional properties**
+
+- `label`: An optional string to further identify the timing event
+
 ### Tracking consent granted events
 
 Use the `trackConsentGrantedEvent` method to track a user opting into data collection. A consent document context will be attached to the event using the `id` and `version` arguments supplied.
@@ -408,3 +379,32 @@ const attachment: MessageNotificationAttachmentProps = {
     url: 'http://att.url',
 };
 ```
+
+### Tracking structured events
+
+Our philosophy in creating Snowplow is that users should capture important consumer interactions and design suitable data structures for this data capture. You can read more about that philosophy [here](/docs/data-product-studio/index.md). Using `trackSelfDescribingEvent` captures these interactions with custom schemas, as desribed above.
+
+However, as part of a Snowplow implementation there may be interactons where custom Self Describing events are perhaps too complex or unwarranted. They are then candidates to track using `trackStructuredEvent`, if none of the other event-specific methods outlined below are appropriate.
+
+For example:
+
+```typescript
+tracker.trackStructuredEvent({
+  category: 'my-category',
+  action: 'my-action',
+  label: 'my-label',
+  property: 'my-property',
+  value: 50.00
+});
+```
+
+**Required properties**
+
+- `category`: The name you supply for the group of objects you want to track e.g. ‘media’, ‘ecomm’
+- `action`: A string which defines the type of user interaction for the web object e.g. ‘play-video’, ‘add-to-basket’
+
+**Optional properties**
+
+- `label`: (string) - identifies the specific object being actioned e.g. ID of the video being played, or the SKU or the product added-to-basket
+- `property`: (string) - describes the object or the action performed on it. This might be the quantity of an item added to basket
+- `value`: (number) - quantifies or further describes the user action. This might be the price of an item added-to-basket, or the starting time of the video where play was just pressed
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md
index 863036eca1..846229c882 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/installation-tracking/index.md
@@ -14,7 +14,7 @@ Installation tracking tracks an install event which occurs the first time an app
 
 If installation autotracking is not enabled, the tracker will still keep track of when the app was first installed, so that when enabled, the tracker will send the recorded install event with a timestamp reflecting when it was first installed.
 
-The installation autotracking is enabled by default. It can be set in `TrackerConfiguration` like in the example below:
+The installation autotracking is disabled by default. It can be set in `TrackerConfiguration` like in the example below:
 
 ```typescript
 const tracker = await newTracker({
diff --git a/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md b/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md
index b9f88ecd13..f3b095d2f2 100644
--- a/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md
+++ b/docs/sources/trackers/react-native-tracker/tracking-events/lifecycle-tracking/index.md
@@ -12,7 +12,7 @@ import TabItem from '@theme/TabItem';
 
 The tracker can capture application lifecycle state changes. In particular, when the app changes state from foreground to background and vice versa.
 
-The lifecycle tracking is disabled by default. It can be enabled using the `lifecycleAutotracking` option like in the example below:
+The lifecycle tracking is enabled by default. It can be disabled using the `lifecycleAutotracking` option like in the example below:
 
 ```typescript
 const tracker = await newTracker({