> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# インプレッショントラッカー実装リファレンス

> バイヤー内部のインプレッショントラッカーの非規範的リファレンス — マルチアイデンティティ重複排除、fcap_keys ラベルモデル、インプレッションピクセルから Identity Match 境界のキャップ発火エントリまでのパス。

# インプレッショントラッカー実装リファレンス

このページは、[フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) 境界の背後に位置するインプレッショントラッカーの **非規範的リファレンスコンテンツ** です。プロトコルは次のみを制約します:

* ワイヤー仕様 — [TMP 仕様](/docs/trusted-match/specification) を参照。
* Identity Match サービスが満たさなければならない適合性不変条件 — [TMP 仕様](/docs/trusted-match/specification#conformance-invariants-for-identitymatch-eligibility) でも規範的。
* キャップ発火境界コントラクト — [フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) で定義。

このページのすべてはバイヤー内部です: インプレッショントラッカーがどうインプレッションをカウントし、解決されたアイデンティティをまたいで重複排除し、ウィンドウを評価し、キャップがいつ発火するかを決めるか。準拠するインプレッショントラッカーを実行するバイヤーは、境界で正しいキャップ発火イベントを生成する任意のアプローチを選べます。このページは 1 つのそのようなアプローチ — [`adcp-go/targeting`](https://github.com/adcontextprotocol/adcp-go/tree/main/targeting) で実装されたもの — を文書化し、他の実装者が実践的なリファレンスを持てるようにします。

## クロスアイデンティティ重複排除問題

ユーザーへの単一のインプレッションは、しばしば同じ TMPX 内で複数のアイデンティティ（RampID、ID5、MAID、UID2、パブリッシャー発行トークンなど）に解決されます。アイデンティティごとにカウントする素朴なインプレッショントラッカーは、1 つのインプレッションをユーザーのキャップに対して 2〜3 としてカウントします。バイヤーがアイデンティティグラフを実行する場合、バイヤーはカウント前にアイデンティティを正準化できます。バイヤーがグラフなしまたは部分的にグラフ化されている場合（一般的 — Scope3 のホストされた Identity Match はグラフなし）、正準 id は存在しません。

カウンターベースのアプローチは、アイデンティティごとのカウンターを読むとき `merge_rule`（MAX / OR / SUM）でこれを取り繕います。どのマージルールも一般には正しくありません。病理的なケースは、インプレッションをまたいだアイデンティティ解決のトグルです: 一部のインプレッションは `rampid` のみを解決し、一部は `rampid` と `id5` の両方を解決します。MAX マージされたカウンターは過少カウント、SUM は過剰カウント、OR は 1 より多くを表現できません。どちらにせよキャップが誤ったタイミングで発火します。

リファレンス実装は、`impression_id` スキームで merge-rule 問題を完全に回避します: インプレッションごとに 1 つの id、すべての解決されたアイデンティティのログに書き込み、読み取り時に id で重複排除。カウントは、アイデンティティが上流で正準化されているかにかかわらず正確です。

## impression\_id ルール

インプレッショントラッカーはインプレッションごとに 1 つの `impression_id` を維持し、すべての解決されたアイデンティティのログに書き込みます。読み取り時に、ユーザーのすべてのアイデンティティログをスキャンし `impression_id` で重複排除すると、distinct-impression カウントが正確に復元されます。

必要なプロパティ:

1. **すべてのセラー、ソース、時間にわたってグローバルに一意。** バイヤーエージェントは多くのセラーから供給されるインプレッションを提供します。セラーをまたいだ衝突は distinct なインプレッションを黙ってマージしキャップを過少カウントします。十分なエントロピーを持つ任意の衝突耐性のある識別子スキームが許容されます — UUID（任意バージョン）、ULID、snowflake、または同等物。プロトコルは形式をピン留めしません。任意の層（パブリッシャー、決定層、またはデコード時のバイヤー）で鋳造された値は、他のすべての当事者にとって不透明な文字列です。
2. **値の 3 つの有効なソース、優先順位順。** `impression_id` は (a) パブリッシャー自身のファーストパーティコード、(b) 広告決定層（Prebid TMP モジュール、アドサーバー、SSP）、(c) TMPX デコード時のバイヤーのインプレッショントラッカーによって生成されます。層 (a) と (b) は、[`{IMPRESSION_ID}`](/docs/creative/universal-macros#impression-identification) ユニバーサルマクロ経由でピクセル URL に値を代入することでバイヤーに値を配信します。それらの違いは運用上 — パブリッシャーのスタックで誰が鋳造するか — で、ピクセルが到着するとバイヤーには不透明です。
3. **バイヤー消費ルール。** バイヤーは、存在するとき `{IMPRESSION_ID}` をピクセル URL から消費しなければならず（MUST）、欠如のときのみデコード時鋳造にフォールバックします。バイヤーがデコード時に鋳造するとき、TMPX nonce を `impression_id` として再利用してはなりません（MUST NOT） — TMPX nonce は Identity-Match-評価ごとで、サーブウィンドウ内のすべてのインプレッションで共有されるため、衝突します。
4. **コンテキストのみの要件。** コンテキストのみのインプレッション（ピクセルに `{TMPX}` 代入なし）については、デコード時のバイヤー側鋳造は不可能 — 層 (a) または (b) からの `{IMPRESSION_ID}` が唯一の利用可能なソースです。パブリッシャーと決定層は、TMP コンテキストのみのインプレッションに `{IMPRESSION_ID}` を含めなければなりません（MUST）。インプレッショントラッカーは、その欠如を統合エラーとして扱い、ログし、露出書き込みをスキップするか、ピクセル発火ごとのワンショット識別子にフォールバックすべきです（SHOULD）。フォールバックは、クロスアイデンティティ重複排除を保持できないため劣化しています。
5. **インプレッションごとに 1 つの id、そのインプレッションのユーザーのすべての解決されたアイデンティティログに書き込む。** アイデンティティごとに異なる id を生成すると重複排除コントラクトが壊れます — 同じインプレッションが解決されたアイデンティティごとに 1 回カウントされます。
6. **ピクセルリトライは別の関心事。** 同じピクセルが 2 回発火する（ネットワークリトライ、ページリフレッシュなど）ことは、2 つの `impression_id` を鋳造してはなりません — 2 つを鋳造するとピクセルリトライがキャップに対して二重カウントします。ピクセル URL の冪等性キーまたは `Idempotency-Key` ヘッダーでインバウンドリクエストを重複排除するか、リトライからの小さな過剰カウントを fcap 目的で無害として受け入れるかのいずれか。クロスアイデンティティ重複排除とピクセルごとの冪等性は、異なる緩和を持つ異なる問題です。（小文字の表現: このページは非規範的です。[フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) ページの境界コントラクトが適合性テストが引用するものです。）

## fcap\_keys ラベルモデル

キャップは、インプレッション書き込み時に `dimension:value` ラベルでタグ付けされます。パッケージはどのラベルにマップするかを宣言し、fcap ポリシーは各ラベルに `window` と `max_impression_count` を付けます。

```
package 2342:                   fcap_keys ["campaign:42", "campaign_group:7", "advertiser:13"]
policy "campaign:42":           {window: {interval: 10, unit: "minutes"}, max_impression_count: 5}
policy "campaign_group:7":      {window: {interval: 1,  unit: "days"},    max_impression_count: 50}
policy "advertiser:13":         {window: {interval: 1,  unit: "days"},    max_impression_count: 20}
```

インプレッショントラッカーが package 2342 のインプレッションの露出を書き込むとき、エントリの `fcap_keys` は `["campaign:42", "campaign_group:7", "advertiser:13"]` です。キャップが発火したかを評価するとき、そのポリシーのウィンドウ内で各ラベルに一致するエントリをログでスキャンします。

**ウィンドウ unit は負荷を担う**、単なる人間可読の省略形ではありません。リファレンス実装は `unit` をスライディングウィンドウのバケットサイズとして使います: `unit: "hours"` は時間単位のバケットに対して評価し、`unit: "minutes"` は分単位のバケットに対して評価します。duration 的に等価に見える 2 つのポリシー — `{interval: 2, unit: "hours"}` 対 `{interval: 120, unit: "minutes"}` — は **同じウィンドウ長** だが **異なるキャップ後再評価ケイデンス** を持ちます。ユーザーが 2 時間バケットキャップに達した後、新しいトラフィックを許可する次の適格性チェックは次の時間バケット境界で起こります。120 分バケットポリシーでは、次の分バケット境界で起こります。より小さい数字に収まる duration ではなく、望むケイデンスに合わせて `unit` を選んでください。

**文字セット制約。** 各セグメントは `[a-zA-Z0-9_-]+` に一致するため、`:` デリミタは曖昧でありません。URL を運ぶまたは他にコロンを運ぶ値はハッシュ化または短縮されなければなりません。

**マルチテナントオペレーター** は通常、共有状態上の広告主組織をまたいだキー衝突を防ぐデプロイ慣例として、テナントプレフィックス（`buyer-acme:campaign:42`）を採用します。これはオペレーターポリシーであり、プロトコルではありません。

**なぜ階層ではなくラベルか。** キャップ次元は顧客をまたいで異種です — 一部はクリエイティブでキャップし、一部はラインアイテムで、一部は広告主ロールアップで。固定スキーマは過剰規定するか過少提供するかのいずれかです。ラベルはクロスセラーキャップも自動にします: キーがセラーをまたいで共有される任意のポリシー（例: `buyer-acme:advertiser:13`）は、追加モードなしにそれらすべてにわたって強制します。横断的なポリシーは明示的です — キャンペーンごとと広告主ごとの両方のキャップが必要なキャンペーンは、両方のキーを宣言し 2 つのポリシールックアップを得ます。

## リファレンスデータモデル（valkey 裏付け、ログベース）

下のレイアウトは [`adcp-go/targeting`](https://github.com/adcontextprotocol/adcp-go/tree/main/targeting) が使うものです。任意のバックエンド（Aerospike、DynamoDB、インメモリ、何でも）が問題ありません。データ形状はリファレンスであり、要件ではありません。

### 露出ログ（アイデンティティごと）

```
type:  STRING  (binary-encoded []ExposureEntry, lazy-pruned to window)
key:   user:exposures:{HashToken(uid_type + ":" + user_token)}
value: [
  { impression_id, fcap_keys[], timestamp },
  ...
]
```

`HashToken` は 16 バイトの SHA-256 プレフィックス、16 進エンコード。バイナリエントリエンコーディングがログをコンパクトに保ちます（[`exposure_binary.go`](https://github.com/adcontextprotocol/adcp-go/blob/main/targeting/exposure_binary.go)） — 典型的なユーザーの 30 日ログは数 KB です。

各エントリは記録します:

* `impression_id` — TMPX デコード時に生成。このインプレッションのすべてのアイデンティティログで同じ値。
* `fcap_keys[]` — このインプレッションがカウントするラベル。
* `timestamp` — unix 秒。

### Fcap ポリシー（fcap\_key ごと）

```
type:  STRING  (JSON-encoded FcapPolicy)
key:   fcap_policy:{fcap_key}
value: { window: {interval, unit}, max_impression_count, active, updated_at }
```

スライディングウィンドウは、ウィンドウをまたぐ現在と以前のバケットに落ちるログエントリをカウントすることで読み取り時に適用されます。バケットサイズは `window.unit`（`minutes`/`hours`/`days`/`weeks`/`months`）から導出され、ウィンドウ長は `interval × unit` です。エントリタイムスタンプの秒ごとの `>=` フィルターではなくバケットレベルのフィルターが、本番が使うものです — これがキャップ発火後の再評価ケイデンスをポリシーの `unit` から予測可能にします。

### パッケージ設定（パッケージごと）

```
type:  STRING  (JSON-encoded PackageConfig)
key:   package:identity:{package_id}
value: {
  fcap_keys: ["campaign:42", "advertiser:13"],
  active:    true,
  updated_at: <unix seconds>
}
```

パッケージ → fcap\_keys をマップ。インプレッショントラッカーは、新しい露出をどのラベルでタグ付けするかを把握するためにこれを読みます。

## 書き込みパス: ピクセル → ログ

ピクセル発火時に、インプレッショントラッカーは:

1. **アイデンティティとパッケージコンテキストを解決する。** `{TMPX}` が存在するとき、TMPX をデコード（HPKE 復号 + バイナリパース） → 解決されたアイデンティティ + `(seller_agent_url, package_id)`。`{TMPX}` が欠如するとき（コンテキストのみのインプレッション）、他のピクセルパラメーターからパッケージコンテキストを解決し、解決されたアイデンティティセットは空 — 露出は、アイデンティティごとではなく上流で鋳造された（パブリッシャーまたは決定層）impression\_id でキー付けされた単一のコンテキストのみのログに書き込まれる。
2. パッケージの `fcap_keys` をルックアップする。
3. **`impression_id` を取得する。** ピクセル URL が `{IMPRESSION_ID}`（パブリッシャーまたは広告決定層によって上流で鋳造 — バイヤーはどちらかを区別できず、する必要もない）を運ぶ場合、その値を使う。そうでなければ 1 つ鋳造する — ただし `{TMPX}` が存在するときのみ。コンテキストのみのインプレッションでは、劣化モード動作について上のルールセクションのルール #2 を参照。
4. 各解決されたアイデンティティについて、`{impression_id, fcap_keys, timestamp}` を `user:exposures:{hash(identity)}` に追加する。最も長いアクティブウィンドウ（デフォルト 30 日）より古いエントリを刈り取る。解決されたアイデンティティのないコンテキストのみのインプレッションについては、エントリは適用される配信カウントログにのみ書き込まれる — 重複排除するアイデンティティがないとき、クロスアイデンティティ重複排除は意味を持たない。

アイデンティティごとの read-modify-write はリファレンス実装ではアトミックでありません（[`engine.go:478`](https://github.com/adcontextprotocol/adcp-go/blob/main/targeting/engine.go#L478)） — 同じユーザーの並行書き込みは露出を失いうる。リファレンス実装はこれを明示的に受け入れます。競合下の過少カウントは fcap 目的で無害です。Lua または `Store.Append` 拡張経由のアトミック追加は延期された最適化です。

## このインプレッションがキャップを使い果たしたかの評価

露出を書き込んだ後、インプレッショントラッカーは任意のキャップがちょうど発火したかを決めます。**パッケージは通常複数の `fcap_keys`（campaign、campaign\_group、advertiser、…）にマップし、それぞれ独自のポリシーを持ちます。ポリシーは独立して評価され、そのうち *いずれか 1 つ* がそのウィンドウ内で `max_impression_count` に達したときキャップが発火します。** ユーザーは、広告主ごとのポリシーに一度も近づかずにキャンペーンごとのポリシーでパッケージをキャップされうるし、逆も同様です。

露出の各 `fcap_key` について、インプレッショントラッカーはユーザーのアイデンティティログをスキャンします:

1. すべての解決されたアイデンティティについて `user:exposures:{h}` を読む。
2. エントリを、`policy.window` をまたぐ現在+以前のバケットに落ち、`fcap_key ∈ entry.fcap_keys` のものにフィルターする。
3. ユーザーのすべてのアイデンティティログにわたって `impression_id` で重複排除する。
4. 重複排除されたカウントを `policy.max_impression_count` と比較する。

任意のポリシーの重複排除されたカウントが `>= max_impression_count` なら、このインプレッションでキャップが発火しました。インプレッショントラッカーは次に、パッケージが使い果たされた `fcap_key` にマップするすべての `(user_identity, package_id)` について、Identity Match キャップ状態ストアにキャップ発火エントリを書き込みます。有効期限は `policy.window` の現在のバケットの終わり（バケットセマンティクスの下で最も古いスコープ内露出が期限切れになるとき）です。

複数のセラーの複数のパッケージにマップする広告主レベルのラベル（`advertiser:13`）のキャップについては、インプレッショントラッカーは影響を受ける `(user_identity, seller_agent_url, package_id)` ごとに 1 つのキャップ発火エントリを発します — main の [境界コントラクト](/docs/trusted-match/identity-match-implementation#the-cap-fire-event) はパッケージスコープなので、クロス次元のキャップは書き込み時にファンアウトします。

## SDK プリミティブ

SDK は、インプレッション処理を 1 つのバンドルされた呼び出しではなく、2 つの合成可能な関数として出荷します。本番トラッキングエンドポイントは通常、取り込み時にデコードし、下流のワーカーに独自のペースでストアを書かせます。decode+write を単一の関数にバンドルすることは、同期トポロジーを強制しバッファリングを妨げます。

```
decodeTmpx(raw_tmpx) -> DecodedExposures
  Decrypts HPKE ciphertext, parses the published TMPX binary format
  (/docs/trusted-match/specification#binary-format), returns the resolved
  identity entries in a structured form ready for serialization onto a
  topic or for direct write. The persistent per-identity exposure log
  is a separate, store-resident structure — see Reference data model above.

writeExposure(decoded, fcap_keys, store_context) -> { ok, fired_caps }
  Appends entries to each resolved identity's exposure log with a fresh
  impression_id and the supplied fcap_keys. Prunes entries older than the
  longest active window. Returns the set of caps that fired on this
  impression — the caller fans these out to the Identity Match cap-state
  store.
```

加えてバイヤー側の管理プレーン:

```
upsertPackage(seller_agent_url, package_id, fcap_keys, opts)
upsertFcapPolicy(fcap_key, {window: {interval, unit}, max_impression_count})
inspectExposures(uid_type, user_token, fcap_key?)   // debugging helper
```

加えて、net-new SDK プリミティブとしての HPKE 暗号化/復号（X25519 KEM、ChaCha20-Poly1305、RFC 9180 `mode_base` 準拠の HKDF-SHA256）。暗号化は TMPX を発する Identity Match サービスが必要とし、復号は `decodeTmpx` を呼ぶインプレッショントラッカーが必要とします。

同じサーフェスが `@adcp/client`（TS）、`adcp-go`、`adcp`（Python）で出荷されます。

> **プリミティブ名は説明的です。** `decodeTmpx`、`writeExposure`、`upsertPackage`、`upsertFcapPolicy`、`inspectExposures` は SDK サーフェスの形状を記述します。正準署名は対応する SDK RFC とともに着地し、命名や引数順で異なる場合があります。このセクションを API コントラクトとしてではなく、インプレッショントラッカーの分解として扱ってください。

## 本番トポロジーパターン

典型的な Scope3 スタイルのデプロイ:

```
publisher pixel fires {TMPX} → tracking endpoint
                                      │
                          decodeTmpx (synchronous, at intake)
                                      │
                                      ▼
                              pub/sub topic
                                      │
                          frequency_writer worker
                                      │
                          writeExposure (asynchronous)
                                      │
                                      ▼
                              valkey (exposure log)
                                      │
                          if cap fired → RecordCap to
                                         Identity Match cap-state store
```

取り込み時にデコード。バッファリングのため pub/sub に発する。下流のワーカーが露出ログを書きキャップ発火イベントを発する。バッファリング、リトライ、重複排除、可観測性、悪用防止はキュー層に存在 — そのどれも SDK の仕事ではありません。よりシンプルな同期パイプライン（同じハンドラーでの decode + write）も低ボリュームデプロイに有効です。

## 適合性シナリオ

これらはインプレッショントラッカーの動作をエンドツーエンドで説明します。それらはバイヤー内部のメカニクスです。ワイヤー上の観測可能なものは、Identity Match キャップ状態ストアに着地するキャップ発火エントリで、後の `identity_match_request` 呼び出しで適格性決定としてサーフェスします。

両シナリオのセットアップ: `seller-a.example` の `package = "pkg-42"`、`fcap_keys: ["campaign:42"]`、`policy campaign:42 = {window: {interval: 1, unit: "days"}, max_impression_count: 5}`。

### シナリオ A — マルチアイデンティティ重複排除

ユーザーはインプレッションストリームにわたって 2 つの解決されたアイデンティティを持ちます: `rampid:abc` と `id5:def`。アイデンティティ解決はトグルします — ほとんどのインプレッションは両方を解決するが、1 つは rampid のみを解決します。

**imp-001、imp-002、imp-003** — TMPX が両方のアイデンティティを解決。各インプレッションが同じ `impression_id` を両方のログに書き込む:

```
user:exposures:<hash(rampid:abc)> = [ imp-001, imp-002, imp-003 ]
user:exposures:<hash(id5:def)>    = [ imp-001, imp-002, imp-003 ]
```

**imp-004** — TMPX が rampid のみを解決（id5 ルックアップ失敗）。imp-004 は rampid のログのみに書き込まれる:

```
user:exposures:<hash(rampid:abc)> = [ imp-001..imp-004 ]
user:exposures:<hash(id5:def)>    = [ imp-001..imp-003 ]    unchanged
```

**imp-005** — TMPX が再び両方のアイデンティティを解決。imp-005 は両方のログに書き込まれる。インプレッショントラッカーは次に両方の解決されたアイデンティティログを読んでキャップを評価する:

```
rampid:abc log: { imp-001, imp-002, imp-003, imp-004, imp-005 }   = 5 entries
id5:def log:    { imp-001, imp-002, imp-003,           imp-005 }   = 4 entries
```

ログをまたいでエントリを union し、`impression_id` で重複排除:

```
{ imp-001, imp-002, imp-003, imp-004, imp-005 } = 5 distinct impressions
```

5 = `max_impression_count` → キャップがちょうど使い果たされた。imp-005 で両方のアイデンティティが解決されているため、インプレッショントラッカーは両方のキャップ発火エントリを発する:

```
RecordCap(rampid:abc, [{seller-a.example, pkg-42}], expire_at)
RecordCap(id5:def,    [{seller-a.example, pkg-42}], expire_at)
```

2 つのことが実証されます:

* **重複排除が重要。** アイデンティティごとのカウントを素朴に合計すると `5 + 4 = 9` — `max_impression_count` を大幅に超える。`impression_id` による重複排除が正しいカウント 5 を復元する。
* **アイデンティティ解決の安定性は不要。** imp-004 は id5 のログエントリを完全に逃した。両方のアイデンティティが次に一緒に解決されたとき、評価時の重複排除が依然として正しい答えを生成する。

MAX merge\_rule を持つカウンターベースのトラッカーは、ここでカウンター `max(rampid=5, id5=4) = 5` を見る — この時点では偶然正しいが、それは分岐がたまたま単一の逃した書き込みだったからにすぎない。2 番目の id5 を逃したインプレッション（imp-006 スタイル）は rampid を 6 に押し上げ id5 を 5 に残す。MAX は依然として 5 と言い 1 つ過剰提供する。SUM（= ここで 9）は反対方向に過剰カウントする。ログ + `impression_id` 重複排除は構成上正しい。

実装者のためにフラグを立てる帰結: 将来のクエリが id5:def のみを解決する場合、キャップ状態ルックアップは imp-005 で書き込まれた id5:def エントリにヒットし、ユーザーは正しく抑制される。将来のクエリでどちらのアイデンティティも解決されない場合、キャップ状態ルックアップは全く起こらない — それは fcap の上流のアイデンティティ解決問題であり、fcap の正しさの問題ではない。

### シナリオ B — クロスセラー広告主キャップ

異なるセラーの 2 つのパッケージ、両方が同じ広告主レベルのラベルにマップ:

```
package:identity:pkg-A = { fcap_keys: ["advertiser:13"], active: true }   // seller-a
package:identity:pkg-B = { fcap_keys: ["advertiser:13"], active: true }   // seller-b
fcap_policy:advertiser:13 = { window: {interval: 1, unit: "days"}, max_impression_count: 10 }
```

`seller-a` からの `pkg-A` の 10 インプレッション。各露出エントリの `fcap_keys` は `advertiser:13` を含む。10 番目の書き込みで、`advertiser:13` の重複排除されたカウントが `max_impression_count` に一致する。インプレッショントラッカーは、**すべてのセラーにわたって `advertiser:13` にマップするすべてのパッケージ** について、すべての解決されたアイデンティティに対してキャップ発火エントリを発する:

```
RecordCap(<identity>, [
  {seller-a.example, pkg-A},
  {seller-b.example, pkg-B},
], expire_at)
```

`pkg-B` の `seller-b` からの後続の `identity_match_request` は、キャップ状態エントリが存在するため `eligible_package_ids: []` を返す。`fcap_key` が共有されているため、広告主レベルのキャップはセラーをまたいで強制する。IdentityMatch サービスでクロスセラー協調は不要 — バイヤーエージェントのインプレッショントラッカーが単一の真実の源泉で、キャップ状態ストアが公開チャネル。

## パフォーマンスリファレンス

下の数字は [`targeting/scale_test.go`](https://github.com/adcontextprotocol/adcp-go/blob/main/targeting/scale_test.go) からの、インメモリモックストアに対する単一 goroutine のものです。CPU をネットワークから分離しています。それらは **インプレッショントラッカーの** 評価コスト — ログをスキャンしこのインプレッションがちょうどキャップを発火したかを決めるコスト — を記述します。Identity Match サービスのクエリ時コストは、別個のはるかに小さいキャップ状態存在チェックです。

**書き込み時の eval ごと、ログサイズ変動、単一アイデンティティ、単一 fcap\_key:**

| Prior exposures in user's log | Eval latency |
| ----------------------------- | ------------ |
| 0                             | 368 ns       |
| 100                           | 5.3 µs       |
| 1,000                         | 53 µs        |
| 10,000                        | 118 µs       |

バイナリ lazy 重複排除を伴う線形スキャン。10K エントリでミリ秒未満。

**結合負荷（マルチアイデンティティ、マルチパッケージ eval）、すべての次元変動:**

| packages mapped via fcap\_keys | log entries / id | identities | CPU/eval                                 |
| ------------------------------ | ---------------- | ---------- | ---------------------------------------- |
| 100                            | 1,000            | 3          | 1.0 ms                                   |
| 1,000                          | 1,000            | 3          | 7.5 ms ← realistic Scope3-shape load     |
| 1,000                          | 10,000           | 3          | 58 ms  ← pathological tail (heavy users) |

CPU は `packages × log_entries × identities` でスケールします。病理的な裾野は [adcp-go#103](https://github.com/adcontextprotocol/adcp-go/pull/103) のアルゴリズム最適化（ヒューリスティックゲートのプレフィルターバケット。小さいリクエストでの回帰を避けるため `numPackages > 50` でゲート）で対処されます:

| packages | log entries | identities |    Before |    After | Speedup |
| -------- | ----------: | ---------: | --------: | -------: | ------: |
| 1,000    |         100 |          3 |    784 µs |    71 µs |   11.0× |
| 1,000    |       1,000 |          3 |  7,566 µs |   287 µs |   26.4× |
| 1,000    |      10,000 |          3 | 57,861 µs | 1,500 µs |   \~38× |

本番のサイジングは、valkey ラウンドトリップレイテンシー、負荷下の裾野の動作、ヘビーユーザーのインプレッション分布形状にも依存します。モックストア CPU は下限であり、本番の数字ではありません。

## 関連項目

* [フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) — このページが背後に位置するキャップ発火境界コントラクト
* [TMP 仕様](/docs/trusted-match/specification) — ワイヤー仕様、適合性不変条件
* [`adcp-go/targeting`](https://github.com/adcontextprotocol/adcp-go/tree/main/targeting) — このページのモデルのリファレンス Go 実装
* [`adcp-go/targeting/fcap`](https://github.com/adcontextprotocol/adcp-go/tree/main/targeting/fcap) — 境界の反対側のリファレンスキャップ状態ストア