CTV Device Identity Landscape: Rescoped IAB ifa_typePersonas, Limit Ad Tracking, and Household Graphs

When a Server-Side Ad Insertion (SSAI) stitcher constructs an OpenRTB 2.6 bid request for a Connected TV (CTV) ad pod, an omitted device.ifa string or a misclassified device.ext.ifa_type attribute immediately triggers bid shading or hard floor rejections across tier-1 DSPs that require deterministic cross-screen frequency capping. Unlike desktop or mobile web environments that historically leaned on third-party browser cookies, CTV monetization operates across a fragmented constellation of proprietary living-room operating systems, each governing its own hardware-level Identifier for Advertising (IFA), privacy opt-out flag, and application sandboxing rules. For ad engineering and yield operations teams, maintaining high bid density requires translating these disparate device signals into standardized OpenRTB objects without leaking sensitive user data or triggering Invalid Traffic (IVT) filters.

The technical complexity of CTV identity intensifies at the intersection of hardware telemetry and server-side proxy architecture. Because video streams are stitched in the cloud to prevent buffering between content segments and ad creatives, the SSAI layer acts as a middleman that must extract client-side device parameters during session initialization and forward them cleanly in outbound bid requests. If the stitcher fails to distinguish between a persistent hardware identifier, a publisher-scoped login hash, and an ephemeral session token, downstream buyers cannot accurately price the impression.

At Sky Boosts, our engineering infrastructure validates and normalizes CTV identity signals across OpenRTB 2.6 and VAST 4.3 workflows to protect both buyer return on ad spend and publisher yield. By enforcing strict schema compliance, integrating HUMAN and Pixalate pre-bid IVT filtering, and monetizing 100% Google-friendly mainstream inventory, we help publishers eliminate bidstream signal loss and secure reliable Net-30 and Net-60 payouts.

The Fragmented Ecosystem of Connected TV Operating Systems (Roku, Tizen, Fire TV, webOS, tvOS)

Connected TV hardware lacks a unified runtime environment. While mobile monetization consolidated around iOS and Android over a decade ago, the living room remains split across at least five major operating system families, alongside dozens of regional Android TV Operator Tier forks and white-label hospitality displays. Each platform exposes a proprietary SDK method for retrieving the local advertising identifier and checking the user's privacy preference.

On Roku OS, applications written in BrightScript interact with the Roku Advertising Framework (RAF) or query the roDeviceInfo component directly. Calling CreateObject("roDeviceInfo").GetRIDA() returns the Roku ID for Advertising (RIDA), a version-4 UUID that persists across all channels installed on that physical unit until the viewer triggers a manual reset in system settings. Developers must simultaneously evaluate IsRIDADisabled(), which returns a boolean indicating whether the viewer has enabled Limit Ad Tracking.

Samsung Smart TVs run on Tizen OS, a Linux-based platform where applications are predominantly built using HTML5, JavaScript, and WebAssembly wrapped in Tizen packages. To access device identity, the client application invokes the Tizen AdInfo API via webapis.adinfo.getTIFA() to retrieve the Tizen Identifier for Advertising (TIFA) and webapis.adinfo.isLAT() to inspect the opt-out state. If the application fails to declare the http://tizen.org/privilege/adinfo privilege in its config.xml manifest, the API throws a security exception and the player initializes without a hardware ID.

Amazon Fire TV runs Fire OS, a derivative of the Android Open Source Project (AOSP). Fire TV apps retrieve the Fire Advertising ID (often referenced historically as AFAI) by querying Settings.Secure.getString(getContentResolver(), "advertising_id") alongside the integer flag limit_ad_tracking. Meanwhile, LG Smart TVs running webOS rely on the asynchronous Luna Service Bus, requiring the video player to issue a service call to luna://com.webos.service.admanager/getAdId to obtain the LG UDID (lgudid) and its associated tracking preference.

Apple tvOS enforces the most restrictive identity posture in the CTV market. Governed by Apple's App Tracking Transparency (ATT) framework via ATTrackingManager, tvOS applications must present an explicit system prompt before accessing ASIdentifierManager.shared().advertisingIdentifier (IDFA). Because living-room viewers overwhelmingly decline the ATT prompt using their television remotes, deterministic IDFA availability on tvOS routinely hovers below 18%. When a user denies permission, the OS returns a zeroed-out string (00000000-0000-0000-0000-000000000000), forcing publishers to rely on Apple's identifierForVendor (IDFV), which is scoped strictly to applications published under the same Apple Developer account.

Managing these five distinct retrieval patterns across client-side codebases creates substantial maintenance overhead for streaming providers. Integrating standardized TV platform SDKs, alongside the Google Programmatic Access Library (PAL) SDK or IMA SDK, abstracts these OS-level API calls so the video player can package normalized telemetry into the initial VAST ad tag or SSAI session-creation payload.

The 2023+ IAB Tech Lab Update to device.ext.ifa_type

When the IAB Tech Lab published its original OTT IFA guidelines in 2018, the specification instructed supply-side platforms and publishers to populate the OpenRTB device.ext.ifa_type field with a commercial string identifying the underlying operating system or OEM ID format, such as rida, tifa, afai, idfa, or lgudid. In production, this taxonomy quickly broke down. As dozens of new smart TV manufacturers, cable set-top boxes, and gaming consoles entered the programmatic ecosystem, maintaining an exhaustive static registry of commercial OS names inside ifa_type proved untenable. Furthermore, the legacy approach duplicated data that was already explicitly present in standard OpenRTB fields like device.os, device.make, and device.model.

To resolve this architectural flaw, the IAB Tech Lab ratified a major update to the OTT IFA guidelines that fundamentally rescoped device.ext.ifa_type. Rather than repeating the commercial name of the operating system, the updated specification defines ifa_type according to the persona or originating entity in the programmatic supply chain that generated the identifier, coupled with whether that identifier is persistent or session-based. Hardware vendor and operating system classification are now read strictly from the parent device object, while device.ext.ifa_type informs the DSP's identity parser of the exact provenance and persistence guarantees of the UUID inside device.ifa.

Why IAB Replaced Commercial OS Lists with Persona-Based Origin Types (Device vs. Publisher vs. SSP/SSAI)

Before the persona-based rescoping, a widespread anti-pattern degraded CTV identity graphs across the programmatic ecosystem. Whenever a client application failed to retrieve a hardware ID (due to a missing Tizen manifest privilege, an uninitialized SDK, or an Apple tvOS ATT opt-out), either the publisher's player or the SSAI stitcher would synthesize a random UUID to prevent downstream DSPs from dropping the bid request. However, the SSAI layer would still label that synthetic fallback string with ifa_type: "rida" or ifa_type: "idfa".

For buy-side identity algorithms, this practice caused severe graph corruption. DSPs ingested transient, app-specific, or session-scoped fallback UUIDs believing they were persistent cross-app hardware identifiers. As a result, household identity graphs splintered, frequency caps failed to hold across different apps on the same television, and audience targeting models paid premium CPMs for unverified ephemeral IDs.

The updated IAB Tech Lab specification eliminates this ambiguity by establishing six distinct persona values for device.ext.ifa_type, categorized along two axes: the generating entity (Device Platform, Publisher, or SSP/SSAI) and the persistence window (Persistent vs. Session):

• dpid (Device Platform ID): A persistent identifier generated and maintained by the physical device hardware or operating system (such as a genuine RIDA, TIFA, or Fire Advertising ID). It remains constant across all applications installed on the TV until reset by the consumer.
• ppid (Publisher Provided ID): A persistent identifier generated by the CTV publisher or application developer. This includes Apple's IDFV on tvOS as well as deterministic subscriber UUIDs assigned by an authenticated streaming app across a user's logged-in sessions.
• sspid (SSP or SSAI Platform ID): A persistent or semi-persistent identifier synthesized by the supply-side platform, ad server, or SSAI vendor using network and device heuristics when neither a dpid nor a ppid is present.
• dpsid (Device Platform Session ID): A temporary, session-scoped identifier generated by the operating system specifically for a single viewing session or a maximum 24-hour window.
• ppsid (Publisher Provided Session ID): An ephemeral identifier generated by the publisher's video player when a viewer opens the app, expiring immediately upon app closure or within 24 hours.
• sspsid (SSP or SSAI Session ID): An ephemeral identifier generated by the SSAI stitcher or SSP at the start of a stream playback session to support within-stream pod deduplication and competitive separation when no persistent ID is permitted.

By pairing device.make and device.os with the rescoped device.ext.ifa_type, an OpenRTB 2.6 bid request communicates complete transparency to the buyer, as shown in the following production payload for a Samsung Tizen device:

{
  "id": "80ce30c53c16e",
  "imp": [
    {
      "id": "1",
      "video": {
        "mimes": ["video/mp4"],
        "minduration": 15,
        "maxduration": 30,
        "protocols": [7, 8, 11, 12],
        "w": 1920,
        "h": 1080,
        "placement": 1,
        "plcmt": 1,
        "linearity": 1,
        "minbitrate": 1500,
        "maxbitrate": 15000
      },
      "bidfloor": 14.50,
      "bidfloorcur": "USD"
    }
  ],
  "app": {
    "id": "10492",
    "name": "Apex Stream News",
    "bundle": "G19283746552",
    "storeurl": "https://www.samsung.com/us/appstore/app/G19283746552",
    "publisher": {
      "id": "pub-9941",
      "name": "Apex Broadcasting Corp"
    }
  },
  "device": {
    "ua": "Mozilla/5.0 (SMART-TV; LINUX; Tizen 7.0) AppleWebKit/537.36 (KHTML, like Gecko) 94.0.4606.31/7.0 TV Safari/537.36",
    "ip": "172.56.21.89",
    "make": "Samsung",
    "model": "QN65S95BAFXZA",
    "os": "Tizen",
    "osv": "7.0",
    "devicetype": 3,
    "ifa": "7a9b8c1d-2e3f-4a5b-8c9d-0e1f2a3b4c5d",
    "lmt": 0,
    "ext": {
      "ifa_type": "dpid",
      "atts": 0
    }
  },
  "regs": {
    "coppa": 0,
    "gpp": "DBABLA~BVQqAAAACgA.QA",
    "gpp_sid": [7]
  }
}

Session IDs When Limit Ad Tracking (device.lmt=1) Is Enabled

When a consumer enables Limit Ad Tracking in their TV privacy menu (device.lmt: 1) or opts out via state privacy signals carried in the IAB Global Privacy Platform string (regs.gpp), programmatic platforms are prohibited from using the device's hardware identifier for cross-context behavioral profiling or long-term audience retargeting. On platforms like tvOS and newer versions of Roku OS and Fire OS, the operating system enforces this at the API layer by returning an all-zero UUID (00000000-0000-0000-0000-000000000000) when lmt is active.

However, transmitting an all-zero string or omitting device.ifa entirely breaks critical, privacy-safe ad serving mechanics during a CTV broadcast. A two-hour live sports stream or feature film typically contains six to eight commercial breaks, each structured as a multi-slot ad pod lasting 90 to 120 seconds. Without a session correlation key, the ad server and participating DSPs cannot enforce within-session frequency capping or competitive separation. Viewers who opt out of behavioral tracking do not expect to see the exact same 30-second insurance commercial repeated four times inside a single two-minute ad break.

The IAB Tech Lab persona framework solves this operational impasse through explicit session identifiers (ppsid and sspsid). When our CTV monetization platform ingests an ad request where device.lmt is set to 1 and the hardware ID is zeroed out, the normalization engine strips the all-zero string so it never pollutes downstream bid evaluation. Instead, if the publisher player has generated an ephemeral viewing token, we pass that UUID in device.ifa with device.ext.ifa_type: "ppsid" while strictly preserving device.lmt: 1.

This combination of lmt: 1 and ifa_type: "ppsid" (or "sspsid") acts as a cryptographically clear contract with tier-1 DSPs: the buyer's bidder is permitted to cache the identifier in short-term memory for 15 to 120 minutes to pace frequency across consecutive ad pods within the active movie or broadcast, but must immediately purge the UUID afterward and never link it to a persistent household graph.

CTV Household IP Co-Viewing Challenges and CGNAT Collisions

Because Connected TVs are fixed, shared appliances wired into residential routers, programmatic buyers have long relied on the public IP address (device.ip and device.ipv6) as the foundational spine of the household identity graph. By clustering the CTV device's IP address with mobile phones, tablets, and laptops observed on the same residential Wi-Fi network, cross-device identity providers link living-room video exposures to downstream web conversions and mobile app installs.

In modern network engineering, relying on IPv4 addresses as a deterministic proxy for a single physical household introduces two severe failure modes: Carrier-Grade Network Address Translation (CGNAT) and multi-screen co-viewing collisions.

First, the rapid expansion of 5G Fixed Wireless Access (FWA) home internet (offered by major cellular carriers) and low-Earth-orbit satellite broadband has placed millions of streaming households behind CGNAT gateways. Under CGNAT architecture, an internet service provider shares a single public IPv4 address across dozens or even hundreds of distinct residential subscribers simultaneously, rotating port assignments dynamically. When an SSP or DSP relies solely on device.ip for household resolution or frequency capping:

1. Neighborhood Frequency Cap Bleed: If Household A watches four ad pods on a shared CGNAT IPv4 address, DSPs capping frequency by IP will stop bidding on impressions originating from Household B and Household C on the same cellular tower, artificially depressing publisher fill rates and clearing prices.
2. False-Positive IVT Filtering: Pre-bid anti-fraud scanners monitor request velocity per IPv4 address to detect data-center botnets and spoofed CTV servers. When 300 legitimate living-room TVs behind a 5G FWA gateway stream a high-concurrency live football broadcast simultaneously, naive IP thresholds flag the traffic as automated volumetric fraud unless the bid request includes verified dpid hardware identifiers, accurate IPv6 /64 prefixes, and clean SSAI forwarding headers.

Second, even on dedicated fiber or cable connections with a static residential IP, a single household frequently operates three to four smart TVs across different rooms alongside multiple personal devices. Without granular device.ifa and device.ext.ifa_type disambiguation, simultaneous streams from a living-room LG webOS panel and a bedroom Roku stick collapse into a single undifferentiated IP profile.

To insulate publishers from CGNAT penalties and IP collisions, our CTV publisher solutions enforce dual-stack IPv4/IPv6 telemetry extraction and strict SSAI header verification. When an SSAI stitcher fetches VAST payloads or initiates OpenRTB auctions from cloud data centers, it must pass the viewer's true client IP in device.ip (and device.ipv6 where available) while declaring the stitcher's own server IP via standard HTTP forwarding headers (X-Forwarded-For and X-Device-IP). Preserving the client's /64 IPv6 prefix alongside a persistent dpid or ppid allows HUMAN and Pixalate verification engines to distinguish legitimate CGNAT consumer clusters from server-side spoofing.

Passing Publisher First-Party Login Hashes and PAIR Clean Room IDs in Authenticated CTV Apps

As hardware ID availability fluctuates across tvOS and privacy-restricted environments, authenticated CTV publishers (including SVOD ad-supported tiers, MVPD apps, and registration-gated AVOD services) possess a major structural advantage: deterministic first-party login data. When a viewer activates a CTV app by scanning an on-screen QR code on their smartphone, the publisher authenticates the user's email address or phone number against a unified subscriber database.

Rather than confining that identity signal to proprietary direct-sold campaigns, publishers can activate their first-party data across programmatic auctions using two complementary mechanisms: the OpenRTB user.ext.eids array and Google Ad Manager's Publisher Provided Identifier (PPID) combined with the IAB Tech Lab's Publisher Advertiser Identity Reconciliation (PAIR) protocol.

When a user logs in, the publisher's backend normalizes the email address (trimming whitespace and converting characters to lowercase), applies SHA-256 hashing, and exchanges that hash with interoperable identity services such as Unified ID 2.0 (UID2), LiveRamp RampID, ID5, and Google PAIR. Unlike universal IDs that rely on shared cross-publisher lookup tables, PAIR (pair-protocol.com) operates via clean rooms using three-stage commutative encryption. Both the publisher and the advertiser independently encrypt their first-party customer lists using their own private keys plus a shared clean-room key, producing cryptographic PAIR IDs that can only be matched for that specific publisher-advertiser pair. Raw SHA-256 hashes never enter the open bidstream, preventing unauthorized harvesting or cross-site tracking.

The following OpenRTB 2.6 JSON snippet illustrates how an authenticated CTV application passes both an encrypted Google PAIR array and a publisher first-party ID (ppid) inside a single bid request when hardware tracking is restricted (device.lmt: 1):

{
  "device": {
    "ua": "AppleTV14,1/17.4",
    "ip": "98.42.118.204",
    "ipv6": "2601:647:5800:1a20::1",
    "make": "Apple",
    "model": "AppleTV14,1",
    "os": "tvOS",
    "osv": "17.4",
    "devicetype": 3,
    "ifa": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
    "lmt": 1,
    "ext": {
      "ifa_type": "ppid",
      "atts": 2
    }
  },
  "user": {
    "ext": {
      "eids": [
        {
          "source": "pair-protocol.com",
          "uids": [
            {
              "id": "AQEBAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f",
              "atype": 3
            },
            {
              "id": "BwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYn",
              "atype": 3
            }
          ]
        },
        {
          "source": "uidapi.com",
          "uids": [
            {
              "id": "AgAAAAN678901234567890abcdef1234567890abcdef",
              "atype": 3,
              "ext": {
                "provider": "apexstream.tv"
              }
            }
          ]
        }
      ]
    }
  }
}

In parallel with OpenRTB eids, publishers monetizing through Google Ad Manager 360 (GAM 360) and AdX should populate the ppid parameter inside the Google PAL SDK NonceRequest object on the client device. The PAL SDK encrypts the publisher's subscriber identifier junto with device integrity signals into a cryptographic nonce (paln), which the SSAI stitcher appends to the GAM ad tag. This enables GAM 360 and Open Bidding partners to enforce cross-device frequency management and audience segment matching even when device.lmt equals 1 on tvOS.

For engineering and AdOps teams auditing their CTV supply paths today, three concrete execution steps separate high-yielding inventory from discounted remnant traffic:

1. Migrate Legacy ifa_type Mappings: Audit your SSAI stitcher and Prebid Server adapters immediately to retire static OS tokens (rida, tifa, afai, idfa) inside device.ext.ifa_type. Map authentic hardware IDs to "dpid", logged-in publisher UUIDs or tvOS IDFVs to "ppid", and opt-out fallback tokens strictly to "ppsid" or "sspsid".
2. Enforce Zero-UUID Scrubbing on lmt=1: Configure your ad router to detect all-zero UUID strings (00000000-0000-0000-0000-000000000000) and replace them with compliant, short-lived session identifiers (ppsid or sspsid) so buyers can execute within-pod competitive separation without violating consumer privacy choices.
3. Activate Dual-Stack IP and Authenticated eids: Ensure your SSAI proxy preserves both client IPv4 and /64 IPv6 addresses to mitigate 5G FWA CGNAT collisions, and pipe QR-code login hashes into user.ext.eids and Google PAL SDK nonces to capture premium audience budgets across authenticated streams.