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は、3種類のクリックIDからメディアソースを判定していました。gclidはgoogleadwords_int、dclidはdoubleclick_int、msclkidはbingsearch_intに対応していました。

Web Performance Measurementでは、さらに多くのクリックIDに対応しています。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の組み合わせに対するカスタムの対応ルールが拡大されています。PBAでは限定的な単一のmedium値にしか対応していませんでしたが、paid、paid_search、paid-searchなど、同じ意味を持つより多くのmedium値に対応し、TikTok、Snapchat、Pinterestも対象に追加されました。カスタムルールに一致しない場合は、どちらもutm_sourceの値をそのまま使用します。

チャネルの値の表記も変わります。PBAのDirect / Organic search / Social media / Email / Ad / Referral / Otherは、新しいDIRECT / ORGANIC_SEARCH / SOCIAL_MEDIA / EMAIL / AD / REFERRAL / OTHERになります。従来の値に基づくフィルターやグループ化の設定は、更新が必要です。

移行を容易にするため、AIコーディングツール（Claude Code、Cursorなど）にそのまま使える指示文を用意しました。ツールに既存のETLコードへのアクセスを許可し、以下の指示文を貼り付けてください。すべてのフィールドの対応関係と、動作上の違いを網羅しています。この指示文に沿って、ツールが現在のデータ処理の流れを把握し、新しいレポートに対応するように再構築します。

AppsFlyerの従来のPBA Data Lockerローデータレポート（Webサイト訪問＋Webサイトイベント）から、Web Performance MeasurementのData Lockerレポート（エンドユーザーイベント）へETL処理を移行してください。この指示文には、構造の変更、すべてのフィールドの対応関係、検証手順など、必要な情報がすべて含まれています。ここに記載されていない内容を推測しないでください。不明な点があれば、私に確認してください。

## 手順1：現在のデータ処理の流れを把握

コードを書く前に、既存のコードを調べ、以下を一覧にまとめてください。
1. 利用しているPBAレポート（Webサイト訪問、Webサイトイベント、または両方）と、その取り込み先。
2. 読み込んでいるすべてのPBAフィールドと、それぞれの後続処理での用途（変換、結合、ダッシュボード、アラート、データ出力）。
3. 読み込み頻度とスケジュールに関する前提（PBAは日次で提供）。
4. 訪問行とイベント行を分離または結合するロジック。
5. PBAフィールドの値に基づくフィルター、グループ化、コードに直接記述された値（media_sourceの名称、チャネル名、event_type、platformの値など）。

一覧を私に提示し、確認を得てから次に進んでください。

## 手順2：以下を私に確認

1. 新しいエンドユーザーイベントレポートは、Data Lockerですでに有効になっていますか（AppsFlyerの管理画面で有効化）？まだの場合は、私が先に有効にする必要があります。
2. 新しいWebアプリの統合アプリID（Unified App ID）は何ですか？形式："website-{domain}"（例：website-www.example.com）。分からない場合は、続行する前にAppsFlyerのダッシュボードで確認します。
3. 旧処理と新処理を並行して実行し、結果を比較する期間を設けますか？ それとも直接切り替えますか？並行稼働を推奨してください。
4. 新しい処理では、コンバージョンレポート（重複行のない、一意のアトリビューション記録）またはクロスプラットフォームのエンドユーザーイベントレポート（CUIDで重複を排除した、Webとモバイルのユーザー単位のデータ）も取り込みますか？デフォルトの対象範囲は、PBAレポートを直接置き換える、プラットフォーム単位のエンドユーザーイベントレポートです。

## 設計に反映する構造の変更

1. **2つのレポートを1つに統合。** PBAでは訪問とイベントが別々のレポートでした。新しいエンドユーザーイベントレポートには両方が含まれます。訪問行はend_user_event_type = 'SESSION'、イベント行はend_user_event_type = 'IN_APP'です。有効なevent_nameが入るのはIN_APP行のみです。SESSION行のevent_nameは空になります（PBAでは"website visit"が記録されていました）。
2. **すべてのプラットフォームでスキーマを共通化。** Webサイト、モバイル、CTV、PCで同じレポートを使用します。 Webデータだけを抽出するため、必ずplatform = 'WEBSITE'でフィルタリングしてください。
3. **両方への成果の紐付けに伴う重複を排除。** 同じ行動が、主たる成果の紐付け先を示す行と、副次的な紐付け先を示す行（新規ユーザー獲得ビューのLTVに使用する、元の獲得元）の2行で記録される場合があります。二重計上を防ぐため、デフォルトでis_primary_attribution = trueのフィルターを適用してください。このフィルターを外すのは、conversion_typeを使って新規ユーザー獲得ビューとリターゲティングビューを個別に分析する場合だけにしてください。
4. **日次から1時間ごとの提供に変更。** 新しいレポートは1時間ごとに提供され、データ反映までの時間は約2時間です。増分データの読み込みは、1日分の一括取り込みではなく、1時間ごとの処理を前提に再設計してください。
5. **オーガニックと有料広告の区別。** PBAのmedia_type（"Paid"）は廃止されます。真偽値のis_organicを使用してください。media_sourceからオーガニックか有料広告かを推測しないでください。
6. **ユーザー数の集計。** COALESCE(customer_user_id, appsflyer_id_value)を使ってユーザーを集計・結合してください。安定したカスタマーユーザーIDを優先し、それがない場合はCookieベースのIDを使用します。
7. **空の値。** STRINGフィールドは''、NUMERICフィールドはNULLです。

## フィールドごとの対応関係（PBA → エンドユーザーイベント）

ステータスの意味：変更なし＝名称とデータが同じ。名称変更＝データは同じで、列名が変更。定義変更＝データまたは値の形式が変更（取り扱いに注意）。廃止＝対応するフィールドなし。

| PBAのフィールド | ステータス | 新しいフィールド／対応方法 |
|---|---|---|
| advertising_id | 廃止 | モバイル／デバイスのID。クロスプラットフォームレポートはCUIDに基づくため、このフィールドは使用しないでください。 |
| af_web_id | 名称変更 | appsflyer_id_value。同じWeb Cookie。 |
| amazon_aid | 廃止 | モバイル／デバイスのID。Webには該当しません。 |
| android_id | 廃止 | モバイル／デバイスのID。Webには該当しません。 |
| app_id | 廃止 | クロスプラットフォームで使用するモバイル関連のフィールド。新しいWebアプリ識別子はunified_app_id（"website-{domain}"）です。単なる名称変更ではなく、別の概念です。 |
| app_name | 変更なし | app_name。 |
| app_version | 廃止 | クロスプラットフォームで使用するモバイル関連のフィールド。 |
| appsflyer_id | 廃止 | モバイルアプリのインストールID。注意：新しいappsflyer_id_valueはWeb Cookie（PBAのaf_web_id）であり、このフィールドとは異なります。 |
| attributed_touch_time | 名称変更 | event_time__attribution。 |
| attributed_touch_type | 廃止 | 従来は固定値。訪問とイベントの区別には、end_user_event_typeを使用します。 |
| bundle_id | 廃止 | クロスプラットフォームレポートでは、プロダクトラインによるグループ化に置き換わります。 |
| campaign | 名称変更 | 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 | 定義変更 | "Conversion event"としての区分は廃止されます。訪問とイベントの区別には、end_user_event_type（SESSION / IN_APP）を使用します。 |
| event_url | 変更なし | event_url。URLクエリパラメータ（UTMなど）の主な取得元にもなります。 |
| event_value | 変更なし | event_value。 |
| idfa / idfv / imei / oaid | 廃止 | モバイル／デバイスのID。Webには該当しません。 |
| install_time | 廃止 | モバイル関連のフィールド。 Webでのユーザー獲得時刻は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の情報は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（UTMによるGoogleのディスプレイ広告・動画広告の判定）、"X Ads" → "Twitter"（UTMによるTwitterの判定）。さらに多くの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になります。
- 対応するクリックIDの拡大（より多くのアドネットワークをクリックIDから判定）。dclid単独での判定は行われなくなり、fbclidも使用しません。

従来の値に基づくフィルター、CASE、結合キー、ダッシュボードのグループ化がないかコード全体を調べ、更新してください。

## 手順3：実装

1. 新しいETL設計を提案してください（データの取り込み、スキーマ、1時間ごとの増分処理、「構造の変更」で示した必須フィルター）。
2. 私の承認後、既存の規約とインフラを使用して実装してください。
3. 一覧にまとめた廃止フィールドのうち、後続処理で使用されているものについては、それぞれの利用先と対応策を示してください（削除、推奨される代替フィールドへの置き換え、業務担当者への確認）。

## 手順4：検証

1. 旧処理と新処理を同じ日付範囲で実行し、訪問（SESSION行）とPBAのWebサイト訪問、イベント（IN_APP行）とPBAのWebサイトイベント、収益の合計を比較してください。
2. 完全な一致ではなく、差が生じることを想定してください。新しいアトリビューションロジックはより高度なため、成果が紐付けられる項目（media_source、campaign）はPBAと完全には一致しません。セッションの集計ロジックは変わらないため（30分間のアクティビティ）、訪問数はおおむね同程度になると考えられます。
3. is_primary_attributionのフィルターがすべての処理に適用されていることを確認してください。適用されていない場合、イベント数が過大になります。
4. 対応付けた項目、削除した項目、値の変更、業務担当者が確認すべき未解決事項をまとめた簡潔な移行レポートを作成してください。

• 訪問をサーバー側から送信可能。 PBAのS2Sが受け付けるのはイベントのみであり、訪問はWeb SDKから送信する必要がありました。新しい/visitsエンドポイントにより、Webサイトの計測をサーバー側だけで行えます。
• setcuidの呼び出しが不要。 PBAではWeb SDKが必須だったため、CUIDをWebユーザーに紐付けるための個別の呼び出しが必要でした。新しいAPIでは、各リクエストにユーザー識別情報を含めて送信するため、この手順は不要です。
• データ送信が遅れた場合の扱い。イベントと訪問は1日分まとめて送信するのではなく、発生時にリアルタイムで、できればイベント発生から30分以内に送信してください。イベントが発生したUTC日付の終了から30分を過ぎて到着したデータも受け付けられますが、イベント時刻はAppsFlyerが受信した時刻に置き換えられます。

PBAのサーバー間APIでイベントを送信している場合に向けて、AIコーディングツール（Claude Code、Cursorなど）にそのまま使える指示文を用意しました。 AppsFlyerにイベントを送信するサービスへのアクセスをツールに許可し、以下の指示文を貼り付けてください。エンドポイントと送信データのすべての対応関係を網羅しています。この指示文に沿って、ツールが現在の実装を把握し、更新後の実装を作成します。

AppsFlyerの従来のPBA Web S2SイベントAPI（webs2s.appsflyer.com）から、Web Performance Measurementの新しいS2S API（events.appsflyer.com）へサーバー側の連携を移行してください。この指示文には、エンドポイント、認証、送信データのすべての対応関係、動作の変更など、必要な情報がすべて含まれています。ここに記載されていない内容を推測しないでください。不明な点があれば、私に確認してください。

## 手順0：コードを変更する前に以下を私に確認

1. 既存のサービスをそのまま変更しますか？ それとも、並行稼働してからスムーズに切り替えられるよう、別のサービス／モジュールを作成しますか？既存のものと並行して、新しいモジュールを作成することを推奨してください。
2. 新しいWebアプリの統合アプリID（Unified App ID）を把握していますか？形式："website-{domain}"（例：website-www.example.com）。 URLパス内のPBAのバンドルIDに置き換わります。分からない場合は、続行する前にAppsFlyerのダッシュボードで確認します。
3. 新しいS2S APIキーは取得済みですか？認証は、リクエスト本文内のwebDevKeyから、このキーを含むAuthorizationヘッダーに移りました。未取得の場合は、AppsFlyerのダッシュボードから取得します。
4. PBAと同様にイベントだけを送信しますか？ それとも、新しい訪問用エンドポイントも使用しますか？新しいAPIはサーバー側からの訪問送信に対応しているため、Webサイトの計測をサーバー側だけで行えます。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（旧） | 新しいS2S API |
|---|---|---|
| ベースURL | https://webs2s.appsflyer.com | https://events.appsflyer.com |
| イベント送信 | POST /v1/{bundleId}/event | POST /v2.0/s2s/inapps/app/web/{appId} |
| 訪問送信 | 非対応 | POST /v2.0/s2s/visits/app/web/{appId} |
| ユーザー識別情報の送信 | POST /v1/{bundleId}/setcuid | 個別の呼び出しは不要。各呼び出しのuser_idオブジェクト内に含めて送信 |
| パス内のアプリ識別子 | bundleId（ブランドバンドルID） | appId＝Webの統合アプリID（Unified App ID）（"website-{domain}"） |
| 認証 | JSON本文内のwebDevKey | S2S APIキーを含むAuthorizationヘッダー |
| コンテンツタイプ | 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時刻、ミリ秒単位） | timestamp（Unix時刻、ミリ秒単位） | 形式は同じです。すべての呼び出しに含めることを推奨します。省略した場合、AppsFlyerは受信時刻を使用します。 |
| eventValue | event_value | 形式は任意です。custom_parametersサブオブジェクトに対応しています。 |
| eventRevenue | event_revenue | 任意項目に変更（PBAではダッシュボードへの表示に必須でした）。 |
| eventRevenueCurrency | event_revenue_currency | 任意項目に変更（PBAではダッシュボードへの表示に必須でした）。 |
| referrer | http_referrer | 名称変更。 |
| userAgent | user_agent | 名称変更。 |
| ip | ip | 変更なし。 |
| （新規） | event_url | 訪問では必須、イベントでは任意です。 |
| （新規） | customer_dedup_id | 別の送信元（Web SDKなど）から到着した同じイベントとの重複を排除します。 |
| （新規） | email_hashed, phone_number_hashed, phone_number_e164_hashed, first_name_hashed, last_name_hashed | 正規化した値をSHA256でハッシュ化したもの（小文字の16進数64文字）。ユーザー識別情報を充実させるために使用します。 |

## 動作の変更と注意点

1. **appIdは統合アプリID（Unified App ID）です。"Web SDK ID"ではありません。** AppsFlyerのアプリ設定ページには、"Web SDK ID"というUUIDが表示されます（旧Web Dev Key。既存SDKを引き続き使用するために維持されています）。 S2Sのパスには、必ず統合アプリID（Unified App ID）（"website-{domain}"）を指定してください。このUUIDを指定しないでください。 401の"app not found"は、通常、パス内のappIdが誤っているか、Authorizationヘッダーが未指定または無効であることを示します。
2. **成功時のレスポンスは200ではなく202です。** これに合わせて、稼働状況の確認、再試行、アラートを更新してください。
3. **旧エンドポイントの応答で検証しないでください。** 旧エンドポイントは引き続き200を返す場合がありますが、この応答だけではWeb Performance Measurementにデータが届いたことを確認できません。新しいWebアプリのデータに、実際にイベントが表示されていることを必ず確認してください。
4. **setcuidの処理をすべて廃止してください。** ユーザー識別情報は、各イベントと訪問のuser_idオブジェクト内に含めて送信します。
5. **イベントより先に訪問を送信してください。** システムは、ユーザーのイベントより前に訪問があることを前提としています。過去の訪問がないユーザーのイベントは、オーガニックに分類されます。訪問はWeb SDK、または新しい/visitsエンドポイントから送信されます。
6. **一括送信せず、リアルタイムで送信してください。** 各イベントと訪問を発生時に送信し、できればイベント発生から30分以内に送信してください。イベントが発生したUTC日付の終了から30分を過ぎて到着したデータも受け付けられますが、イベント時刻が受信時刻に置き換えられるため、アトリビューションにずれが生じます。必ずタイムスタンプを送信してください。資料などに記載されている約30分間のアトリビューションの待機時間は、これとは別にAppsFlyerのサーバー側で設けられるものです。こちらで実装する必要はありません。
7. **サーバー側だけで計測する構成（訪問送信を採用する場合）。** Web SDKを使わない場合、Webユーザーの識別子は自社サーバーで管理します。初回訪問者に対して安定したIDを生成し、サーバーから設定するファーストパーティHTTP Cookieとして保存してください（JavaScriptではなくSet-Cookieヘッダーを使用。SafariではJavaScriptで設定するCookieの有効期間が約7日に制限されます）。すべてのリクエストで同じIDを再利用し、user_id.appsflyer_idとして送信してください。訪問の送信データにはevent_urlが必須です。アトリビューションの精度を高めるため、ip、user_agent、http_referrerも含めることを推奨します。
8. **SDKとS2Sを併用する場合。** 両方から同じイベントを送信する場合は、customer_dedup_idを設定し、AppsFlyerが1件だけを保持するようにしてください。

## 手順2：実装

1. 新しいクライアント／モジュール、設定（ベースURL、appId、APIキーをシークレット管理サービスに保存し、コードには直接記述しないこと）、イベント用の送信データ生成処理（対象範囲に含まれる場合は訪問も）、202レスポンスへの対応と再試行処理を含む設計を提案してください。
2. 私の承認後、既存の規約に従って実装してください。
3. 一覧のすべてのフィールドを、上記の送信データの対応表に沿って対応付けてください。現在送信しているフィールドに新しい対応項目がない場合は、その旨を示してください。

## 手順3：検証

1. テストイベント（対象範囲に含まれる場合は訪問も）を送信し、202レスポンスを確認してください。
2. AppsFlyerの新しいWebアプリ（ダッシュボードまたはData Locker）にテストデータが表示されていることを確認してください。成功の判断基準は、HTTPレスポンスではなく、実際のデータ反映です。
3. イベント名が新しい制約に準拠していることを確認してください（1～64文字。@ = + -は使用不可）。
4. 旧サービスと並行稼働する場合は、切り替え前に数日間、旧サービスと新サービスのイベント数を比較してください。その後、setcuidを含む旧APIの呼び出しを廃止してください。