Skip to content

A device module cannot say how sure it is that a person is there, nor what the device is #1286

Open

Description

@jwrosewell

The problem

A device module answers one question, whether the request looks like a browser, and the Edge Cookie gate reads the answer. A module that reaches a detection service knows far more, including how confident it is that a person is looking at the page and what the device is, and a bidder prices inventory on the device it is told about. Core has no place for either answer, so a module's knowledge stops at the gate and a bid request leaves without the device.

The change

DeviceSignals gains human_confidence, one of High, Medium, Low and Unknown. A module that scores the request writes it and every other module leaves it Unknown, which is kept apart from Low because a request alone cannot establish a person, so a first-time visitor is never called a machine. Nothing reads it yet, and it is not stored in the identity graph with the other signals. Redirect middlewares that treat Low, Medium and High differently follow once this set of changes has landed, and are kept out of it so the set does not grow.

DeviceAttributes is what a bidder is told about the device, being the OpenRTB device type, make, model, operating system and version, and screen size, every field optional because every source is partial. DeviceModule::advertising_attributes answers it from the same module call detect is handed, with a default of nothing so no existing module changes. After each auction request is built, core asks the selected module and puts the answer on the request's device object, which the OpenRTB request carries, each field absent where nothing resolved it. A module that resolves nothing adds no device object, because an absent object and an empty one say the same to a bidder and the absent one is smaller, and a device type name the mapping does not know maps to nothing, because a wrong type is worse for a bidder than an absent one. The consent-denied path, which makes no outbound call, asks no module.

The attributes stay apart from the signals. The signals answer whether the request looks like a browser and are stored in the identity graph. The attributes answer what a bidder prices and are stored nowhere.

The seam probe's device module scores the request and answers fixed attributes, so the Axum adapter proves both answers reach core from a module it does not know.

Where it is

Draft on the fork, jwrosewell#23, on top of the prefix module (fork pull request 22).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions