Важно понимать, что для онлайн-канала были разработаны различные типы методов проверки личности. Однако не все из них соответствуют требованиям , необходимым для безопасного и надежного выполнения процесса .

Одним из методов, которым не соответствует соответствующим стандартам безопасности для удаленной проверки личности людей, является использование изображений и селфи .Это процесс, который обычно используется для идентификации операций с низким уровнем риска, хотя он ненадежен и безопасен .

Однако проверка подлинности потокового видео является безопасным и отвечает требованиям гарантий и юридических требований правил удаленной проверки личности. Некоторые решения, такие как VideoID , используют искусственный интеллект и машинное обучение для обеспечения полной надежности.

Процесс eKYC состоит из проверки личности людей на расстоянии в цифровом и онлайн-формате.Вам понадобится только устройство с камерой (компьютер, планшет, мобильный телефон…) и подключение к Интернету.

1. Пользователь, желающий зарегистрироваться, посещает веб-сайт , приложение или платформу компании , организации или учреждения.
2. Допускает использование камеры и микрофона для проверки личности.
3. Его просят показать удостоверение личности с обеих сторон , и он распознается и проверяется.
4. Впоследствии на пользователь показывает свое лицо, улыбаясь в камеру .
5. При необходимости группа квалифицированных агентов проверяет видео в отдельном процессе.
6. Личность была подтверждена, и учетные данные человека, а также записанное видео с документом, удостоверяющим личность человека и его лицом, а также подтверждение адреса электронной почты и телефона служат доказательством того, что пользователь является тем, кем он себя называет. Затем пользователь регистрируется компанией или организацией.

Запросите бесплатную демонстрацию прямо сейчас и узнайте из первых рук о процессе проверки личности.

Электронная подпись и аутентификация по лицу Методы также являются службами проверки личности , выполняющими различные процессы для разных целей. Оба могут работать с идентификацией потокового видео, наиболее безопасным и надежным методом проверки личности.

AML5 (или 5AMLD, Пятая директива о борьбе с отмыванием денег ) и eIDAS ( электронная идентификация, аутентификация и доверительные службы ) — это правила, которые устанавливают стандарты и нормы в отношении использования и форм онлайн-идентичности. проверка.

AML5 отвечает требованиям борьбы с мошенничеством и подделкой личных данных, отмыванием денег и финансированием терроризма, в то время как eIDAS регулирует все аспекты, связанные с электронной подписью, трастовыми услугами и электронными транзакциями в Интернете.

Эти европейские правила являются строгими, и завершают , обеспечивая процессы проверки личности , которые соответствуют им, с гарантированной поддержкой безопасности и надежности . Они являются эталоном международной нормативной базы во всех странах, касающейся процессов удаленной проверки личности.

Загрузите здесь полное руководство по этим правилам и преимуществам, которые они приносят в процессах идентификации.

Этот процесс необходим и обеспечивает полную безопасность в следующих случаях и ситуациях:

• Банковское дело и финансы : Открытие банковского счета , банковские и финансовые процедуры любого вида или онлайн-продаж и покупок .
• Телекоммуникации и страхование : закупка из продуктов и услуг , а также создание представлений
• Приложения и платформы: процесс входа в систему в Интернете или приложениях, вторичная аутентификация, доступ к объектам и здания, регистрация туристов, регистрация клиентов и пользователей и т. д.
• Правительство и администрация : для продления или выдачи электронных сертификатов, обновления документов, удостоверяющих личность, процессов идентификации для создания учетных данных электронного правительства или медицинских приложений и процедур, связанных с здоровье или рецепт на лекарства.

Electronic IDentification, eID, предлагает комплексные услуги по проверке личности для клиентов и граждан с помощью трех основных продуктов:

• VideoID , уникальное решение для идентификации с помощью видео в реальном времени на основе на основе искусственного интеллекта и машинного обучения , которое соответствует AML5 и eIDAS, что эквивалентно идентификации лицом к лицу.
• SmileID , биометрия лица сервис для высоконадежной аутентификации .
• SignatureID , окончательное простое, современное и квалифицированное решение для электронной подписи для всех типов документов, а также для заключения договоров или потребностей в цифровой подписи.

Свяжитесь с нами для получения дополнительной информации о решениях цифровой идентификации с высокой степенью защиты.

Различные способы определения пользовательских сегментов — ролей, демографии, состояний потребностей и персон.| Кейт Конрик

Я получаю много вопросов о том, как их сгруппировать и почему вы можете использовать разные типы идентификации пользователя. Ниже приведены некоторые из наиболее распространенных методов, используемых в промышленности и правительстве, а также короткие примеры, которые помогут вам понять каждый подход.

Роли определяют то, что человек пытается выполнить в определенном контексте. Это может быть их работа или их роль во взаимодействии со службой — например, клиент, консультант или сотрудник колл-центра.

Роли иногда называют действующими лицами, и когда у вас есть четкое представление и общее понимание различных ролей или действующих лиц, задействованных в службе, вы сможете лучше определить их опыт.

Роли помогают определить общие задачи, мотивацию и болевые точки. Роли могут пересекаться с демографическими группами или персонажами.

Некоторые практики сосредотачиваются на ролях, когда продукты или услуги, над которыми они работают, имеют разные типы пользователей, которые взаимодействуют друг с другом или сервисом при определенных обстоятельствах в зависимости от их роли.Это отличается от пользовательской базы, которая может иметь довольно однородные взаимодействия, но сами по себе совершенно разные.

Роли в действии

В налоговой инспекции ключевой пользовательский путь — это подача годовой налоговой декларации. Налоговая служба признает несколько ключевых ролей пользователей в этом путешествии:

• Физическое лицо , подающее налоговую декларацию
• Налоговый специалист , сторонний консультант, который оказывает коммерческую помощь в этом процессе
• Оценщики , внутренний персонал, который проверяет и обрабатывает налоговые декларации
• Персонал колл-центра , который направляет запросы о подаче налоговых деклараций и помогает людям находить нужные ответы

Демографические данные — это характеристики населения, такие как возраст, раса, этническая принадлежность, пол, семейное положение, способности, доход, образование и занятость.Кроме того, у нас есть внешние факторы, которые влияют на восприятие человека, например его местоположение и даже устройства, которые он использует.

При разработке цифровых услуг для службы поддержки, ориентированной на клиентов, действительно важны демографические данные. Определение основных демографических данных может помочь вам разработать дизайн, отвечающий их конкретным потребностям, и иногда может рассказать нам больше о том, что может испытывать пользователь, чем его роль. Так же, как вы — больше, чем ваша работа, иногда стоит рассмотреть более широкие факторы, чем роль пользователя.Различные демографические характеристики человека играют огромную роль в его опыте.

Демография в действии

При разработке продукта, который предоставляет необходимые социальные услуги, всегда необходимо учитывать множество различных демографических данных, в том числе (но не ограничиваясь ими):

• Пользователи с физическими ограничениями , в том числе с нарушениями зрения, слуха или подвижности, которым может быть труднее выполнять различные типы задач, например использование компьютеров, доступ к веб-сайтам или использование мобильных устройств
• Пользователи с когнитивными нарушениями или нарушениями обучения или с низким уровнем образования, которые могут иметь низкие навыки цифровой грамотности или плохо понимать контент и концепции
• Пользователи в удаленных или сельских районах или с низким уровнем доступа к технологиям , которые не обязательно имеют такой же уровень доступа к услугам, который можно было бы ожидать во многих городах

Каждая из этих демографических характеристик сразу помогает нам лучше понять соображения, которые мы должны учитывать, когда разработка для этих пользователей.Если у вашей пользовательской базы есть общие или основные демографические данные, определите их и убедитесь, что вы лучше понимаете потребности этих пользователей.

Подобно демографии, состояния потребности уходят корнями в маркетинг и рассказывают нам больше об опыте пользователя. В конце концов, реалии коммерческого рынка показали, что удовлетворение потребностей клиентов может дать продукту или услуге преимущество перед их конкурентами. Однако, в отличие от демографии, состояния потребности сосредоточены на попытках охарактеризовать поведение и мотивацию пользователей, которые могут меняться или переходить между состояниями в течение жизненного цикла взаимодействия с сервисом.

Может быть полезно выявить и определить некоторые ключевые состояния потребностей, чтобы развить общее понимание как «стенографию» для использования в исследованиях и проектировании.

Состояния потребности в действии

На сайте business.gov.au существует широкий спектр услуг, начиная от лиц, собирающихся начать бизнес, и заканчивая уже существующими предприятиями, отвечающими за регистрацию, отчетность и обязательства по лицензированию.

Вместо того, чтобы просто распознавать такие роли, как индивидуальный торговец или основатель компании, вы можете подумать о различных потребностях, которые затрагивают всю базу пользователей, независимо от ролей или демографии.Сюда могут входить такие категории, как:

• Options Explorer — новый пользователь, который изучает основы, чтобы помочь им принимать решения
• Trouble Shooter — часто разовый пользователь, специалист по устранению неполадок использует сервис для решения или получить помощь по конкретной проблеме
• Конструктор знаний — вернувшийся пользователь, который стремится расширить свои знания и часто будет изучать контент более тщательно, чем другие
• Пользователь Professional — опытный пользователь, который возвращается, чтобы получить доступ к конкретным информация или инструменты на регулярной основе, часто для профессиональных или коммерческих целей

На самом базовом уровне вы можете просто классифицировать пользователей как новых, вернувшихся или опытных.Распознавание состояний потребностей поможет вам удовлетворить конкретные потребности в различных обстоятельствах.

Персона — это профиль, в котором используется стереотипное воображаемое лицо для описания и представления сегмента пользовательской базы продукта. Они используются командами, работающими над продуктами и услугами, чтобы создать картину своих пользователей, к которой они могут легко вернуться.

Nielsen Norman Group описывает Персоны как:

вымышленное, но реалистичное описание типичного или целевого пользователя продукта.Персона — это архетип, а не реальный живой человек, но персонажи следует описывать так, как если бы они были настоящими людьми.

Персонажи — популярный инструмент, потому что, смешивая и сопоставляя роли, демографические данные и состояния потребностей в набор установленных персонажей, вы часто можете охватить все три вместе. Без этого можно легко сосредоточиться только на одном аспекте пользователей и игнорировать остальные.

Они также могут быть полезны в ситуациях, когда вы не сможете провести обширное тестирование с большим количеством пользователей.Помня о своих ролях, демографических данных и состояниях потребностей, команда может разработать решения, которые лучше подходят для этих пользователей.

Персонажи в действии

Персоны часто называют персонами — практика, которая помогает охарактеризовать их как «настоящие» и создать мысленный образ пользователя в команде.

Допустим, мы работали над продуктом или услугой, которые затрагивают широкую базу пользователей, например, приложение для онлайн-банкинга. Важно учитывать, как это работает для самых разных людей:

Что такое идентификаторы и связанные с ними факторы?

Подробнее

Что такое идентифицируемость?

Если вы можете отличить человека от других людей, то это лицо «идентифицировано» или «идентифицируемо».Часто имени человека вместе с некоторой другой информацией бывает достаточно, чтобы идентифицировать его.

Имя, пожалуй, самый распространенный способ идентифицировать кого-либо. Однако, действительно ли какой-либо потенциальный идентификатор, включая имя, идентифицирует человека, зависит от контекста.

Само по себе имя «Джон Смит» не всегда может быть личными данными, потому что есть много людей с таким именем. Однако, если имя сочетается с другой информацией (например, адресом, местом работы или номером телефона), этого часто бывает достаточно для четкой идентификации одного человека.

Пример

«Джон Смит, который работает в почтовом отделении в Уилмслоу».

Обычно этой информации может быть достаточно, чтобы напрямую идентифицировать человека. Однако, если это общепринятое имя и в этой организации работает более одного Джона Смита, вам потребуются дополнительные сведения, чтобы напрямую идентифицировать их, например:

«Джон Смит со светлыми волосами и зелеными глазами с татуировкой на правой руке, который работает в почтовом отделении в Уилмслоу».

Эта дополнительная информация помогает выделить этого конкретного человека.

Какая информация может быть идентификатором?

GDPR Великобритании предоставляет неполный список общих идентификаторов, которые при использовании могут позволить идентифицировать человека, к которому может относиться данная информация. Эти идентификаторы включают:

• наименование;
Идентификационный номер
• ;
• данных о местоположении; и
• онлайн-идентификатор.

Что такое онлайн-идентификаторы?

GDPR Великобритании специально включает термин «онлайн-идентификаторы» в определение того, что составляет персональные данные.

Они могут включать информацию, относящуюся к устройству, которое использует человек, приложениям, инструментам или протоколам. Неполный список включен в Recital 30:

• адресов интернет-протокола (IP);
• идентификаторов файлов cookie; и
• другие идентификаторы, такие как метки радиочастотной идентификации (RFID).

Другие примеры сетевых идентификаторов, которые могут быть личными данными, включают:

• MAC-адресов;
• рекламных идентификаторов;
• пиксельных тегов;
• дескрипторов счетов; и
• отпечатков пальцев устройства.

Их использование может оставить следы, которые в сочетании с уникальными идентификаторами и другой информацией, полученной серверами, могут быть использованы для создания профилей людей и их идентификации.

При оценке того, можно ли идентифицировать человека, вы должны учитывать, могут ли онлайн-идентификаторы, сами по себе или в сочетании с другой информацией, которая может быть доступна тем, кто обрабатывает данные, могут отличать одного пользователя от другого, возможно, путем создания профили людей для их идентификации.

Это может быть либо указанное лицо, либо просто уникальный пользователь электронных коммуникаций и других интернет-услуг, которого можно отличить от других пользователей.

Пример

Использование файлов cookie или аналогичных технологий для отслеживания человека на веб-сайтах включает обработку персональных данных, если это отслеживание включает в себя онлайн-идентификаторы, которые используются для создания профиля человека.

Пример

Использование распознавания лиц с целью однозначной идентификации человека включает обработку особых категорий персональных данных.

В этом контексте методы распознавания лиц фиксируют уникальные черты лица человека, чтобы отличить одного человека от другого. Затем он связывается с конкретным лицом и сохраняется для справки для будущего сравнения при идентификации, аутентификации и / или проверке.

Пример

«Обозначение» или имя пользователя в социальных сетях, которое может показаться анонимным или бессмысленным, по-прежнему является достаточным для их идентификации, поскольку оно однозначно идентифицирует этого человека.Имя пользователя является личными данными, если оно отличает одного человека от другого, независимо от того, возможно ли связать «онлайн-личность» с «реальным» именем человека.

Что еще может идентифицировать человека?

GDPR Великобритании дает понять, что личность человека может быть идентифицирована по другим факторам. К ним относятся:

«… один или несколько факторов, специфичных для физической, физиологической, генетической, умственной, экономической, культурной или социальной идентичности этого физического лица».

Такие характеристики могут помочь однозначно идентифицировать конкретного человека, поскольку они что-то говорят вам о нем.

Что делать, если мы все еще не уверены, является ли информация личными данными?

Бывают обстоятельства, при которых остается неясным, являются ли конкретные данные личными. Если это так, мы считаем, что в соответствии с передовой практикой вы все равно должны относиться к собранной информации как к личным данным. Вам по-прежнему необходимо защищать информацию из-за риска того, что в противном случае кто-то может с большей или меньшей уверенностью сделать вывод о конкретном человеке.Например, если он был опубликован и объединен с информацией, которой владеют другие организации. В некоторых случаях информация будет личными данными, и к ней будет применяться GDPR Великобритании. В частности вам следует:

• хранить информацию в безопасности;
• защитить его от ненадлежащего раскрытия;
• открыто рассказывайте о том, как вы собираете информацию; и
• гарантирует, что вы оправданы в любой обработке.

Дополнительная литература

Европейский совет по защите данных (EDPB), который заменил Рабочую группу по статье 29 (WP29), включает представителей органов по защите данных каждого государства-члена ЕС.Он принимает рекомендации по соблюдению требований GDPR. Руководящие принципы EDPB больше не будут иметь прямого отношения к режиму Великобритании и не будут иметь обязательной силы в рамках режима Великобритании. Однако они могут по-прежнему давать полезные советы по определенным вопросам.

Статья 29 Мнение Рабочей группы 4/2007 о концепции персональных данных WP136

Как Google Analytics использует файлы cookie для идентификации пользователей

Давайте поговорим о веб-файлах cookie и Google Analytics. Предупреждение: в этом сообщении блога не говорится о съедобных файлах cookie, но мы углубимся в детали, из которых состоят наши данные Google Analytics (каламбур!).

Основы файлов cookie

Файл cookie — это небольшой фрагмент информации, который сохраняется на вашем компьютере. Файлы cookie — это для конкретного браузера , что означает, что Chrome и Firefox не смогут получить доступ к файлам cookie друг друга. Файлы cookie также относятся к для конкретного сайта , что означает, что Amazon.com не сможет просматривать файлы cookie, которые вы сохранили на Facebook.com.

Общие типы файлов cookie

С каждым файлом cookie связан домен, и многие файлы cookie относятся к домену вашего веб-сайта (в нашем случае это будет Bounteous.com). Эти типы файлов cookie считаются «собственными» и создаются для доступа к информации одного и того же сайта относительно домена веб-сайта в адресной строке.

Разработчики вашего веб-сайта используют собственные файлы cookie для хранения информации о действиях пользователя — даже если он вошел в систему — от страницы к странице. Общие варианты использования файлов cookie включают в себя многосеансовый вход (сохранение пользователя в системе, даже когда он закрывает вкладку браузера) или запоминание предпочтений пользователя.

Однако часто домен, связанный с файлом cookie, не соответствует домену вашего веб-сайта (домену в адресной строке).Если домены различаются, эти файлы cookie считаются межсайтовыми или «сторонними» файлами cookie.

Это различие между собственными и сторонними файлами вскоре станет более важным, но пока давайте сосредоточимся на собственных файлах cookie и их использовании в Google Analytics.

Основы файлов cookie Google Analytics

Все версии отслеживания Google Analytics, которые вы можете встроить на свой веб-сайт, используют файлы cookie для хранения и запоминания ценной информации. Сегодня мы сосредоточимся на реализации Universal Analytics из Google Analytics, которая использует постоянный файл cookie _ga.

Файл cookie _ga хранит одну ценную информацию: ваш идентификатор клиента .

Это выглядит примерно так:

  GA1.2.12349876.1500644855  

Этот идентификатор клиента представляет вас, пользователя, который посещает веб-сайт, на котором реализован код отслеживания. В частности, Google Analytics использует _ga cookie для распознавания вашей уникальной комбинации браузера и устройства .

Примечание : Этот пост посвящен файлам cookie, используемым для представления пользователей.Существует отличный способ идентифицировать пользователей на вашем сайте, которые вошли в систему с помощью идентификатора пользователя, который передается в Google Analytics. Для получения дополнительной информации ознакомьтесь с разделом внизу!

Каким образом этот файл cookie получает свою ценность?

Для большинства реализаций по умолчанию, когда пользователь заходит на ваш веб-сайт, выполняется код Google Analytics и проверяется, существует ли уже файл cookie _ga. Если он есть, отлично — вы постоянный пользователь! Если файл cookie _ga отсутствует, он случайным образом сгенерирует новый идентификатор клиента для нового пользователя (также известного как «Новые пользователи» в Google Analytics).

Этот идентификатор клиента представлен в виде четырех наборов чисел, которые генерируются и затем сохраняются в файле cookie в браузере и на компьютере пользователя.

Что означает этот номер?

Идентификатор клиента — это комбинация 4 различных значений: версия, домен, идентификатор и время первого посещения.

Первым фиксированным числом является 1, которое представляет версию используемого формата файлов cookie.

Второе число, которое в приведенном выше примере является числом 2, зависит от домена, в котором установлен файл cookie.Легкий способ представить это — рассмотреть количество точек между поддоменами и корневыми доменами (например, bounteous.com = 1, www.bounteous.com = 2).

Третий набор чисел генерируется случайным образом для идентификации разных пользователей. (Технически, случайно сгенерированное 32-разрядное целое число без знака или любое другое значение от 1 до 2 147 483 647.).

Последний набор чисел — это отметка времени, когда пользователь впервые посетил сайт. Эта метка времени округляется до ближайшей секунды (не миллисекунды) первого посещения пользователя.

Как Google Analytics использует ваши файлы cookie

Файл cookie _ga используется для уникальной идентификации пользователей, в частности, с помощью третьего и четвертого набора чисел, описанных выше. Каждое действие, которое вы совершаете на веб-сайте или в приложении, называется Hit и отправляет данные вместе с вашим уникальным идентификатором клиента в Google Analytics.

Google Analytics затем ищет обращения, которые имеют один и тот же отдельный идентификатор клиента, и связывает обращения, которые происходят в течение одного и того же временного окна, в то, что мы называем сеансами . Пользователь , или уникальный идентификатор клиента, будет иметь от одного до нескольких сеансов, связанных с конкретным пользователем. В нашей отчетности Google Analytics идентификатор клиента также отвечает за сбор данных как для новых, так и для вернувшихся пользователей.

Сегодня мы не будем тратить слишком много времени на Scope, но ознакомьтесь с этой записью в блоге, чтобы получить больше информации: Understanding Scope in Google Analytics Reporting.

Однако на изображении ниже мы можем увидеть визуализацию идентификатора клиента («cid») и то, как cookie можно использовать для сбора обращений и создания сеансов для конкретного пользователя.

Все о сохранении файлов cookie

Сохранение файлов cookie — это постоянно меняющаяся тема, но мы выделим некоторые из наиболее важных концепций, которые вы должны знать и о которых нужно знать, включая ITP (интеллектуальное предотвращение отслеживания), субдомен и междоменное отслеживание.

Постоянство устройства

Файлы cookie пользователей не передаются между устройствами. Различные браузеры или устройства будут приводить к разным файлам cookie и, следовательно, к разным пользователям. Сколько браузеров вы используете для выхода в Интернет? Вы когда-нибудь посещали одни и те же сайты на разных устройствах? Здесь вы можете найти проблему.

Сохраняемость браузера

Каждый идентификатор клиента зависит от браузера, поэтому он не передается в разные браузеры на одном устройстве, например в два разных браузера на одном компьютере.

Для большинства браузеров (например, Google Chrome) _ga cookie по умолчанию сохраняется в течение двух лет бездействия. Для вернувшихся пользователей, каждый раз, когда пользователь посещает ваш сайт, это продлевает срок действия до двух лет с последней даты. При необходимости вы можете настроить это с помощью Диспетчера тегов Google или изменив скрипт Google Analytics на странице.

Однако недавние изменения в вопросах конфиденциальности со стороны таких браузеров, как Apple и Firefox, изменили постоянство сохранения cookie Google Analytics _ga по умолчанию для многих браузеров. Это изменение является результатом Intelligent Tracking Prevention, или ITP.

Что такое интеллектуальная система предотвращения слежения (ITP)?

ITP — это способ Apple (Safari) и Firefox ограничить возможность отслеживания пользователей на веб-сайтах с помощью сторонних файлов cookie. ITP (и его охват) продолжает развиваться, но окно сохранения файлов cookie продолжает сокращаться.

Apple впервые представила свой план интеллектуальной защиты отслеживания в 2017 году, при этом ITP 2.1 будет запущен 25 марта 2019 года. В этом выпуске все файлы cookie на стороне клиента (включая доверенные файлы cookie первой стороны, такие как Google Analytics) были ограничены до семи дней хранения.

Это может показаться коротким окном, поскольку многие пользователи не посещают веб-сайт каждую неделю. Однако с появлением ITP 2.2 и ITP 2.3, объявленных в сентябре 2019 года, все файлы cookie на стороне клиента теперь ограничены до 24-часового хранилища для пользователей Safari в macOS Mojave 10.14.5. Это означает, что если пользователь посетит ваш сайт в понедельник и вернется в среду, ему по умолчанию будет предоставлен новый файл cookie _ga.

Что это значит для наших данных Google Analytics?

В конечном итоге вашей организации необходимо будет определить уровень воздействия ITP на ваш веб-сайт и действовать соответствующим образом. Например, веб-сайты с большим количеством пользователей Safari и Firefox испытают всплеск уникальных посетителей, что нарушит показатель новых и вернувшихся пользователей.

Apple предоставила несколько рекомендаций, которые можно использовать для установки cookie _ga на два года, как ожидалось ранее.Подробнее по этим темам читайте здесь.

Как насчет очистки файлов cookie?

Вы затронули слабую сторону использования файлов cookie. Пользователь может очистить свои файлы cookie в любое время. Если пользователь посещает ваш сайт и отправляет информацию о трафике в Google Analytics с одним идентификатором клиента, а затем очищает свой кеш перед возвращением на ваш сайт, ему будет предоставлен новый файл cookie и идентификатор клиента, и он будет рассматриваться как новый пользователь в наших отчетах Google Analytics. .

Важно помнить, что показатель «Пользователи» в отчетах Google Analytics по умолчанию относится не к конкретным лицам, а к конкретным идентификаторам клиентов, которые могут меняться по многим причинам.

Но я вошел в Chrome…

Можно создать профиль в Chrome с вашим логином. Вы можете иметь персональную домашнюю страницу, синхронизировать закладки и иметь несколько пользователей на одном компьютере. К сожалению, файл cookie не прошел между этими сеансами входа в систему, поэтому один пользователь, вошедший в Chrome на разных устройствах, будет рассматриваться как два пользователя.

А как насчет субдоменов и междоменов?

Помните, что файлы cookie относятся к конкретному сайту .Если у вас есть поддомены или междомены, которые вы отслеживаете вместе в Google Analytics, вам необходимо проверить следующие две части.

Реализация Google Analytics по умолчанию предназначена для автоматической работы с субдоменами. (Помните, что два поддомена будут выглядеть как «blog.example.com» и «www.example.com.»). Если кто-то будет перемещаться между этими двумя сайтами, они сохранят одни и те же файлы cookie. Узнайте больше об отслеживании субдоменов, если вас беспокоит существующая реализация.

В то время как субдомены отслеживаются по умолчанию, междоменное отслеживание — это совсем другое дело. (Помните, что кросс-домены будут выглядеть как exampleblog.com и coolbusiness.com.). В этом случае ваши файлы cookie не будут передаваться между сайтами, если вы не настроите междоменное отслеживание с помощью Google Analytics. Подробнее: Требуется ли междоменное отслеживание?

Захват реальных пользователей вместо устройств и браузеров

Если вы качаете головой из-за ограничений сохранения файлов cookie, описанных выше, то вы захотите воспользоваться функцией User ID .

Хотя файлы cookie генерируются случайным образом и используются для представления анонимных посетителей, идентификатор пользователя удобен для сайтов, на которых вы действительно знаете , кто этот человек. Если на вашем сайте есть вход в систему, User ID для вас! В этом случае вы можете передать хешированный, не идентифицирующий личность идентификатор в Google Analytics, который можно использовать для сшивания сеансов и пользователей в разных браузерах и на разных устройствах. Подробнее о функции User ID в Google Analytics:

Использование идентификатора клиента для устранения неполадок

Наконец, понимание идентификатора клиента и его важности может быть очень полезным при устранении распространенных проблем, таких как ошибки отслеживания субдоменов, междоменное отслеживание, окна iframe … вы называете это.

Если вы хотите увидеть Client ID в действии, ознакомьтесь с несколькими сообщениями об устранении неполадок и отладке ваших данных:

Файлы cookie: основа веб-аналитики

являются основой большинства средств отслеживания веб-аналитики и полезны по ряду причин. Понимание того, как они работают, и потенциальных недостатков базового отслеживания Google Analytics может быть полезным для выявления ошибок отслеживания и лучшего описания ваших данных из Google Analytics.

Как мы уже упоминали выше, существует ряд факторов, изменяющих способ взаимодействия продуктов Google Analytics и Google Платформа для маркетинга с собственными и сторонними файлами cookie для некоторых браузеров. Прежде чем внедрять какое-либо решение для файлов cookie, важно понять потребности и проблемы вашего бизнеса и выбрать решение, которое наилучшим образом соответствует вашим маркетинговым целям и целям веб-сайта.

идентификаторов пользователей | Zendesk Developer Docs

Идентификационные данные пользователя — это то, что можно использовать для идентификации личности.Скорее всего, это адрес электронной почты, дескриптор Twitter или номер телефона. Zendesk Support поддерживает ряд таких идентификаторов.

Формат JSON

User Identities представлены как объекты JSON со следующими свойствами:

Если идентификатор имеет тип «phone_number», номер телефона должен быть прямой линией, а не общим телефонным номером.См. Номер телефона в API пользователей.

Состояние поставки

Если удостоверением является адрес электронной почты, свойство deliveryrable_state указывает, отправляет ли Zendesk уведомления по электронной почте на этот адрес. Если установлено значение «доставляемый», Zendesk отправляет уведомления на этот адрес. Zendesk не отправляет уведомления, если значение равно одному из следующих:

Пример

 
  {  «created_at»: «2011-07-20T22: 55: 29Z»,   «deliveryrable_state»: «доставляемый»,   «id»: 35436,   «primary»: true,   "type": "email",   "updated_at": "2011-07-20T22: 55: 29Z",   "url": "https://company.zendesk.com/api/v2/users/135 / identity / 35436.json ",  " user_id ": 135,  " value ":" [email protected] ",  " Verified ": true  }  

Список идентификаторов

• GET / api / v2 / users / {user_id} / identity

Возвращает список идентификаторов для данного пользователя.

• Пагинация курсора (рекомендуется)
• Смещение страницы

См. Разбивка на страницы.

Возвращает не более 100 записей на страницу.

Разрешено для

Параметры

Использование curl

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities.json \   -v -u {адрес электронной почты}: {пароль}  

Пример ответа

 
  Статус 200 ОК  
   {  «идентификаторов»: [  {  «created_at»: «2011-07-20T22: 55: 29Z»,   «id»: 35436,   «primary»: true,   » type ":" email ",  " updated_at ":" 2011-07-20T22: 55: 29Z ",  " user_id ": 135,  " value ":" [email protected] ",  " проверено ": true  },   { " created_at ":" 2012-02-12T14: 25: 21Z ",  " id ": 77136,  " primary ": false,  " type ": "twitter",   "updated_at": "2012-02-12T14: 25: 21Z",   "user_id": 135,   "value": "didgeridooboy",   "Verified": true  } ,   {  "created_at": "2012-02-12T14: 25: 21Z",   "id": 88136,   "primary": true,   "type": "phone_number",  «updated_at»: «2012-02-12T14: 25: 21Z»,   «user_id»: 135,   «value»: «+1 555-123-4567»,   «Verified»: true  }  ]  }  

Показать личность

• GET / api / v2 / users / {user_id} / identity / {user_identity_id}

Показывает личность с данным идентификатором для данного пользователя.

Разрешено для

Параметры

Использование curl

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities/{user_identity_id}.json \   -v -u {email_address}: {пароль}  

Пример ответа

 
  Статус 200 ОК  
   {  "identity": {  "created_at": "2012-02-12T14: 25: 21Z",   "id": 77938,   "primary": false,   "type": "twitter",   "updated_at": "2012-02-12T14: 25: 21Z",   "user_id": 13531,   "value": "cabanaboy",   "Verified": false  }  }  

Создать личность

• POST / api / v2 / users / {user_id} / identity
• POST / api / v2 / end_users / {user_id} / identity.JSON

Добавляет удостоверение в профиль пользователя. Агент может добавить идентификатор к любому профилю пользователя. Конечный пользователь может только добавить удостоверение в свой профиль пользователя.

Используйте первую конечную точку при аутентификации в качестве агента. Используйте второй, если аутентифицируетесь как конечный пользователь. Конечные пользователи должны аутентифицироваться с помощью токена.

Поддерживаемые типы удостоверений:

Чтобы создать удостоверение без отправки проверочного электронного письма, включите свойство «проверено»: true .

Разрешено для

• Агенты
• Проверенные конечные пользователи

Параметры

Использование curl

Только агенты

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities.json \   -H "Content-Type: application / json" -X POST \   -d '{"identity": {"type": "email", "value": "[email protected]"}} '-v -u {email_address}: {пароль}  

Использование curl

Только проверенные конечные пользователи

 
  curl https: // {subdomain} .zendesk.com / api / v2 / end_users / {user_id} /identities.json \   -H "Content-Type: application / json" -X POST \   - d '{"identity": {"type": "email", "value": "[email protected]"}}' -v -u {email_address} / token: {api_token}  

Пример ответа

 
  Статус 201 Создано  
   {  "identity": {  "created_at": "2012-02-12T14: 25: 21Z",   "id": 77938,   "primary": false,   "type": "twitter",   "updated_at": "2012-02-12T14: 25: 21Z",   "user_id": 13531,   "value": "cabanaboy",   "Verified": false  }  }  

Обновить идентификатор

• PUT / api / v2 / users / {user_id} / identity / {user_identity_id}

Эта конечная точка позволяет:

• Установить указанную личность как подтвержденную (но вы не можете отменить подтверждение подтвержденной личности)
• Обновить значение свойство указанного идентификатора

Вы не можете изменить первичный атрибут удостоверения личности с помощью этой конечной точки.Вместо этого вы должны использовать конечную точку Make Identity Primary.

Разрешено для

Параметры

Использование curl

К обновлению проверено

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities/{user_identity_id}.json \   -H "Content-Type: application / json" -X PUT \   -d '{"identity": { "Verified": true}} '-v -u {email_address}: {пароль}  

Использование curl

Обновить значение

 
  curl https: // {subdomain} .zendesk.com / api / v2 / users / {user_id} / identity / {user_identity_id} .json \   -H "Content-Type: application / json" -X PUT \   -d '{"identity": {"value": "[email protected]"}}' -v -u {email_address}: {password}  

Пример ответа

 
  Статус 200 ОК  
   {  «идентификатор»: {  «created_at»: «2011-07-20T22: 55: 29Z»,   «deliveryrable_state»: «доставляемый»,   «id»: 35436,   «основной» ": true,  " type ":" email ",  " updated_at ":" 2011-07-20T22: 55: 29Z ",  " user_id ": 135,  " value ":" [электронная почта защищена ] ",  " проверено ": верно  }  }  

Сделать идентификацию основным

• PUT / api / v2 / users / {user_id} / identity / {user_identity_id} / make_primary
• PUT / api / v2 / end_users / {user_id} / identity / {user_identity_id} / make_primary

Устанавливает указанный идентификатор как основной.Чтобы изменить другие атрибуты, используйте конечную точку Update Identity. Это операция на уровне коллекции, и правильным поведением клиента API является последующая перезагрузка всей коллекции.

Первая конечная точка является предпочтительным вариантом при аутентификации в качестве агента. При аутентификации в качестве конечного пользователя вы можете использовать только вторую конечную точку. Конечные пользователи должны аутентифицироваться с помощью токена.

Разрешено для

• Агенты
• Проверенные конечные пользователи

Параметры

Использование curl

Только агенты

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities/{user_identity_id}/make_primary.json \   -X PUT -v -u {email_address}: {password} -d '{}' -H "Содержание -Тип: application / json " 

Использование curl

Только проверенные конечные пользователи

 
  curl https: // {subdomain} .zendesk.com / api / v2 / end_users / {user_id} / identity / {user_identity_id} /make_primary.json \   -X PUT -v -u {email_address}: { пароль} -d '{}' -H "Content-Type: application / json"  

Пример ответа

 
  Статус 200 ОК  
   {  «идентификаторов»: [  {  «created_at»: «2011-07-20T22: 55: 29Z»,   «id»: 35436,   «primary»: true,   » type ":" email ",  " updated_at ":" 2011-07-20T22: 55: 29Z ",  " user_id ": 135,  " value ":" [email protected] ",  " проверено ": true  },   { " created_at ":" 2012-02-12T14: 25: 21Z ",  " id ": 77136,  " primary ": false,  " type ": "twitter",   "updated_at": "2012-02-12T14: 25: 21Z",   "user_id": 135,   "value": "didgeridooboy",   "Verified": true  } ,   {  "created_at": "2012-02-12T14: 25: 21Z",   "id": 88136,   "primary": true,   "type": "phone_number",  «updated_at»: «2012-02-12T14: 25: 21Z»,   «user_id»: 135,   «value»: «+1 555-123-4567»,   «Verified»: true  }  ]  }  

Подтвердите личность

• PUT / api / v2 / users / {user_id} / identity / {user_identity_id} / verify

Устанавливает указанную личность как подтвержденную.

Разрешено для

Параметры

Использование curl

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities/{user_identity_id}/verify.json \   -X PUT -v -u {email_address}: {password} -d '{}' -H "Содержание -Тип: application / json " 

Пример ответа

 
  Статус 200 ОК  
   {  "identity": {  "created_at": "2012-02-12T14: 25: 21Z",   "id": 77938,   "primary": false,   "type": "twitter",   "updated_at": "2012-02-12T14: 25: 21Z",   "user_id": 13531,   "value": "cabanaboy",   "Verified": false  }  }  

Запросить подтверждение пользователя

• PUT / api / v2 / users / {user_id} / identity / {user_identity_id} / request_verification

Отправляет пользователю письмо с подтверждением со ссылкой для подтверждения права собственности на адрес электронной почты.

Разрешено для

Параметры

Использование curl

 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities/{user_identity_id}/request_verification.json \   -X PUT -v -u {email_address}: {password} -d '{}' -H "Содержание -Тип: application / json " 

Пример ответа

  
 Удалить личность 
 
 
 
  УДАЛИТЬ / api / v2 / users / {user_id} / identity / {user_identity_id}  
 
 
 Удаляет удостоверение для данного пользователя. 
  
 Разрешено для 
 
  
 Параметры 
 
 
 
 
 
 Имя 
 
 Тип 
 
 В 
 
 Требуется 
 
 Описание 
 
 
 
 
 
 user_id 
 
 целое число 
 
 Путь 
 
 правда 
 
 ID пользователя 
 
 
 
 user_identity_id 
 
 целое число 
 
 Путь 
 
 правда 
 
 Идентификатор личности пользователя 
 
 
 
  
 Использование curl 
 
 
 
  curl https: // {subdomain}.zendesk.com/api/v2/users/{user_id}/identities/{user_identity_id}.json \   -X DELETE -v -u {email_address}: {пароль}  
 Пример ответа 
  
 Идентификация отдельных пользователей для анализа сеанса 
 
     
 Одной из ключевых функций Dynatrace Real User Monitoring является возможность однозначно идентифицировать отдельных пользователей в разных браузерах, устройствах и пользовательских сеансах.
С помощью пользовательских тегов вы можете анализировать поведение конкретного пользователя и опыт отдельных пользователей с помощью анализа пользовательских сеансов.По умолчанию Dynatrace назначает уникальный случайный идентификатор каждому новому пользователю. Однако вы можете назначить более значимые пользовательские теги, которые состоят, например, из имен пользователей или адресов электронной почты. Вы можете настроить пользовательские теги пользователей либо с помощью Dynatrace JavaScript API, либо с помощью метаданных страницы. 
 
 Добавление тегов пользователей через RUM JavaScript API
      
       
 
 Пользовательские теги могут быть организованы с помощью Dynatrace JavaScript API для реального мониторинга пользователей. Образцы и документацию можно загрузить из пользовательского интерфейса Dynatrace: 
 
 
 В меню Dynatrace перейдите в  Настройки >  Веб-и мобильный мониторинг >  Расширенная настройка .
 
 Выбрать  Загрузить документацию и образцы . Образец HTML-файла с именем  identifyUser.html  с правильно отформатированным фрагментом кода JavaScript можно найти в каталоге  samples \ sessions . 
 
 
 Пользовательские теги на основе источника страницы
      
       
 
 Этот подход к тегам пользователей работает путем сбора доступных данных в исходном коде страницы вашего приложения. Если вы внимательно посмотрите на исходный код страницы своего приложения, вы, вероятно, обнаружите, что имена пользователей где-то уже включены.Имена пользователей могут быть включены в текст элемента DOM или переменной JavaScript (полный список см. Здесь). 
 
 Например, easyTravel, демонстрационное приложение Dynatrace, включает имя пользователя в приветственное сообщение в правом верхнем углу домашней страницы (см. Изображение ниже). Используя инструменты разработки, встроенные в большинство браузеров, вы можете создать уникальный селектор CSS для этого конкретного элемента. 
 
 
 
 После того, как вы определили, где находятся имена пользователей в исходном коде страницы, вы можете создавать пользовательские теги на основе имен пользователей: 
 
 
 В меню Dynatrace перейдите на  Frontend .
 
 Выберите приложение, которое вы хотите настроить. 
 
 Выберите  Обзор  (… )>  Изменить . 
 
 Выберите  Захват , а затем выберите  Пользовательские теги . 
 
 Выберите  Добавить тег (идентификатор), правило . 
 
 В раскрывающемся списке  Expression type to capture  выберите  CSS selector . В этом примере идентификатор пользователя извлекается из источника страницы с помощью селектора  CSS .См. Доступные источники данных страницы, чтобы узнать о других источниках данных. 
 
 Введите значение селектора CSS в поле  селектора CSS . 
 
 необязательно. Чтобы обеспечить точное извлечение значения имени пользователя, вы можете применить правило очистки регулярных выражений, включив переключатель  Включить правило очистки , а затем введя регулярное выражение в поле  Regex . 
 
 Выберите  Добавить тег (идентификатор), правило , а затем выберите  Сохранить .
 
 
  Примечание : Вы можете добавить до 20 правил пользовательских тегов (идентификаторов) для каждого приложения. 
 
 Чтобы убедиться, что конфигурация пользовательского тега была применена правильно, после сохранения конфигурации и перезагрузки страницы взгляните на внедренный код JavaScript в обновленном источнике страницы вашего приложения. Как видно из приведенного ниже примера, свойство с именем  md =  теперь указано в выражениях метаданных этой страницы. 
 
 
 
 По завершении этого процесса перейдите к  Session segmentation  в меню Dynatrace.Щелкните текстовое поле фильтра вверху страницы. Выберите атрибут  User tag  и выберите пользовательский тег из списка. На диаграмме теперь отображаются подробные данные сеанса, относящиеся к сеансам этого конкретного пользователя. Вы можете щелкнуть имя пользователя, которое отображается под диаграммой, чтобы перейти на страницу обзора этого пользователя и просмотреть дополнительные сведения. 
 
 Доступные источники данных страницы
      
       
 
 Список  Тип источника  предоставляет вам следующие источники данных, из которых вы можете извлечь идентификатор пользователя: 
 
 
  Селектор CSS : используйте, когда идентификатор пользователя отображается на вашей странице.Этот механизм будет захватывать значение  innerText / textContent  первого совпадения (доступно для браузеров, поддерживающих  querySelector ). Чтобы получить конкретное значение атрибута элемента, добавьте символ «@», за которым следует имя атрибута (например, «# someDomElement @ someAttribute»). 
 
  Переменная JavaScript : используйте, когда, например, вы уже отправляете свой идентификатор пользователя через диспетчер тегов другим инструментам. Затем вы можете повторно использовать свой объект уровня данных.Эта переменная должна быть доступна глобально. Используйте точечную нотацию для ссылки на свойства с переменными JavaScript (‘someVar.version’). За подробностями обращайтесь к документации вашего менеджера тегов. 
 
  Мета-тег : используйте, когда идентификатор вашего пользователя присутствует в одном из метатегов в источнике вашей страницы. Здесь указывается имя метатега, которое Dynatrace будет использовать для захвата своего значения «содержимого». 
 
  Значение cookie  используется, когда идентификатор вашего пользователя присутствует в одном из ваших существующих файлов cookie.
 
  Строка запроса : используйте, когда идентификатор вашего пользователя является частью определенного параметра строки запроса, который вы можете определить здесь. 
 
  Атрибут запроса на стороне сервера : используйте, если вы хотите использовать атрибуты запроса на стороне сервера для маркировки каждого сеанса пользователя. После того, как вы определили атрибут запроса, все, что вам нужно сделать, это использовать его на шаге 6. Обратите внимание, что атрибут запроса службы не может быть захвачен для каждого действия пользователя / сеанса пользователя, так как ваш PurePath на стороне сервера может быть не захвачен. за счет адаптивного управления захватом.
 
 
 Что делать, если в моей компании запрещено отслеживание пользователей?
      
       
 
 Если ваша организация не позволяет отслеживать отдельных пользователей из соображений конфиденциальности, вы также можете определить пользовательские теги, соответствующие названиям команд или отделам. Таким образом, вы можете отслеживать опыт отдельных пользователей, не раскрывая при этом никакой идентифицирующей информации. 
 
 Дополнительные примечания и ограничения
      
       
 
 
 Все захваченные значения обрезаются до максимальной длины 100 символов.
 
 Если вы используете JavaScript API для идентификации своих пользователей, API может переопределить любые существующие правила метаданных, которые были настроены. Таким образом, если вы определяете пользовательские теги через JavaScript API, эти пользовательские теги переопределяют любые другие теги на основе метаданных, которые могут существовать. 
 
 Все настроенные пользовательские теги фиксируются на каждой странице. RUM JavaScript используется для оценки каждого отслеживаемого действия пользователя по каждому правилу пользовательских тегов, которое вы создаете, поэтому сведите список правил пользовательских тегов к минимуму, чтобы уменьшить накладные расходы.
 
 Последнее действие пользователя в сеансе, содержащее тег, будет использоваться как тег для всего сеанса. 
 
 Вы также можете идентифицировать мобильных пользователей собственных мобильных приложений. 
 
  
 правил безопасности и аутентификации Firebase | Документация Firebase 
 

    
      

    
    
  

 Правила безопасности 
 Firebase обеспечивают контроль доступа и проверку данных в формате, поддерживающем
несколько уровней сложности. Для построения систем доступа на основе пользователей и ролей
которые обеспечивают безопасность данных ваших пользователей, используйте Firebase Authentication с
Правила безопасности Firebase.

 
 Идентифицировать пользователей 

 
 Аутентификация идентифицирует пользователей, запрашивающих доступ к вашим данным, и обеспечивает это
информацию как переменную, которую вы можете использовать в своих правилах. Переменная  auth 
содержит следующую информацию: 

 
 
   uid :  Уникальный идентификатор пользователя, назначенный запрашивающему пользователю. 
 
   token :  Карта значений, собранных аутентификацией. 
 
 
 Переменная  auth.token  содержит следующие значения: 

 
 
 
 
 Поле 
 
 Описание 
 
 
 
 
 
  электронная почта  
 
 Адрес электронной почты, связанный с учетной записью, если таковой имеется.
 
 
 
  email_verified  
 
  true , если пользователь подтвердил, что у него есть доступ к адресу электронной почты  . Некоторые провайдеры автоматически проверяют принадлежащие им адреса электронной почты. 
 
 
 
  номер телефона  
 
 Номер телефона, связанный с учетной записью, если таковой имеется. 
 
 
 
  название  
 
 Отображаемое имя пользователя, если установлено. 
 
 
 
  переходник  
 
 UID пользователя Firebase.Это уникально в рамках проекта. 
 
 
 
  firebase.identities  
 
 Словарь всех идентификаторов, связанных с учетной записью этого пользователя. Ключи словаря могут быть любыми из следующих:  email ,  phone ,  google.com ,  facebook.com ,  github.com ,  twitter.com . Значения словаря представляют собой массивы уникальных идентификаторов для каждого поставщика удостоверений, связанного с учетной записью.Например,  auth.token.firebase.identities ["google.com"] [0]  содержит первый идентификатор пользователя Google, связанный с учетной записью. 
 
 
 
  firebase.sign_in_provider  
 
 Поставщик входа, использованный для получения этого токена. Может быть одной из следующих строк:  custom ,  password ,  phone ,  anonymous ,  google.com ,  facebook.com ,  github.com ,  twitter.com .
 
 
 
 
 Если вы хотите добавить настраиваемые атрибуты аутентификации, маркер аутентификации  
переменная также содержит любые настраиваемые утверждения
вы указываете. 

 
 Когда пользователь, запрашивающий доступ, не вошел в систему, переменная  auth  имеет значение  null .
Вы можете использовать это в своих правилах, если, например, вы хотите ограничить чтение
доступ к авторизованным пользователям —  auth! = null . Однако мы обычно рекомендуем
дальнейшее ограничение доступа на запись. 

 
 Дополнительные сведения о переменной  auth  см. В справочнике.
документация для
Cloud Firestore,
База данных в реальном времени и
Облачное хранилище.

 
 Использование информации о пользователе в правилах 

 
 На практике использование аутентифицированной информации в ваших правилах делает ваши правила
более мощный и гибкий. Вы можете контролировать доступ к данным в зависимости от пользователя
личность. 

 
 В ваших правилах определите, как информация в переменной  auth  —
информация о пользователе запрашивающего — совпадает с информацией о пользователе, связанной с
запрашиваемые данные. 

 
 Например, ваше приложение может захотеть убедиться, что пользователи могут только читать и писать свои
собственные данные.В этом сценарии вам понадобится совпадение между
  auth.uid  переменная и идентификатор пользователя по запрошенным данным: 

 
 Cloud Firestore 
 
  service cloud.firestore {
  матч / базы данных / {база данных} / документы {
    // Убедитесь, что uid запрашивающего пользователя совпадает с именем пользователя
    // документ. Подстановочное выражение {userId} делает переменную userId
    // доступно в правилах.
    match / users / {userId} {
      разрешить чтение, запись: если request.auth! = null && request.auth.uid == userId;
    }
  }
}
  
 База данных в реальном времени 
  {
  "правила": {
    "users": {
      "$ userId": {
        // предоставляет доступ на запись владельцу этой учетной записи
        // чей uid должен точно соответствовать ключу ($ userId)
        ".write": "$ userId === auth.uid"
      }
    }
  }
}
  
 Облачное хранилище 
  service firebase.storage {
  // Только пользователь может загрузить свой файл, но любой может его просмотреть
  match / users / {userId} / {fileName} {
    разрешить читать;
    разрешить запись: если запрос.auth! = null && request.auth.uid == userId;
  }
}
  
 Определить пользовательскую информацию 
 Вы можете дополнительно использовать переменную  auth  для определения назначенных настраиваемых полей
пользователям вашего приложения.
 Например, предположим, что вы хотите создать роль «администратора», которая разрешает доступ для записи.
на определенных путях. Вы назначаете этот атрибут пользователям, и
затем используйте его в правилах предоставления доступа по путям.
 В Cloud Firestore вы можете добавить настраиваемое поле в документы пользователей и получить
значение этого поля со встроенным чтением в ваших правилах.Итак, ваш админский
правило будет выглядеть следующим образом:
 Cloud Firestore 
  service cloud.firestore {
  match / databases / {database} / documents / some_collection: {
    // Помните, что в Cloud Firestore операции чтения, встроенные в ваши правила, оплачиваются
    напишите: if request.auth! = null && get (/ databases / (database) / documents / users / $ (request.auth.uid)). data.admin) == true;
    читать: если request.auth! = null;
  }
}
  
 Для правил в базе данных в реальном времени и облачном хранилище,
создавать настраиваемые утверждения в проверке подлинности.Тогда ты можешь
ссылаться на эти настраиваемые утверждения с помощью переменной  auth.token .
 База данных в реальном времени 
  {
  "правила": {
    "some_path / $ sub_path": {
      // Создание настраиваемого утверждения для роли администратора
      ".write": "auth.uid! = null && auth.token.writer == true"
      ".read": "auth.uid! = null"
      }
    }
  }
  
 Облачное хранилище 
  service firebase.storage {
  // Создание настраиваемого утверждения для роли администратора
  match / files / {fileName} {
    разрешить чтение: если запрос.auth.uid! = null;
    разрешить запись: если request.auth.token.admin == true;
  }
}
  
 Чтобы увидеть больше примеров основных правил, использующих аутентификацию, см.
Основные правила безопасности.