From d84122ede8fb6b3644863e2d083c00286b7ba82e Mon Sep 17 00:00:00 2001 From: forstisabella <92472883+forstisabella@users.noreply.github.com> Date: Tue, 23 Apr 2024 12:00:21 -0400 Subject: [PATCH 1/3] Update Identify spec to include note about uuidv4 format --- src/connections/spec/identify.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/connections/spec/identify.md b/src/connections/spec/identify.md index a4f79e692c..595df4a3e0 100644 --- a/src/connections/spec/identify.md +++ b/src/connections/spec/identify.md @@ -109,7 +109,7 @@ There are certain cases where you don't actually know who the user is according In these cases, you should use an Anonymous ID. -The Anonymous ID can be any pseudo-unique identifier. For example, on your servers you can use a session id. If you don't have any readily available identifier, you can always generate a new random one—Segment recommends [UUIDs](http://en.wikipedia.org/wiki/Universally_unique_identifier){:target="_blank"}. +The Anonymous ID can be any pseudo-unique identifier. For example, on your servers you can use a session id. If you don't have any readily available identifier, you can always generate a new random one — Segment recommends [UUIDv4 format](/docs/guides/working-with-ids/#segments-guidance-on-identifier-formats). > info "" > Segment's [browser and mobile libraries](/docs/connections/sources/) automatically use Anonymous IDs to keep track of users as they navigate around your website or app, so you don't need to worry about them when using those libraries. @@ -126,9 +126,9 @@ analytics.identify({ User IDs are a more permanent and robust identifier, like a database ID. Since these IDs are consistent across a customer's lifetime, Identify calls should include a User ID as often as possible. -A User ID is usually the unique identifier that you recognize a user by in your own database. For example, if you're using MongoDB it might look something like `507f191e810c19729de860ea`. +A User ID is usually the unique identifier that you recognize a user by in your own database. For example, if you're using MongoDB, User IDs might look something like this: `507f191e810c19729de860ea`. -Segment recommends using database IDs instead of simple email addresses or usernames, because database IDs _never_ change. That guarantees that even if the user changes their email address, you can still recognize them as the same person in all of your analytics tools. And even better, you'll be able to correlate analytics data with your own internal database. +Segment recommends using database IDs, [in `uuidv4` format](/docs/guides/working-with-ids/#segments-guidance-on-identifier-formats), instead of simple email addresses or usernames because database IDs _never_ change. That guarantees that even if the user changes their email address, you can still recognize them as the same person in all of your analytics tools. And even better, you'll be able to correlate analytics data with your own internal database. > success "" > Instead of using an email address or a username as a User ID, send them along as [custom traits](/docs/unify/traits/custom-traits/). From fb023aeeddc9ec291d8c879d8ed27f12ddc5fc3f Mon Sep 17 00:00:00 2001 From: forstisabella <92472883+forstisabella@users.noreply.github.com> Date: Tue, 23 Apr 2024 12:04:04 -0400 Subject: [PATCH 2/3] [netlify-build] --- src/connections/spec/identify.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/connections/spec/identify.md b/src/connections/spec/identify.md index 595df4a3e0..49153d879c 100644 --- a/src/connections/spec/identify.md +++ b/src/connections/spec/identify.md @@ -167,4 +167,4 @@ Reserved custom traits Segment has standardized: > info "" > You might be used to some destinations recognizing special traits by slightly different names. For example, Mixpanel recognizes a `$created` trait when the user's account was first created, while Intercom recognizes the same trait as `created_at` instead. Segment attempts to handle all the destination-specific conversions for you automatically. If you need help understanding if a specific field will be converted to a destination, take a look at Segment's [open source integration code](https://github.com/segment-integrations?q=&type=all&language=&sort=){:target="_blank"}, view the destination's documentation, or [contact Segment support](https://app.segment.com/workspaces?contact=1){:target="_blank"}. -**You can pass these reserved traits using camelCase or snake_case**, so in JavaScript you can match the rest of your camel-case code by sending `firstName`, while in Ruby you can match your snake-case code by sending `first_name`. That way the API never seems alien to your code base. Keep in mind that not all destinations support these reserved traits, so sending these traits in camelCase and snake_case can result in two sets of traits in other destinations. +**You can pass these reserved traits using camelCase or snake_case**, so in JavaScript you can match the rest of your camel-case code by sending `firstName`, while in Ruby you can match your snake-case code by sending `first_name`. That way the API never seems alien to your code base. Keep in mind that not all destinations support these reserved traits, so sending these traits in camelCase and snake_case can result in two sets of traits in other destinations. \ No newline at end of file From fdb24826aa46dde3e7f976a8f49ef29edc00dd7a Mon Sep 17 00:00:00 2001 From: forstisabella <92472883+forstisabella@users.noreply.github.com> Date: Tue, 23 Apr 2024 14:03:33 -0400 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: Casie Oxford --- src/connections/spec/identify.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/connections/spec/identify.md b/src/connections/spec/identify.md index 49153d879c..5d75e4b0be 100644 --- a/src/connections/spec/identify.md +++ b/src/connections/spec/identify.md @@ -128,7 +128,7 @@ User IDs are a more permanent and robust identifier, like a database ID. Since t A User ID is usually the unique identifier that you recognize a user by in your own database. For example, if you're using MongoDB, User IDs might look something like this: `507f191e810c19729de860ea`. -Segment recommends using database IDs, [in `uuidv4` format](/docs/guides/working-with-ids/#segments-guidance-on-identifier-formats), instead of simple email addresses or usernames because database IDs _never_ change. That guarantees that even if the user changes their email address, you can still recognize them as the same person in all of your analytics tools. And even better, you'll be able to correlate analytics data with your own internal database. +Segment recommends using database IDs, [in `uuidv4` format](/docs/guides/working-with-ids/#segments-guidance-on-identifier-formats), instead of email addresses or usernames because database IDs _never_ change. That guarantees that even if the user changes their email address, you can still recognize them as the same person in all of your analytics tools, and you'll be able to correlate analytics data with your own internal database. > success "" > Instead of using an email address or a username as a User ID, send them along as [custom traits](/docs/unify/traits/custom-traits/). @@ -167,4 +167,4 @@ Reserved custom traits Segment has standardized: > info "" > You might be used to some destinations recognizing special traits by slightly different names. For example, Mixpanel recognizes a `$created` trait when the user's account was first created, while Intercom recognizes the same trait as `created_at` instead. Segment attempts to handle all the destination-specific conversions for you automatically. If you need help understanding if a specific field will be converted to a destination, take a look at Segment's [open source integration code](https://github.com/segment-integrations?q=&type=all&language=&sort=){:target="_blank"}, view the destination's documentation, or [contact Segment support](https://app.segment.com/workspaces?contact=1){:target="_blank"}. -**You can pass these reserved traits using camelCase or snake_case**, so in JavaScript you can match the rest of your camel-case code by sending `firstName`, while in Ruby you can match your snake-case code by sending `first_name`. That way the API never seems alien to your code base. Keep in mind that not all destinations support these reserved traits, so sending these traits in camelCase and snake_case can result in two sets of traits in other destinations. \ No newline at end of file +**You can pass these reserved traits using camelCase or snake_case**, so in JavaScript you can match the rest of your camelCase code by sending `firstName`, while in Ruby you can match your snake-case code by sending `first_name`. That way the API never seems alien to your code base. Keep in mind that not all destinations support these reserved traits, so sending these traits in camelCase and snake_case can result in two sets of traits in other destinations. \ No newline at end of file