TC stringとは実際に何か

IAB Transparency & Consent Frameworkは、単一のコンパクトなトークン — TC string — を生成します。これはすべての広告リクエストとともに移動し、ユーザーが何に同意し何に同意していないかをベンダーに正確に伝えます。Base64-URLでエンコードされ、ビットレベルでパックされているため、意味不明に見えますが（CPxy...AAA）、正確で監査可能な記録をエンコードしています。

セグメント

完全なTC stringは、ドットで区切られた複数のセグメントです。最初のものはコア文字列で、他はオプションです：

• コア — CMP ID、CMPバージョン、同意のタイムスタンプ、ポリシーバージョン、そして決定的に重要な目的の同意とベンダーの同意のビットフィールド。
• 開示されたベンダー — どのベンダーがユーザーに表示されたか。
• Publisher TC — あなた、パブリッシャーに固有の同意。

ビットフィールドがその核心です。ビットNが1に設定されていれば、目的NまたはベンダーNへの同意を意味します。目的1は“デバイス上の情報を保存/アクセスする”、目的3と4はパーソナライズ広告をカバーし、以下同様です。

実際にデコードする

ビットを手作業でデコードすることはめったにありません。IABが提供するライブラリか公開デコーダを使用してください：

• .で分割し、コアセグメントをBase64-URLデコードします。
• 固定幅のヘッダーフィールドを読み取ります（version、created、lastUpdated、cmpId、cmpVersion）。
• 目的とベンダーのビットフィールドをたどり、どれが許可されているかを正確に確認します。

JavaScriptでは__tcfapi('getTCData', 2, cb)呼び出しが既にパース済みのオブジェクトを返します — tcData.purpose.consentsとtcData.vendor.consentsはid → booleanのマップです。これがランタイムでのあなたの基準となる真実です。

収益を殺すエラー

パーソナライズされた需要が静かに消えるとき、通常はTC stringが原因です：

• 文字列の欠落 — 広告リクエストがgdprApplies/TC stringを運んでいないため、準拠SSPは非パーソナライズに落ちます。
• ベンダーが未同意 — あなたの需要パートナーのベンダーIDビットが0なので、パーソナライズで入札できません。
• 期限切れまたは古い文字列 — 古いタイムスタンプは下流プラットフォームに不信感を抱かせます。
• 誤ったCMP ID — 未登録またはテスト用のCMP IDは文字列全体を無効にします。

デバッグのワークフロー

ユーザーの同意を再現し、__tcfapiまたは広告リクエストからライブのTC stringを取得し、バリデータにかけて、デコードされた目的/ベンダーをパートナーが要求するものと比較します。10回中9回、ギャップは単一のベンダービットか欠落した目的1です。

FlexyConsentの位置づけ

FlexyConsentは、登録済みのCMP IDで仕様に準拠したTC stringを生成し、それらを新鮮に保ち、デバッグ用にデコードされた状態を公開し、トラフィック全体でどの目的とベンダーが実際に許可されているかを報告します — これにより、同意（と収益）がどこで漏れているかを推測ではなく確認できます。

主なポイント

• TC stringは、すべての同意選択のビットパックされた監査可能な記録です。
• 目的とベンダーのビットフィールドが、パートナーがパーソナライズ広告を配信できるかどうかを決定します。
• ほとんどの収益低下は、文字列の欠落、未同意のベンダー、または古い/無効なCMP IDに起因します。
• デバッグ時は__tcfapiでライブ文字列をデコードし、パートナー要件と照合して検証してください。