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. Фильтры и группировки, привязанные к старым меткам, нужно обновить.

Чтобы упростить этот переход, мы подготовили готовый к использованию промпт для вашего ИИ-агента написания кода (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, метки channel, 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» / «ТВ»). Обновите всю логику, завязанную на ключах значений. |
| 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 | Переименовано | континент, код континента (например, "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, ключей соединения и группировок на дэшбордах, использующих эти старые значения, и обновите их.

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

1. Предложите новую архитектуру ETL (приём данных, схему, логику почасовой инкрементальной загрузки и обязательные фильтры из раздела «Структурные изменения»).
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, и вставьте приведённый ниже промпт – он содержит полное сопоставление эндпоинтов и передаваемых данных. Он поможет агенту изучить вашу текущую реализацию и создать обновленную.

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


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

1. Следует изменить существующий сервис или создать новый сервис/модуль параллельно с ним, чтобы обеспечить параллельную работу и затем полностью перейти на новый сервис? Рекомендуй создать новый модуль параллельно с существующим.

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

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

Изучите кодовую базу и составьте перечень:
1.

## Шаг 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, но такой ответ не подтверждает, что данные поступили в Web Performance Measurement. Всегда проверяйте, что события действительно появляются в данных нового веб-приложения.
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. Payload визита должен включать 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.