# Импорт транзакций

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

1. Уточнение популярности товаров — в ранжировании по популярности будут принимать участие и данные из событий и загруженные данные.
2. Данные для алгоритма “Purchased Together” — в расчёте скоров для товаров, покупаемых в рамках одного чека будут учитываться и данные из событий и загруженные данные.
3. Персональные рекомендации в рамках алгоритма “Affinity” — при формировании рекомендаций для пользователя будут использоваться как его поведение на сайте / в приложении, так и покупки, загруженные в платформу (требуются идентификаторы пользователя).
4. Исключение товаров, купленных пользователем в офлайн магазинах или до интеграции платформы, если загружаются исторические данные (требуются идентификаторы пользователя).
5. Создание пользовательских сегментов на основании данных о покупках пользователей (требуются идентификаторы пользователя).

При загрузке идентификаторы в событиях “Login” / “Signup”, должны совпадать с идентификаторами в загружаемых данных. В расчётах участвуют только товары, присутствующие в фиде на момент загрузки данных. Также к загруженным данным применяются все правила применяемые к исходным стратегиям (например диапазон данных). Описание рекомендательных стратегий

# Процедура загрузки данных

Процедура состоит из следующих шагов:

1. Обсудить с менеджером по персонализации кейсы, в которых планируется использование загруженных данных.
2. Определить период загружаемых данных (для исторических данных) или периодичность загрузки данных (для данных об оффлайн продажах).
3. Подготовить выгрузку в соответствии с форматом ниже и обеспечить возможность загрузить файл с выгрузкой по прямой ссылке.
4. Передать ссылку коллегам из Gravity Field.
5. Первичная загрузка данных и обновление профилей пользователей может занимать до недели.

# Структура данных

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

Десятичный разделитель - точка

Параметры со звёздочкой (*) обязательны для заполнения

Во избежание фрагментации профилей рекомендуется использовать единый идентификатор пользователя во всех каналах (Web, мобильные SDK, Server-Side API и импорт офлайн-данных) — SHA-256 хеш нормализованного мобильного телефона с типом phone_hash.

Чаще всего данные об офлайн‑покупках формируются из CDP или DWH. В этом случае:

• при построении CSV для Gravity Field на стороне CDP должен использоваться ровно тот же алгоритм нормализации и хеширования, что и во фронтенде/мобильных SDK;
• в CDP рекомендуется хранить “золотой” ключ (Golden Record) в виде нормализованного телефона и/или его хеша и использовать его как источник поля cuid для всех выгрузок в Gravity Field.

Перед построением хеша:

• Удалите все символы, кроме цифр.
• Для РФ/КЗ приводите номер к формату 7XXXXXXXXXX (без +, пробелов, скобок и дефисов).
• Для других стран используйте международный формат без + и разделителей.
• Считайте SHA-256 по строке в UTF-8 и передавайте результат в виде lowercase hex.

# Проверка корректности загрузки данных

1. Логи каждой загрузки доступны в выделенной папке на нашем сервере с парольным доступом (доступ предоставляется по запросу). Формат имени файла лога: offline_purchase_upload_log_YYYY-MM-DD-HH-MM-SS.csv.
2. После первичной загрузки данных рекомендуется проверить, что данные появились в аудиториях при выборе условия “Products purchased offline”.

# Образец файла

offline_purchases_data_example.csv