Add docs text

docs/base/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Basics",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Basic knowledge about ABRouter."
+  }
+}

docs/base/settingUpExperiment.md

@@ -0,0 +1,18 @@
+---
+sidebar_position: 3
+---
+
+# Process of setting up the experiment
+
+Sometimes it's useful to think about the experiments overall, about the process of implementing new experiments in your product. Based on that process quality level you will have the level of quality for your final results.
+
+1. Define the hypothesis of the improvement, and what feature you can improve. For example, you want to test the color of the purchase button
+2. Define the multiple variables of the improvement. For the button, it will be "gray", "red", and "blue" for example. Currently, the color of the button is orange.
+3. Create the experiment in the ABRouter dashboard with the name "Purchase button color", uid: "purchase_button_color", and with the following branches: gray, red, blue, original (orange, current color). The split between branches will be 25/25/25/25.
+4. Set up the ABRouter in your project. See the available SDKs
+5. Define the events to track in your app and start sending them to ABRouter statistics.
+6. Implement the behavior on the running experiment in your product codebase. After a run, the application will receive the branch name. Based on that you have to change your application regarding the branch.
+7. Wait for enough data in the statistics to make a decision. Time-to-time checks the statistics to see the impact on your OKR metrics. If experiment branches are losing, time to think about stopping and reworking the experiment.
+8. After receiving enough data it's time to make the decision. Choose the right branch to make it a behavior.
+9. Deploy experiment removal
+10. Remove the experiment from ABRouter.

docs/base/settingUpFeatureFlag.md

@@ -0,0 +1,14 @@
+---
+sidebar_position: 4
+---
+
+# Process of setting up the feature flag
+
+Feature flags are easier than experiments. Don't need to keep the eye on the statistic by feature flag, but you need to focus on why needed this feature flag and when to enable or disable it.
+
+1. Create feature flag
+2. Disable it
+3. Integrate it into your code (see how to implement feature flags to your code)
+4. Enable it to check it when needed
+
+It's done. Your feature flag is working.

docs/base/whatExperiment.md

@@ -0,0 +1,16 @@
+---
+sidebar_position: 1
+---
+
+# What is experiment ?
+
+A/B testing, also known as split testing, refers to a randomized experimentation process wherein two or more versions of a variable (web page, page element, etc.) are shown to different segments of website visitors at the same time to determine which version leaves the maximum impact and drives business metrics.
+
+Learn how more about:
+
+[Setup experiments in Laravel](/docs/sdks/laravel)
+
+[Setup experiments in Symfony](/docs/sdks/symfony)
+
+[Setup experiments in vanilla PHP or other frameworks](/docs/sdks/php)
+

docs/base/whatFeatureFlag.md

@@ -0,0 +1,14 @@
+---
+sidebar_position: 2
+---
+
+# What is a feature flag?
+
+A feature flag is a software development process used to enable or disable functionality remotely without deploying code. New features can be deployed without making them visible to users. Feature flags help decouple deployment from release letting you manage the full lifecycle of a feature.
+
+[Setup feature flags in Laravel](/docs/sdks/laravel)
+
+[Setup feature flags in Symfony](/docs/sdks/symfony)
+
+[Setup feature flags in vanilla PHP or other frameworks](/docs/sdks/php)
+

docs/deploy/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Deploy ABRouter",
+  "position": 7,
+  "link": {
+    "type": "generated-index",
+    "description": "Deploying ABRouter tips and instructions."
+  }
+}

docs/deploy/deploy.md

@@ -0,0 +1,15 @@
+---
+sidebar_position: 2
+---
+
+# Deploying ABRouter locally or on the remote server.
+
+There is no things easiest in this world than deploying ABRouter locally or on your remote machine.
+
+The main repository of ABRouter is (https://github.com/abrouter/abrouter).
+
+This repository contains docker-compose.yml and instructions how to build ABRouter locally or on your remote machine.
+
+## Machine Requirements.
+
+It's enough to have 1GB RAM(Memory) and 1 Intel CPU to run ABRouter on your machine. This configuration can handle a lot of incoming requests.

docs/deploy/proscons.md

@@ -0,0 +1,27 @@
+---
+sidebar_position: 1
+---
+
+# Pros&cons of using self-hosted solution
+
+## Your decision: self-hosted or cloud solution
+
+ABRouter can be easily installed on your server and you can manage and run all A/B tests there.
+
+It's only your decision what to choose: self-hosted solution or cloud ABRouter. Pros&cons:
+
+Self-hosted:
+
++ +Forever free
++ +You can modify it for your needs
++ -Require support and monitoring
++ -Require updates
++ -Require payments for the server
+
+
+Cloud-hosted:
+
++ +Not expensive solution, free small products
++ +Allow you to focus on your business and metrics, not on the A/B tests tool - we will manage it for you
++ +Guaranteed up-time with SLA
+

docs/developer/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Developer cautions",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "description": "Most important information about ABRouter for developers."
+  }
+}

docs/developer/apiResources.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 5
+---
+
+# API Resources
+
+bla-bla-bla

docs/developer/branchMemorization.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 4
+---
+
+# Branch memorization
+
+After the experiment runs the user will get into the branch. Each further running will return the same branch. Syncing with glued temporary user-id is currently not implemented, but you can help us do it. 

docs/developer/howItWorksRunning.md

@@ -0,0 +1,11 @@
+---
+sidebar_position: 2
+---
+
+#  How it works: Running A/B test on the server
+
+ABRouter SDKs are working pretty easily. They making the HTTP requests to the ABRouter remote server. You need to send the user identifier and branch uid to run the experiment. The response will contain what branch the user got.
+
+If you don't enable the parallel running for your SDK request will be made synchronously.
+
+Parallel running mode allows you to reduce the time of running the experiment by PHP. 

docs/developer/separatingenvs.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 6
+---
+
+# Separating env's
+
+Currently, we don't have the ability to separate the env's in a single account. You can easily separate it by the different accounts for dev/RC/prod env's. 

docs/developer/userIdentifiers.md

@@ -0,0 +1,11 @@
+---
+sidebar_position: 3
+---
+
+# User identifiers
+
+In the world of ABRouter statistics exists multiple user identifiers. The temporary user id and user id.
+A temporary user id is an identifier to use when you don't have a real user id like a record from MySQL `users` table. It can be session-id or device id. You can generate it when the user doesn't have the permanent user id. For example, you can put PHP uniqid() to session and use it to send all events within the current session until the exchange for the permanent user id.
+At the moment, when you already have the permanent user id, you have to send it with a temporary user id to glue the user. Send it at least one time. There is no problem with sending it always. If you have any temporary user id, you can send it along with a permanent one.
+These users will become equal in the ABRouter system after the first glue.
+Each relationship between those users with the event will be calculated as +1 in the incremental display event type in the statistics.

docs/intro.md

@@ -2,46 +2,35 @@
 sidebar_position: 1
 ---
 
-# Tutorial Intro
+# Intro
 
-Let's discover **Docusaurus in less than 5 minutes**.
+Let's discover **ABRouter**.
 
-## Getting Started
+## About ABRouter
 
-Get started by **creating a new site**.
+ABRouter is a open-source, written on PHP+Laravel, platform to run A/B tests and feature flags on your product. ABRouter has a high level of support of PHP and PHP frameworks: Laravel and Symfony.
 
-Or **try Docusaurus immediately** with **[docusaurus.new](https://docusaurus.new)**.
+You can [learn more about the supported technologies on the SDK's page](developer/sdks).
 
-### What you'll need
+## ABRouter UI
 
-- [Node.js](https://nodejs.org/en/download/) version 14 or above:
-  - When installing Node.js, you are recommended to check all checkboxes related to dependencies.
+Besides, the good clients for PHP, we also have a pretty UI to manage A/B tests and feature flag.
 
-## Generate a new site
+You can start, stop, a/b tests and feature flags there, track the statistics and just enjoy it.
 
-Generate a new Docusaurus site using the **classic template**.
+## Using locally or cloud
 
-The classic template will automatically be added to your project after you run the command:
+We highly recommend you the pros&cons of [using ABRouter locally and as the cloud solution](deploy/proscons) before deploying it.
+[Learn more about how to deploy ABRouter](docs/deploy).
 
-```bash
-npm init docusaurus@latest my-website classic
-```
+## Getting started
 
-You can type this command into Command Prompt, Powershell, Terminal, or any other integrated terminal of your code editor.
+The first thing you need to do - sign up on the [ABRouter](https://abrouter.com/en/signup). Then, you can to [create experiment](managing/managingAbTests) or [feature flag](managing/managingFeatureFlags).
 
-The command also installs all necessary dependencies you need to run Docusaurus.
+After creating experiment or feature flag, please learn more about the process of releasing it for release managers or team-leads:
 
-## Start your site
+[Process of setting up the experiment](base/settingUpExperiment)
 
-Run the development server:
+[Process of setting up the feature flag](base/settingUpFeatureFlag)
 
-```bash
-cd my-website
-npm run start
-```
-
-The `cd` command changes the directory you're working with. In order to work with your newly created Docusaurus site, you'll need to navigate the terminal there.
-
-The `npm run start` command builds your website locally and serves it through a development server, ready for you to view at http://localhost:3000/.
-
-Open `docs/intro.md` (this page) and edit some lines: the site **reloads automatically** and displays your changes.
+We hope it will explain a lot. Additionally, we are recommending to read the [cautions for developers](category/developer-cautions).

docs/managing/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Managing",
+  "position": 3,
+  "link": {
+    "type": "generated-index",
+    "description": "Common knowledge about managing A/B tests and feature flags"
+  }
+}

docs/managing/makingDecisions.md

@@ -0,0 +1,16 @@
+---
+sidebar_position: 5
+---
+
+# Making decisions
+
+The main reason why we should use A/B testing is to optimize our conversions, LTV, and other metrics which will lead your product to grow.
+The test should be running until the exact win for one of the branches.
+
+But, winning by what? To define the winning rules we have to do some more things:
+
+1. Collect and set up the built-in statistics
+2. Define the key metrics as OKR (Objective Key Results)
+
+So, when already collecting statistics and having the events on the dashboard you have to decide the key(OKRs) metrics for you, depends on you can decide on what branch is winning.
+Don't rush, better to wait for enough collected data from the experiment and then, make the decision, set up the behavior of the winning branch as default in your product remove the experiment from the product codebase.

docs/managing/managingAbTests.md

@@ -0,0 +1,31 @@
+---
+sidebar_position: 1
+---
+
+# Managing and creating feature flags
+
+## Creating
+Important things in the experiment are experiment uid and branches. Experiment uid will be used in the code of your project to identify the experiment. Branches are the percentage to control the spreading of the users into testing variables.
+Let's do it step by step:
+
+Login to your account
+
+Click "Create new experiment"
+
+Imagine experiment name:
+The experiment name is your internal title of the experiment. You don't have to use it in your code.
+
+Imagine experiment uid:
+Experiment uid will be used to identify the experiment in your code.
+
+Branches:
+Now, you have to define the branches, and the splits(percentages) for each branch, that will be used for spreading your users into the branches. The branch, that the user got will define what he will see or experience in your product.
+Relying on the branch you have to create the "if-statement" in your app to apply the experiment to the application behavior.
+
+Then, click "Create" to save the data. You can edit it any time except the experiment uid. After creating the experiment will appear in your dashboard. You can copy the Experiment ID to use in your application.
+
+## Editing experiment
+To edit the experiment, find it in your dashboard and click on the pencil icon. You can easily change the percentage splits to raise the number of users who will get into some branches. It's highly recommended to set up the lower split to the branch which will probably affect your revenue and user experience. Then, based on the data you can raise the percentage if you see the sales/revenue growth in that branch.
+
+## Deleting the experiment
+If you already running the experiment in the application we highly don't recommend you delete that branch. It will not break your application, but can probably affect something. So, be careful and delete your experiment if you are sure the experiment is not used in your app yet or anymore.

docs/managing/managingFeatureFlags.md

@@ -0,0 +1,24 @@
+---
+sidebar_position: 2
+---
+
+# Process of setting up the feature flag
+
+## Creating feature flag"
+It takes a few moments to create a feature flag via ABRouter UI.
+Feature flag can enable or disable some features in your application with a click.
+
+Login to your account
+
+Click "Add new feature flag"
+
+Imagine the name of the feature flag
+
+Click "Create". 
+
+## Enabling/Disabling the feature flag:
+
+You can enable and disable the feature flag by the toggle on the dashboard. Changes will be automatically synced with your application.
+
+## Deleting the feature flag
+If you already running the feature flag in the application we highly don't recommend you delete the feature flag. It will not break your application, but can probably affect something. So, be careful and delete your feature flag if you are sure the experiment is not used in your app yet or anymore.

docs/managing/overallStatistics.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 4
+---
+
+#  Overall statistics
+
+Link to the overall statistic you can find in the left sidebar of your dashboard. Overall statistics are displaying the metrics regarding all display events and received events. It does not depend on the concrete experiment or branch. It can be useful to measure your current traction and find the opportunities to grow and funnel places to optimize. 

docs/managing/trackingAbTests.md

@@ -0,0 +1,39 @@
+---
+sidebar_position: 3
+---
+
+# Tracking A/B tests
+
+After creating the experiment and integrating it into your app, the next step is tracking. Built-in ABRouter statistics allow you to effectively track the best-performing branches of your experiments and the funnel overall.
+
+The first step on the way to track your experiment is defining your events, and starting to send the statistics to the ABRouter. You can do it by any of the ABRouter SDK's. Defining the events to track should be integrated into the process of creating new features in your product. If you don't sure track that event or not - better decide to track because you can decide to see the statistics by this event later.
+
+See how to send the events to ABRouter statistics.
+
+After start sending the events of the product to the ABRouter, you have to set up the display events in your statistics dashboard.
+
+A Statistics dashboard is currently common for all experiments and overall statistics, but we plan to implement the custom dashboards with the list of events to show.
+
+To set up the display events:
+
+Login to your account
+
+Click "Statistics" on the left sidebar
+
+Click "Add events". On this page, you will see the list of events that you have created.
+
+Then, click "Add event".
+
+Fill in the name of the event you're sending. Then, define the type of the event. ABRouter statistics currently have only 2 event types:
+
+## Incremental
+The incremental type is used to track the funnel indicators.
+For example, if your user has visited the payment page, you can send the "visit_payment_page" event. Then, set up the display event with the name "visit_payment_page" and type "Incremental".
+That metric will show you the unique relationship between user and payment page visits. If you're sending this event on each page reload, statistics will show calculate those events as one(+1), because you don't need to keep into account the rest of the events.
+
+## Summarizable
+Summarizable event type representing the value of the event in numbers. It can be a purchase, refund, or something else. Each summarizable event is calculatable. The Statistics dashboard will show you the daily sum for values of those types of events.
+
+
+After determining the type of event you can create the display event. After creating an event it will appear on each statistics page of our system: statistics by experiment, overall statistics.
+

docs/opensource.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 7
+---
+
+# Open-source
+
+Contributing to the ABRouter is welcoming. We will so glad to see you in the following repositories:

docs/sdks/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "SDK's",
+  "position": 5,
+  "link": {
+    "type": "generated-index",
+    "description": "List of client package for using ABRouter."
+  }
+}