New Nav Structure

docs/best-practices/edgedb-and-edge-flags/edge-db-via-api-simple.md

@@ -40,7 +40,7 @@ To test it yourself, here is the data:
 
 Next, we need to supply the auth. Switch to the authorization tab and change the type to API Key. 
 
-For the “Value”, supply the server SDK key found in your [environments & keys tab.](/essentials/keys)
+For the “Value”, supply the server SDK key found in your [environments & keys tab.](/platform/account-management/keys)
 
 ![Untitled](/sept-6-2022-edge-flags-api-3.png)
 

docs/best-practices/edgedb-and-edge-flags/import-from-anywhere.md

@@ -9,7 +9,7 @@ Super Segments are collections of users that are targeted by data from any exter
 
 This means that users or their data can be “imported” into DevCycle for targeting in experiments or features by making use of EdgeDB. 
 
-While this can all be handled via the [EdgeDB API](/bucketing-api/#tag/EdgeDB), as outlined in [here](/platform/edgedb), DevCycle has created a Zapier integration which allows for easy sending of data directly to the desired EdgeDB environment in a project. This makes connecting any tools (like [Amplitude](https://amplitude.com/), [Segment](https://segment.com/) and others) with Zapier integrations directly to DevCycle extremely simple!
+While this can all be handled via the [EdgeDB API](/bucketing-api/#tag/EdgeDB), as outlined in [here](/platform/feature-flags/targeting/edgedb), DevCycle has created a Zapier integration which allows for easy sending of data directly to the desired EdgeDB environment in a project. This makes connecting any tools (like [Amplitude](https://amplitude.com/), [Segment](https://segment.com/) and others) with Zapier integrations directly to DevCycle extremely simple!
 
 ## Salesforce Guide
 
@@ -61,7 +61,7 @@ If you connect your account, the following fields will require input.
 
 ![Authorize DevCycle](/sept_6_2022_zapier_guide_8.png)
 
-[These keys can be found directly on your Organization’s setting page within DevCycle.](/essentials/keys)
+[These keys can be found directly on your Organization’s setting page within DevCycle.](/platform/account-management/keys)
 
 ![Keys Successful](/sept_6_2022_zapier_guide_9.png)
 
@@ -98,7 +98,7 @@ Now, any time a new lead enters SalesForce, it will be sent to EdgeDB with their
 Now that we’ve got data in EdgeDB, it can be used for targeting in any feature within DevCycle.
 
 :::info 
-Any data saved to EdgeDB is considered a “Custom Property” within DevCycle and can be targeted by simply adding that same property in the dashboard. To find out more about Custom Properties, [read here.](/platform/advanced-targeting/custom-properties) 
+Any data saved to EdgeDB is considered a “Custom Property” within DevCycle and can be targeted by simply adding that same property in the dashboard. To find out more about Custom Properties, [read here.](/platform/feature-flags/targeting/custom-properties) 
 :::
 
 To use the SalesForce data from above, simply create a new custom property in the dashboard (if it does not already exist):

docs/best-practices/engineering-led-experiments.md

@@ -14,18 +14,18 @@ While experimentation is often associated with marketing and revenue, experiment
 
 To complete this guide, you may want to review the following topics:
 
-- [Creating and Managing Variations](/essentials/variables)
-- [Random Distribution Targeting](/essentials/targeting)
-- [Feature Experimentation](/essentials/feature-experimentation)
-- [Creating a Metric](/platform/metrics/creating-and-managing-metrics) and [Metric Types](/platform/metrics/creating-and-managing-metrics#types)
+- [Creating and Managing Variations](/platform/feature-flags/variables-and-variations/variations)
+- [Random Distribution Targeting](/platform/feature-flags/targeting/random-variations)
+- [Feature Experimentation](/platform/experimentation/feature-experimentation)
+- [Creating a Metric](/platform/experimentation/creating-and-managing-metrics) and [Metric Types](/platform/experimentation/creating-and-managing-metrics#types)
 
 ## Metrics in DevCycle
 
 Metrics are how DevCycle measures data based on the custom events you choose to track. For example, you may conduct an experiment to determine what features cause the most errors. In this case, you would create a metric to track error rates.
 
 When you create a metric, it is not tied to a specific feature; they can be defined once and applied to as many features as desired. For instance, we could use the same error metric to determine the error rate of other features.
 
-To learn how to create a metric, read [Creating and Managing Metrics](/platform/metrics/creating-and-managing-metrics#creating-a-metric).
+To learn how to create a metric, read [Creating and Managing Metrics](/platform/experimentation/creating-and-managing-metrics#creating-a-metric).
 
 :::info
 Metrics are available to all customers on any plan. However, Metrics rely on custom events that incur extra costs. These costs will be added to your existing plan. To learn more, read about our pricing, or contact us at support@devcycle.com.
@@ -53,7 +53,7 @@ The `type` field in the object must correspond to the Event Type you defined whe
 :::
 ![Use the Event Type, not the Type](/august-2022-event-type-not-metric-type.png)
 
-If your Metric was a [numerical Type](/platform/metrics/creating-and-managing-metrics#types) (such as Sum Per User, Total Average, etc.) you may want to provide a value within your `event`. Some numerical data you may want to track are latency, load time, number of API calls, etc. Adding a numerical value to your object in JavaScript would look something like this:
+If your Metric was a [numerical Type](/platform/experimentation/creating-and-managing-metrics#types) (such as Sum Per User, Total Average, etc.) you may want to provide a value within your `event`. Some numerical data you may want to track are latency, load time, number of API calls, etc. Adding a numerical value to your object in JavaScript would look something like this:
 
 ```jsx
 const event = {
@@ -65,7 +65,7 @@ devcycleClient.track(event)
 
 You can include other data within the `event` object such as date, target, and metadata. For more information about tracking custom events with our other SDKs, refer to [Tracking Custom Events](/sdk/features).
 
-Once you have set up the SDK to send custom events, you can [apply your Metric to a feature](/platform/metrics/creating-and-managing-metrics#attaching-metrics-to-features).
+Once you have set up the SDK to send custom events, you can [apply your Metric to a feature](/platform/experimentation/creating-and-managing-metrics#attaching-metrics-to-features).
 
 ## Suggested Metrics
 
@@ -116,7 +116,7 @@ Some of the simplest and most precise experiments are basic A/B tests comparing
 
 For more complex features you may compare more variations with several combinations of variable values. You would then randomly distribute the variations according to the number of variations you are including in the experiment.
 
-For more information about comparing multiple variations in an experiment, refer to [Feature Experimentation](/essentials/feature-experimentation#comparing-multiple-variations).
+For more information about comparing multiple variations in an experiment, refer to [Feature Experimentation](/platform/experimentation/feature-experimentation#comparing-multiple-variations).
 
 ### Choosing Metrics
 

docs/best-practices/feature-grouping.md

@@ -10,7 +10,7 @@ This guide describes how to manage large amounts of feature flags with DevCycle.
 
 ## Why Group Flags?
 
-Feature Flags can accumulate very quickly. Without an organizational mechanism, the feature management dashboard would be extremely cluttered. Imagine developing a complex feature with various parts, such as the [Metrics and Experimentation feature in DevCycle](/essentials/feature-experimentation). Each piece of functionality needs a flag: There’s a flag for the API, the UI, each type of experimentation, string flags for naming, and so on. It would be helpful to have the ability to find all these flags in the same place.
+Feature Flags can accumulate very quickly. Without an organizational mechanism, the feature management dashboard would be extremely cluttered. Imagine developing a complex feature with various parts, such as the [Metrics and Experimentation feature in DevCycle](/platform/experimentation/feature-experimentation). Each piece of functionality needs a flag: There’s a flag for the API, the UI, each type of experimentation, string flags for naming, and so on. It would be helpful to have the ability to find all these flags in the same place.
 
 Not only do we want flags for each part of a feature, but we also want the ability to turn off the entire feature, all at once, in case something goes wrong. Other Feature Flag management solutions require you to create complex feature flag dependencies to set up a “master switch” for a group of flags. In contrast, DevCycle allows you to easily group feature flags and disable them simultaneously with one switch.
 
@@ -38,7 +38,7 @@ We should also rename our variation. Since our `show-metrics-api` flag is no lon
 
 ![Metrics API Variable is Off](/july-2022-metrics-api-false.png)
 
-But what if we only want a specific group of users to have the API disabled? Let’s say we want our Internal QA users to continue seeing the API, but we want it to be hidden from external users. **This leads to the second method to disable Variables: creating a new [Variation](/essentials/variables).** We can create a new Variation called “General Users” and set the `show-metrics-api` variable to `false`.
+But what if we only want a specific group of users to have the API disabled? Let’s say we want our Internal QA users to continue seeing the API, but we want it to be hidden from external users. **This leads to the second method to disable Variables: creating a new [Variation](/platform/feature-flags/variables-and-variations/variations).** We can create a new Variation called “General Users” and set the `show-metrics-api` variable to `false`.
 
 ![General users variation for Metrics Feature](/july-2022-general-users-variation.png)
 
@@ -48,13 +48,13 @@ Doing so will hide the API from users receiving the General Users variation, whi
 
 **Managing multiple Variables and Variations:**
 
-To learn more about managing multiple Variables and Variations within a feature, [Read here](/essentials/variables).
+To learn more about managing multiple Variables and Variations within a feature, [Read here](/platform/feature-flags/variables-and-variations/variables).
 
 :::
 
 ### Using Targeting as a “Master Switch”
 
-One challenge with many Feature Flag management solutions is creating a switch that controls a whole feature and its feature flag dependencies. DevCycle, however, makes it easy to disable an entire Feature and its Remote Variables using [Targeting Rules](/essentials/targeting).
+One challenge with many Feature Flag management solutions is creating a switch that controls a whole feature and its feature flag dependencies. DevCycle, however, makes it easy to disable an entire Feature and its Remote Variables using [Targeting Rules](/platform/feature-flags/targeting/targeting-overview).
 
 **Method 1: Disabling a feature for everyone**
 
@@ -74,7 +74,7 @@ Targeting Rules also allow you to disable the entire feature for only a specific
 
 **Targeting Users:**
 
-[Read here to learn more about how to Target Users](/essentials/targeting).
+[Read here to learn more about how to Target Users](/platform/feature-flags/targeting/targeting-overview).
 
 :::
 
@@ -90,4 +90,4 @@ Here are similar resources to help with organizing Feature Flags:
 
 - [Feature Types](/essentials/features)
 - [Effectively Organizing Your Feature Flags](/best-practices/effectively-organizing-feature-flags)
-- [Creating Variables & Variations](/essentials/variables)
+- [Creating Variables & Variations](/platform/feature-flags/variables-and-variations/variables)