Merge pull request #273 from amplitude/DOC-253

DOC-253 fix 404s

content/collections/analytics/en/product-analytics.md

@@ -19,7 +19,7 @@ This feature is available on all Amplitude plans. For more information, see the
 
 On the Basic Settings page, select the event that represents an active action in your product. By default, Amplitude sets `[Amplitude] Any Active Event` as the event.
 
-Next, select the retention intervals that are most meaningful to you. Set both Daily and Weekly intervals. Use Amplitude's [usage interval analysis](docs/analytics/charts/retention-analysis/retention-analysis-usage-interval) to determine how long users go between triggering your critical event.
+Next, select the retention intervals that are most meaningful to you. Set both Daily and Weekly intervals. Use Amplitude's [usage interval analysis](/docs/analytics/charts/retention-analysis/retention-analysis-usage-interval) to learn how long users go between triggering your critical event.
 
 Configure breakdown properties for the Product Overview, Onboarding, and Retention views. Select up to three.
 

content/collections/event-segmentation/en/event-segmentation-in-line-events.md

@@ -19,26 +19,20 @@ Follow these steps to add a custom event:
 
 1. Click *More Options* in the *Events* side control and select *Combine events inline*.
 
-![](/docs/output/img/event-segmentation/-4kwHCRJq_nvW0E9oN9Y_JbirBp57tTdA5TE09o5UHb3XWt3Vx_rWP6A0e4C87r9LLOIk14GvHYr5554HS8HD1HPjYk0D9-O_qWjTZaswL24ICTPq5ti88C6sOXme80Qcj4Y77J8AyoPQZqsLrCA-uc)
-
 2. Next, click *Add event inline* to add a custom event. Add any number of custom events.
 
-![](/docs/output/img/event-segmentation/rFM_7I88rsHivl7dYUFlLxirvXBSxjBv0yilzSTzFeznNiL4mVchXd5brDg0Xay_nsnlJx6jjm8arG1yu5g_FQUVjr6clxac2oNyh1Z32iSoncl0PHk3PzcvK8AixQXFA7qRX_iFmjMv8zU9aBrXK28)
-
-{{partial:admonition type='note'}}
- The in-line event that you create will only be relevant to that specific chart and will not be accessible anywhere else unless it is saved as a custom event. 
-{{/partial:admonition}}
+  {{partial:admonition type='note'}}
+  The in-line event that you create is relevant to that specific chart and isn't accessible anywhere else unless you save it as a custom event. 
+  {{/partial:admonition}}
 
 3. If desired, hover on the event and click *Filter* to add event properties. Add as many filter properties as needed for each in-line event.
 
-![](/docs/output/img/event-segmentation/2qGAw9uAmao0tp6ZE4c0Hyo3VXKt6VApaZNJE0LKdXPKLt2i-yeaFyfSM_vn_d0EtYOiVS2SxFmBNLPZy1cAFuTN5WNp_Aj6dQfWT1sMG63QJfh4i44oHfaHYs4KTzOZLN93vEmKMepdCZHkLT23e_w)
-
 4. Save the in-line events as a [custom event](/docs/analytics/charts/group-events) to use it in other charts. Click **More Options** and choose *Save Custom Event*.
 
-![inline_to_custom.png](/docs/output/img/event-segmentation/inline-to-custom-png.png)
+  ![inline_to_custom.png](/docs/output/img/event-segmentation/inline-to-custom-png.png)
 
 5. Click *Remove* to remove properties and in-line events, as needed.
 
 {{partial:admonition type="note" heading=""}}
-Custom events can't contain other custom events. Also, *Show User Journeys*, *Explore Conversion Drivers* and *Show User Paths* aren't available via the Microscope for in-line event steps in funnels.
+Custom events can't contain other custom events. Also, *Show User Journeys*, *Explore Conversion Drivers* and *Show User Paths* aren't available from the Microscope for in-line event steps in funnels.
 {{/partial:admonition}}

content/collections/experiment/en/cohort-targeting.md

@@ -8,19 +8,19 @@ updated_by: c0ecd457-5b72-4dc9-b683-18a736413d32
 updated_at: 1723477635
 ---
 
-A cohort is a static or dynamic set of users defined in Amplitude. For experiment use cases, cohorts are particularly useful for advanced audience targeting. That said, cohorts are not always the best solution for targeting, so understanding how cohort targeting works with [local](./local-evaluation.md) vs [remote](./remote-evaluation.md) evaluation is important.
+A cohort is a static or dynamic set of users defined in Amplitude. For experiment use cases, cohorts are particularly useful for advanced audience targeting. That said, cohorts aren't always the best solution for targeting, so understanding how cohort targeting works with [local](/docs/experiment/local-evaluation) vs [remote](/docs/experiment/remote-evaluation) evaluation is important.
 
 Experiment cohort targeting currently only supports targeting **user** cohorts.
 
 ## Remote evaluation
 
-When you target a cohort in a remote evaluation flag, the cohort is automatically synced to the *Amplitude Experiment* destination. For dynamic cohorts, this sync runs hourly by default. This means that dynamic cohorts targeted in remote evaluation are **not real-time**. For example, if you target a cohort of users who performed a `Sign Up` event, users will be targeted within an hour of performing the event--not immediately after.
+When you target a cohort in a remote evaluation flag, the cohort is automatically synced to the *Amplitude Experiment* destination. For dynamic cohorts, this sync runs hourly by default. This means that dynamic cohorts targeted in remote evaluation aren't real-time. For example, if you target a cohort of users who performed a `Sign Up` event, users are targeted within an hour of performing the event--not immediately after.
 
-Cohorts targeted for remote evaluation may have a propagation delay on the initial sync or large change depending on the size of the difference. E.g. syncing a cohort of 10 million users for the first time will take some time to initially sync fully.
+Cohorts targeted for remote evaluation may have a propagation delay on the initial sync or large change, depending on the size of the difference. For example, the first sync of 10-million-user cohort is likely to take a lot more time than later syncs.
 
 **Use remote evaluation cohort targeting if...**
 
-- You are targeting users based on user behavior or properties which are not available in Experiment targeting segments.
+- You are targeting users based on user behavior or properties that aren't available in Experiment targeting segments.
 - You are ok with some targeting delay introduced by cohort sync intervals.
 
 **Don't use remote evaluation cohort targeting if...**
@@ -29,17 +29,17 @@ Cohorts targeted for remote evaluation may have a propagation delay on the initi
 
 ## Local evaluation
 
-Local evaluation flags and experiment that are deployed to up-to-date server-side SDKs can also target cohorts. When you target a cohort in a local evaluation flag, the cohort is automatically synced to the *Experiment Local Evaluation* destination. For dynamic cohorts, this sync runs hourly by default. This means that dynamic cohorts targeted in local evaluation are **not real-time**. For example, if you target a cohort of users who performed a `Sign Up` event, users will be targeted within an hour of performing the event--not immediately after.
+Local evaluation flags and experiment that are deployed to up-to-date server-side SDKs can also target cohorts. When you target a cohort in a local evaluation flag, the cohort is automatically synced to the *Experiment Local Evaluation* destination. For dynamic cohorts, this sync runs hourly by default. This means that dynamic cohorts targeted in local evaluation aren't real-time. For example, if you target a cohort of users who performed a `Sign Up` event, users will be targeted within an hour of performing the event--not immediately after.
 
 {{partial:admonition type="note" heading="Cohorts only support User IDs"}}
-Local evaluation cohorts currently only sync **User IDs** to the SDKs. This means that in order to target cohorts in local evaluation flags, you **must** include a User ID in the user object passed to the evaluate function.
+Local evaluation cohorts currently only sync **user IDs** to the SDKs. This means that to target cohorts in local evaluation flags, you **must** include a user ID in the user object passed to the evaluate function.
 {{/partial:admonition}}
 
 ### SDK Support
 
-Server-side SDKs can target cohorts if configured to do so. Client-side SDKs do not currently support local evaluation cohort targeting.
+Server-side SDKs can target cohorts if configured to do so. Client-side SDKs don't currently support local evaluation cohort targeting.
 
-On initialization, configure the cohort sync configuration with the project API and Secret key to enable local evaluation
+On initialization, configure the cohort sync configuration with the project API and secret key to enable local evaluation
 cohort downloading and targeting.
 
 | SDK | Cohort Targeting | Version |
@@ -119,7 +119,7 @@ experiment = AmplitudeExperiment.initialize_local('DEPLOYMENT_KEY',
 
 ## Troubleshooting
 
-Troubleshooting cohort targeting can challenging due to the asynchronous nature of dynamic cohorts and cohort syncs in general. If you find that users that should be in the targeted cohort are not being targeted...
+Troubleshooting cohort targeting can challenging due to the asynchronous nature of dynamic cohorts and cohort syncs in general. If you find that your experiment isn't targeting users who should be in the targeted cohort ...
 
 - For local evaluation, check that the SDK version supports local evaluation cohort targeting, and that **the cohort sync config has been set on initialization**.
 - Check that **the cohort has the required sync** (*Amplitude Experiment* for remote evaluation, *Experiment Local Evaluation* for local evaluation).

content/collections/faq_and_troubleshooting/en/funnel-analysis.md

@@ -7,7 +7,7 @@ category: charts
 ---
 This article covers frequently asked questions about the [Funnel Analysis](/docs/analytics/charts/funnel-analysis) chart.
 
-## Funnel Metrics
+## Funnel metrics
 
 {{partial:collapse name="Do funnels count by unique users or by event totals?"}}
 Either one. To switch from unique users to event totals, select *Totals* from the *Counting by* dropdown:
@@ -21,13 +21,13 @@ For event totals, the earliest-longest logic no longer applies. Amplitude consid
 You can use the Holding Property Constant feature to count by unique user-property pairs as well. For example, if you hold `Session ID` constant, you can count a user multiple times if they performed the funnel events in different sessions.
 
 {{partial:admonition type='note'}}
-In order to hold a property constant, it must exist in all events of the funnel.
+To hold a property constant, it must exist in all events of the funnel.
 {{/partial:admonition}}
 
 {{/partial:collapse}}
 
 {{partial:collapse name="Do funnel charts count conversion in 24-hour windows or by calendar dates?"}}
-The conversion window uses a **24-hour window** when looking at conversion from Step 1 to Step 2. It is not based on strict calendar dates.
+The conversion window uses a **24-hour window** when looking at conversion from Step 1 to Step 2. It's not based on strict calendar dates.
 
 ![funnels_FAQ_24_hour_window.png](/docs/output/img/faq/funnels-faq-24-hour-window-png.png)
 {{/partial:collapse}}
@@ -63,11 +63,9 @@ See more in [this help center article](/docs/analytics/charts/funnel-analysis/fu
 
 
 {{partial:collapse name="How is the median time to convert calculated?"}}
-When the funnel chart looks at the median time to convert in distribution view, it only takes the first conversion per user in the entire date range into account. When you switch to the time to convert over time view, we take the first conversion of each user in each day of the date range (e.g. If users can convert more than once in a day, only the first conversion of that day is considered).
+When the funnel chart looks at the median time to convert in distribution view, it only takes the first conversion per user in the entire date range into account. When you switch to the time to convert over time view, we take the first conversion of each user in each day of the date range (for example, if users can convert more than once in a day, only the first conversion of that day is considered).
 
 In both cases, we use [an approximate algorithm](https://metamarkets.com/2013/histograms/) to estimate the median time to convert. The median time to convert is only an approximation.
-
-![](/docs/output/img/faq/dpaf3D_0L1RNCWkqjfbc-I8KU0Wv12nsedi50Y7wlC0uukjqOmY9T4cMVwiSYvhA_qvCozNmAoZgvS2D3CF4n_UkMQMzwvJzpZgo7w5H8TVf_0FBeosPEBfG7grX5tnIJNkVYM8NpYKRbu_JOtDrlHE)
 {{/partial:collapse}}
 
 

content/collections/get-started/en/create-a-new-account.md

@@ -34,7 +34,7 @@ When Amplitude verifies that it can receive events, click *Next* to create your
 
 ## Other ways to install
 
-Amplitude supports other [integrations](/docs/data/source-catalog), [SDKs](/docs/sdks/analytics), and [API](docs/apis/analytics/http-v2) to help you start sending data.
+Amplitude supports other [integrations](/docs/data/source-catalog), [SDKs](/docs/sdks/analytics), and [API](/docs/apis/analytics/http-v2) to help you start sending data.
 
 For these methods, view the associated documentation for help getting started.
 

content/collections/get-started/en/create-project.md

@@ -12,7 +12,7 @@ exclude_from_sitemap: false
 this_article_will_help_you:
   - 'Create a project in Amplitude'
 ---
-Once your [organization is set up](/docs/get-started/create-org) and users have joined it, you can begin adding **projects**. Each analysis you create belongs to a specific project. In Amplitude, a project is a way to subdivide your Amplitude organization into distinct territories—for example, you might want to create individual projects for different products, or for different areas or sections of your app. It’s a useful way to keep related analyses grouped together.
+Once your organization is set up and users have joined it, you can begin adding **projects**. Each analysis you create belongs to a specific project. In Amplitude, a project is a way to subdivide your Amplitude organization into distinct territories—for example, you might want to create individual projects for different products, or for different areas or sections of your app. It’s a useful way to keep related analyses grouped together.
 
 Each project in Amplitude has its own separate API key for sending data. For example, if you have one iOS project and one Android project within your organization, each app sends data to their respective API keys.
 

content/collections/get-started/en/identify-users.md

@@ -15,9 +15,9 @@ Amplitude uses a combination of three different methods to identify your users:
 
 In Amplitude, a user ID is a unique identifier applied to individual users. Using them is optional, but recommended: your product should set a user ID once a user has created an account, logged in, or is otherwise identified in your product.
 
-Amplitude can use a user ID to reconcile events across multiple devices under the same user ID. Additionally, Amplitude merges a user's event data on the backend: this connects the correct user ID to any anonymous events the user generated before the assignment of their user ID. For this reason, you can wait to assign user IDs if that makes sense for your product. Conversely, this is also why you should **not** set user IDs for anonymous users.
+Amplitude can use a user ID to reconcile events across multiple devices under the same user ID. Additionally, Amplitude merges a user's event data on the backend: this connects the correct user ID to any anonymous events the user generated before the assignment of their user ID. For this reason, you can wait to assign user IDs if that makes sense for your product. Conversely, this is also why you shouldn't set user IDs for anonymous users.
 
-Once set, user IDs in Amplitude **cannot be changed**.
+Once set, you can't change user IDs in Amplitude.
 
 If your product doesn't currently assign user IDs, then feel free to skip this section.
 
@@ -28,4 +28,4 @@ Before continuing on to the next step, be sure to see [this article about how Am
 * **Don't set the user ID if there isn't one.** For example, if you set the user ID to the string `None`  for multiple users, Amplitude doesn't recognize those users as separate users. Instead, it assumes all those users are actually the **same** user, and it groups all events for those users together under that `None`  user ID. As stated earlier, you can always set the user ID later.
 * **Don't assign a user ID that might change.** User IDs are fixed forever: don't, for example, set a user's email address as their user ID—email addresses change.
 * **User IDs are case-sensitive.** If you set a user ID in a different case, Amplitude tracks two separate profiles for the same user.
-* **Assigning user IDs server-side can be tricky.** If you're running into issues assigning user IDs, [contact Amplitude Support](/docs/hc/en-us/requests/new).
+* **Assigning user IDs server-side can be tricky.** If you're running into issues assigning user IDs, [contact Amplitude Support](https://support.amplitude.com).