Spelling fixes (#1688)

cspell.json

@@ -22,46 +22,87 @@
     "images"
   ],
   "words": [
+    "Adblockers",
     "addatatable",
+    "Adgroup",
+    "adid",
+    "akdav",
+    "Appsflyer",
+    "ARPU",
     "Authy",
     "autoload",
     "autoplay",
+    "autopopulate",
     "autoprovisioning",
+    "autotrack",
+    "autotracked",
     "backgrounded",
+    "backgrounding",
+    "Baiduspider",
     "Bamboleo",
+    "bingbot",
+    "bingewave",
+    "boto",
     "Bucketize",
     "callout",
     "Cartfile",
     "CCPA",
+    "checksumming",
     "Clickstream",
+    "cloudfunctions",
     "cloudimport",
     "clsx",
     "Cocoapods",
     "cohorting",
+    "colpito",
     "concat",
     "Dagster",
     "datetimes",
     "dclid",
+    "deprioritized",
+    "detangle",
     "Discoverability",
     "docsearch",
+    "Dorimoody",
     "DPDPA",
     "DWCK",
+    "Ecomm",
+    "ecommerce",
+    "elif",
+    "endswith",
     "expirable",
     "falsey",
     "fbclid",
+    "feross",
     "Figjam",
+    "fileobj",
+    "Fivetran",
     "Freshpaint",
     "gclid",
     "Geocluster",
     "geolocate",
     "Geolocation",
+    "Googlebot",
+    "groupkey",
+    "groupprofile",
+    "gsheets",
+    "gsutil",
+    "headlessui",
     "herokuapp",
     "Hightouch",
+    "hllsketch",
+    "hostapp",
+    "hotshard",
     "IDFA",
     "iframe",
+    "irlandese",
     "Isha",
+    "ivandiblasi",
+    "jashkenas",
     "Jayaram",
+    "JDBC",
     "Kapa",
+    "Kapture",
     "Leanplum",
     "Marketo",
     "Maxmind",
@@ -72,8 +113,10 @@
     "mpcehash",
     "mpeditor",
     "mpmetrics",
+    "mputils",
     "msclkid",
     "mxpnl",
+    "MYAPP",
     "mytoken",
     "nessie",
     "nextra",
@@ -85,34 +128,51 @@
     "Passcode",
     "Podfile",
     "postback",
+    "postbuild",
+    "Presta",
     "projectoken",
+    "projectsettings",
     "projecttoken",
+    "prostoalex",
     "pubspec",
     "quickstart",
+    "randint",
     "rdme",
+    "reactnative",
     "redocly",
     "Referer",
+    "remarketing",
     "retriggered",
     "retryable",
     "ROAS",
     "Rollbar",
     "rudderanalytics",
     "Rudderstack",
+    "sanitario",
+    "sccid",
     "SCIM",
     "screenflows",
     "searchbox",
     "serviceaccount",
+    "shlex",
     "Signup",
     "Signups",
+    "skus",
+    "splitlines",
+    "Stackdriver",
     "stddev",
     "Steph",
     "struct",
+    "Sunrostern",
     "superpropname",
     "superpropvalue",
     "tailwindcss",
+    "TBLPROPERTIES",
     "Tealium",
     "Textareas",
+    "trackcall",
     "ttclid",
+    "tupl",
     "twclid",
     "typeof",
     "uaparser",
@@ -121,17 +181,30 @@
     "unregistering",
     "Unsets",
     "unverify",
+    "upsell",
+    "upsells",
+    "upsold",
     "urlencode",
     "urllib",
     "urlparse",
+    "utag",
+    "utagdb",
+    "Varbyte",
+    "VARCHAR",
+    "Vendo",
     "Vijay",
     "virality",
     "waitlist",
     "wbraid",
     "webkitallowfullscreen",
+    "webp",
+    "webscraping",
     "xcworkspace",
     "XPUT",
+    "XSMALL",
+    "YOURAPISECRET",
     "yourdomain",
-    "yourfullname"
+    "yourfullname",
+    "YOURPROJECT"
   ]
 }

pages/docs/tracking-best-practices/debugging.md

@@ -148,7 +148,7 @@ Mixpanel records all events in Coordinated Universal Time (UTC) at intake. By de
 
 ### Different Queries
 
-- Are both systems looking at the same event and the same timeframe?
+- Are both systems looking at the same event and the same time frame?
 - Are any filters applied to the query? Does the discrepancy persist if you remove them?
 - Are you looking at event or user properties?
 
@@ -180,7 +180,7 @@ A cohort might show more in Mixpanel than what is actually being exported to the
 To debug, please make sure that you are looking at data in both systems like this:
 
 - data that is triggered at the same point of the user journey
-- at the same timeframe and timezone
+- at the same time frame and timezone
 - with the same filtering for the query of the data
 - at the same unit (unique user count, total event count or session count)
 

pages/docs/tracking-best-practices/hot-shard-limits.md

@@ -43,7 +43,7 @@ Updated Event -
 }
 ```
 
-These events can be queried from the dashboard just like any other events. An email is sent to organisation owners and the specific project's owners to alert them of the hot shard. In addition, a monthly report (per project) is sent as well for hot shards that were detected and remediated in the past month.
+These events can be queried from the dashboard just like any other events. An email is sent to organization owners and the specific project's owners to alert them of the hot shard. In addition, a monthly report (per project) is sent as well for hot shards that were detected and remediated in the past month.
 
 Starting in June 2024, we are also limitedly emitting a new type of events called `$hotshard_record`. The purpose is to keep track of all user-analytics and group-analytics hotshard remediation history that has happened inside your project in a central event type.
 
@@ -78,7 +78,7 @@ The board eases the process of identifying the data marked as coming from a hot
 Once you have identified the cluster of `distinct_id` values related to the issue, it would be time to review your implementation and inspect the reason why a set of these IDs are getting a higher than usual number of events. In general terms, you will often find these main scenarios:
 
 #### Events that are non-attributable to users but marked with a specific ID
-In some instances, your project will have events that should not be attributed to a specific user or group, like some automated tests being tracked, or perhaps ad-spend data you're importing; it may be that when implementing, a specific ID was abritrarily chosen for those events, say the string `"0"`, `"spend_data"` or perhaps even the name of the pod/server the data is coming from. This can lead to hundreds of thousands of events with the same ID causing this issue. 
+In some instances, your project will have events that should not be attributed to a specific user or group, like some automated tests being tracked, or perhaps ad-spend data you're importing; it may be that when implementing, a specific ID was arbitrarily chosen for those events, say the string `"0"`, `"spend_data"` or perhaps even the name of the pod/server the data is coming from. This can lead to hundreds of thousands of events with the same ID causing this issue. 
 
 If your use case is similar to this, and the event **should not be attributed to specific users or groups**, you can change your implementation to send those events with an empty string value `""`. Upon ingestion, Mixpanel will randomly store these events in different shards so you will not incur a performance hit if this is your intended use case.
 
@@ -373,7 +373,7 @@ for file_name in exported_files:
 ## Hot Shard FAQ
 
 #### How does hot shard detection work?
-The detection step runs in the ingestion pipeline. A counter of events is maintained for each `distinct_id` and `event_date` combination. The counter is best-effort as a result of the underlying systems used to maintain such a large keyspace.
+The detection step runs in the ingestion pipeline. A counter of events is maintained for each `distinct_id` and `event_date` combination. The counter is best-effort as a result of the underlying systems used to maintain such a large key space.
 
 Once a pre-defined threshold is crossed, the `distinct_id` is marked as contributing to a hot shard and all subsequent events for this `distinct_id` and `event_date` are updated to even the load across shards. Historical events prior to the hotshard detection for the same `distinct_id` are not updated.
 

pages/docs/tracking-methods/id-management/identifying-users-original.mdx

@@ -105,7 +105,7 @@ If using our Web/Mobile SDKs or a CDP like Segment or Rudderstack, there are onl
 
 
 <Callout type="warning">
-    The `distinct_id` is programatically selected by Mixpanel, using one of the IDs inside of an identity cluster, based on the most optimal merging process. This means that the canonical distinct_id could be set to a `$device_id` or your chosen `user_id`. This is not user-configurable. You can use any of the IDs in the cluster for ingestion, but only the canonical `distinct_id` can be used in queries and exports.
+    The `distinct_id` is programmatically selected by Mixpanel, using one of the IDs inside of an identity cluster, based on the most optimal merging process. This means that the canonical distinct_id could be set to a `$device_id` or your chosen `user_id`. This is not user-configurable. You can use any of the IDs in the cluster for ingestion, but only the canonical `distinct_id` can be used in queries and exports.
 </Callout>
 
 ## Example User Flows
@@ -115,7 +115,7 @@ Let's walk through a few user flows where ID Merge is useful, and when to call `
 
 1. A user lands in your product on a new device and interacts with your product before signing up. Our SDK will assign the user a random `$device_id` (D1) and persists it. All events tracked at this point will have `distinct_id` set to the `$device_id` value (D1).
 
-2. The user returns later and signs up for your product. You call `.identify(U1)`. Mixpanel adds U1 and D1 to the same identity cluster. Moving forward, any events tracked using either U1 or D1 will resolve to the same user. Mixpanel will set U1 or D1 as the `distinct_id` moving forward. This is programatically determined by Mixpanel and is not user-configurable.
+2. The user returns later and signs up for your product. You call `.identify(U1)`. Mixpanel adds U1 and D1 to the same identity cluster. Moving forward, any events tracked using either U1 or D1 will resolve to the same user. Mixpanel will set U1 or D1 as the `distinct_id` moving forward. This is programmatically determined by Mixpanel and is not user-configurable.
 
 ### Returning User
 

pages/docs/tracking-methods/id-management/migrating-to-simplified-id-merge-system.md

@@ -19,7 +19,7 @@ The Organization Settings for Identity Merge determines the default identity man
 
 <br />
 
-You can change the identity management version for a specific project (without affecting other projects) via Project Settings, provided no data has been ingested into the project. For new projects, we recommend setting the Simplied ID Merge (<b>Simplified API</b>) option as it is a generally more straightforward, simpler way of managing your users' identity in Mixpanel. 
+You can change the identity management version for a specific project (without affecting other projects) via Project Settings, provided no data has been ingested into the project. For new projects, we recommend setting the Simplified ID Merge (<b>Simplified API</b>) option as it is a generally more straightforward, simpler way of managing your users' identity in Mixpanel. 
 
 ![image](/Tracking/project-setting.png)
 
@@ -33,7 +33,7 @@ This guide assists you in evaluating whether a migration to Simplified ID Merge
 
 The main limitation of Legacy ID Management was that anonymous user states could become orphaned. This happens when an anonymous user was initially tracked on one platform or device, signs up as a user, and later on moved to another platform or device, triggering various anonymous events before logging in. The anonymous events on the second platform would be orphaned, resulting in duplicated users on Mixpanel. 
 
-Aliasing on Legacy ID Management can only be done once. Once a User ID is aliased to an Anonymous ID (typically on the 1st device where they started using your product), subsequent attempts to alias the same User ID to a different Anonymous ID (generate from a different platform or device) will fail. Here’s a diagram illustrating how a typical user journey on different devices ends up creating an ophaned user.
+Aliasing on Legacy ID Management can only be done once. Once a User ID is aliased to an Anonymous ID (typically on the 1st device where they started using your product), subsequent attempts to alias the same User ID to a different Anonymous ID (generate from a different platform or device) will fail. Here’s a diagram illustrating how a typical user journey on different devices ends up creating an orphaned user.
 
 ![image](/Tracking/legacy-id-management.png)
 
@@ -50,7 +50,7 @@ While retroactive identity merging is supported on Original ID Merge, the main l
 
 Reaching the 500 Distinct IDs per ID cluster limit is possible, when the process of generating new Anonymous IDs through `reset()` call on logout, and adding them to the ID cluster repeats 500 times. The `reset()` call is typically implemented in products where multiple users are sharing the same device. This ensures that anonymous events post logout are linked to the next user who logins in, rather than the last user who logout. If some of your users are approaching this cluster limit, you should revisit your implementation and consider removing the `reset()` call, unless there is a compelling use case where the benefits outweigh the implications of reaching the ID cluster limit. 
 
-Also, if you are considering Simplified ID Merge, it's important to note that it does not support multiple identified IDs (i.e. User IDs) per ID cluster. This is supported on Original ID Merge via special events such as \$merge and \$create_alias but they are not supported on Simplified ID Merge as the approch to identity management is completely different, more details [here](/docs/tracking-methods/id-management/identifying-users-simplified#example-user-flows).
+Also, if you are considering Simplified ID Merge, it's important to note that it does not support multiple identified IDs (i.e. User IDs) per ID cluster. This is supported on Original ID Merge via special events such as \$merge and \$create_alias but they are not supported on Simplified ID Merge as the approach to identity management is completely different, more details [here](/docs/tracking-methods/id-management/identifying-users-simplified#example-user-flows).
 
 ><b>Staying on Original ID Merge</b>
 >- If you don’t generally support multiple users sharing the same device, and don’t have a compelling use case requiring `reset()` calls on logout (or if you are implementing via server-side and do not generate new anonymous IDs for the same user), you are unlikely to run into the limit of 500 IDs per ID cluster, and should not consider the migration.  
@@ -241,7 +241,7 @@ Take note of the following details when planning for the migration from Legacy I
         "event": "App Install",
         "properties": {
             "token": "{{token}}",
-            "distinct_id": "$device:anoymous111"
+            "distinct_id": "$device:anonymous111"
         }
     }        
     ```
@@ -252,7 +252,7 @@ Take note of the following details when planning for the migration from Legacy I
         "event": "App Install",
         "properties": {
             "token": "{{token}}",
-            "distinct_id": "$device:anoymous111",
+            "distinct_id": "$device:anonymous111",
             "$device_id": "anonymous111"
         }
     }
@@ -301,7 +301,7 @@ Update your tech stack with the new project’s token, API secret, and service a
 
 1. Mixpanel <b>[Client-Side SDK](/docs/tracking-methods/choosing-the-right-method#client-side-tracking)</b> integration:
 
-   - Upgrade to the latest SDK version supporting Simplified ID Merge and initialise the SDK with new project’s token:
+   - Upgrade to the latest SDK version supporting Simplified ID Merge and initialize the SDK with new project’s token:
       - [Javascript ≥ v2.46.0](https://github.com/mixpanel/mixpanel-js/releases/tag/v2.46.0)
       - [Android ≥ v7.3.0](https://github.com/mixpanel/mixpanel-android/releases/tag/v7.3.0)
       - [iOS (Objective-C) ≥ v5.0.2](https://github.com/mixpanel/mixpanel-iphone/releases/tag/v5.0.2)
@@ -407,7 +407,7 @@ Discuss internally and decide on the best data migration approach with minimal i
 
 ### Migrating Reports and Non-Data Entities
 
-As part of creating the new Simplfied ID Merge project, you would also need to migrate existing boards, reports, and non-data entities (e.g. cohorts, custom events, custom properties, lookup tables, etc.) into the new project. Below is a recommended approach on how to go about doing this work:
+As part of creating the new Simplified ID Merge project, you would also need to migrate existing boards, reports, and non-data entities (e.g. cohorts, custom events, custom properties, lookup tables, etc.) into the new project. Below is a recommended approach on how to go about doing this work:
 
 1. <b>Cohorts, Custom Events, and Custom Properties</b>
    
@@ -428,7 +428,7 @@ As part of creating the new Simplfied ID Merge project, you would also need to m
    Move Board: Mixpanel provides a [Move Board](/docs/boards/advanced#move-board) feature that allows you to directly [transfer Boards between projects](/changelogs/2023-07-27-move) preserving reports, filters, and text annotations.
 
    Before you move any Board, it's important to note the following:
-   - Duplicate the existing Board and move the new copy into the new project. This would minimise impact where users are still using Boards and reports in the old project.
+   - Duplicate the existing Board and move the new copy into the new project. This would minimize impact where users are still using Boards and reports in the old project.
    - Any saved cohorts, custom events, custom properties, lookup tables would need to be created first as they don't get automatically moved as part of the Move Board. 
    - You may need to replicate the permissions for the moved Board should you have very specific [sharing permissions](/docs/boards/advanced#sharing) set in the existing project.
    - Double check that all reports (especially those that use cohorts, custom events, custom properties, lookup tables) are working properly.

pages/docs/tracking-methods/integrations/google-pubsub.md

@@ -46,7 +46,7 @@ def main(event, context):
     msg = base64.b64decode(event["data"]).decode("utf-8")
     events = [json.loads(line) for line in msg.split("\n") if len(line) > 0]
 
-    # Adjust the timestammps of each of the sample events so that
+    # Adjust the timestamps of each of the sample events so that
     # they appear recent. Note: this is just for this demo, do not
     # do this in production.
     for e in events:

pages/docs/tracking-methods/integrations/segment.mdx

@@ -171,7 +171,7 @@ Calling Segment SDK function [analytics.group()](https://segment.com/docs/connec
 //the groupId is "some_company"
 //the second argument contain 3 group profile properties to be set
 analytics.group("some_company", {
-    "$name": "some_companys_name",
+    "$name": "some_company_name",
     "employees": 100,
     "id": "some_company"
 })
@@ -203,7 +203,7 @@ If you are using [Segment Device Mode](https://segment.com/docs/connections/dest
 
 ## Debugging
 For debugging purposes, it can be useful to see exactly what Segment is sending to Mixpanel. You can validate this data through the [Segment Source Debugger](https://segment.com/docs/connections/sources/debugger/). In the Segment Source Debugger, you can select the event you are looking to validate:
-<img width="1080" alt="yGK1yH7zGy_cv5hLBEHgdU9oMyALishD6S0kObRRJANGxbjIEL" src="https://github.com/mixpanel/docs/assets/97630035/6ee0bbcd-8bf2-4f86-83a7-b0a3c39108e4" />
+<img width="1080" alt="debugger screenshot" src="https://github.com/mixpanel/docs/assets/97630035/6ee0bbcd-8bf2-4f86-83a7-b0a3c39108e4" />
 
 Click the “Validate” button in the top right corner and choose “Mixpanel” as the destination. After the event has been sent, you can click to view the request from Segment to grab the data payload:
 ![pasted image 0 (1)](https://github.com/mixpanel/docs/assets/97630035/0344decc-dc96-4569-ac3d-cc530c63bdb3)