Чтобы упростить этот переход, мы подготовили готовый к использованию промпт для вашего ИИ-агента написания кода (Claude Code, Cursor или аналогичного инструмента). Предоставьте агенту доступ к вашему текущему ETL-коду и вставьте промпт ниже; он содержит полное сопоставление полей и все поведенческие различия. Он поможет агенту изучить ваш текущий конвейер обработки данных и перестроить его для нового отчета.

Вы переносите ETL-конвейер с устаревших отчетов Data Locker по необработанным данным PBA в AppsFlyer (Website visits + Website events) на отчет Data Locker AppsFlyer Web Performance Measurement (End User Events). В этом промпте есть все необходимое: структурные изменения, полное сопоставление полей и шаги валидации. Не додумывай ничего сверх того, что здесь написано; если что-то неоднозначно, спроси у меня.

## Шаг 1: Изучите текущий конвейер

Прежде чем писать какой-либо код, изучите существующую кодовую базу и составьте перечень:
1. Какие отчеты PBA вы используете (Website visits, Website events или оба) и где они загружаются.
2. Каждое поле PBA, которое мы считываем, и где каждое из них далее используется (преобразования, объединения, дэшборды, оповещения, экспорт).
3. Частота загрузки и допущения по расписанию (PBA доставляется ежедневно).
4. Любая логика, которая разделяет или объединяет строки визитов и строки событий.
5. Любые фильтры, группировки или жестко заданные значения, завязанные на значениях полей PBA (например, имена media_source, метки каналов, event_type, значения platform).

Покажи мне этот список и дождись моего подтверждения, прежде чем продолжить.

## Шаг 2: Задайте мне эти вопросы

1. Новый отчет End User Events уже включен в Data Locker (включается в интерфейсе AppsFlyer)? Если нет, мне нужно сначала включить это.
2. Какой Unified App ID у нашего нового веб-приложения? Формат: "website-{domain}" (например, website-www.example.com). Если я этого не знаю, я возьму эту информацию из дэшборда AppsFlyer, прежде чем мы продолжим.
3. Нужен ли нам период параллельного запуска (старый и новый пайплайн работают бок о бок, сравнивая результаты) или прямое переключение? Рекомендуй параллельный запуск.
4. Должен ли новый пайплайн также использовать отчет Conversions (уникальные случаи атрибуции, без дублирующихся строк) или кроссплатформенный отчет End User Events (с дедупликацией по CUID, на уровне пользователей web+mobile)? Область применения по умолчанию — отчет End User Events на уровне платформы, прямой преемник отчетов PBA.

## Структурные изменения, которые нужно учесть в дизайне

1. **Один отчет вместо двух.** В PBA визиты и события были разделены на два отчета. Новый отчет End User Events содержит оба типа данных: визиты — это строки с end_user_event_type = 'SESSION', а события — строки с end_user_event_type = 'IN_APP'. Только строки IN_APP содержат корректное значение event_name; в строках SESSION поле event_name пустое (в PBA туда записывали "website visit").
2. **Единая схема для всех платформ.** Этот отчет общий для website, mobile, CTV и PC. Всегда фильтруйте platform = 'WEBSITE', чтобы выделить веб-данные.
3. **Двойной учет атрибуции, нужна дедупликация.** Одно и то же действие может появляться дважды: строка с основным учетом и строка со вторичным учетом (исходный UA-источник, для LTV в представлении UA). По умолчанию применяйте фильтр is_primary_attribution = true, чтобы избежать двойного подсчета. Убирайте этот фильтр только для специального анализа представления UA и представления ретаргетинга с использованием conversion_type.
4. **Ежечасно вместо ежедневно.** Новый отчет доставляется ежечасно с задержкой обновления данных примерно 2 часа. Перестройте инкрементальные загрузки вокруг почасовых пакетов вместо ежедневной выгрузки.
5. **Органический vs платный.** Поле media_type ("Paid") в PBA больше не используется. Используйте логическое поле is_organic; никогда не определяйте органический/платный трафик по media_source.
6. **Подсчет пользователей.** Для подсчета и объединения пользователей используйте COALESCE(customer_user_id, appsflyer_id_value): сначала стабильный идентификатор пользователя customer_user_id, а в качестве резервного варианта — идентификатор на основе cookie.
7. **Пустые значения.** Для полей STRING используется '', для полей NUMERIC — NULL.

## Сопоставление полей (PBA → End User Events)

Обозначения статусов: Unchanged = имя и данные не изменились. Renamed = те же данные, новый столбец. Redefined = изменились данные или формат значения (используйте с осторожностью). Deprecated = эквивалента нет.

| Поле PBA | Статус | Новое поле / обработка |
|---|---|---|
| advertising_id | Deprecated | Идентификатор устройства. Кроссплатформенные отчеты основаны на CUID; удалите его. |
| af_web_id | Renamed | appsflyer_id_value, тот же веб-файл cookie. |
| amazon_aid | Deprecated | Идентификатор устройства, не относится к вебу. |
| android_id | Deprecated | Идентификатор устройства, не относится к вебу. |
| app_id | Deprecated | Мобильное кроссплатформенное поле. Новый идентификатор веб-приложения — unified_app_id ("website-{domain}"); это другое понятие, а не переименование. |
| app_name | Unchanged | app_name. |
| app_version | Deprecated | Мобильное кроссплатформенное поле. |
| appsflyer_id | Deprecated | Идентификатор мобильной установки. Примечание: новый appsflyer_id_value — это веб-файл cookie (af_web_id в PBA), а НЕ это поле. |
| attributed_touch_time | Renamed | event_time__attribution. |
| attributed_touch_type | Deprecated | Было константой. Теперь различие между visit и event задается в end_user_event_type. |
| bundle_id | Deprecated | Заменено группировкой Product Line в кроссплатформенном отчете. |
| campaign | Renamed | campaign_name. |
| campaign_id | Без изменений | campaign_id. |
| city | Без изменений | city. |
| country_code | Без изменений | country_code. |
| customer_user_id | Без изменений | customer_user_id. |
| device_type | Переименовано + изменены значения | device_category, значения отличаются (например, "Desktop" → "MOBILE_PHONE" / значения в стиле "TV"). Обновите всю логику, завязанную на ключах значений. |
| dma | Без изменений | dma. |
| event_name | Переопределено | События: без изменений. Визиты: теперь пусто (PBA написал «website visit»). Чтобы определить визиты, используйте end_user_event_type = 'SESSION'. |
| event_revenue | Переименовано | revenue_value_original. |
| event_revenue_currency | Переименовано | revenue_currency_original. |
| event_revenue_usd | Переименовано | revenue_usd. |
| event_source | Без изменений | event_source. |
| event_time | Без изменений | event_time. |
| event_type | Переопределено | Маркер "событие конверсии" больше не существует. Разделение визитов и событий находится в end_user_event_type (SESSION / IN_APP). |
| event_url | Без изменений | event_url, теперь это также основное место, откуда считываются параметры запроса URL-адреса (UTM и т. д.). |
| event_value | Без изменений | event_value. |
| idfa / idfv / imei / oaid | Устарело | Идентификаторы мобильных устройств, неактуально для веба. |
| install_time | Устарело | Поле для мобильных устройств. В вебе время привлечения пользователя — это event_time__conversion, отдельное понятие. |
| ip | Переименовано | ip_address_value (плюс ip_address_type для метода хеширования). |
| language | Переопределено | language, формат изменен на ISO 639-1 + код страны (раньше, например, "English"). |
| media_channel | Устарело | При необходимости можно использовать sub_param_1-5. |
| media_source | Без изменений | media_source (но см. переименование значений ниже). |
| media_type | Устарело | Вместо этого используйте булев флаг is_organic. |
| original_url | Переименовано | Объединено в event_url (для посещений event_url равен исходному URL-адресу). Отдельный столбец удален. |
| platform | Переопределено | platform всегда имеет значение "WEBSITE". ОС перенесена в os_version / user_agent. |
| postal_code | Без изменений | postal_code. |
| query_params | Устарело | Необработанная строка запроса теперь находится в event_url; столбец с разобранным JSON удален. При необходимости заново реализуй парсинг из event_url. |
| referrer | Переименовано | http_referrer. |
| region | Переименовано | continent, код континента (например, "NA"). |
| state | Без изменений | state. |

## Изменения атрибутированных значений (обновите фильтры и группировки)

Механизм атрибуции теперь иначе определяет источники трафика, поэтому некоторые значения меняются даже там, где названия полей остаются прежними:
- Переименования media_source: doubleclick_int → dv360_int (Google display/video через UTM); "X Ads" → "Twitter" (Twitter через UTM). Теперь больше значений PID сопоставляются с отображаемыми именами (например, iossearchads_int → Apple Search Ads, metweb_int → Facebook Ads, tiktokweb_int → tiktokglobal_int, snapweb_int → snapchat_int).
- Формат меток каналов меняется: Direct / Organic search / Social media / Email / Ad / Referral / Other становятся DIRECT / ORGANIC_SEARCH / SOCIAL_MEDIA / EMAIL / AD / REFERRAL / OTHER.
- Расширено покрытие Click-ID (теперь больше сетей определяется по click ID); один только dclid больше не определяется; fbclid не используется.

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

## Шаг 3: Сборка

1. Предложи новый дизайн ETL (ingestion, schema, почасовую инкрементальную логику, обязательные фильтры из «Structural changes»).
2. После моего одобрения внедри это, повторно используя наши существующие соглашения и инфраструктуру.
3. Для каждого устаревшего поля, которое инвентаризация обнаружила в последующем использовании, укажите потребителя и предложите решение (удалить, заменить предложенной альтернативой или передать на рассмотрение владельцу бизнеса).

## Шаг 4: Проверка

1. Запустите оба пайплайна для одного и того же диапазона дат и сравните: посещения (строки SESSION) и посещения сайта PBA, события (строки IN_APP) и события сайта PBA, а также итоговые суммы дохода.
2. Ожидайте различий, а не равенства: новая логика атрибуции более продвинута, поэтому атрибутированные измерения (media_source, campaign) не будут точно совпадать с PBA. Логика подсчета сессий не изменилась (30 минут активности), поэтому объемы посещений должны быть сопоставимыми.
3. Убедитесь, что фильтр is_primary_attribution применяется везде; его отсутствие проявляется в виде завышенного количества событий.
4. Подготовьте краткий отчет о миграции: что было сопоставлено, что было отброшено, что изменилось в значениях и какие открытые вопросы остались для владельца бизнеса.

• Визиты теперь обрабатываются на стороне сервера. S2S в PBA принимал только события; визиты должны были поступать из Web SDK. Новый эндпоинт /visits позволяет сайту полностью работать на стороне сервера.
• Вызов setcuid больше не нужен. Для PBA требовался Web SDK, поэтому был нужен отдельный вызов, чтобы связать CUID с веб-пользователем. Новый API передает идентификатор в каждом запросе, поэтому этот шаг исключается.
• Окно для поздних данных. Отправляйте события и визиты в реальном времени, предпочтительно в течение 30 минут после возникновения события, а не объединяйте их в одну ежедневную загрузку. Данные, поступившие более чем через 30 минут после окончания дня UTC, в который произошло событие, по-прежнему принимаются, но время события заменяется временем, когда AppsFlyer их получил.

Если вы отправляете события через PBA Server-to-server API, мы подготовили готовый к использованию промпт для вашего ИИ-агента для написания кода (Claude Code, Cursor или аналогичного). Предоставьте агенту доступ к сервису, который отправляет события в AppsFlyer, и вставьте промпт ниже; он содержит полное сопоставление endpoint и payload. Он поможет агенту изучить вашу текущую реализацию и создать обновленную.

Вы переносите серверную интеграцию с устаревшего API веб-событий PBA Web S2S AppsFlyer (webs2s.appsflyer.com) на новый S2S API AppsFlyer для измерения эффективности веб-ресурсов (events.appsflyer.com). В этом запросе есть всё, что вам нужно: конечные точки, аутентификация, полное сопоставление полезной нагрузки и изменения в поведении. Не делайте предположений сверх того, что здесь написано; если что-то неоднозначно, спросите меня.

## Шаг 0: Задайте мне эти вопросы, прежде чем вносить изменения в код

1. Нам следует изменить существующий сервис на месте или создать рядом с ним новый сервис/модуль (чтобы обеспечить параллельный запуск и чистое переключение)? Рекомендуйте новый модуль рядом с существующим.
2. Знаю ли я Unified App ID нашего нового веб-приложения? Формат: "website-{domain}" (например, website-www.example.com). Он заменяет bundle ID PBA в пути URL-адреса. Если я его не знаю, я найду его на дэшборде AppsFlyer, прежде чем мы продолжим.
3. Есть ли у меня новый ключ S2S API? Аутентификация перенесена из webDevKey в теле запроса в заголовок Authorization, передающий этот ключ. Если у меня его нет, я найду его на дэшборде AppsFlyer.
4. Мы хотим отправлять только события (как в PBA) или также использовать новую конечную точку visits? Новый API поддерживает визиты на стороне сервера, поэтому сайт может полностью работать на стороне сервера; PBA принимал только события.
5. AppsFlyer Web SDK по-прежнему работает на нашем сайте? (Определяет, поступают ли визиты из SDK и нужна ли дедупликация событий между SDK и S2S.)

## Шаг 1: Изучите текущий сервис

Изучите кодовую базу и составьте перечень:
1. Все места вызова webs2s.appsflyer.com, вызовы /event и любые вызовы /setcuid.
2. Поля, заполняемые при каждом вызове (customerUserId, afUserId, eventName, eventValue, eventRevenue, timestamp, referrer, userAgent, ip и т. д.), и источники их значений.
3. Обработка ошибок и мониторинг, завязанные на ответ 200 OK.
4. Поведение повторных попыток, пакетной обработки и очередей.

Предоставьте мне этот список и дождитесь моего подтверждения, прежде чем продолжить.

## Что изменилось: конечные точки и аутентификация

|  | PBA Web-S2S (старый) | Новый API S2S |
|---|---|---|
| Базовый URL-адрес | https://webs2s.appsflyer.com | https://events.appsflyer.com |
| Вызов события | POST /v1/{bundleId}/event | POST /v2/s2s/inapps/app/web/{appId} |
| Вызов визита | Недоступно | POST /v2/s2s/visits/app/web/{appId} |
| Вызов идентификации | POST /v1/{bundleId}/setcuid | Нет, идентификация встроена в объект user_id в каждом вызове |
| Идентификатор приложения в пути | bundleId (bundle ID бренда) | appId = унифицированный идентификатор веб-приложения ("website-{domain}") |
| Аутентификация | webDevKey в теле JSON | Заголовок Authorization с ключом API S2S |
| Тип контента | application/json | application/json (415, если отсутствует) |
| Успешный ответ | 200 OK | 202 Accepted |

## Сопоставление полей полезной нагрузки

| Поле PBA | Новое поле | Примечание |
|---|---|---|
| customerUserId | user_id.customer_user_id | Вложено в объект user_id. |
| afUserId | user_id.appsflyer_id | Вложено в объект user_id. Отправляйте как минимум одно из значений: customer_user_id или appsflyer_id; отправляйте оба, когда пользователь идентифицирован. |
| webDevKey | (удалено) | Аутентификация перенесена в заголовок Authorization; приложение идентифицируется по appId в пути. |
| eventType (всегда "EVENT") | (удалено) | Тип определяется конечной точкой (/inapps или /visits). |
| eventName | event_name | 1–64 символа; не может содержать символы @ = + -. |
| timestamp (Unix ms) | timestamp (Unix ms) | Тот же формат. Рекомендуется при каждом вызове; если параметр не указан, AppsFlyer использует время получения. |
| eventValue | event_value | Произвольный формат; поддерживает вложенный объект sub-object custom_parameters. |
| eventRevenue | event_revenue | Теперь необязателен (PBA требовал его для дэшбордов). |
| eventRevenueCurrency | event_revenue_currency | Теперь необязателен (PBA требовал его для дэшбордов). |
| referrer | http_referrer | Переименован. |
| userAgent | user_agent | Переименован. |
| ip | ip | Без изменений. |
| (new) | event_url | Обязателен для визитов; необязателен для событий. |
| (new) | customer_dedup_id | Удаляет дубликаты одного и того же события, поступающего из другого источника (например, из Web SDK). |
| (new) | email_hashed, phone_number_hashed, phone_number_e164_hashed, first_name_hashed, last_name_hashed | SHA256 (64-символьная шестнадцатеричная строка в нижнем регистре) нормализованных значений для обогащения идентификации. |

## Изменения в поведении и важные нюансы

1. **appId — это Unified App ID, а не "Web SDK ID".** На странице настроек приложения в AppsFlyer отображается UUID "Web SDK ID" (бывший Web Dev Key, сохраненный для непрерывности SDK). Путь S2S должен содержать Unified App ID ("website-{domain}"), а не этот UUID. 401 "app not found" обычно означает неверный appId в пути или отсутствие/некорректность заголовка Authorization.
2. **Успешный статус — 202, а не 200.** Соответственно обновите проверки работоспособности, повторы попыток и оповещения.
3. **Не выполняйте проверку по старой конечной точке.** Устаревшая конечная точка всё ещё может возвращать 200, но этот ответ не подтверждает, что данные поступили в систему измерения эффективности веб-ресурсов. Всегда проверяйте, что события действительно появляются в данных нового веб-приложения.
4. **Полностью откажитесь от потока setcuid.** Идентификационные данные передаются inline в объекте user_id при каждом событии и визите.
5. **Сначала визиты, потом события.** Система ожидает визит до любого события от пользователя; события для пользователя без предыдущего визита классифицируются как органические. Визиты поступают из Web SDK или, теперь, из эндпоинта /visits.
6. **Отправляйте в реальном времени; не отправляйте пакетами.** Отправляйте каждое событие и каждый визит по мере их возникновения, желательно в течение 30 минут после наступления события. Данные, поступившие позже чем через 30 минут после окончания дня UTC, в который произошло событие, всё равно принимаются, но время события заменяется временем получения, что искажает атрибуцию. Всегда отправляйте временную метку. Обратите внимание: приблизительно 30-минутная задержка атрибуции, о которой вы могли читать, — это отдельная серверная задержка на стороне AppsFlyer, и нам ничего реализовывать не нужно.
7. **Полностью серверный вариант (если мы внедрим визиты).** Без Web SDK наш сервер управляет идентификатором веб-пользователя: сгенерируйте стабильный идентификатор для посетителей, которые заходят впервые, сохраните его как установленный сервером first-party HTTP cookie (заголовок Set-Cookie, не JavaScript; в Safari срок действия JS-cookie ограничен примерно 7 днями), используйте его повторно при каждом запросе и отправляйте как user_id.appsflyer_id. Полезная нагрузка визита должна включать event_url (и должна также включать ip, user_agent и http_referrer для качества атрибуции).
8. **SDK + S2S вместе.** Если оба отправляют одно и то же событие, заполните customer_dedup_id, чтобы AppsFlyer сохранил только одну копию.

## Step 2: Сборка

1. Предложите архитектуру: новый клиент/модуль, конфигурация (базовый URL-адрес, appId, хранение API-ключа в нашем менеджере секретов, никогда не хардкодить), конструкторы полезной нагрузки для событий (и визитов, если они входят в область работ), а также обработка ответов и повторных попыток для 202.
2. После моего одобрения внедрите это в соответствии с нашими существующими соглашениями.
3. Сопоставьте каждое поле из инвентаря с полезной нагрузкой, указанной выше; отметьте все поля, которые мы сейчас отправляем, но для которых нет нового эквивалента.

## Step 3: Проверка

1. Отправьте тестовое событие (и визит, если он входит в область работ) и подтвердите ответ 202.
2. Проверьте, что тестовые данные появились в новом веб-приложении в AppsFlyer (в дэшборде или в Data Locker); это и есть реальный признак успеха, а не HTTP-ответ.
3. Убедитесь, что имена событий соответствуют новым ограничениям (1–64 символа, без @ = + -).
4. Если старая служба и новая работают параллельно, сравните объемы событий в старой и новой службе в течение нескольких дней перед переключением, а затем выведите из эксплуатации старые вызовы, включая setcuid.

Web Performance Measurement также сопоставляет больше значений PID с отображаемыми названиями, например: iossearchads_int → Apple Search Ads, metweb_int → Facebook Ads, twitterweb_int → Twitter, tiktokweb_int → tiktokglobal_int, snapweb_int → snapchat_int. В отчетах, построенных на старых необработанных значениях, нужно ожидать новые.

PBA сопоставлял три идентификатора кликов: gclid — с googleadwords_int, dclid — с doubleclick_int и msclkid — с bingsearch_int.

Web Performance Measurement сопоставляет гораздо больше идентификаторов кликов: gclid/wbraid/gbraid — с googleadwords_int, msclkid — с bingsearch_int, twclid — с Twitter, vmcid — с yahoogemini_int, sccid — с snapchat_int, li_fat_id — с linkedin_int, ttclid — с tiktokglobal_int, tbclid — с taboola_int, ob_click_id/dicbo — с outbrain_int, yclid — с yandex_int, rdt_cid — с reddit_int.

В Web Performance Measurement сопоставление пользовательских utm_source + utm_medium стало шире: оно включает больше синонимов для medium (paid, paid_search, paid-search и т. д.), а также добавлен охват TikTok, Snapchat и Pinterest помимо узких правил PBA с единственным значением medium. Если ни одно пользовательское правило не подходит, в обоих случаях используется исходное значение utm_source.

Формат значений канала также меняется: вместо используемых в PBA Direct / Organic search / Social media / Email / Ad / Referral / Other теперь используются новые DIRECT / ORGANIC_SEARCH / SOCIAL_MEDIA / EMAIL / AD / REFERRAL / OTHER. Фильтры и группировки, привязанные к старым меткам, нужно обновить.