style cleanup to Get Started articles #118
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
markzegarelli
requested changes
Jun 21, 2024
There was a problem hiding this comment.
@SpencerFleury I didn't make it through all of them, but let me know your thoughts on the suggestions in the requested changes.
|
|
||
| For example, suppose you're trying to get users who have been inactive for more than seven days to return to your app, and you're testing the effectiveness of an email to make that happen. If the [Identify API](/docs/apis/analytics/identify) is used to update a user property, it will only be applied to those users who have returned to trigger an event in your application. If a user remains inactive after receiving the email, the user property will not be applied to this user. As a result, this inactive user will not be included in the experiment group that has received the email, because the user property never attached to them. In situations like these, we recommend updating user properties on an event action (eg. an event called "Email Sent"). | ||
| For example, suppose you're trying to get users who have been inactive for more than seven days to return to your app, and you're testing the effectiveness of an email to make that happen. If the [Identify API](/docs/apis/analytics/identify) is used to update a user property, it will only apply to those users who have returned to trigger an event in your application. If a user remains inactive after receiving the email, the user property doesn't apply to this user. As a result, this inactive user isn't included in the experiment group that has received the email, because the user property never attached to them. In situations like these, consider updating user properties on an event action (for example, an event called "Email Sent"). |
There was a problem hiding this comment.
Flagging for later, I don't like the word 'suppose' here.
| @@ -11,33 +11,33 @@ exclude_from_sitemap: false | |||
| updated_by: 0c3a318b-936a-4cbd-8fdf-771a90c297f0 | |||
| updated_at: 1717611551 | |||
| --- | |||
| A/B Testing is a method of conducting controlled, randomized experiments with the goal of improving a website or application metric. With Amplitude's [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret), you can measure the impact of your experiments by comparing how each experiment group behaves in your application. | |||
| A/B testing is a method of conducting controlled, randomized experiments with the goal of improving a website or application metric. With Amplitude's [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret), you can measure the impact of your experiments by comparing how each experiment group behaves in your application. | |||
|
|
|||
| For example, you can show two different onboarding flows to different groups of new users, then use the results to determine which one is more effective in driving users to complete the onboarding process. Or you can test different checkout flows to see which is more effective in generating sales. | |||
There was a problem hiding this comment.
Suggested change
| For example, you can show two different onboarding flows to different groups of new users, then use the results to determine which one is more effective in driving users to complete the onboarding process. Or you can test different checkout flows to see which is more effective in generating sales. | |
| For example, you can show two different onboarding flows to different groups of new users, then use the results to decide which one is more effective in driving users to complete the onboarding process. Or you can test different checkout flows to see which is more effective in generating sales. |
|
Those seem fine to me. Is Vale flagging all those passive voice instances?
I went out of my way to change them when they cropped up unless there was
no no-awkward way to do it. I'm surprised I could have skipped these if
they were flagged.
*Spencer Fleury*
Senior Help Center Program Manager
***@***.***
…On Fri, Jun 21, 2024 at 12:21 PM markzegarelli ***@***.***> wrote:
***@***.**** requested changes on this pull request.
@SpencerFleury <https://github.com/SpencerFleury> I didn't make it
through all of them, but let me know your thoughts on the suggestions in
the requested changes.
------------------------------
In content/collections/get-started/en/amplitude-home-page.md
<#118 (comment)>
:
> @@ -14,7 +14,7 @@ In Amplitude, the Home page is where you can get a quick overview on what’s ha
-You can go directly to the Home page anytime. Just click the Amplitude logo in the upper-left corner of the screen.
+Go directly to the Home page by clicking the Amplitude logo in the upper-left corner of the screen.
⬇️ Suggested change
-Go directly to the Home page by clicking the Amplitude logo in the upper-left corner of the screen.
+Click the Amplitude logo at the top-left of the screen to go to the Home page.
I'd love for us to use active voice more.
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
There are two main ways to update a user property:
1. [SDKs](/docs/sdks) & [Http API](/docs/apis/analytics/http-v2): Update user properties on event action.
- * **How:** User properties can be sent with each event via our [SDKs](/docs/sdks) or [HTTP API](/docs/apis/analytics/http-v2).
- * **Pros:** User properties will take effect at the moment the event is sent and exist with the user for all subsequent events, until the property values are explicitly updated.
- * **Cons:** These events will count towards your monthly event volume. Further, these events will count users as **active** users by default, so you'll need to ensure any A/B testing-related events are marked as [inactive events](/docs/data/change-event-activity-status).
+ * **How:** Send user properties with each event via Amplitude's [SDKs](/docs/sdks) or [HTTP API](/docs/apis/analytics/http-v2).
⬇️ Suggested change
- * **How:** Send user properties with each event via Amplitude's [SDKs](/docs/sdks) or [HTTP API](/docs/apis/analytics/http-v2).
+ * **How:** Send user properties with each event with Amplitude's [SDKs](/docs/sdks) or [HTTP API](/docs/apis/analytics/http-v2).
Personal nit, will add a vale rule for this.
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
2. [Identify API](/docs/apis/analytics/identify): Update user properties without sending an event.
* **How:** Amplitude's [Identify API](/docs/apis/analytics/identify) allows you to update a user property without sending an event.
- * **Pros:** Can asynchronously update a user property without sending an event, and will not impact your monthly event volume count.
- * **Cons:** The user property will not take effect until the user takes an action. This usually is not an issue for most experiments, but it **may have an impact on experiments** that are aimed to track whether or not inactive users are returning to your application.
+ * **Pros:** Can asynchronously update a user property without sending an event, and don't affect your monthly event volume count.
+ * **Cons:** The user property don't take effect until the user takes an action. This usually isn't an issue for most experiments, but it **may have an impact on experiments** intended to track whether inactive users are returning to your application.
⬇️ Suggested change
- * **Cons:** The user property don't take effect until the user takes an action. This usually isn't an issue for most experiments, but it **may have an impact on experiments** intended to track whether inactive users are returning to your application.
+ * **Cons:** The user property doesn't take effect until the user takes an action. This isn't an issue for most experiments, but it may impact on experiments that track if inactive users return to your application.
"usually" and "for most" feels duplicative. Can also make this shorter
overall
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
-For example, suppose you're trying to get users who have been inactive for more than seven days to return to your app, and you're testing the effectiveness of an email to make that happen. If the [Identify API](/docs/apis/analytics/identify) is used to update a user property, it will only be applied to those users who have returned to trigger an event in your application. If a user remains inactive after receiving the email, the user property will not be applied to this user. As a result, this inactive user will not be included in the experiment group that has received the email, because the user property never attached to them. In situations like these, we recommend updating user properties on an event action (eg. an event called "Email Sent").
+For example, suppose you're trying to get users who have been inactive for more than seven days to return to your app, and you're testing the effectiveness of an email to make that happen. If the [Identify API](/docs/apis/analytics/identify) is used to update a user property, it will only apply to those users who have returned to trigger an event in your application. If a user remains inactive after receiving the email, the user property doesn't apply to this user. As a result, this inactive user isn't included in the experiment group that has received the email, because the user property never attached to them. In situations like these, consider updating user properties on an event action (for example, an event called "Email Sent").
Flagging for later, I don't like the word 'suppose' here.
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
User Property Key: `Experiment 1`
User Property Value: `variation_a`
**Pros:** Can easily select experiments to segment by from the user segmentation tab.
-**Cons:** Can result in an overwhelming list of user properties, depending on the number of experiments being run.
+**Cons:** Can result in an overwhelming list of user properties, depending on the number of experiments currently running.
⬇️ Suggested change
-**Cons:** Can result in an overwhelming list of user properties, depending on the number of experiments currently running.
+**Cons:** Can result in an overwhelming list of user properties, depending on the number of active experiments.
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
> @@ -11,33 +11,33 @@ exclude_from_sitemap: false
updated_by: 0c3a318b-936a-4cbd-8fdf-771a90c297f0
updated_at: 1717611551
---
-A/B Testing is a method of conducting controlled, randomized experiments with the goal of improving a website or application metric. With Amplitude's [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret), you can measure the impact of your experiments by comparing how each experiment group behaves in your application.
+A/B testing is a method of conducting controlled, randomized experiments with the goal of improving a website or application metric. With Amplitude's [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret), you can measure the impact of your experiments by comparing how each experiment group behaves in your application.
For example, you can show two different onboarding flows to different groups of new users, then use the results to determine which one is more effective in driving users to complete the onboarding process. Or you can test different checkout flows to see which is more effective in generating sales.
⬇️ Suggested change
-For example, you can show two different onboarding flows to different groups of new users, then use the results to determine which one is more effective in driving users to complete the onboarding process. Or you can test different checkout flows to see which is more effective in generating sales.
+For example, you can show two different onboarding flows to different groups of new users, then use the results to decide which one is more effective in driving users to complete the onboarding process. Or you can test different checkout flows to see which is more effective in generating sales.
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
There are two main ways to update a user property:
1. [SDKs](/docs/sdks) & [Http API](/docs/apis/analytics/http-v2): Update user properties on event action.
- * **How:** User properties can be sent with each event via our [SDKs](/docs/sdks) or [HTTP API](/docs/apis/analytics/http-v2).
- * **Pros:** User properties will take effect at the moment the event is sent and exist with the user for all subsequent events, until the property values are explicitly updated.
- * **Cons:** These events will count towards your monthly event volume. Further, these events will count users as **active** users by default, so you'll need to ensure any A/B testing-related events are marked as [inactive events](/docs/data/change-event-activity-status).
+ * **How:** Send user properties with each event via Amplitude's [SDKs](/docs/sdks) or [HTTP API](/docs/apis/analytics/http-v2).
+ * **Pros:** User properties take effect at the moment the event is sent, and exist with the user for all subsequent events, until the property values are explicitly updated.
+ * **Cons:** These events count towards your monthly event volume. Further, these events count users as **active** users by default, so make sure any A/B testing-related events are marked as [inactive events](/docs/data/change-event-activity-status).
⬇️ Suggested change
- * **Cons:** These events count towards your monthly event volume. Further, these events count users as **active** users by default, so make sure any A/B testing-related events are marked as [inactive events](/docs/data/change-event-activity-status).
+ * **Cons:** These events count towards your monthly event volume. Further, these events count users as **active** users by default, so make sure to mark any A/B testing-related events as [inactive events](/docs/data/change-event-activity-status).
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
User Property: `Split Tests`
User Property Value: [`experiment_1_value`, `experiment_2_value`]
You can segment on the user property `Split Tests` by selecting the appropriate value or test group in the chart's [segmentation module](/docs/analytics/charts/build-charts-add-user-segments).
-**Pros:** You will only have one user property related to your split testing (rather than one per experiment), so your user property list will be more manageable in the dashboard.
-**Cons:** Arrays are limited to 10,000 characters if `append` or `prepend` is used. If an array were to exceed the character limit, then the characters past the threshold will not be recorded.
+**Pros:** You will only have one user property related to your split testing (rather than one per experiment), so your user property list is more manageable in the dashboard.
+**Cons:** Arrays may not exceed 10,000 characters if `append` or `prepend` is used. If an array were to exceed this limit, any characters past the threshold wouldn't be recorded.
⬇️ Suggested change
-**Cons:** Arrays may not exceed 10,000 characters if `append` or `prepend` is used. If an array were to exceed this limit, any characters past the threshold wouldn't be recorded.
+**Cons:** Arrays can't exceed 10,000 characters if you use `append` or `prepend` . If an array exceeds this limit, Amplitude doesn't record any characters past the threshold.
Present tense, active voice
------------------------------
In content/collections/get-started/en/analyze-a-b-test-results.md
<#118 (comment)>
:
>
## Viewing results in Amplitude
-You can review the results of your split tests after user properties have been updated for each experiment group. The [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret) chart that will allow you to conduct this analysis.
+You can review the results of your split tests after user properties update for each experiment group. The [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret) chart allows you to conduct this analysis.
⬇️ Suggested change
-You can review the results of your split tests after user properties update for each experiment group. The [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret) chart allows you to conduct this analysis.
+Review the results of your split tests after user properties update for each experiment group. Use the [AB Test View](/docs/analytics/charts/funnel-analysis/funnel-analysis-interpret) conduct this analysis.
—
Reply to this email directly, view it on GitHub
<#118 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGEII7H3MJPEOHQDIEUSFP3ZIR4LDAVCNFSM6AAAAABJUZLJK6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCMZTGI3TGOBWGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.