Целостность данных: почему это важно для понимания поведения пользователей

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

Распространенные ситуации, ухудшающие целостность данных

Дублирование данных
Дублирование не только вредно для целостности данных, но и может напрямую привести к увеличению затрат из-за емкости хранилища. Это может быть дублирование профилей пользователей или даже многократное возникновение одного и того же события, хотя оно должно было быть вызвано один раз.
Типичный пример дублирования: ваш интегрированный SDK по умолчанию отслеживает некоторые «системные события», такие как запуск приложения или нажатие уведомления, но ваши разработчики игнорируют это и также вызывают событие вручную. В таком случае вы сохраняете одно и то же событие дважды, что увеличивает затраты на вашу платформу, поскольку вы быстрее превысите квоту на отслеживание событий. В масштабе миллионов пользователей эти дополнительные расходы действительно нанесут ущерб вашим маркетинговым и аналитическим бюджетам.
Управление часовыми поясами
Большая часть маркетинговых кампаний привязана к времени, и неправильно указанный часовой пояс пользователя может означать, что ваша кампания останется незамеченной, поскольку она проводится в 3 часа ночи, а не в 19:00. Это особенно важно, если у вас международный бизнес.
Данные о местоположении
Существует два типа местоположений, которые вы можете получить из своего приложения:

1. Грубое расположение:  

Эту информацию можно получить с помощью поставщика мобильной сети и точек доступа Wi-Fi без доступа к GPS, но она не имеет высокой точности.
Этого может быть достаточно для ваших вариантов использования, например, если вы просто хотите отправлять кампании или сегментировать пользователей на основе примерного местоположения, например, пользователей из Калифорнии.
Грубых данных о местоположении также может быть достаточно для получения ценной и важной информации, такой как проникновение на рынок, принятие клиентов и многое другое.
Для получения этой информации вам, вероятно, не потребуется собирать более дорогостоящие данные о точном местоположении пользователя.

2. Точное местоположение:  

Для этого используется доступ к GPS и точность до нескольких метров.
Высокоточные данные о местоположении имеют большее значение в таких отраслях, как электронная коммерция, доставка еды и продуктов и т. д. Местоположение пользователя важно для специальных предложений, персонализации на основе местоположения, рекомендаций и т. д.
Например, многие клиенты CleverTap используют геозонирование для предоставления пользователям высокоточных взаимодействий на основе местоположения, например, для отправки купона, когда они находятся рядом с одной из торговых точек клиента. Как вы понимаете, для этого необходимы данные о местоположении с точностью до нескольких метров.
Для обеспечения высокой точности требуется доступ к GPS со стороны конечного пользователя. Имейте в виду, что если конечный пользователь решит отклонить разрешение на доступ к данным о местоположении из-за конфиденциальности и/или из-за проблем с аккумулятором, эти взаимодействия обязательно пострадают.
Вы можете выбрать необходимую вам точность данных о местоположении, понимая важность данных о местоположении в ваших конкретных маркетинговых сценариях использования. Затраты на получение точных данных о местоположении во многих случаях могут перевешивать выгоды, поскольку вы можете потерять возможность получать данные от пользователей, которые решили отказаться от предоставления данных о местоположении, и вам может потребоваться измененный путь для этих пользователей.
Но имейте в виду, что если вы решите использовать грубые данные о местоположении, все заинтересованные стороны должны знать, что данные о местоположении могут быть нечеткими и не должны использоваться там, где требуется точное местоположение.
Плохое именование событий
То, как вы называете события приложения, может иметь долгосрочное влияние на ясность ваших данных. Вы можете назвать событие, при котором продукт рассматривается как:

1. ProductView
2. Продуктпросмотрен
3. Просмотренный продукт
4. ПользовательПродуктВью
5. Товар_просмотрен
6. просмотренный продукт
7. ПосмотретьПродукт

Мы рекомендуем синтаксис «Существительное + Глагол». Например, продукт просмотрен, регистрация завершена.
Что бы вы ни выбрали, убедитесь, что ваше соглашение об именах соблюдается на всех платформах, и ваши команды будут на одной странице. Мы наблюдали случаи, когда одно и то же событие называлось или писалось по-разному в приложениях для iOS и Android, и это приводило либо к потере данных, либо к дезинформации, а исправление могло оказаться затруднительным.
Будьте последовательны и ясны в именах, чтобы обеспечить простой рабочий процесс. Обязательно проконсультируйтесь с соответствующими внутренними командами, такими как команды по маркетингу и обработке данных, чтобы обеспечить бесперебойную совместимость и низкие накладные расходы.
Ознакомьтесь с примерами мероприятий по отраслевым вертикалям, чтобы получить хорошую отправную точку.
Уникальные проблемы с идентификацией пользователей
Управление идентификацией — очень важная часть ваших маркетинговых усилий. Вам необходимо однозначно идентифицировать пользователей и избегать многократной отправки одних и тех же кампаний одному и тому же пользователю и других подобных ошибок.
Вот несколько важных рекомендаций по настройке идентификаторов пользователей на вашей маркетинговой платформе:

1. Не устанавливайте идентификатор, если его нет. Например, установка идентификатора«Нет»для нескольких пользователей, вероятно, сгруппирует всех пользователей под этим идентификатором «Нет» (т. е. любой пользователь с идентификатором «Нет» считается одним и тем же пользователем). Лишь немногие платформы назначают внутренний уникальный идентификатор. Идентификатор для пользователей в случае, если переданный идентификатор равен нулю, как это делает CleverTap, и этот идентификатор по-прежнему можно использовать для идентификации отдельных пользователей.
2. Не назначайте удостоверение, которое может измениться. Например, если чей-то адрес электронной почты может измениться в вашем приложении, не рекомендуется разрешать электронную почту в качестве удостоверения. Большинство маркетинговых платформ помечают человека как нового пользователя, если он меняет адрес электронной почты. То же самое можно применить к номеру мобильного телефона, идентификатору Facebook и т. д.

У вас могут быть особые случаи использования, например, несколько пользователей используют приложение с одного устройства. Сложные платформы, такие как CleverTap, могут переключаться между различными профилями пользователей в зависимости от того, кто в данный момент вошел в систему.
Данные о событии
Убедитесь, что данные о ваших мероприятиях тщательно спланированы и реализованы как с точки зрения разработчика, так и с точки зрения бизнеса.
Методично обдумывайте свои события и свойства событий. Вы не хотите вызывать событие Purchase, не имея идентификатора продукта в качестве свойства события.
Определите триггерные точки для каждого события и убедитесь, что событие возникает в нужное время.
И не вызывайте события на разных этапах пути пользователя в вашем приложении для Android по сравнению с приложением для iOS. Например, вы можете случайно вызвать событие «Просмотр главного экрана» на Android, когда главный экран начинает загружаться, а на iOS — после загрузки страницы. Это может вызвать явное несоответствие между числами Android и iOS и привести к неправильной информации, поскольку многие пользователи могут закрыть приложение, пока главный экран все еще загружается, что приводит к относительно меньшему количеству пользователей iOS, что, в свою очередь, может привести к тому, что вы сделаете ненужные изменения.
Используйте тестовую учетную запись и тестового пользователя, чтобы сопоставить фактические действия приложения с событиями, возникающими на странице профиля пользователя.
Тип данных данных о событии
Определение правильных типов данных для свойств вашего события должно быть хорошо продуманным решением. Немногие маркетинговые платформы, такие как CleverTap, имеют встроенный инструмент управления схемой, который может помочь вам определить типы данных для каждого свойства события.
Мы наблюдали случаи, когда дни рождения пользователей передавались из приложения в виде строки, а не объекта Date. Это делает данные по большей части бесполезными, поскольку простые запросы типа «Какой % моих пользователей принадлежат к поколению Z?» невозможно ответить быстро.
Недавно у нас был клиент, который отправлял данные о сумме своей транзакции в виде строки, а не целого числа. Это делает невозможным выполнение многих простых математических операций.
Простые упущения могут привести к значительной трате ресурсов: попыткам преобразовать данные постфактум или необходимости полностью их отбросить.

Как я могу поддерживать высокую целостность данных?

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

1. Единообразное и четкое наименование событий в вашей документации и на всех ваших платформах.
2. Потратьте дополнительное время во время первоначальной интеграции с вашей маркетинговой платформой, чтобы тщательно вручную протестировать события, возникающие на разных платформах. Прежде чем начать работу, используйте тестовую учетную запись и ленту активности профиля пользователя. Это сэкономит вам много времени и боли в будущем.
3. Тщательный аудит следует проводить часто, особенно когда некоторые структуры событий изменяются или добавляются.
4. Тщательно продумайте, какие события вы хотите отслеживать, не переусердствуйте и не пропустите важные события. Обязательно четко определите свои ключевые показатели эффективности и варианты использования.
5. Проконсультируйтесь с соответствующими командами, которым могут быть полезны данные, например с командой маркетинга, руководством, разработчиками и специалистами по обработке данных.
6. Убедитесь, что все команды платформы (Android, iOS, SDK) единодушны при принятии решения о том, когда инициировать событие.
7. Уделяйте время поддержанию схемы событий. Посетите нашу документацию , чтобы узнать больше о схеме и о том, как она помогает поддерживать целостность данных.

Достижение и поддержание целостности данных

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