Обеспечьте работу каждой функции на основе минимально обоснованного контекста
Полезному приложению-компаньону не нужно, чтобы каждая функция обращалась к масштабному, постоянному портрету пользователя. Начните с базового уровня с нулевым профилем: может ли человек открыть функцию, сделать разовый выбор, получить нейтральный результат и завершить задачу при отсутствии сохраненных интересов, предполагаемых характеристик, истории, местоположения, контактов и демографических полей? Затем добавляйте только тот контекст, который влияет на четко определенное решение. Фиксируйте его в реестре зависимостей профиля с указанием результата функции, исходного поля, способа получения (указано напрямую или выведено), необходимости, резервного варианта (fallback), срока действия, способа исправления и наблюдаемого результата. Этот подход не отвергает персонализацию. Он делает ее опциональной, проверяемой и соразмерной, не позволяя старому предположению незаметно стать основой для несвязанных функций.
Составляйте список решений, а не просто собираемых полей
Начните с результатов, с которыми люди действительно сталкиваются: начальные предложения, подсказки для диалога, напоминания, порядок поиска, повторный показ сохраненных элементов, время уведомлений, язык, параметры доступности, рекомендации и настройки совместного доступа по умолчанию. Для каждого результата запишите точное принятое решение и задействованные данные профиля. Существующее поле не становится автоматически необходимым. Спросите себя, что произойдет, если оно окажется пустым, неверным, устаревшим или недоступным. Руководство ICO по минимизации данных описывает персональные данные как адекватные, релевантные и ограниченные тем, что необходимо для конкретной цели, с обязательным пересмотром, когда они больше не требуются. Превратите этот принцип в вопрос на уровне конкретной функции: какие минимальные входные данные достаточны для этого решения сегодня? Отделяйте прямые пользовательские записи от предположений системы, поскольку выбранный пользователем язык и угаданное предпочтение требуют разного уровня достоверности, путей исправления и сроков действия.
Спроектируйте путь с нулевым и минимальным профилем
Протестируйте сервис с пустым профилем и только с теми полями, которые необходимы для создания учетной записи. Начальный экран должен оставаться понятным; поиск должен принимать явный запрос; диалоговое окно может предлагать несколько нейтральных отправных точек; а разовый выбор может определять текущую сессию, не превращаясь в постоянную характеристику. Если функция не может продолжить работу, укажите недостающие входные данные и причину их необходимости вместо запроса подробной биографии. Отдавайте предпочтение постепенным запросам непосредственно в момент использования. Функция, связанная с календарем, может требовать выбранное время для одного напоминания, а не доступ ко всем предыдущим разговорам. Выбор языка интерфейса может быть необходим для отображения, тогда как хобби, статус отношений или местоположение могут не иметь никакого значения для этого же решения.
Отделяйте контекст сессии от постоянного профиля
Контекст может существовать в рамках одного экрана, одного разговора, ограниченного проекта или всей учетной записи. Выбирайте кратчайшую область действия, которая все еще позволяет выполнить задачу. Временный выбор, такой как «показать спокойные идеи для отдыха в помещении прямо сейчас», может определить текущий результат и затем утратить силу; он не должен превращаться в долгосрочное утверждение о человеке. Если сохранение данных действительно добавляет удобства, покажите, что именно будет сохранено, где это будет использоваться и как это исключить или сбросить. Предположения требуют видимого источника и более короткого интервала проверки, поскольку они могут утрачивать актуальность. Никогда не позволяйте полю, созданному для удобства, становиться скрытым обязательным условием для несвязанной навигации, экспорта, настроек конфиденциальности или доступа к учетной записи. Принципы ограничения цели и минимизации из статьи 5 GDPR подтверждают необходимость привязки использования данных к заявленной причине вместо того, чтобы позволять каждому сохраненному полю распространяться повсеместно.
Обеспечьте для каждой зависимости резервный вариант, возможность исправления и срок действия
Реестр должен указывать нейтральный резервный вариант (fallback) для каждой необязательной зависимости: хронологический порядок вместо ранжирования на основе прогнозов, широкие категории вместо персонализированного ярлыка, ручной поиск вместо выведенного ярлыка быстрого доступа или приватный черновик вместо угадывания аудитории. Добавьте действия по редактированию, удалению, исключению из этой функции, сбросу и установке срока действия там, где текущий продукт их поддерживает. Исправление должно влиять на зависимый результат, а не просто менять страницу профиля. Зафиксируйте, обновляются ли существующие предложения, изменяются ли только будущие результаты или сохраняется производный результат. Не обещайте удаление за рамками контролируемых процессов. В этом отношении полезна Privacy Framework от NIST, поскольку она рассматривает риск конфиденциальности как часть системной обработки и управления, а не как отдельный экран согласия. Реестр делает наглядными владельцев данных и незаполненные поля.
Сравнивайте персонализированные и базовые результаты с помощью нейтральных тестов
Создайте две тестовые учетные записи или состояния, которые вы уполномочены использовать: одну с минимальным профилем, а другую с небольшим, нейтральным предпочтением. Выполните одни и те же базовые задачи и сравните показатели выполнения, ясность, пути исправления и неожиданные варианты использования, а не то, какой результат кажется более привлекательным. Очистите предпочтение, повторите задачу и проверьте поиск, предложения, уведомления, настройки совместного доступа по умолчанию, экспорт и видимый профиль. Эффективный персонализированный путь должен плавно деградировать при отсутствии данных и предсказуемо реагировать на исправления. Фиксируйте версию, локаль, устройство, входные данные, ожидаемый резервный вариант, наблюдаемый результат и нерешенное поведение. Повторяйте проверку после того, как функция начнет обращаться к новому источнику, после смены мажорной версии или если поле продолжает оказывать влияние после истечения заявленного срока действия. Цель — четко очерченная карта зависимостей, а не постоянная слежка.
Частые вопросы
Означает ли снижение зависимости от профиля отключение всей персонализации?
Нет. Это означает, что каждое персонализированное решение имеет необходимые входные данные, ограниченную область действия, видимый резервный вариант, путь исправления и точку пересмотра.
Что такое базовый уровень с нулевым профилем?
Это рабочий пользовательский путь, наблюдаемый в том случае, когда необязательные сохраненные и выведенные поля профиля отсутствуют.
Должны ли выведенные предпочтения сохраняться так же долго, как и прямые указания пользователя?
Не обязательно. Предположения требуют видимого источника, способа исправления и срока действия, соответствующего тому, как быстро они могут стать неактуальными.