Краткий обзор: Подготовьте исходные данные так, чтобы максимально повысить процент совпадений между наборами данных партнеров и оптимизировать результаты совместной работы.
О подготовке данных
Платформа AppsFlyer Data Collaboration Platform (DCP) от AppsFlyer предназначена для приёма и обработки крупномасштабных транзакционных данных, пользовательских данных или их комбинации, поступающих от нескольких партнёров. После загрузки данных DCP может сопоставлять пользователей в разных наборах данных, используя общие идентификаторы (например, хешированная электронная почта, электронное письмо или хешированный номер телефона), и запускать рабочие процессы совместной работы на основе этих данных.
В этой статье рассматривается:
- Типы данных, которые может обрабатывать DCP (транзакционные, данные на уровне пользователя или их комбинация)
- Как структурировать данные для максимизации вероятности совпадения между партнерами и для оптимального сопоставления для партнеров по активации.
- Какие структуры данных рекомендуются, а какие нет
- Как обрабатывать многозначные идентификаторы при использовании файлов CSV
Разберитесь в типах данных.
Большинство источников, задействованных в совместной работе, содержат один или оба следующих типа данных:
-
Данные на уровне пользователя (идентификационные данные)
- Цель: Представляет каждого пользователя и идентификаторы, используемые для сопоставления.
- Рекомендуемая структура: Одна строка на пользователя
-
Транзакционные (событийные) данные
- Цель: Представляют действия пользователя (покупки, посещения, транзакции).
- Типичная структура: Несколько строк на одного пользователя (поскольку у пользователя может быть много транзакций)
Рекомендации по структурированию данных
В этом разделе представлены рекомендации и лучшие практики по структурированию данных в DCP.
Рекомендуемые структуры данных
Чтобы структурировать исходные данные для оптимальной загрузки в DCP и получения максимальных результатов:
- Убедитесь, что данные соответствуют требованиям к формату исходных файлов. .
- Для лучшего результата структурируйте данные идентификации пользователя в виде одной строки на каждого пользователя и включите все доступные идентификаторы для этого пользователя. См. Рекомендуемые структуры идентификаторов .
- Если у пользователей несколько адресов электронной почты или телефонных номеров, используйте форматы на основе массивов (например Parquet, BigQuery или Snowflake).
- Убедитесь, что соблюдаются правила хеширования .
- Для транзакционных наборов данных (и других типов данных, где это применимо) используйте инструмент DCP Data View, чтобы создать ориентированное на бизнес, безопасное с точки зрения конфиденциальности подмножество данных, оптимизированное для совместной работы, и делитесь им вместо необработанных таблиц. Почему рекомендуется использовать Data View .
Хотя можно использовать и другие структуры, они могут быть не столь оптимальны для использования всех возможностей DCP. См. раздел «Структуры данных, которые не рекомендуется использовать» .
Рекомендуемые структуры идентификаторов
Чтобы повысить процент совпадений, рекомендуется передавать пользовательские идентификационные данные в виде одной строки на пользователя (когда это возможно) и включать все доступные идентификаторы в структуру, которая точно отражает то, как представлены пользователи.
Вариант 1: Одна строка на пользователя, одно значение на тип идентификатора
Просто и эффективно.
Используйте этот формат, когда у каждого пользователя есть не более одного хешированного адреса электронной почты, номера телефона и т.д.
Пример
| Идентификатор пользователя | Хешированный адрес электронной почты | Хешированный телефон |
|---|---|---|
| 123 | 5d41402 | 152d234b70 |
| 456 | 7d793037 | |
| 789 | 0e6e5414 |
Почему этот вариант предпочтителен
- Проще всего подготовить и внедрить
- Легко валидировать и устранять неполадки
- Высокая эффективность сопоставления при наличии полных и согласованных идентификаторов (для сопоставления с наборами данных партнеров и сопоставления медиапартнеров по активации).
Оптимальное соответствие
- Отлично подходит для загрузки файлов в формате CSV.
- Также хорошо работает с Parquet / BigQuery / Snowflake
Вариант 2 Массивы (списки) идентификаторов для многозначных полей
Наилучший показатель точности в случае, если у пользователей несколько адресов электронной почты и телефонов.
Используйте этот формат, когда у пользователя может быть несколько значений одного и того же типа идентификатора, например:
- Несколько хешированных электронных адресов
- Несколько хешированных номеров телефона
Эта структура должна быть представлена в виде нативных массивов .
Пример
| Идентификатор пользователя | Хешированный адрес эл.почты | Хешированный номер телефона | MAID |
|---|---|---|---|
| u_0001 | [a1b2 · c3d4 · e5f6] | [p1q2 · r3s4] | m001 |
| u_0002 | [z9y8 · x7w6] | m002 | |
| u_0003 | [t1u2 · v3w4 · x5y6] |
Почему этот вариант предпочтительнее
- Отражает способ хранения идентификационных данных внутри системы
- Не нужно гадать, сколько «колонок адресов электронной почты» может понадобиться
- Избегает постоянных изменений схемы
- Повышает потенциал сопоставления (для наборов данных партнеров и для сопоставления медиапартнеров по активации), позволяя использовать несколько идентификаторов для каждого пользователя
Лучше всего для
- Parquet (S3/GCS)
- BigQuery
- Snowflake
Практический контрольный список для структурирования данных
Контрольный список набора идентификационных данных (уровень пользователя)
- Одна строка соответствует одному пользователю.
- Включает все доступные идентификаторы (хешированный адрес электронной почты, хешированный номер телефона, MAID и т. д.).
- Если существует несколько значений (например, несколько адресов электронной почты), по возможности используйте нативные массивы.
- Избегайте списков в ячейках, избегайте структуры «email_1/email_2/email_3» и многострочных структур идентификаторов.
Контрольный список набора данных транзакций (событий).
- Оставьте строки события/транзакций без изменений. См. Примеры данных транзакций.
- При необходимости используйте Обзор данных для создания готовых к совместной работе сводных отчетов на уровне пользователя.
Контрольный список представлений данных
- Создавайте ориентированные на бизнес представления данных подготовленные для аудитории, агрегированные, стандартизированные)
- По возможности предоставляйте доступ к представлениям данных, а не к исходным конфиденциальным таблицам.
- Ограничьте количество полей, которыми вы делитесь, только необходимой информацией (в целях обеспечения конфиденциальности и защиты бизнеса).
- Рассмотрите возможность агрегирования данных, чтобы снизить доступ к конфиденциальной информации и повысить эффективность.
Поддерживаемые облачные сервисы и форматы загрузки
DCP поддерживает загрузку данных через различные облачные сервисы, такие как:
- AWS S3
- GCS (Google Cloud Storage)
- BigQuery
- Snowflake
Рекомендации по форматированию
- Используйте CSV (разделенные запятыми), если для каждого пользователя указано только одно значение для каждого типа идентификатора (один адрес электронной почты, один номер телефона и так далее).
- Когда у пользователей может быть несколько значений одного и того же типа идентификатора (например, несколько хешированных адресов электронной почты), предпочтительнее использовать форматы, поддерживающие массивы :
- Parquet (распространён в экосистемах Big Data)
- BigQuery (массивы встроены)
- Snowflake (массивы встроены)
Примечания:
- Под «массивами» подразумевается просто «список значений».
- Формат Parquet и массивы в BigQuery/Snowflake являются стандартом, и большинство дата-команд легко их поддерживают.
См. примеры ресурсов, специфичных для коннекторов (AWS S3, GCS, BigQuery, Snowflake).
Не рекомендуемые структуры данных
Определённые способы структурирования данных идеально подходят для загрузки в DCP, а другие — нет. Ниже приведён список структур данных, использование которых не рекомендуется :
Избегать: Нескольких столбцов для одного и того же типа идентификатора
Использование таких примеров, как «основной/дополнительный/третий адрес электронной почты», не рекомендуется.
Пример, которого следует избегать
| Идентификатор пользователя | Хешированный адрес электронной почты 1 | Хешированный адрес электронной почты 2 | Хешированный адрес электронной почты 3 |
|---|---|---|---|
| 123 | a1b2 | c3d4 | |
| 456 | z9y8 |
Почему этого следует избегать
- Количество значений на одного пользователя непредсказуемо.
- Приводит к разрастанию числа столбцов и усложнению сопровождения схемы
Избегать: «Списки внутри одной ячейки» (текст в свободной форме)
Даже если это выглядит удобным, метод чреват ошибками.
Пример, которого следует избегать
| Идентификатор пользователя | Хэшированные электронные письма (текст) |
|---|---|
| 123 | a1b2 · c3d4 · e5f6 |
Почему этого следует избегать
- Не является настоящим типом массива.
- Проблемы с форматированием и экранированием встречаются достаточно часто
- Небольшие несоответствия могут нарушить процесс загрузки
Избегать: Несколько строк на одного пользователя для идентификаторов (когда ваша цель — таблица идентификации пользователей).
Не следует разделять идентификационные данные по строкам, если можно оставить одну строку на каждого пользователя.
Пример, которого следует избегать
| Идентификатор пользователя | Тип идентификатора | Значение идентификатора |
|---|---|---|
| 123 | hashed_email | a1b2 |
| 123 | hashed_email | c3d4 |
Почему этого следует избегать
- Требует дополнительной обработки для восстановления пользователей
- Повышенный риск дубликатов и несоответствий
- Менее эффективно при масштабировании
Примечание: Несколько строк на одного пользователя — это нормально для транзакционных таблиц, но не оптимально для таблицы идентификации (уровня пользователя), используемой для сопоставления.
Дополнительные сведения
В этом разделе приводится дополнительная, более детальная информация по соответствующим темам.
Примеры транзакционных данных
Данные транзакционний/ событий могут содержать несколько строк для каждого пользователя:
| Идентификатор транзакции | Идентификатор пользователя | Дата транзакции | Сумма | Категория |
|---|---|---|---|---|
| t_001 | 123 | 2025-12-01 | 120,00 | Продукты питания |
| t_002 | 123 | 2025-12-15 | 45.00 | Лекарства |
| t_003 | 456 | 2025-12-20 | 300.00 | Электроника |
Рекомендовано
- Загружайте транзакционные данные в их естественной структуре
- Используйте инструмент «Просмотр данных» для создания представления на уровне пользователя, готового к совместной работе (например, расходы за последние 30 дней, предпочтительные категории, сводки по давности/частоте).
Примеры ресурсов, специфичных для коннектора (AWS S3, GCS, BigQuery, Snowflake)
Что означает «массив/список идентификаторов»?
Иногда у одного пользователя может быть более одного адреса электронной почты или номера телефона (например, личный и рабочий адрес эл.почты). Вместо того чтобы помещать их в лишние столбцы или неудобные текстовые поля, мы представляем их в виде списка значений.
| Идентификатор пользователя | Хэшированные электронные письма (список) |
|---|---|
| u_0001 | [a1b2 · c3d4 · e5f6] |
| u_0002 | [z9y8 · x7w6] |
1. Коннектор AWS S3 и GCS (Parquet)
Что должен содержать образец идентификации (схема)
| Поле | Тип | Примечания |
|---|---|---|
| user_id | string | Одна строка на пользователя |
| hashed_emails | массив строк | Многозначный идентификатор (рекомендуется) |
| hashed_phones | массив строк | Многозначный идентификатор (рекомендуется) |
| maid | string | Дополнительный идентификатор (необязательный) |
Parquet изначально поддерживает списки, поэтому его рекомендуют, когда у пользователей несколько адресов электронной почты или телефонных номеров.
2. Коннектор BigQuery (предварительный просмотр таблицы и скриншот схемы)
Пример схемы идентификации (BigQuery)
| Поле | Тип | Режим |
|---|---|---|
| user_id | STRING | МОЖЕТ БЫТЬ NULL |
| hashed_emails | STRING | ПОВТОРЯЮЩИЙСЯ (МАССИВ) |
| hashed_phones | STRING | ПОВТОРЯЮЩИЙСЯ (МАССИВ) |
| maid | STRING | МОЖЕТ БЫТЬ NULL |
В BigQuery массивы поддерживаются нативно (поля типа REPEATED). Это рекомендуемый подход, если существует несколько адресов электронной почты/телефонов.
3. Коннектор Snowflake (предварительный просмотр таблицы и скриншот схемы)
Пример схемы идентификации (Snowflake)
| Поле | Тип | Примечания |
|---|---|---|
| USER_ID | VARCHAR | Одна строка на пользователя |
| HASHED_EMAILS | МАССИВ | Многозначный идентификатор |
| HASHED_PHONES | МАССИВ | Многозначный идентификатор |
| MAID | VARCHAR | Необязательно |
Snowflake поддерживает поля, похожие на списки (массивы). Это предпочтительнее, чем создание столбцов email_1/email_2/email_3.
Почему рекомендуется использовать «Просмотр данных»
Просмотр данных — это настраиваемые подвыборки ваших существующих источников данных, которые можно создать, не изменяя исходный набор. Они позволяют выполнять операции по изменению, уточнению и агрегированию данных, чтобы в рамках сотрудничества делиться только релевантной информацией, сохраняя передаваемые данные ясными и целенаправленными, а весь остальной массив — конфиденциальным и защищённым. Используйте «Просмотр данных» в совместной работе, потому что они:
Ориентированы на бизнес и упрощают совместную работу
- Представления данных позволяют выводить информацию в чистой, понятной для бизнеса структуре (например «Представление идентификации клиентов», «Представление допустимой аудитории», «Представление сводной информации о покупках») вместо сырых логов или сложных транзакционных схем.
- Они помогают унифицировать определения (например, «активный клиент», «общие расходы за последние 30 дней»), чтобы обе стороны работали согласованно и использовали единую логику.
Более надежны с точки зрения защиты конфиденциальности по своей конструкции.
- Представления данных поддерживают принцип минимизации данных: вы можете делиться только теми полями и строками, которые необходимы для сотрудничества, не раскрывая полный сырой набор данных.
- Они снижают риск нарушения конфиденциальности, позволяя вам:
- Исключить ненужные атрибуты
- Ограничить детализацию (например, предоставлять сводные метрики вместо данных по отдельным строкам транзакций).
- Предоставлять только идентификаторы, необходимые для сопоставления (а не дополнительные конфиденциальные столбцы).
Защитите конфиденциальные бизнес-данные
- Необработанные таблицы транзакций могут содержать крайне конфиденциальную бизнес-информацию (например, подробные данные о покупательском поведении, ценовой политике, связи с продавцами, внутренних идентификаторах).
- Функция «Представление данных» позволяет делиться только той информацией, которая необходима для совместной работы:
- Пример: передавайте агрегированные данные на уровне категорий вместо детализации по отдельным товарам
- Пример: делитесь агрегированными расходами по диапазонам или сводными метриками вместо точных строковых позиций
- Это снижает риск непреднамеренного раскрытия конкурентной или конфиденциальной информации.
Может сделать работу с данными более экономичной и производительной
«Представление данных «можно структурировать таким образом, чтобы они были более лёгкими и эффективными, что часто приводит к сокращению:
- Данные отсканированы
- Время обработки
- Вычислительные затраты
Предварительная структуризация представления, готового к совместной работе (особенно агрегированных представлений), может ускорить сотрудничество и сделать его более предсказуемым с операционной точки зрения.
Загрузка нескольких идентификаторов/ключей и поведение сопоставления по платформам
Загрузка идентификаторов DCP
| Партнер/Платформа | Поддерживаемые типы идентификаторов | Режим загрузки | Поведение при загрузке | Приоритет идентификатора (для партнеров одного типа) |
|---|---|---|---|---|
| Meta | Электронная почта, телефон, IDFA, GAID, идентификатор Android, имя, фамилия, дата рождения, город, штат, почтовый индекс, страна | Все поддерживаемые типы | Загружает все поддерживаемые типы идентификаторов. | Недоступно - загружает все |
| Электронная почта, телефон, IDFA, GAID, идентификаторб Android, идентификатор клиента | Один тип | Загружает один тип идентификатора для каждой аудитории | 1. Адрес электронной почты 2: Телефон 3. Идентификаторы мобильных устройств *4 Идентификатор клиента | |
| TikTok | Электронная почта, телефон, IDFA, GAID, идентификатор Android | Все поддерживаемые типы | Загружает все поддерживаемые типы идентификаторов. | Недоступно - загружает все |
| Электронная почта, телефон, IDFA, GAID | Один тип | Загружает один тип идентификатора для каждой аудитории | 1. Адрес электронной почты 2: Телефон 3. Идентификаторы мобильных устройств | |
| Infillion | Электронная почта, телефон, IDFA, GAID, MM-UUID | Все поддерживаемые типы | Загружает все поддерживаемые типы файлов, сгруппированные максимум в 3 файла. | Недоступно - загружает все |
| TheTradeDesk | Электронная почта, Телефон | Один тип | Загружает один тип идентификатора для каждой аудитории | 1. Адрес электронной почты 2: Телефон |
| Data Locker от AppsFlyer | Все доступные идентификаторы | Все типы в совокупности | Предоставляет все идентификаторы в одном объединенном файле | Недоступно - доставляет все |
| Платформа | Можно ли отправлять несколько идентификаторов для одного пользователя? | Могут ли они сопоставляться по любому из этих идентификаторов? | Могут ли они объединять несколько идентификаторов? | Модель сопоставления (практическая) | Примечания |
|---|---|---|---|---|---|
| Meta | Да | Да | Да | Детерминированный, любой идентификатор /комбинация | Проверяются электронная почта, телефон, MAID и fbp/fbc; применяется максимально сильная логика сопоставления «по любому из идентификаторов» |
| Да | Ограниченные возможности | Нет | Детерминированный, приоритетный | Один идентификатор определяет пользователя; идентификаторы не комбинируются для сопоставления | |
| TikTok | Да | Да | Да | Детерминированный, любой идентификатор /комбинация | Очень похоже на Meta; ttclid хорошо работает для событий |
| Да | Частичный | Ограниченные возможности | Детерминированный, ориентированный на идентификатор | В основном электронная почта + MAID; ограниченное перекрестное подтверждение идентификатора. | |
| The Trade Desk (TTD) | Да | Через идентификационный граф | Да (через граф идентификаторов) | Детерминированное сопоставление через граф идентификаторов | UID2 + MAID + cookie-файлы, разрешаемые через граф EUID/UID2 |
| Infillion | Да | Через идентификационный граф | Да (через граф идентификаторов) | Детерминированный с помощью графа партнеров | Опирается на OmniID / разрешение идентификаторов партнёра |
Основные выводы для планирования активаций
-
Meta и TikTok
- Отправьте все имеющиеся данные
- Настоящая логика «любой идентификатор»
- Лучшие платформы для активации в чистой среде данных с богатой идентификацией
-
Google
- Отправляйте несколько идентификаторов для расширения охвата
- Не ожидайте усиления перекрестной идентификации
- Доминантную роль играют адрес электронной почты и номер телефона
-
TTD и заполнение
- Качество сопоставления в большей степени зависит от участия в графе идентификаторов
- Покрытие UID2 / OmniID имеет большее значение, чем простое количество идентификаторов
-
Pinterest
- Ведёт себя скорее как Google, чем как Meta.
- Дополнительный эффект сверх пары электронная почта + MAID незначителен
КРАТКОЕ СОДЕРЖАНИЕ
- Только Meta и TikTok нативно поддерживают сопоставление «любого из них».
- Google — детерминированная система, но с разрешением по одному идентификатору
- Платформы открытого веба выполняют сопоставление через графы идентификаторов, а не по «сырым» ID
Рекомендации по форматированию хешированных данных от медиапартнера
Универсальные правила нормализации:
Перед хешированием любых данных практически все платформы требуют выполнения следующих шагов нормализации для обеспечения точности сопоставления:
- Текст: Преобразовать в нижний регистр и удалить все пробелы в начале и конце слова.
- Телефон: Преобразовать в формат E.164 (например, +15551234567)
- Хеширование: SHA-256 является индустриальным стандартом, хотя некоторые платформы принимают MD5 или SHA-1.
| Медиапартнер | Правила использования электронной почты | Рекомендации по использованию номеров телефонов | Рекомендации по использованию мобильного идентификатора (MAID) | Особенности конкретных платформ и логика сопоставления | Актуальная справочная информация |
|---|---|---|---|---|---|
| Google Ads / DV360 | Формат: Преобразовать в нижний регистр, удалить пробелы. Укажите домен. Правило Gmail: Для адресов @gmail.com / @googlemail.com удалите точки (.) перед символом "@" и суффиксы после него (+). Хеширование: SHA-256 (в шестнадцатеричном коде). | Формат: E.164 (например, +16505551212). Должен включать код страны. Хеширование: SHA-256. | Формат: IDFA (iOS) или GAID (Android). Хеширование: Не использовать хеширование. | Приоритет сопоставления: Детерминированный и приоритетный (1. Адрес эл.почты 2. Телефон, 3. мобильные идентификаторы). Он не объединяет несколько идентификаторов для формирования сопоставления (разрешение по одному идентификатору). DV360 PAIR: DV360 также поддерживает протокол PAIR для безопасного согласования данных между издателем и рекламодателем. | Начало работы с Customer Match (Google Ads API). |
| Meta (Facebook/ Instagram) |
Формат: Преобразовать в нижний регистр, удалить пробелы. Хеширование: Требуется SHA-256. Примечание: Meta не удаляет точки из адресов электронной почты в процессе нормализации хеширования. Для Meta перед хешированием следует применять только перевод в нижний регистр и удаление пробелов по краям. Отправка хешированного адреса электронной почты без точек («Hashed email (no dots)» в сопоставлении источников DCP) не совпадёт с хешем Meta и приведёт к снижению процента совпадений для пользователей данного домена электронной почты. Этот вариант идентификатора предназначен для партнеров, которым требуется удаление точки (например, Google Ads), и не должен использоваться для активации в Meta/ Facebook . |
Формат: Удалите символы, буквы и ведущие нули. Включить код страны (например, 16505551212). Хеширование: SHA-256. | Формат: IDFA или GAID. Хеширование: Не использовать хеширование. Строчными буквами, сохранить дефисы. |
Логика сопоставления: Использует логику «любой идентификатор»: объединяет несколько ID (эл.почта, телефон, MAID и др.) для определения пользователя, обеспечивая усиление между идентификаторами. CAPI: Для сопоставления браузеров требуются нехешированные client_ip_address и client_user_agent. |
Параметры информации о клиенте - API конверсий |
| TikTok | Формат: Переведите в нижний регистр, удалите все пробелы. Хеширование: SHA-256. | Формат: E.164 (+[код страны][номер]). Также принимается без знака +. Хеширование: SHA-256. | Формат: GAID (Android) или IDFA (iOS). Регистр: Все заглавные или все строчные. Хеширование: SHA-256 или MD5. |
Логика сопоставления: Аналогично Meta, применяет детерминированную логику «любой идентификатор», при которой для сопоставления достаточно одного корректного ID. Размер аудитории: Для активации пользовательской аудитории требуется минимум 1 000 совпавших пользователей. |
Как создать пользовательскую аудиторию из клиентского файла. |
| The Trade Desk (UID2) | Формат: То же самое «правило Gmail», что и у Google (убрать точки/плюсы). Кодировка: Закодируйте исходные байты в Base64 (в результат получится 44 символа). | Формат: E.164. Хеширование: SHA-256. Кодировка: Закодируйте исходные байты в формате Base64. | Формат: AAID (строчные буквы) / IDFA (заглавные буквы). Хеширование: SHA-256, MD5 или SHA-1. |
Логика сопоставления: Детерминированное сопоставление через граф идентификаторов. Сопоставление зависит от участия в графе идентификаторов, а не от объёма «сырых» ID. Важный нюанс: Необходимо закодировать в Base64 необработанные байты хеша. Кодирование шестнадцатеричной строки завершится ошибкой. |
|
| Формат: Должно включать "@". Хеширование: SHA-256, MD5 или SHA-1. | Формат: E.164. Удалите специальные символы (пробелы, дефисы). Хеширование: SHA-256, MD5 или SHA-1. | Формат: IDFA или GAID. Хеширование: SHA-256, MD5 или SHA-1. | Логика сопоставления: «Ориентировано на ID.» Сопоставление осуществляется преимущественно на основе электронной почты и MAID. Дополнительные идентификаторы приносят лишь ограниченную пользу, поскольку межидентификаторное усиление заметно слабее, чем у Meta. Поведение при загрузке: Для каждой аудитории загружается один тип идентификатора. | Руководство по загрузке и структурированию данных в DCP. |